Урок 8: Команда AI-проекта — CISO, DPO, юрист, интегратор

Чему вы научитесь

• Разводить обязательные и факультативные роли в AI-проекте промышленного предприятия
• Понимать, за что персонально отвечает CISO, а за что — DPO, юрист по IT и интегратор
• Быстро собирать минимальную команду для проекта с ПД и для проекта на объекте КИИ
• Выбирать тип подрядчика под задачу: OT-интеграция, SOC, криптография, аудит КИИ, защита ПД
• Проверять кандидата в CISO и не нанимать «координатора закупок» вместо руководителя по ИБ

Проблема большинства AI-проектов в промышленности не в том, что «нет модели», а в том, что никто не владеет риском целиком. Бизнес владелец хочет пилот за месяц, интегратор обещает быстрое подключение, ИТ даёт доступ, а юрист и ИБ узнают о проекте за неделю до запуска. После 2024–2026 годов это уже не организационная небрежность, а прямой путь к нарушению 152-ФЗ, 187-ФЗ и указа № 250 (Указ Президента РФ № 250 от 01.05.2022; Постановление Правительства РФ № 1272 от 15.07.2022; 152-ФЗ, ст. 22.1).

Главный вывод урока: у AI-проекта на заводе нет «одного ответственного». Есть цепочка ролей. Если хотя бы одно звено формально назначено, но не включено в работу, проект превращается в источник персональной ответственности руководства.

Почему команда стала юридическим требованием, а не вопросом удобства

Указ Президента РФ № 250 от 1 мая 2022 года обязывает ряд организаций назначить заместителя руководителя, ответственного за обеспечение информационной безопасности, а также выстроить организационный контур ИБ (Указ № 250). Постановление Правительства РФ № 1272 от 15 июля 2022 года утвердило типовые положения и для такого заместителя, и для структурного подразделения ИБ (ПП РФ № 1272). Для субъекта КИИ это означает простую вещь: CISO в проекте — не факультативный советник, а часть обязательной модели управления.

По персональным данным логика похожая. 152-ФЗ требует назначить лицо, ответственное за организацию обработки персональных данных; именно оно получает указания непосредственно от исполнительного органа и контролирует соблюдение требований закона внутри организации (152-ФЗ, ст. 22.1). В российской практике эту роль часто называют DPO, но юридически корректнее говорить «ответственный за организацию обработки ПД». Это не нюанс терминологии, а вопрос полномочий: западный DPO и российское ответственное лицо — не всегда одно и то же.

Если связать это с предыдущими уроками модуля, получается такая рамка:

• в уроке 1 вы уже видели, что ПД в AI-проекте начинаются не на этапе дообучения, а в промптах, логах, вложениях и эмбеддингах;
• в уроке 2 про КИИ разбирается, почему на значимых объектах иностранный облачный AI-контур нельзя считать допустимым вариантом;
• в этом уроке задача другая: собрать такую команду, которая остановит плохую архитектуру до закупки и до пилота.

flowchart LR
    A[Бизнес-владелец / CDTO] --> B[Юрист по IT]
    A --> C[DPO / ответственный по ПД]
    A --> D[CISO / замруководителя по ИБ]
    D --> E[Интегратор ИБ / OT-архитектор]
    D --> F[SOC / мониторинг]
    D --> G[Криптопровайдер / СКЗИ]
    C --> E
    B --> E
    E --> H[Техническое решение и запуск]
    F --> H
    G --> H

Кто должен быть в команде и за что отвечает

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

Минимальная команда для трёх типовых сценариев

Не каждому AI-проекту нужен одинаковый состав. Но есть минимумы, ниже которых проект неуправляем.

Практический ориентир для AI+КИИ-проекта в промышленности — по одной роли на каждый контур: интегратор ИБ, криптопровайдер, SOC, консультант по ПД и юрист по IT. Это не бюрократия. Это минимальная разметка ответственности.

Когда кого подключать

1. На этапе идеи — CISO и юрист по IT. Если вы подключаете их после выбора сервиса, они уже не управляют риском, а только оформляют последствия.

2. Как только появились реальные данные — DPO. Не после договора, а в тот момент, когда команда сказала: «для пилота возьмём выгрузку из CRM или HR-системы».

3. Если затрагивается производство — OT-интегратор. Любой доступ к historian, SCADA, MES, инженерным станциям и промышленным шлюзам должен проходить через специалиста по промышленной архитектуре, а не через обычного корпоративного интегратора.

4. Если проект идёт в эксплуатацию — SOC. С этого момента нужен не только дизайн, но и детектирование, расследование и дежурный процесс реагирования 24/7 (Solar JSOC).

5. Если есть защищённые каналы и подпись — криптопровайдер. Ключи, ГОСТ VPN, TLS и ЭП нельзя оставлять на команду разработки; здесь нужен отдельный вендорский стек, например КриптоПро CSP или ViPNet Client 5 (КриптоПро CSP, ViPNet Client 5).

6. Перед закупкой — общее решение по ролям. В протоколе должно быть видно, кто владелец риска по ПД, кто владелец риска по КИИ, кто отвечает за эксплуатацию и кто подписывает инцидентный сценарий.

7. Перед пилотом — проверка на конфликт интересов. Интегратор, который продаёт сервис, не должен единолично подписывать его безопасность. Нужен внутренний владелец или независимый аудит.

8. Перед масштабированием — пересборка команды. Пилот на стенде и эксплуатация на заводе — это разные режимы. То, что было допустимо на синтетике, перестаёт быть допустимым в бою.

Какие подрядчики закрывают какие задачи

Рынок подрядчиков стоит читать не по бренду, а по специализации. Один вендор силён в OT-видимости, другой — в SOC, третий — в ГОСТ-криптографии. Ниже — срез по состоянию на апрель 2026 года: даты релизов и новостей важны как ориентир актуальности, а не как признак, что продукт «застыл» в прошлом.

Смотрите на рынок без романтики. «Крупный интегратор» — не роль, а вывеска. Для проекта на производстве вам обычно нужен не один подрядчик, а связка из трёх типов: проектировщик, наблюдатель и криптографический слой.

Что спросить у кандидата в CISO

Если вы нанимаете или назначаете руководителя ИБ под AI-программу, проверяйте не общую эрудицию, а управляемость промышленного риска.

1. Как вы разделяете ИТ-контур и промышленный контур в AI-проекте? Хороший ответ начинается со схемы сети, сегментации, шлюзов и списка систем, которые нельзя трогать напрямую.

2. Кто у вас владелец решения по ПД? Если кандидат отвечает «юристы посмотрят потом», это не CISO, а координатор согласований.

3. Что вы считаете стоп-фактором для пилота? Нужны конкретные критерии: нет основания обработки, нет уведомления, иностранный SaaS для КИИ, нет журналирования, нет сценария реагирования.

4. Какой у вас сценарий инцидента для AI-сервиса? Должны прозвучать логи, форензика, уведомление, изоляция, владелец решения и тайминг.

5. Как вы проверяете подрядчика? Нужны вопросы про хранение логов, вторичное обучение модели, доступ персонала, цепочку поставки и наличие российских компонентов.

6. Как вы встроите SOC в эксплуатацию? Если CISO не понимает, какие события должны уходить в мониторинг и кто реагирует ночью и в выходные, проект останется без наблюдаемости.

7. Как вы работаете с уроком 1 и уроком 2 этого модуля на практике? Кандидат должен связать ПД и КИИ в одну управленческую картину: нельзя отдельно «разрешить ПД» и забыть про режим промышленной инфраструктуры.

8. Что вы делаете, если бизнес просит быстро подключить OpenAI? Хороший ответ — сначала классифицируем данные и контур. Для КИИ запрет обсуждается на уровне допустимости, а не на уровне удобства; для некритичного контура возможна только модель с локализацией и юридической проверкой.

9. Кого вы привлекаете внешне, а что оставляете внутри? Сильный CISO не обещает сделать всё сам. Он знает, когда нужен OT-интегратор, когда — криптопровайдер, когда — независимый аудит.

10. Как выглядит ваш протокол запуска AI-сервиса? Должны быть артефакты: карта данных, протокол согласования, требования к подрядчику, тестовые сценарии, журнал решений.

Как распределять ответственность без серых зон

Рабочее правило простое:

• CDTO отвечает за бизнес-результат и бюджет;
• CISO отвечает за допустимость архитектуры и ИБ-меры;
• DPO отвечает за законность обработки ПД и внутренний контроль по 152-ФЗ;
• юрист по IT отвечает за договорную модель и права на данные;
• интегратор отвечает за техническое исполнение, но не за нормативное решение вместо заказчика;
• SOC отвечает за наблюдаемость и реагирование, а не за исходное проектирование;
• криптопровайдер отвечает за криптографический слой, а не за общую безопасность системы.

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

Итоги