# Блок 05. Безопасность и комплаенс

- Курс: [Переход на разработку с ИИ](https://ykononov.ru/ai-cto/), блок 5 из 15
- Автор: Юрий Кононов, CTO (https://ykononov.ru/)
- Страница: https://ykononov.ru/ai-cto/bezopasnost-politika-ii/
- Обновлено: 2026-10-12. Данные на 2026 год
- Время чтения: 20 мин
- Лицензия: CC BY-NC 4.0: можно использовать и распространять с указанием автора и ссылкой на страницу, коммерческое использование запрещено

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

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

Вы технический директор, а руководитель ИБ узнал про пилот и готов его остановить. Дальше – как превратить ИБ из блокера в участника: с какими вопросами она придёт, что должно быть готово заранее и чем российское регулирование отличается от западных чек-листов.

## Ситуация: ИБ узнала про пилот

**Руководитель ИБ · вторник, 16:40:** Мне сказали, что у вас пилот с ИИ. Код куда уходит? Кто что отправлял, где журнал? Пока не увижу ответов, ставлю запрет на внешние ИИ-инструменты. Неделя у вас есть.

Что известно:

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

**С чем вы пойдёте к руководителю ИБ?**

- **A. Решить через генерального.** Пилот согласован наверху, генеральный ждёт результатов. Он может попросить ИБ не останавливать пилот, пока вы готовите ответы. Пилот не встанет, но ИБ узнает о решении сверху.
- **B. Уйти в свой контур.** Остановить пилот и развернуть открытую модель на своём железе. Код не покидает периметр, все вопросы ИБ закрыты разом. Нужны оборудование, люди и несколько месяцев без пилота.
- **C. Позвать ИБ в пилот.** За неделю подготовить ответы на 4 вопроса ИБ: куда уходит код, где журнал, какие правила, что с персональными данными. Пригласить человека из ИБ участником. Пилот станет меньше, и придётся признать, что пришли поздно.

## Что происходит через квартал

Цифры условные: они показывают направление изменений, точной величины в них нет. Шаблон политики и чек-лист для ИБ лежат в [блоке 15](/ai-cto/shablony/), защита от prompt injection разобрана в [блоке 12](/ai-cto/slozhnosti-vnedreniya-ii/).

### Вариант A: Пилот спасли, ИБ потеряли

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

| Метрика | Было | Стало |
| --- | --- | --- |
| Дней на согласование (медиана по заявкам в ИБ) | 14 | 60 |
| Использование через корпоративные инструменты (доля до запрета в конце квартала, по данным инструмента) | 55% | 40% |
| Запросы с журналом аудита (доля от всех запросов к моделям) | 0% | 0% |
| Инциденты с отправкой лишнего (найдены случайно) | 0 | 1 |
| Активные пользователи в пилоте (по данным инструмента, после запрета) | 85% | 0% |

**Вердикт:** Вы выиграли неделю и потеряли квартал. ИБ могла стать союзником, а стала проверяющим, и после инцидента её запрет уже не оспорить.

### Вариант B: Свой контур, потерян квартал

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

| Метрика | Было | Стало |
| --- | --- | --- |
| Дней на согласование (медиана по заявкам в ИБ) | 14 | 7 |
| Использование через корпоративные инструменты (доля, по данным инструмента) | 55% | 30% |
| Расходы на ИИ (оборудование и люди, план = 100) | 100 | 240 |
| Время от коммита до прода (пилотная команда, метрика DORA) | 5,5 дн | 6 дн |
| Активные пользователи в пилоте (по данным инструмента) | 85% | 0% |

**Вердикт:** Для закрытых данных решение правильное. Но вы применили его ко всему сразу и потеряли квартал без пилота.

### Вариант C: ИБ стала соучастником

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

| Метрика | Было | Стало |
| --- | --- | --- |
| Дней на согласование (нового инструмента, по процедуре) | нет данных | 10 |
| Использование через корпоративные инструменты (доля, по данным инструмента) | 55% | 80% |
| Запросы с журналом аудита (доля от всех запросов к моделям) | 0% | 100% |
| Инциденты с отправкой лишнего (о которых сообщили сами) | 0 | 1 |
| Сервисов в пилоте (без персональных данных) | 8 | 5 |

**Вердикт:** Пилот стал меньше, зато его больше никто не остановит. Правила вы написали вместе с теми, кто будет их проверять.

## Четыре опасения ИБ и как их закрыть

### Взаимодействие со службой информационной безопасности

Главная ошибка состоит в том, чтобы прийти к ИБ с готовым решением и попросить его согласовать. Так вы получаете отказ или 2 месяца переписки, о которых я писал в [блоке 01](/ai-cto/ii-v-razrabotke/). Правильный порядок другой: прийти до выбора инструмента и спросить, какие условия нужно выполнить, чтобы согласование прошло.

**Первая встреча с ИБ, если нет ни инструмента, ни пилота.** На 1 час, с руководителем ИБ или тем, кто согласует новые инструменты. Повестка:

1. Зачем внедряем: 2–3 причины и метрики к ним (документ [блока 02](/ai-cto/zachem-vnedryat-ii/)).
2. Что уже происходит: кто и чем пользуется через личные аккаунты. Без поиска виноватых.
3. Какие данные и системы не трогаем: персональные данные, критичные системы, КИИ, требования регулятора (раздел про российскую специфику ниже).
4. Условия согласования: какие пути ИБ допускает (отечественный поставщик, модель в контуре, зарубежная модель для остального кода, шлюз) и что ей нужно увидеть по каждому из 4 опасений ниже.
5. Процедура и срок: кто согласует, сколько это займёт, какие документы нужны от вас.
6. Участник пилота от ИБ и дата следующей встречи – на ней вы покажете черновик политики на одну страницу.

Результат встречи – список требований ИБ и имя участника. С ними можно выбирать инструмент.

У ИБ 4 типовых опасения, каждое из них нужно закрыть явно.

1. **Куда уходит код:** самый известный пример даёт [Samsung](https://www.theregister.com/2023/04/06/samsung_reportedly_leaked_its_own). В марте 2023 года, меньше чем через 3 недели после того, как инженерам разрешили ChatGPT, случились как минимум 3 утечки: исходный код программы для базы данных полупроводников, код для поиска неисправного оборудования и запись совещания. В мае компания [запретила](https://www.bloomberg.com/news/articles/2023-05-02/samsung-bans-chatgpt-and-other-generative-ai-use-by-staff-after-leak) внешние ИИ-инструменты. Ответ на опасение: корпоративный тариф с договором об отказе от обучения на ваших данных, модель на своём железе или оба варианта сразу.
2. **Кто и что делал:** ответ даёт журнал действий (см. раздел про аудит).
3. **Что попадёт в код снаружи:** нужны те же проверки, что и для человеческого кода (статический анализ безопасности и проверка зависимостей, [блок 09](/ai-cto/ii-v-ci-cd/)), плюс защита от prompt injection ([блок 12](/ai-cto/slozhnosti-vnedreniya-ii/)).
4. **Как это согласуется с регуляторами:** ответ в разделе про российскую специфику ниже.

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

### Правила работы с ИИ с точки зрения ИБ

Политика использования ИИ (шаблон из 8 пунктов в [блоке 15](/ai-cto/shablony/)) отвечает на вопросы ИБ простым языком. Главных вопросов 5:

- **Какие инструменты разрешены:** нужен явный список вместо формулировки «любые на усмотрение». Всё остальное запрещено, но есть понятная процедура добавления нового инструмента.
- **Что нельзя отправлять в модель:** секреты, ключи, персональные данные клиентов, код закрытых систем, если нет контура. Список должен быть конкретным.
- **Какие аккаунты использовать:** только корпоративные, потому что личный аккаунт в точности повторяет [сценарий Samsung](https://www.theregister.com/2023/04/06/samsung_reportedly_leaked_its_own).
- **Кто отвечает за код:** инженер, который его смержил, на ИИ ответственность переложить нельзя. Это важно для аудита и для культуры: слова «так написал ИИ» оправданием не считаются.
- **Что делать при инциденте:** куда сообщать, если отправили лишнее.

Политика должна помещаться на одну страницу. Документ на 20 страниц никто не прочитает, поэтому теневое использование из [блока 02](/ai-cto/zachem-vnedryat-ii/) вернётся.

**Корпорация:** согласование с ИБ – главный критический путь внедрения, закладывайте на него от 2 недель до квартала и начинайте до выбора инструмента. Для кода критичных систем и данных с ограничениями нужна модель в контуре или отечественный поставщик по договору. Зарубежный корпоративный тариф без обучения на ваших данных подходит только для остального кода, и у него своя цена. [Anthropic](https://www.anthropic.com/supported-countries) и [OpenAI](https://help.openai.com/en/articles/5347006-openai-api-supported-countries-and-territories) с Россией официально не работают. Anthropic не обслуживает и компании, которые контролируются из России, где бы они ни были зарегистрированы. На практике такой тариф получают через иностранное юрлицо или через реселлера. Риски: аккаунт могут заблокировать без предупреждения, договор об отказе от обучения заключён с посредником, а не с вами, оплата идёт через третьих лиц. Такую схему решают вместе с юристами и ИБ.

Есть и российские прокси-сервисы (я упоминал о них в [блоке 03](/ai-cto/ii-agenty-i-podhody/)). Договор и счёт выставляет российская компания, закрывающие документы приходят через ЭДО. Часть таких сервисов включена в реестр российского ПО и участвует в закупках по 223-ФЗ. Для бухгалтерии и закупок это решает вопрос оплаты. Для ИБ этого может быть мало: юридические моменты нужно уточнить с поставщиком. Перед договором спросите прокси-сервис:

- куда физически уходят запросы;
- описана ли трансграничная передача в договоре и в политике обработки персональных данных;
- где и сколько хранится журнал запросов;
- подпишет ли он NDA и ответит ли на анкету ИБ.

**Небольшая компания:** службы ИБ нет, поэтому её роль берёт на себя технический директор. Минимум: политика на одну страницу ([блок 15](/ai-cto/shablony/)), включённые у поставщика режимы «без обучения на данных» и «без хранения запросов», проверка, что в репозитории нет секретов. Если вы обрабатываете персональные данные клиентов, 152-ФЗ действует и на вас, независимо от размера.

#### 2 слоя правил: политики ИБ и уточнения проекта

Политика на одну страницу – это документ для людей. Но агент документы в вики не читает, он читает файлы в репозитории. Значит, правила ИБ должны лежать там же, где код, и тут возникает опасность: если правила безопасности лежат в том же файле контекста, что и договорённости команды, любой инженер или сам агент при очередной перегенерации может их стереть, и никто не заметит: файл по-прежнему выглядит правдоподобно.

Решение – разделить правила на 2 слоя с разными владельцами. Так устроен мой инструмент Brownspec из [блока 03](/ai-cto/ii-agenty-i-podhody/), но подход работает с любым инструментом.

| Файл | Кто пишет | Кто может менять | Что внутри |
| --- | --- | --- | --- |
| `policies.md` | Служба ИБ и архитектура | Только ИБ, через пул-реквест с обязательным ревью ИБ | Что нельзя отправлять в модель, какие модули не трогать, какие действия требуют подтверждения человека, какие профили регуляторов включены (например, 152-ФЗ) |
| `conventions.md` | Инструмент генерирует из кода | Команда, свободно, файл перегенерируется | Как здесь обрабатывают ошибки, как логируют, где лежат слои, принятые библиотеки |

Правило одно: инструмент никогда не перезаписывает `policies.md`, а спецификация каждого изменения проверяется против него: если изменение задевает правило, в спецификации появляется пометка «затрагивает правило PDN-03, покажите ИБ». PDN-03 здесь – одно из правил профиля 152-ФЗ, например «персональные данные в журналах маскируются». Инструмент маршрутизирует к человеку, а не выносит вердикт «соответствует»: ложное чувство защищённости опаснее отсутствия проверки.

**Уточнения на уровне проекта.** Политика ИБ – одна на компанию, но проекты разные: в платёжном сервисе запретов больше, во внутренней админке меньше. Поэтому проект может добавлять к политике свои уточнения, но только в одну сторону: сузить разрешённое можно, расширить нельзя. В платёжном сервисе команда дописывает «агент не трогает модуль расчёта комиссий без ревью 2 сеньоров» и «тестовые данные только из генератора, не из прода». Во внутренней админке уточнений может не быть вовсе. Уточнения живут в отдельном файле `policies.project.md` рядом с `policies.md`: его меняет лид команды, а ИБ видит каждое изменение в пул-реквесте. Общий файл меняет только ИБ. Так у каждого файла 1 владелец, и это проверяется настройками репозитория.

Как это выглядит в файле:

```
# policies.md – владелец ИБ, менять только через пул-реквест с ревью @security
- SEC-01: секреты, ключи и токены не попадают в контекст модели
- SEC-02: персональные данные клиентов – только в модель в контуре или у отечественного поставщика по договору
- SEC-03: деплой, удаление данных, отправка наружу – только с подтверждением человека

profiles: [ru/152-fz-pdn]

# policies.project.md – владелец лид команды, только сужает policies.md
- PAY-01: модуль fees/ меняется только с ревью 2 сеньоров
- PAY-02: тестовые данные только из генератора fixtures/
```

Аудитору такой файл нравится: видно, кто владеет правилом, когда оно менялось и кто согласовал – всё это есть в истории репозитория. И ИБ такой подход согласовывает быстрее, потому что правила под её контролем, а не в головах инженеров.

### Аудит действий

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

Что логировать: автора запроса, время, инструмент и модель, содержимое запроса и ответа (если полное хранение противоречит политике – с замаскированными секретами и персональными данными; одного хеша мало: по нему не восстановить, что ушло в модель), какой код в итоге попал в репозиторий и через какой пул-реквест. Срок хранения задаёт регулятор для вашей отрасли.

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

**Шлюз у прокси-сервиса или свой.** Российские прокси к зарубежным моделям ([блок 03](/ai-cto/ii-agenty-i-podhody/)) часто дают часть функций шлюза из коробки:

- роли «владелец, администратор, сотрудник»;
- вход через корпоративный SSO;
- лимиты на сотрудника и команду;
- отчёт о расходах по сотрудникам и ключам.

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

Ещё одна деталь: в кабинетах прокси-сервисов администратор компании часто видит историю чатов сотрудников. Напишите об этом в политике ([блок 15](/ai-cto/shablony/)), чтобы для сотрудников это не стало сюрпризом.

### Маскирование персональных данных перед отправкой

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

Пример ([документация GPTunneL](https://docs.gptunnel.ru/api/pii-obfuscation/)):

| Шаг | Текст |
| --- | --- |
| Запрос сотрудника | Меня зовут Иван Петров, телефон +7 916 245-33-18. Составь подпись к письму. |
| Видит поставщик модели | Меня зовут <<PER0>>, телефон <<PHONE1>>. Составь подпись к письму. |
| Отвечает модель | С уважением, <<PER0>>, тел. <<PHONE1>> |
| Получает сотрудник | С уважением, Иван Петров, тел. +7 916 245-33-18 |

Где это взять: свой шлюз с модулем маскирования или российский прокси, у которого маскирование встроено. Хороший маскировщик распознаёт:

- ФИО в любом падеже;
- паспорт, ИНН, СНИЛС;
- номера карт и счетов;
- телефоны и адреса;
- пароли и ключи API.

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

Что проверить, прежде чем на это опираться:

- Что происходит, если маскировщик недоступен. Правильный ответ: запрос отклоняется, а не уходит без маскирования.
- Работает ли маскирование в том формате API, через который ходит ваш инструмент. У прокси-сервисов оно бывает только в одном из форматов: OpenAI или Anthropic.
- Маскируются ли картинки и вложения. Обычно нет.
- Качество на ваших данных. Прогоните 50–100 реальных фрагментов журналов и обращений и посчитайте, сколько данных прошло мимо.

Маскирование снижает риск, но не решает юридический вопрос. Если по контексту человека можно узнать, замаскированный текст остаётся персональными данными. Поэтому вопрос о трансграничной передаче (ниже, «Российская специфика») всё равно решают юристы. Для данных, которые закон или ИБ запрещают выпускать за периметр, нужна модель в контуре. В сопровождении маскирование – главный способ начать разбирать журналы с ИИ, не дожидаясь модели в контуре ([блок 10](/ai-cto/soprovozhdenie-monitoring/)).

### Российская специфика

Здесь я даю только ориентиры, юридической консультацией они не являются. Точные требования для вашей отрасли уточняйте у юристов и у вашей ИБ, а редакцию норм – на consultant.ru или garant.ru: они меняются. Подробная открытая сводка регуляторных требований к ИИ в российской корпоративной разработке содержится в части 8 [whitepaper Сбера «AI-Disrupt PDLC»](https://sbertech.ru/whitepaper). Это документ вендора, который продвигает собственную методологию и собственные модели, но регуляторная часть в нём изложена предметно. Дальше я опираюсь на неё и помечаю, где взгляд Сбера и где мой.

- **Персональные данные:** по федеральному закону 152-ФЗ запись, накопление и хранение персональных данных граждан России при сборе идут в базах данных на территории России ([ст. 18 ч. 5](https://www.consultant.ru/document/cons_doc_LAW_61801/cbf4e15b7c330f9372e876cdf2bc928bad7950ef/)). Перед трансграничной передачей оператор обязан уведомить Роскомнадзор ([ст. 12](https://www.consultant.ru/document/cons_doc_LAW_61801/e4ebbe1780de623c7cf32a59ca82a7bb523a25dd/)), а для самой передачи нужно законное основание – согласие субъекта лишь одно из них. За нарушения предусмотрены штрафы. Отправка клиентских данных во внешнюю зарубежную модель почти наверняка нарушит эти требования. На практике в промптах не должно быть клиентских данных, либо модель должна стоять в вашем контуре или у отечественного поставщика.
- **Банки и финансовые организации:** требования к защите информации в банках задаёт [положение Банка России 851-П](https://ppt.ru/obzory/vstupaet-v-silu/polozhenie-banka-rossii-30-01-2025-851-p). Оно действует с 29 марта 2025 года и [заменило 683-П](https://habr.com/ru/companies/ussc/news/903152). В некредитных финансовых организациях – 757-П. Среди требований 851-П – оценка соответствия прикладного ПО при изменении его исходного кода, значит, и кода, написанного с ИИ. Требования к операционной надёжности задаёт отдельное положение 787-П. По оценке Сбера, для финансовых организаций решения, принятые с участием ИИ-агентов, должны быть документированы и воспроизводимы при регуляторной проверке. Это прямое требование к аудиту действий из предыдущего раздела. Для такой оценки пригодится цепочка по каждому релизу: требование – изменение – тест – проверка безопасности – решение о выпуске. Её можно вести вручную или в платформе, которая собирает её сама ([блок 03](/ai-cto/ii-agenty-i-podhody/)).
- **Критическая информационная инфраструктура:** для субъектов КИИ (критической информационной инфраструктуры) действуют закон 187-ФЗ, приказы ФСТЭК (Федеральной службы по техническому и экспортному контролю) о защите информации и указы Президента № 166 и № 250 от 2022 года, которые ограничивают использование иностранного программного обеспечения и средств защиты. Если ваши системы относятся к значимым объектам КИИ, иностранный ИИ-инструмент может запретить сам закон, независимо от соображений ИБ.
- **Государственные информационные системы:** с 1 марта 2026 года действует [приказ ФСТЭК № 117](https://ppt.ru/amp/obzory/vstupaet-v-silu/prikaz-fstek-rossii-11-04-2025-117) о защите информации в ГИС. В августе 2026 года ФСТЭК вынесла на обсуждение [проект дополнений к нему про ИИ](https://regulation.gov.ru/projects/170500/): отдельный сегмент для ИИ, многофакторная аутентификация, минимальные права, фильтрация входных и выходных данных, контроль ИИ-агентов. Планируемый срок вступления – 1 марта 2027 года. Если вы делаете ГИС или работаете на госзаказчика, учитывайте эти требования уже сейчас.
- **Вывод Сбера, с которым я согласен:** совокупность этих норм делает отечественный инференс (работу модели в российском контуре) обязательным компонентом архитектуры для большинства корпоративных сценариев в России, о предпочтении речь уже не идёт. Для банка это и есть ответ на вопрос «своё железо или API» из [блока 03](/ai-cto/ii-agenty-i-podhody/).
- **Ландшафт поставщиков:** Сбер делит модели на 4 категории: зарубежные проприетарные (доступ ограничен или закрыт для критичных задач и данных с персональными данными), отечественные коммерческие (GigaChat от Сбера, YandexGPT, T-Pro от Т-Технологий, Cotype от МТС, у них приоритет для задач с персональными данными и регуляторным контекстом), открытые модели для развёртывания на своём железе (нужны GPU-кластеры и экспертиза в MLOps – эксплуатации моделей машинного обучения) и корпоративные шлюзы-прокси, через которые идёт весь трафик к моделям. Качество отечественных моделей здесь оценивает Сбер, который сам один из поставщиков, поэтому проверяйте их на своём наборе эталонных задач.
- **Архитектурный принцип, общий для Сбера и этого курса:** среда работы агентов должна быть отделена от конкретной модели. Тогда можно держать отечественную модель для данных с ограничениями и зарубежную для экспериментов, менять поставщика без переписывания процесса и не зависеть от одного вендора. Об этом же говорит раздел про зависимость от поставщика в [блоке 03](/ai-cto/ii-agenty-i-podhody/).
- **Кадры:** Сбер отмечает, что у российских инженеров сильная техническая база, но меньше практического опыта с агентными процессами, доступ к GitHub Copilot, Cursor и Claude Code частично закрыт, а документация и сообщества в основном англоязычные. Отсюда их рецепт: внутренняя программа «проводников». В организации от 50 команд группа из 5–7 опытных инженеров учит остальных, и практики передаются от коллеги к коллеге.

### Источники

- [The Register, 3 утечки кода Samsung через ChatGPT, апрель 2023](https://www.theregister.com/2023/04/06/samsung_reportedly_leaked_its_own)
- [Bloomberg, Samsung запретил ИИ-инструменты после утечки кода, май 2023](https://www.bloomberg.com/news/articles/2023-05-02/samsung-bans-chatgpt-and-other-generative-ai-use-by-staff-after-leak)
- [IBM Cost of a Data Breach Report 2025 (PDF)](https://www.bakerdonelson.com/webfiles/Publications/20250822_Cost-of-a-Data-Breach-Report-2025.pdf)
- [OWASP Top 10 для LLM-приложений 2025, официальная страница](https://genai.owasp.org/llm-top-10/)
- [Сбер, AI-Disrupt PDLC, часть 8 «Российский корпоративный контекст»](https://sbertech.ru/whitepaper)
- [152-ФЗ, ст. 18 и ст. 12, КонсультантПлюс](https://www.consultant.ru/document/cons_doc_LAW_61801/)
- [Положение Банка России 851-П, обзор](https://ppt.ru/obzory/vstupaet-v-silu/polozhenie-banka-rossii-30-01-2025-851-p) и [новость УЦСБ о замене 683-П, Хабр](https://habr.com/ru/companies/ussc/news/903152)
- [Приказ ФСТЭК № 117, обзор](https://ppt.ru/amp/obzory/vstupaet-v-silu/prikaz-fstek-rossii-11-04-2025-117) и [проект требований к ИИ в ГИС, август 2026](https://regulation.gov.ru/projects/170500/)

## Что говорят коллеги

Даниил: Банк · 200 инженеров · первый год. Мария: Продуктовая компания · второй год.

### После варианта A

**Даниил:** В банке такая эскалация закончилась бы ещё быстрее: у ИБ у нас фактически право вето, о чём генеральный знает. Но соблазн понимаю, потому что 2 месяца переписки с ИБ я уже проходил. Разница в том, когда приходить. Если бы ИБ узнала о пилоте от вас и до выбора инструмента, вопрос «куда уходит код» решался бы в договоре с поставщиком и до кабинета генерального не дошёл бы.

**Мария:** У нас безопасник сначала тоже был проверяющим, поэтому каждый шаг шёл неделями. Перелом случился, когда мы позвали его в платформенную команду на полставки. Через месяц он сам писал правила для агентов, причём они были реалистичнее наших. Эскалация даёт пилоту неделю, а союзник в ИБ даёт следующие 2 года. Добавлю, что инцидент с личным аккаунтом случился бы при любом вашем выборе, пока нет политики.

- **Даниил:** Мария, полставки человека из ИБ в банке потребуют отдельного согласования на полгода.
- **Мария:** Тогда вместо полставки хватит одного созвона в неделю. Важно, чтобы он видел процесс изнутри.
- **Даниил:** На созвон согласен, но подпись под правилами он всё равно поставит только после своего начальства.

### После варианта B

**Даниил:** Для банка это верное направление, ошибки в самом решении нет: персональные данные клиентов во внешнюю зарубежную модель отправлять нельзя, поэтому своё железо у нас всё равно будет. Ошибка в том, что вы остановили ради него всё. Я бы разделил работу: в контур уходит то, где есть персональные данные и закрытые системы, а остальное – к отечественному поставщику по договору, с журналом и политикой. Зарубежные модели у нас запрещены политикой. Тогда пилот продолжает работать, а ИБ видит, что вы движетесь к контуру.

**Мария:** Мы считали своё железо 2 раза и оба раза отказались: для 60 инженеров оно не окупается, а дороже оборудования оказываются люди, которые его обслуживают. Узкие задачи с чувствительными данными отдаём отечественному поставщику по договору. Если бы я начинала заново, я бы сначала отделила среду агентов от модели: тогда переезд в контур сводится к смене одной настройки и новый пилот с нуля запускать незачем.

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

### После варианта C

**Даниил:** Это правильный порядок, но для банка его мало. К политике на одну страницу у нас добавятся приложения для юристов: каждый пункт придётся связать с положениями Банка России. Журнал аудита мы будем хранить столько, сколько скажет регулятор, срок из тарифа здесь ничего не решает. Ещё я бы заранее спросил юристов, относится ли что-то из наших систем к КИИ: тогда выбор инструмента может быть закрыт по закону, а разговор с ИБ уже ничего не изменит.

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

- **Даниил:** Мария, политика на одну страницу в банке не пройдёт юристов, им нужна ссылка на каждое положение Банка России.
- **Мария:** Пусть ссылки живут в приложениях для юристов, а инженерам нужна одна страница, иначе её никто не прочитает.
- **Даниил:** Согласен, если это 1 документ: страница для инженеров и приложения к ней. О 2 разных политиках аудитор спросит первым делом.

## Промпт для документа: Политика использования ИИ, 8 пунктов

1 страница по шаблону из [блока 15](/ai-cto/shablony/): 8 пунктов, которые простым языком отвечают на вопросы ИБ. Документ на 20 страниц никто не прочитает. Скопируйте промпт в модель, которую разрешила ваша служба ИБ (ChatGPT, Claude, GigaChat, YandexGPT или другую). Модель задаст вопросы по одному и по ответам соберёт документ. Не вставляйте в ответы секреты, персональные данные и код из закрытых систем.

```
Ты – технический директор, который уже согласовывал ИИ-инструменты с ИБ и юристами. Помоги мне написать «Политику использования ИИ в разработке» на 1 страницу, 8 пунктов, простым языком.

Пункты политики:
1. Разрешённые инструменты: какие инструменты и модели можно использовать, где они работают (облако поставщика, отечественный поставщик, наш контур) и как добавить новый инструмент.
2. Аккаунты: только корпоративные.
3. Что нельзя отправлять в модель: секреты и ключи; персональные данные клиентов; код систем из закрытого списка; внутренние документы с грифом. Спроси, что ещё добавить.
4. Ответственность: за код отвечает тот, кто его смержил, а не ИИ.
5. Ревью: какие правила ревью для такого кода.
6. Агенты и бюджет: какие действия агента требуют подтверждения человека (внешняя отправка данных; удаление; деплой – спроси, что ещё); лимит на расход токенов и что происходит при его достижении.
7. Журнал и инциденты: что записываем в журнал запросов и где он хранится (в нашем шлюзе или у поставщика); что делать, если в модель ушло лишнее, и куда сообщать без санкций за своевременное сообщение.
8. Контакты: к кому идти с вопросами.

Что ещё нужно выяснить:
- Какие опасения ИБ уже озвучила.

Пункты 2 и 4 – позиция по умолчанию. Если я предлагаю более слабый вариант (личные аккаунты, ответственность «на ИИ»), возрази и объясни риск.

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

Пиши коротко: каждый пункт – 1–3 предложения без юридических оборотов.

Правила работы:
- Задавай по 1 вопросу за раз и жди моего ответа.
- Начни с 4 вопросов о компании, по одному: сколько в ней инженеров; чем она занимается; есть ли жёсткие требования ИБ или регулятора; используете ли вы ИИ в разработке уже сейчас и как. Учитывай ответы дальше.
- Если ответ размытый, попроси цифру или конкретный пример.
- Если я не знаю ответа, предложи 2–3 варианта и коротко объясни разницу. Не придумывай данные за меня.
- Если ответа нет и после вариантов, оставь поле пустым и иди дальше. На слово «собирай» собери документ из того, что есть.
- Если новый ответ противоречит прежнему, скажи об этом и спроси, какой ответ верный. Если я не могу выбрать, запиши оба значения в список того, что осталось пустым или слабым.
- Когда все вопросы закрыты, собери документ в формате ниже. После документа отдельным списком перечисли, что осталось пустым или слабым и как это закрыть.

Формат документа: заголовок, дата «[дата]», 8 пронумерованных пунктов, внизу – кто согласовал (оставь места для подписи ИБ и юристов; если их нет – для технического и генерального директора).
```

Пример заполненной политики – в [блоке 15](/ai-cto/shablony/), раздел «Политика использования ИИ».

## Итог блока

- **После варианта A:** Квартал прошёл не так, как хотелось: эскалация выиграла неделю ценой доверия ИБ. Главное из блока: к ИБ приходят до выбора инструмента и спрашивают условия вместо просьбы согласовать готовое. Если захотите, пройдите развилку заново: реплики Даниила и Марии будут другими.
- **После варианта B:** Квартал прошёл не так, как хотелось: свой контур нужен, но останавливать ради него пилот было лишним. Главное из блока: у каждого опасения ИБ свой ответ, а модель в контуре отвечает только на вопрос о данных с ограничениями. Если захотите, пройдите развилку заново: реплики Даниила и Марии будут другими.
- **После варианта C:** Вы выбрали позвать ИБ в пилот, это правильный ответ, хотя Даниил прав, что в банке к одной странице добавятся юристы и регулятор. Главное из блока: к ИБ приходят до выбора инструмента, а политика помещается на одну страницу. Соберите документ по промпту и переходите дальше.