Фракционный CTO или vCISO для изменений ИИ по SOC 2

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

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

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

CC8.1 распределяет работу, а не должности

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

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

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

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

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

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

Фракционный CTO отвечает за механизм разработки

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

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

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

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

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

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

CTO также может обучить инженеров и проверять выборки, пока процесс не станет привычным. Это и есть ответственность за разработку. CTO сообщает руководству и vCISO об исключениях и нерешенных рисках, но не должен незаметно одобрять отступления от политики безопасности от имени компании.

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

vCISO отвечает за требования безопасности и проверку

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

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

Модель управления рисками ИИ NIST прямо требует такого разделения, хотя не предписывает названия должностей. GOVERN 2.1 требует документировать роли, обязанности и линии связи при выявлении, измерении и управлении рисками ИИ. GOVERN 2.3 возлагает решения о риске развертывания на исполнительное руководство. Я согласен с этим разделением: vCISO формулирует и проверяет риск безопасности, а основатель или другой уполномоченный руководитель принимает бизнес-риск.

Политика vCISO должна отвечать на вопросы, по которым инженеры могут действовать:

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

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

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

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

Нанимайте под отсутствующее решение, затем добавляйте вторую роль

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

Самая доступная по цене ошибка возникает, когда специалиста выбирают по знакомому названию должности. Основатели часто знают, что для SOC 2 им нужна «безопасность», и передают весь контроль изменений ИИ vCISO. Тот выпускает политику, реестры рисков и формы проверки, но конвейер никто не меняет. Инженеры вручную сохраняют скриншоты, пока нагрузка по сбору свидетельств не становится непосильной. Затем владельца политики обвиняют в состоянии инженерной системы, которую проект не охватывал.

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

При подготовке первого проекта используйте такое распределение:

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

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

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

RACI должен сопровождать запись об изменении

Полезная матрица RACI привязана к реальным решениям, поэтому по каждому изменению видно, кто его предложил, внедрил, проверил, одобрил и отслеживал. Слайд с формулировкой «CTO отвечает за исполнение, CISO несет конечную ответственность» слишком общий для проверки и слишком расплывчатый для работы.

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

В обычной записи RACI буква R означает исполнителя работы. A означает человека, который отвечает за решение. C означает участника консультации, а I означает получателя информации. Это начальное распределение, поскольку владелец системы, чувствительность данных и возможный ущерб могут потребовать другой схемы.

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

Указывайте имена или идентификаторы ролей прямо в системе изменений, не ограничивайтесь политикой. Если риск одобрил «vCISO», но компания не может показать, кто занимал эту роль в тот день, запись теряет вес. Даты начала и окончания полномочий особенно важны при смене фракционных руководителей.

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

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

Свидетельства должны появляться в процессе разработки

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

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

change_id: AI-2026-041
owner: payments-platform
business_objective: reduce manual ticket classification
change_class: customer-data-ai
systems_affected: [support-api, model-gateway]
data_classes: [customer-confidential]
provider_or_model: approved-provider/model-version
permissions_added: [read:support-ticket]
tests:
  functional: ci://run/18442
  security: ci://run/18443
  ai_evaluation: eval://run/771
approval_triggers: [external-model, customer-confidential]
security_review: SEC-882
release_approver: person-id-17
rollback: disable feature flag ai_ticket_classification
deployed_artifact: image-digest-placeholder
deployed_at: 2026-04-18T16:20:00Z

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

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

Простая команда для выборки поможет обнаружить, у каких развернутых коммитов нет записей о проверке:

git log release-2026-04..release-2026-05

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

vCISO проверяет, привели ли нужные условия к проверкам и истекли ли исключения вовремя. CTO исправляет отсутствующие связи, нестабильные идентификаторы и этапы, которые можно обойти. Основатель получает короткий отчет о контроле: размер совокупности, выборки или автоматическое покрытие, исключения, неудачные проверки, просроченные исправления и принятый риск.

В NIST SP 800-218 модель Secure Software Development Framework описана как набор результатов, который нужно приспособить к допустимому риску и ресурсам организации, а не как неизменный контрольный список. Для этой задачи подход верный. Автоматизируйте сбор свидетельств там, где автоматика доказывает результат, и оставляйте решение человеку там, где машина не может принять ответственность.

ИИ-агент быстро обнажает слабые границы

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

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

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

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

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

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

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

Два задания не дадут ролям смешаться

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

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

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

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

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

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

В oleg.is я использую Team & AI Audit, чтобы до предложения услуг фракционного CTO определить, где смешаны разработка и надзор. Аудит помогает задать область работ, но не дает заключения по SOC 2, а вопросы о влиянии изменений контроля на проверку нужно адресовать CPA компании.

Первые 30 дней должны дать рабочие доказательства

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

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

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

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

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

Покажите результат CPA на раннем этапе, особенно если меняются описание системы, формулировка контроля, источник свидетельств или ответственная роль. Аудитор должен сохранять достаточную независимость для проверки контроля, поэтому не просите его проектировать решение. Спросите, понятно ли описание, подтверждают ли свидетельства заявленную работу и влияет ли изменение на план проверки.

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