Внешний CTO для бизнеса, который внедряет ИИ

Руководитель разработки может отвечать за выпуск продукта, а компания при этом останется без защиты от рисков ИИ. Ответственность за разработку означает, что работа выходит вовремя, а система работает стабильно. Ответственность за риски ИИ определяет, кто и какие данные может отправлять модели, что агент вправе менять без согласования, как компания отменит неудачное действие и сколько система может потратить до остановки.

Большинству малых и средних компаний для таких решений не нужен штатный топ-менеджер. Но им нужен один назначенный технический руководитель с полномочиями, которые охватывают разработку, безопасность, финансы, юридические вопросы и операционную работу. Внешний CTO часто подходит лучше всего, если у руководителя разработки нет такого общеорганизационного мандата или опыта создания правил. Название должности менее важно, чем право принимать решения, но оставлять эту роль неформальной опасно.

Ответственность за разработку заканчивается у границы модели

Руководитель разработки должен и дальше отвечать за выпуск продукта, но эти полномочия не распространяются автоматически на риски ИИ для всей компании. Он может выбирать, как команда оценивает задачи, проверяет код, выпускает релизы и исправляет обычные дефекты. Когда модель получает данные клиентов, действует с производственными учетными данными или создает переменные расходы на внешнего поставщика, решение уже затрагивает несколько подразделений.

Возьмем агента для программирования, подключенного к репозиторию. На первый взгляд это еще один инструмент разработчика. На деле кто-то должен решить, может ли агент читать закрытые репозитории, комментарии в трекере задач, переписку поддержки, файлы окружения и производственные журналы. Кто-то также определяет, вправе ли он открыть запрос на слияние, выполнить слияние, запустить миграцию базы данных, изменить инфраструктуру или обратиться к внешнему сервису. Это решения о политике компании с техническими последствиями, а не решения о текущем спринте.

Различие важно, потому что локальная оптимизация создает риск для всей компании. Руководитель разработки может разрешить широкий доступ модели, чтобы экономить команде шесть часов в неделю. Специалист по безопасности возразит, потому что в запросы попадают секреты. Финансовый директор заметит неограниченный счет за вычисления только после того, как зацикленный агент потратит деньги. Юристы могут поздно узнать, что текст клиента ушел за пределы согласованного контура обработки. Каждый видит свою часть, а за общий выбор не отвечает никто.

Фреймворк управления рисками ИИ NIST размещает управление на уровне всей организации, а не внутри команды, которая работает с моделью. Его функции Govern, Map, Measure и Manage полезны тем, что требуют связать контекст, оценку и реакцию. Для малого и среднего бизнеса вывод практический: один человек должен иметь право разрешать компромиссы, которые ни одно подразделение не может разрешить самостоятельно.

Оставьте выпуск продукта за руководителем разработки. Назначьте для рисков ИИ владельца, в чью зону ответственности входят данные, полномочия агента, восстановление, расходы и выбор поставщика. Обе роли может выполнять один человек, но компания должна отдельно записать каждый набор обязанностей.

Компании нужен один ответственный за риски ИИ

Компании нужен один владелец рисков ИИ, даже если его консультируют несколько специалистов. Комитет может рассматривать решения, но комитет нельзя вызвать, когда агент удаляет записи в два часа ночи. Коллективное обсуждение полезно, а коллективная ответственность обычно означает, что последнее слово не принадлежит никому.

Владелец должен иметь явные полномочия:

• разрешать или запрещать доступ к моделям и поставщикам;
• задавать уровень автономности для каждого сценария;
• требовать проверки отката до выдачи производственного доступа;
• устанавливать лимиты расходов и порядок эскалации;
• останавливать процесс с ИИ, не дожидаясь очередного совещания руководства.

Генеральный директор должен назначить этого человека письменно. Достаточно положения на одной странице. В нем нужно перечислить системы в зоне ответственности, подконтрольные решения, обязательных участников согласования, исключения, для которых требуется одобрение генерального директора, и частоту пересмотра. Документ также должен прямо говорить, что срок выпуска продукта не отменяет решение об остановке.

Внешний CTO подходит, когда компании нужны решения руководителя несколько дней в месяц, а не ежедневное управление людьми. Такой руководитель создает систему контроля, разрешает споры между подразделениями, рассматривает исключения с серьезными последствиями и учит руководителя разработки работать по новым правилам. Руководитель разработки по-прежнему управляет командой и применяет эти правила в обычной работе.

Не нанимайте внешнего CTO только ради более высокого начальника над действующим руководителем. Он нужен при нехватке полномочий или опыта. Если руководитель разработки уже отвечает за архитектуру, безопасность, риски поставщиков, бюджеты, инциденты и компромиссы на уровне руководства, выдайте ему мандат владельца рисков ИИ и спрашивайте результат. Еще одна должность лишь замедлит решения.

Владельцу также нужен прямой доступ к генеральному директору. Если отдел продаж может обещать клиентам функцию с ИИ, финансовый директор может сократить расходы на защиту, а основатель может открыть поставщику доступ без участия владельца, роль существует только на бумаге. Проверка проста: может ли этот человек остановить запуск, который укладывается в срок, но провалил проверку отката? Если нет, риском по-настоящему не владеет никто.

Выбор поставщика должен находиться у того же владельца. Закупки могут обсуждать условия, безопасность может проверять средства защиты, а инженеры могут оценивать качество ответа, но кто-то должен решить, приемлема ли услуга целиком для конкретного сценария. Решение должно учитывать субподрядчиков, хранение данных, управление учетными записями, уведомление об инцидентах, изменения модели, выгрузку данных и судьбу корпоративной информации после прекращения договора. Хорошие результаты теста не исправят условия договора, которые противоречат политике работы с данными.

Владелец должен определить и порядок исключений. Сотрудники столкнутся с обоснованными случаями, которых первоначальная политика не предусматривала, а правило без удобного пути для исключений подталкивает к скрытым обходам. В запросе на исключение нужно указать сценарий, данные, разрешения, срок, деловую причину, компенсирующие меры и человека, который принимает остаточный риск. Ограничивайте каждое исключение по времени. Постоянное исключение меняет политику и требует полноценного решения.

Опубликуйте список разрешенных способов работы там, где сотрудники легко его найдут, и запретите личные учетные записи в корпоративных процессах.

Доступ к модели зависит от данных и последствий

Доступ к модели должен зависеть от чувствительности входных данных и последствий результата, а не от популярности конкретной модели. Черновик публичного рекламного текста и исправление производственной базы данных могут использовать похожую технологию, но им нельзя давать одинаковый путь доступа.

Создайте небольшую матрицу, где строками будут сценарии использования. Для каждой строки запишите разрешенную модель или поставщика, допустимые классы данных, настройку хранения, регион при необходимости, учетные данные, инструменты, место назначения результата и согласующего. Не начинайте со списка моделей. Начните с работы, которую компания действительно выполняет.

Практичная классификация содержит четыре уровня:

1. Публичная работа использует уже разрешенную к публикации информацию. Сотрудники могут обращаться к утвержденным универсальным моделям без привилегированных инструментов.
2. Внутренняя работа охватывает планы, исходный код и обычные деловые записи. Нужны корпоративные учетные записи, определенные условия хранения и отсутствие производственных учетных данных.
3. Конфиденциальная работа включает материалы клиентов, результаты проверок безопасности, финансовые сведения или еще не опубликованную интеллектуальную собственность. Их могут обрабатывать только специально утвержденные процессы.
4. Ограниченная работа охватывает секреты, данные аутентификации, регулируемые записи и действия, которые способны существенно изменить производственную среду. Модель не должна получать их, пока компания не спроектирует и не одобрит узкое исключение.

Одной классификации мало. Отслеживайте, куда может попасть результат. Модель, которая читает конфиденциальные обращения поддержки и создает закрытую сводку, несет один риск. Та же модель, которая сразу отправляет ответ клиенту, несет другой. Доступ к входным данным и право действовать требуют отдельных согласований.

Используйте запись политики, которую инженер сможет прочитать во время реализации. Минимальная запись может выглядеть так:

use_case: support_reply_draft
owner: customer_operations
model_access:
  data_classes: [internal, confidential_customer_text]
  allowed_accounts: [company_managed]
  training_on_inputs: false
actions:
  read: [ticket_body, approved_help_articles]
  write: [private_draft]
  prohibited: [send_reply, issue_refund, change_account]
review:
  human_approval: every_output
  expires_on: 2026-10-01

Этот фрагмент предотвращает знакомый сбой: эксперимент по подготовке черновиков незаметно превращается в автономного агента поддержки, потому что позже кто-то добавляет право отправки. Запрещенные действия делают границу видимой при проверке кода. Дата окончания вынуждает принять новое решение, поэтому пилот не превращается в постоянную инфраструктуру из-за бездействия.

Матрицу утверждает владелец рисков. Служба безопасности проверяет работу с данными и учетными данными. Юристы рассматривают договорные и нормативные ограничения. Руководитель разработки реализует доступ и убеждается, что команда соблюдает правила. Так специалисты получают право запрета в своей области, но не несут ответственность за все операционное решение.

Автономность повышают по одному обратимому уровню

Процесс с ИИ должен заслужить автономность доказанными результатами, а каждое повышение должно оставаться обратимым. Команды ошибаются, когда видят только два варианта: окно чата или полностью самостоятельный агент. Между ними есть несколько полезных уровней.

Сначала разделите рекомендацию, подготовку, выполнение и закрепление изменений. Модель может предложить запрос к базе данных, не выполняя его. Она может подготовить запрос на слияние, не сливая код. Она может выполнить обратимое изменение, но не получить право сделать свое разрешение постоянным. У каждого глагола свои последствия.

Я использую пять уровней автономности:

• Уровень 0 разрешает только анализ, без инструментов и записи.
• Уровень 1 разрешает черновики или предлагаемые действия, которые должен утвердить человек.
• Уровень 2 разрешает обратимые действия с небольшими последствиями в узких границах.
• Уровень 3 разрешает ограниченные процессы с выборочной проверкой человеком и автоматической остановкой.
• Уровень 4 разрешает широкую самостоятельную работу только там, где мониторинг и восстановление уже доказали надежность.

Большинство процессов в малом и среднем бизнесе должны оставаться на уровнях 1 или 2. Уровень 3 может подойти для повторяющейся работы, например классификации обычных обращений или обновления тестовой среды. Уровень 4 встречается редко, потому что система контроля часто стоит дороже устраненного ручного труда. Автономность должна экономить больше операционной работы, чем добавляет.

Рекомендации OWASP для приложений с большими языковыми моделями отдельно описывают чрезмерную агентность: модель получает больше функций, разрешений или самостоятельности, чем требует сценарий. Популярный совет «оставить человека в контуре» слишком расплывчат и не решает проблему. Нужно назвать точное действие, которое требует согласования, сведения для проверяющего и результат его бездействия.

Правило согласования должно задавать четыре элемента: событие, согласующего, доказательства и тайм-аут. Например, агент развертывания может обновить тестовый сервис после успешных проверок. Для выпуска в производственную среду дежурный инженер должен увидеть разницу, результаты тестов, целевую среду, оценку изменения расходов и команду отката. Если никто не одобрит запрос за 30 минут, он теряет силу.

Избегайте формального согласования ради галочки. Если проверяющий получает двадцать запросов в день, а важное изменение в каждом спрятано под длинным объяснением модели, одобрение становится рефлексом. Сократите число точек согласования, показывайте относящуюся к делу разницу и оставляйте человеку решения о последствиях, которые он способен оценить. Нажатие кнопки человеком не превращает опасный процесс в безопасный.

Владелец рисков ИИ задает уровень и доказательства, необходимые для повышения. Руководитель разработки может работать внутри этого уровня и запрашивать изменение. Повышение с серьезными последствиями требует участия безопасности или финансов в зависимости от характера риска. Запишите решение, доказательства и дату следующего пересмотра.

Откат должен работать до расширения автономности

Откат должен быть работающей операционной возможностью, а не строкой в политике. До выдачи агенту права менять производственную среду команда должна показать, как она обнаружит плохое действие, остановит следующие действия, восстановит известное состояние и исправит последствия, которые нельзя просто отменить.

Система контроля версий дает инженерам ложную уверенность. Отмена коммита не вернет отправленное письмо, не скроет раскрытый секрет, не отменит внешний платеж и не сообщит клиенту, что автоматический ответ был ошибочным. Технический откат и исправление деловых последствий являются разными задачами. Для каждого сценария нужно продумать обе.

Разберем сбой агента поддержки. Агент читает жалобу по оплате, неверно определяет тип учетной записи, начисляет компенсацию, меняет подписку и отправляет уверенный ответ. Откат кода не меняет ни одной из этих записей. Для восстановления нужны идемпотентная компенсирующая операция для начисления, известное предыдущее состояние подписки, исправляющее сообщение, событие аудита, которое связывает все шаги, и остановка обработки следующего обращения.

Для каждой автономной записи требуйте:

• устойчивую запись входных данных, решения, вызова инструмента, результата и версии политики;
• идентификатор корреляции между событиями модели и бизнес-системы;
• проверенный механизм остановки, который быстро запрещает новые действия;
• процедуру восстановления или компенсации с назначенным оператором;
• правило уведомления затронутых клиентов или сотрудников.

Журналы должны описывать действия в деловых терминах. Трассировка токенов помогает отлаживать модель, но руководителю инцидента нужно знать, что заказ 1842 вернули, для учетной записи 771 изменили тариф, а сообщение 993 отправили. Храните только необходимые для расследования данные, потому что безразборная запись запросов может создать еще одну копию чувствительной информации.

Полезное событие аудита имеет предсказуемую структуру:

{"event":"subscription.change","actor":"agent:retention-v2","policy":"retention-prod-3","correlation_id":"req_8f31","target":"account_771","before":"standard","after":"paused","approval":"apr_204","result":"success"}

Владелец должен попросить команду восстановить тестовый сценарий вместо простой демонстрации документа об откате. Проводите упражнение до запуска и после существенных изменений инструментов, разрешений или потока данных. Если восстановление зависит от того, вспомнит ли создатель агента незаписанную команду, восстановления нет.

Лимиты расходов должны стоять рядом с разрешениями

Лимиты расходов на ИИ должны работать как контроль доступа: быть явными, многоуровневыми, наблюдаемыми и срабатывать до получения счета. Финансы отвечают за бюджет компании, а владелец рисков ИИ решает, как технические ограничения применяются к каждому процессу. Руководитель разработки реализует предупреждения и остановки.

Если поставщик и архитектура позволяют, задайте лимиты на четырех уровнях: на запрос, запуск процесса, день и месяц. Один месячный лимит учетной записи не остановит зацикленного агента, который потратит бюджет всех остальных команд. Один лимит на запрос не заметит тысячи отдельных дешевых обращений.

Денежные лимиты необходимы, но недостаточны. Ограничьте единицы, которые создают расходы: выбор модели, размер входа и выхода, число повторов, итерации с инструментами, параллельные задания и глубину очереди. Агенту, который может рекурсивно поручать работу другим агентам, нужен предел глубины. Пакетному заданию нужно максимальное число элементов. Резервный маршрут не должен незаметно переключать все запросы на самую дорогую модель.

Свяжите каждый процесс с владельцем расходов и деловым показателем. Для системы сводок поддержки можно установить предельную стоимость одного обращения. Для агента программирования можно задать недельный бюджет команды и отдельный лимит на долгий анализ репозитория. Точная сумма зависит от экономики компании, поэтому копировать долларовый предел другого стартапа лениво и бессмысленно.

По мере роста расходов используйте три реакции. Раннее предупреждение просит владельца процесса проверить изменение. Мягкий лимит блокирует дорогие режимы или снижает параллельность. Жесткий лимит останавливает новую работу, кроме явно разрешенных задач восстановления. Запишите, кто и на какой срок может повысить каждый предел.

Финансы должны видеть прогноз и фактические расходы по каждому процессу, а не один счет поставщика. Разработчикам нужны сведения об использовании единиц и характере сбоев. Владелец рисков должен проверять неожиданное отклонение, потому что оно может означать цикл, злоупотребление, ошибку маршрутизации или успешное распространение инструмента. Рост расходов сам по себе не всегда плох, но необъяснимый рост неприемлем.

Не требуйте одобрения CTO для каждого небольшого повышения, чтобы снизить риск расходов. Задайте диапазоны. Руководитель разработки может менять расходы внутри утвержденного операционного бюджета. Владелец рисков разрешает временные исключения и изменения удельной экономики. Генеральный или финансовый директор одобряет существенное изменение бюджета компании. Обычная разработка продолжает двигаться, а компания защищена от обязательств без верхнего предела.

Руководителю разработки и внешнему CTO нужен письменный раздел ролей

Руководитель разработки должен отвечать за ежедневное выполнение, а внешний CTO за систему контроля и компромиссы руководства. Запишите это разделение, потому что дружеские устные договоренности рассыпаются во время запуска или инцидента.

Практичное распределение выглядит так. Руководитель разработки инвентаризирует сценарии, реализует доступ, поддерживает оценки, следит за процессами, проводит проверку отката и сообщает об исключениях. Внешний CTO определяет политику, согласует доступ с серьезными последствиями, разрешает споры подразделений, оценивает поставщиков и архитектуру, руководит серьезными инцидентами с ИИ и докладывает генеральному директору об остаточном риске.

У безопасности, юристов, финансов и владельцев бизнес-процессов остаются прямые обязанности. Безопасность контролирует идентификацию, секреты и мониторинг. Юристы решают, позволяют ли договоры и условия обработки данных использовать сценарий. Финансы отвечают за общий бюджет. Владелец бизнес-процесса определяет приемлемый результат и исправляет последствия для клиентов. Внешний CTO связывает эти оценки и принимает техническое решение при противоречиях.

Используйте реестр решений вместо презентации. Каждая запись должна содержать вопрос, владельца, участников консультации, решение, причину, доказательства, дату окончания и требование к откату. Такой реестр не дает исключению превратиться в устное предание.

Для инцидентов полномочия должны быть такими же ясными. Дежурный инженер должен иметь право немедленно изолировать процесс без разрешения руководства. Руководитель разработки координирует техническое сдерживание и восстановление. Внешний CTO решает, нужно ли остановить связанные процессы, можно ли безопасно возобновить работу и какое изменение политики или архитектуры потребуется. Владелец бизнес-процесса исправляет операционные последствия, а генеральный директор решает вопрос о внешнем раскрытии после консультации с юристами. Записанные до инцидента роли избавляют от спора, когда счет идет на минуты.

decision: allow_agent_to_merge_low_risk_dependency_updates
accountable: fractional_cto
responsible: engineering_manager
consulted: [security_lead, service_owner]
conditions:
  - tests_pass
  - no_permission_changes
  - dependency_is_on_approved_registry
  - rollback_completed_in_staging
expires_on: 2026-09-30

Вначале рассматривайте процессы с серьезными последствиями каждый месяц, а стабильные процессы с низким риском ежеквартально. Проводите внеочередной пересмотр после инцидента, смены поставщика, выдачи нового разрешения инструменту, существенного изменения модели или заметного роста объема. Проверка только по календарю пропускает события, которые меняют риск.

Внешняя схема не работает, если приглашенный руководитель только присутствует на статусных встречах. Ему нужен доступ к архитектуре, договорам, записям об инцидентах, данным о расходах и людям, которые выполняют работу. Нужно заранее выделенное время для решений. Внешний CTO, который не может проверить доказательства или распорядиться об остановке, остается консультантом, а не владельцем.

За 30 дней можно обнаружить пробелы в контроле

Тридцати дней достаточно, чтобы назначить владельца и взять под контроль самые рискованные сценарии ИИ, хотя довести каждый процесс до идеала не получится. Задача состоит в том, чтобы заменить невидимые решения назначенными владельцами, действующими границами и проверенным восстановлением.

В первую неделю проведите инвентаризацию действующих и запланированных способов работы с ИИ. Поговорите с разработкой, продажами, поддержкой, маркетингом, финансами и операционными командами, потому что неофициальные инструменты часто остаются вне поля зрения руководителя разработки. Запишите входные данные, учетные записи моделей, инструменты, результаты, владельца бизнес-процесса, месячные расходы и возможность действовать без согласования. Отключите неизвестные процессы с производственными учетными данными или ограниченными данными, пока кто-то не примет за них ответственность.

На второй неделе классифицируйте данные и автономность. Создайте матрицу доступа, назначьте уровень автономности и перечислите запрещенные действия. Назовите одного владельца рисков и опубликуйте положение о его полномочиях. Не тратьте неделю на общую декларацию об этике ИИ. Она не скажет инженеру, может ли агент завтра вернуть оплату по счету.

На третьей неделе проверьте контроль на процессах с самыми серьезными последствиями. Проверьте границы учетных записей, работу с секретами, сведения для согласования, остановку расходов, события аудита и откат. Вызовите хотя бы один сбой: запретите вызов инструмента, верните искаженный ответ модели, имитируйте тайм-аут поставщика или достигните порога расходов. Посмотрите, что на деле сделают система и оператор.

На четвертой неделе устраните самые опасные пробелы и создайте реестр решений. Назначьте для каждого неустраненного риска владельца, срок, временное ограничение и условие остановки. Сообщите генеральному директору об остаточном риске простыми словами: что процесс может сделать, что может пойти не так, как быстро компания это обнаружит и что потребуется для восстановления.

Результат должен помещаться в небольшой рабочий комплект: положение о полномочиях, список сценариев, матрица доступа, правила автономности, политика расходов, инструкции по откату и реестр решений. Если процесс породил пятьдесят страниц, но инженеры не могут найти правило согласования производственного доступа, он провалился.

В первый месяц также нужно задать показатели. Отслеживайте попытки неразрешенного доступа, отказы в согласовании, результаты проверки отката, исключения из политики, отклонение расходов и инциденты по каждому процессу. Это рабочие сигналы, а не цифры для красивого отчета. Рост числа отказов может означать ухудшение модели, слишком жесткую политику или попытки пользователей выполнять более рискованную работу. Изучите причину до изменения лимита.

Нанимайте внешнего CTO при нехватке опыта и полномочий

Малому и среднему бизнесу стоит нанять внешнего CTO для управления рисками ИИ, если ни один действующий руководитель не может принимать технические решения для всей компании с полномочиями топ-менеджера. Главный признак не размер компании, а повторяющийся разрыв между возможностями процесса с ИИ и правом конкретного руководителя их контролировать.

Роль, скорее всего, нужна, если модели уже работают с конфиденциальными данными, агенты могут записывать сведения в бизнес-системы, расходы распределены между несколькими командами или руководители снова и снова спорят об одном и том же доступе. Она также нужна, когда руководитель разработки понимает реализацию, но никогда не проектировал восстановление после инцидентов, контроль поставщиков и принятие риска руководством.

Скорее всего, внешний CTO не нужен, если ИИ работает только с публичной информацией и черновиками, которые проверяет человек, если у руководителя разработки уже есть полномочия уровня CTO или если полной ответственностью владеет компетентный руководитель по безопасности и архитектуре. В таких случаях письменно назначьте владельца и потратьте деньги на реализацию.

Опишите сотрудничество через решения и доказательства, а не через часы на встречах. На первом этапе ожидайте список сценариев, границы политики, проверенный откат для самых рискованных процессов, систему контроля расходов и утвержденное генеральным директором разделение ответственности. Дальнейшая работа должна быть сосредоточена на исключениях, инцидентах, существенных изменениях и обучении внутреннего руководителя.

Спросите кандидатов, как они ограничат один из ваших реальных процессов. Сильный кандидат отделит доступ к входным данным от права действовать, определит доказательства для согласования, назовет механизм остановки и спросит об удельной экономике. Будьте осторожны, если ответ остается на уровне принципов, восторга от инструментов или типового шаблона политики. Для этой работы нужны решения, которые инженеры смогут реализовать, а руководители обосновать.

Мой Team & AI Audit на oleg.is за $5,000 и пять рабочих дней помогает найти такие пробелы. Я гарантирую не менее $50,000 выявленной годовой экономии, иначе аудит будет бесплатным. После него можно перейти к сопровождению внешнего CTO, если компании нужен владелец изменений, но даже без дальнейшей работы руководство должно получить конкретные решения.

Не оставляйте риски ИИ за «руководством» в целом. Назначьте одного владельца, дайте ему право остановки и проверьте контроль на реальном сбое. Если руководитель разработки не может получить такой мандат, привлеките внешнего руководителя до тех пор, пока эту ответственность не сможет взять человек внутри компании.