Безопасность и комплаенс при работе с ИИ
В корпорации внедрение чаще всего останавливается на службе информационной безопасности, а технология и деньги мешают ему реже. Этот блок о том, как пройти этот этап: что ИБ будет спрашивать, какие правила нужно установить до старта, как обеспечить аудит и что добавляет российская специфика. Комплаенс здесь означает соответствие требованиям регуляторов и внутренним политикам.
Вы технический директор, а руководитель ИБ узнал про пилот и готов его остановить. Дальше – как превратить ИБ из блокера в участника: с какими вопросами она придёт, что должно быть готово заранее и чем российское регулирование отличается от западных чек-листов.
ИБ узнала про пилот
Мне сказали, что у вас пилот с ИИ. Код куда уходит? Кто что отправлял, где журнал? Пока не увижу ответов, ставлю запрет на внешние ИИ-инструменты. Неделя у вас есть.
С чем вы пойдёте к руководителю ИБ?
Что происходит через квартал: все варианты
Цифры условные: они показывают направление изменений, точной величины в них нет. Шаблон политики и чек-лист для ИБ лежат в блоке 15, защита от prompt injection разобрана в блоке 12.
Вариант A. Решить через генерального: Пилот спасли, ИБ потеряли
Генеральный позвонил руководителю ИБ, после чего пилот формально продолжился. Каждый следующий шаг ИБ теперь согласовывала по 2 месяца, а расширение на вторую команду так и не одобрила. В конце квартала инженер вне пилота отправил в чат-ассистент на личном аккаунте конфигурацию с ключами доступа, о чём узнали случайно. ИБ запретила все внешние ИИ-инструменты, включая ваш пилот, а генеральный на этот раз спорить не стал.
| Метрика | Было | Стало |
|---|---|---|
| Дней на согласование (медиана по заявкам в ИБ) | 14 | 60 |
| Использование через корпоративные инструменты (доля до запрета в конце квартала, по данным инструмента) | 55% | 40% |
| Запросы с журналом аудита (доля от всех запросов к моделям) | 0% | 0% |
| Инциденты с отправкой лишнего (найдены случайно) | 0 | 1 |
| Активные пользователи в пилоте (по данным инструмента, после запрета) | 85% | 0% |
Вердикт: Вы выиграли неделю и потеряли квартал. ИБ могла стать союзником, а стала проверяющим, и после инцидента её запрет уже не оспорить.
Что говорят коллеги после варианта A
Даниил: В банке такая эскалация закончилась бы ещё быстрее: у ИБ у нас фактически право вето, о чём генеральный знает. Но соблазн понимаю, потому что 2 месяца переписки с ИБ я уже проходил. Разница в том, когда приходить. Если бы ИБ узнала о пилоте от вас и до выбора инструмента, вопрос «куда уходит код» решался бы в договоре с поставщиком и до кабинета генерального не дошёл бы.
Мария: У нас безопасник сначала тоже был проверяющим, поэтому каждый шаг шёл неделями. Перелом случился, когда мы позвали его в платформенную команду на полставки. Через месяц он сам писал правила для агентов, причём они были реалистичнее наших. Эскалация даёт пилоту неделю, а союзник в ИБ даёт следующие 2 года. Добавлю, что инцидент с личным аккаунтом случился бы при любом вашем выборе, пока нет политики.
- Даниил: Мария, полставки человека из ИБ в банке потребуют отдельного согласования на полгода.
- Мария: Тогда вместо полставки хватит одного созвона в неделю. Важно, чтобы он видел процесс изнутри.
- Даниил: На созвон согласен, но подпись под правилами он всё равно поставит только после своего начальства.
Итог: Квартал прошёл не так, как хотелось: эскалация выиграла неделю ценой доверия ИБ. Главное из блока: к ИБ приходят до выбора инструмента и спрашивают условия вместо просьбы согласовать готовое. Если захотите, пройдите развилку заново: реплики Даниила и Марии будут другими.
Вариант B. Уйти в свой контур: Свой контур, потерян квартал
ИБ была довольна: код не покидает периметр, вопросов нет. Но оборудование пришло только к концу второго месяца, а людей, которые умеют его обслуживать, искали до конца квартала. Всё это время пилот стоял, а инженеры, привыкшие к ассистенту, вернулись к личным аккаунтам, из-за чего теневое использование выросло. Первые ответы открытой модели в контуре оказались заметно слабее того, к чему команда привыкла.
| Метрика | Было | Стало |
|---|---|---|
| Дней на согласование (медиана по заявкам в ИБ) | 14 | 7 |
| Использование через корпоративные инструменты (доля, по данным инструмента) | 55% | 30% |
| Расходы на ИИ (оборудование и люди, план = 100) | 100 | 240 |
| Время от коммита до прода (пилотная команда, метрика DORA) | 5,5 дн | 6 дн |
| Активные пользователи в пилоте (по данным инструмента) | 85% | 0% |
Вердикт: Для закрытых данных решение правильное. Но вы применили его ко всему сразу и потеряли квартал без пилота.
Что говорят коллеги после варианта B
Даниил: Для банка это верное направление, ошибки в самом решении нет: персональные данные клиентов во внешнюю зарубежную модель отправлять нельзя, поэтому своё железо у нас всё равно будет. Ошибка в том, что вы остановили ради него всё. Я бы разделил работу: в контур уходит то, где есть персональные данные и закрытые системы, а остальное – к отечественному поставщику по договору, с журналом и политикой. Зарубежные модели у нас запрещены политикой. Тогда пилот продолжает работать, а ИБ видит, что вы движетесь к контуру.
Мария: Мы считали своё железо 2 раза и оба раза отказались: для 60 инженеров оно не окупается, а дороже оборудования оказываются люди, которые его обслуживают. Узкие задачи с чувствительными данными отдаём отечественному поставщику по договору. Если бы я начинала заново, я бы сначала отделила среду агентов от модели: тогда переезд в контур сводится к смене одной настройки и новый пилот с нуля запускать незачем.
- Мария: Даниил, ты правда считаешь, что в банке без своего контура вообще ничего нельзя?
- Даниил: Для данных клиентов да, считаю. Отечественный инференс для нас обязательное требование, выбирать тут нечего.
- Мария: А для кода без персональных данных свой контур становится просто дорогой осторожностью, за которую платишь кварталом.
Итог: Квартал прошёл не так, как хотелось: свой контур нужен, но останавливать ради него пилот было лишним. Главное из блока: у каждого опасения ИБ свой ответ, а модель в контуре отвечает только на вопрос о данных с ограничениями. Если захотите, пройдите развилку заново: реплики Даниила и Марии будут другими.
Вариант C. Позвать ИБ в пилот: ИБ стала соучастником
Разговор начался тяжело: руководитель ИБ спросил, почему он узнал о пилоте последним. Но вы пришли с ответом на каждое опасение, поэтому запрета не было. Шлюз с журналом запустили за неделю, политику безопасности приняли за 2 недели, сервисы с персональными данными вывели из пилота и начали выбирать отечественного поставщика для них. Человек из ИБ ходил на встречи команды и сам предложил, как упростить заявку на новый инструмент. Один инженер отправил в модель лишнее и сам об этом сообщил.
| Метрика | Было | Стало |
|---|---|---|
| Дней на согласование (нового инструмента, по процедуре) | нет данных | 10 |
| Использование через корпоративные инструменты (доля, по данным инструмента) | 55% | 80% |
| Запросы с журналом аудита (доля от всех запросов к моделям) | 0% | 100% |
| Инциденты с отправкой лишнего (о которых сообщили сами) | 0 | 1 |
| Сервисов в пилоте (без персональных данных) | 8 | 5 |
Вердикт: Пилот стал меньше, зато его больше никто не остановит. Правила вы написали вместе с теми, кто будет их проверять.
Что говорят коллеги после варианта C
Даниил: Это правильный порядок, но для банка его мало. К политике на одну страницу у нас добавятся приложения для юристов: каждый пункт придётся связать с положениями Банка России. Журнал аудита мы будем хранить столько, сколько скажет регулятор, срок из тарифа здесь ничего не решает. Ещё я бы заранее спросил юристов, относится ли что-то из наших систем к КИИ: тогда выбор инструмента может быть закрыт по закону, а разговор с ИБ уже ничего не изменит.
Мария: Мы сделали ровно так же и считаем это лучшим решением нашего первого года. Добавлю одно: пункт «без санкций за своевременное сообщение» оказался важнее остальных. Пока за отправку лишнего наказывали, нам ничего не сообщали, поэтому об инцидентах мы узнавали случайно. Ещё проверяйте политику на деле: раз в квартал смотрите по данным инструмента, сколько использования идёт мимо корпоративных инструментов. Если доля растёт, значит, политика слишком строгая.
- Даниил: Мария, политика на одну страницу в банке не пройдёт юристов, им нужна ссылка на каждое положение Банка России.
- Мария: Пусть ссылки живут в приложениях для юристов, а инженерам нужна одна страница, иначе её никто не прочитает.
- Даниил: Согласен, если это 1 документ: страница для инженеров и приложения к ней. О 2 разных политиках аудитор спросит первым делом.
Итог: Вы выбрали позвать ИБ в пилот, это правильный ответ, хотя Даниил прав, что в банке к одной странице добавятся юристы и регулятор. Главное из блока: к ИБ приходят до выбора инструмента, а политика помещается на одну страницу. Соберите документ по промпту и переходите дальше.
Четыре опасения ИБ и как их закрыть
Вы выбрали прийти к ИБ с ответами и позвать её в пилот. Ниже разобраны 4 опасения ИБ, 5 главных вопросов политики из её 8 пунктов и то, что добавляет российская специфика.
Главная ошибка состоит в том, чтобы прийти к ИБ с готовым решением и попросить его согласовать. Так вы получаете отказ или 2 месяца переписки, о которых я писал в блоке 01. Правильный порядок другой: прийти до выбора инструмента и спросить, какие условия нужно выполнить, чтобы согласование прошло.
Первая встреча с ИБ, если нет ни инструмента, ни пилота. На 1 час, с руководителем ИБ или тем, кто согласует новые инструменты. Повестка:
- Зачем внедряем: 2–3 причины и метрики к ним (документ блока 02).
- Что уже происходит: кто и чем пользуется через личные аккаунты. Без поиска виноватых.
- Какие данные и системы не трогаем: персональные данные, критичные системы, КИИ, требования регулятора (раздел про российскую специфику ниже).
- Условия согласования: какие пути ИБ допускает (отечественный поставщик, модель в контуре, зарубежная модель для остального кода, шлюз) и что ей нужно увидеть по каждому из 4 опасений ниже.
- Процедура и срок: кто согласует, сколько это займёт, какие документы нужны от вас.
- Участник пилота от ИБ и дата следующей встречи – на ней вы покажете черновик политики на одну страницу.
Результат встречи – список требований ИБ и имя участника. С ними можно выбирать инструмент.
У ИБ 4 типовых опасения, каждое из них нужно закрыть явно.
- Куда уходит код: самый известный пример даёт Samsung. В марте 2023 года, меньше чем через 3 недели после того, как инженерам разрешили ChatGPT, случились как минимум 3 утечки: исходный код программы для базы данных полупроводников, код для поиска неисправного оборудования и запись совещания. В мае компания запретила внешние ИИ-инструменты. Ответ на опасение: корпоративный тариф с договором об отказе от обучения на ваших данных, модель на своём железе или оба варианта сразу.
- Кто и что делал: ответ даёт журнал действий (см. раздел про аудит).
- Что попадёт в код снаружи: нужны те же проверки, что и для человеческого кода (статический анализ безопасности и проверка зависимостей, блок 09), плюс защита от prompt injection (блок 12).
- Как это согласуется с регуляторами: ответ в разделе про российскую специфику ниже.
Практический совет: назначьте одного человека из ИБ соучастником пилота вместо проверяющего. Когда ИБ видит процесс изнутри, согласование идёт быстрее, а правила выходят реалистичными.
Политика использования ИИ (шаблон из 8 пунктов в блоке 15) отвечает на вопросы ИБ простым языком. Главных вопросов 5:
- Какие инструменты разрешены: нужен явный список вместо формулировки «любые на усмотрение». Всё остальное запрещено, но есть понятная процедура добавления нового инструмента.
- Что нельзя отправлять в модель: секреты, ключи, персональные данные клиентов, код закрытых систем, если нет контура. Список должен быть конкретным.
- Какие аккаунты использовать: только корпоративные, потому что личный аккаунт в точности повторяет сценарий Samsung.
- Кто отвечает за код: инженер, который его смержил, на ИИ ответственность переложить нельзя. Это важно для аудита и для культуры: слова «так написал ИИ» оправданием не считаются.
- Что делать при инциденте: куда сообщать, если отправили лишнее.
Политика должна помещаться на одну страницу. Документ на 20 страниц никто не прочитает, поэтому теневое использование из блока 02 вернётся.
согласование с ИБ – главный критический путь внедрения, закладывайте на него от 2 недель до квартала и начинайте до выбора инструмента. Для кода критичных систем и данных с ограничениями нужна модель в контуре или отечественный поставщик по договору. Зарубежный корпоративный тариф без обучения на ваших данных подходит только для остального кода, и у него своя цена. Anthropic и OpenAI с Россией официально не работают. Anthropic не обслуживает и компании, которые контролируются из России, где бы они ни были зарегистрированы. На практике такой тариф получают через иностранное юрлицо или через реселлера. Риски: аккаунт могут заблокировать без предупреждения, договор об отказе от обучения заключён с посредником, а не с вами, оплата идёт через третьих лиц. Такую схему решают вместе с юристами и ИБ.
Есть и российские прокси-сервисы (я упоминал о них в блоке 03). Договор и счёт выставляет российская компания, закрывающие документы приходят через ЭДО. Часть таких сервисов включена в реестр российского ПО и участвует в закупках по 223-ФЗ. Для бухгалтерии и закупок это решает вопрос оплаты. Для ИБ этого может быть мало: юридические моменты нужно уточнить с поставщиком. Перед договором спросите прокси-сервис:
- куда физически уходят запросы;
- описана ли трансграничная передача в договоре и в политике обработки персональных данных;
- где и сколько хранится журнал запросов;
- подпишет ли он NDA и ответит ли на анкету ИБ.
службы ИБ нет, поэтому её роль берёт на себя технический директор. Минимум: политика на одну страницу (блок 15), включённые у поставщика режимы «без обучения на данных» и «без хранения запросов», проверка, что в репозитории нет секретов. Если вы обрабатываете персональные данные клиентов, 152-ФЗ действует и на вас, независимо от размера.
2 слоя правил: политики ИБ и уточнения проекта
Политика на одну страницу – это документ для людей. Но агент документы в вики не читает, он читает файлы в репозитории. Значит, правила ИБ должны лежать там же, где код, и тут возникает опасность: если правила безопасности лежат в том же файле контекста, что и договорённости команды, любой инженер или сам агент при очередной перегенерации может их стереть, и никто не заметит: файл по-прежнему выглядит правдоподобно.
Решение – разделить правила на 2 слоя с разными владельцами. Так устроен мой инструмент Brownspec из блока 03, но подход работает с любым инструментом.
| Файл | Кто пишет | Кто может менять | Что внутри |
|---|---|---|---|
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) часто дают часть функций шлюза из коробки:
- роли «владелец, администратор, сотрудник»;
- вход через корпоративный SSO;
- лимиты на сотрудника и команду;
- отчёт о расходах по сотрудникам и ключам.
Для небольшой компании это быстрый старт. Прокси-сервис технически обрабатывает содержимое всех запросов, поэтому в корпорации свой шлюз (LiteLLM, Portkey) ставят перед прокси-сервисом.
Ещё одна деталь: в кабинетах прокси-сервисов администратор компании часто видит историю чатов сотрудников. Напишите об этом в политике (блок 15), чтобы для сотрудников это не стало сюрпризом.
Если данные с персональными данными нельзя отправлять зарубежному поставщику, а модели в контуре пока нет, помогает маскирование до отправки. Персональные данные в запросе заменяются заглушками, модель видит только их, а в ответе настоящие значения подставляются обратно. Одинаковые значения получают одну заглушку, поэтому модель не теряет связи: она понимает, что в 2 местах один и тот же человек.
Пример (документация GPTunneL):
| Шаг | Текст |
|---|---|
| Запрос сотрудника | Меня зовут Иван Петров, телефон +7 916 245-33-18. Составь подпись к письму. |
| Видит поставщик модели | Меня зовут <<PER0>>, телефон <<PHONE1>>. Составь подпись к письму. |
| Отвечает модель | С уважением, <<PER0>>, тел. <<PHONE1>> |
| Получает сотрудник | С уважением, Иван Петров, тел. +7 916 245-33-18 |
Где это взять: свой шлюз с модулем маскирования или российский прокси, у которого маскирование встроено. Хороший маскировщик распознаёт:
- ФИО в любом падеже;
- паспорт, ИНН, СНИЛС;
- номера карт и счетов;
- телефоны и адреса;
- пароли и ключи API.
Внутренние идентификаторы, например номера договоров и табельные номера, маскировщик не знает. Их добавляют своими шаблонами.
Что проверить, прежде чем на это опираться:
- Что происходит, если маскировщик недоступен. Правильный ответ: запрос отклоняется, а не уходит без маскирования.
- Работает ли маскирование в том формате API, через который ходит ваш инструмент. У прокси-сервисов оно бывает только в одном из форматов: OpenAI или Anthropic.
- Маскируются ли картинки и вложения. Обычно нет.
- Качество на ваших данных. Прогоните 50–100 реальных фрагментов журналов и обращений и посчитайте, сколько данных прошло мимо.
Маскирование снижает риск, но не решает юридический вопрос. Если по контексту человека можно узнать, замаскированный текст остаётся персональными данными. Поэтому вопрос о трансграничной передаче (ниже, «Российская специфика») всё равно решают юристы. Для данных, которые закон или ИБ запрещают выпускать за периметр, нужна модель в контуре. В сопровождении маскирование – главный способ начать разбирать журналы с ИИ, не дожидаясь модели в контуре (блок 10).
Здесь я даю только ориентиры, юридической консультацией они не являются. Точные требования для вашей отрасли уточняйте у юристов и у вашей ИБ, а редакцию норм – на consultant.ru или garant.ru: они меняются. Подробная открытая сводка регуляторных требований к ИИ в российской корпоративной разработке содержится в части 8 whitepaper Сбера «AI-Disrupt PDLC». Это документ вендора, который продвигает собственную методологию и собственные модели, но регуляторная часть в нём изложена предметно. Дальше я опираюсь на неё и помечаю, где взгляд Сбера и где мой.
- Персональные данные: по федеральному закону 152-ФЗ запись, накопление и хранение персональных данных граждан России при сборе идут в базах данных на территории России (ст. 18 ч. 5). Перед трансграничной передачей оператор обязан уведомить Роскомнадзор (ст. 12), а для самой передачи нужно законное основание – согласие субъекта лишь одно из них. За нарушения предусмотрены штрафы. Отправка клиентских данных во внешнюю зарубежную модель почти наверняка нарушит эти требования. На практике в промптах не должно быть клиентских данных, либо модель должна стоять в вашем контуре или у отечественного поставщика.
- Банки и финансовые организации: требования к защите информации в банках задаёт положение Банка России 851-П. Оно действует с 29 марта 2025 года и заменило 683-П. В некредитных финансовых организациях – 757-П. Среди требований 851-П – оценка соответствия прикладного ПО при изменении его исходного кода, значит, и кода, написанного с ИИ. Требования к операционной надёжности задаёт отдельное положение 787-П. По оценке Сбера, для финансовых организаций решения, принятые с участием ИИ-агентов, должны быть документированы и воспроизводимы при регуляторной проверке. Это прямое требование к аудиту действий из предыдущего раздела. Для такой оценки пригодится цепочка по каждому релизу: требование – изменение – тест – проверка безопасности – решение о выпуске. Её можно вести вручную или в платформе, которая собирает её сама (блок 03).
- Критическая информационная инфраструктура: для субъектов КИИ (критической информационной инфраструктуры) действуют закон 187-ФЗ, приказы ФСТЭК (Федеральной службы по техническому и экспортному контролю) о защите информации и указы Президента № 166 и № 250 от 2022 года, которые ограничивают использование иностранного программного обеспечения и средств защиты. Если ваши системы относятся к значимым объектам КИИ, иностранный ИИ-инструмент может запретить сам закон, независимо от соображений ИБ.
- Государственные информационные системы: с 1 марта 2026 года действует приказ ФСТЭК № 117 о защите информации в ГИС. В августе 2026 года ФСТЭК вынесла на обсуждение проект дополнений к нему про ИИ: отдельный сегмент для ИИ, многофакторная аутентификация, минимальные права, фильтрация входных и выходных данных, контроль ИИ-агентов. Планируемый срок вступления – 1 марта 2027 года. Если вы делаете ГИС или работаете на госзаказчика, учитывайте эти требования уже сейчас.
- Вывод Сбера, с которым я согласен: совокупность этих норм делает отечественный инференс (работу модели в российском контуре) обязательным компонентом архитектуры для большинства корпоративных сценариев в России, о предпочтении речь уже не идёт. Для банка это и есть ответ на вопрос «своё железо или API» из блока 03.
- Ландшафт поставщиков: Сбер делит модели на 4 категории: зарубежные проприетарные (доступ ограничен или закрыт для критичных задач и данных с персональными данными), отечественные коммерческие (GigaChat от Сбера, YandexGPT, T-Pro от Т-Технологий, Cotype от МТС, у них приоритет для задач с персональными данными и регуляторным контекстом), открытые модели для развёртывания на своём железе (нужны GPU-кластеры и экспертиза в MLOps – эксплуатации моделей машинного обучения) и корпоративные шлюзы-прокси, через которые идёт весь трафик к моделям. Качество отечественных моделей здесь оценивает Сбер, который сам один из поставщиков, поэтому проверяйте их на своём наборе эталонных задач.
- Архитектурный принцип, общий для Сбера и этого курса: среда работы агентов должна быть отделена от конкретной модели. Тогда можно держать отечественную модель для данных с ограничениями и зарубежную для экспериментов, менять поставщика без переписывания процесса и не зависеть от одного вендора. Об этом же говорит раздел про зависимость от поставщика в блоке 03.
- Кадры: Сбер отмечает, что у российских инженеров сильная техническая база, но меньше практического опыта с агентными процессами, доступ к GitHub Copilot, Cursor и Claude Code частично закрыт, а документация и сообщества в основном англоязычные. Отсюда их рецепт: внутренняя программа «проводников». В организации от 50 команд группа из 5–7 опытных инженеров учит остальных, и практики передаются от коллеги к коллеге.
Что включить в политику использования ИИ?
Политика использования ИИ – документ на 1 страницу из 8 пунктов: разрешённые инструменты, аккаунты, что нельзя отправлять в модель, ответственность за код, ревью, где нужно подтверждение человека, журнал и инциденты, контакты.
Что говорят коллеги
Это правильный порядок, но для банка его мало. К политике на одну страницу у нас добавятся приложения для юристов: каждый пункт придётся связать с положениями Банка России. Журнал аудита мы будем хранить столько, сколько скажет регулятор, срок из тарифа здесь ничего не решает. Ещё я бы заранее спросил юристов, относится ли что-то из наших систем к КИИ: тогда выбор инструмента может быть закрыт по закону, а разговор с ИБ уже ничего не изменит.
Мы сделали ровно так же и считаем это лучшим решением нашего первого года. Добавлю одно: пункт «без санкций за своевременное сообщение» оказался важнее остальных. Пока за отправку лишнего наказывали, нам ничего не сообщали, поэтому об инцидентах мы узнавали случайно. Ещё проверяйте политику на деле: раз в квартал смотрите по данным инструмента, сколько использования идёт мимо корпоративных инструментов. Если доля растёт, значит, политика слишком строгая.
Обсуждение:
Политика использования ИИ, 8 пунктов
1 страница по шаблону из блока 15: 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, раздел «Политика использования ИИ».
Вы выбрали позвать ИБ в пилот, это правильный ответ, хотя Даниил прав, что в банке к одной странице добавятся юристы и регулятор. Главное из блока: к ИБ приходят до выбора инструмента, а политика помещается на одну страницу. Соберите документ по промпту и переходите дальше.
Дальше блок 06 «Сбор требований»: В блоке 03 я говорил, что при разработке от спецификации работа руководителя смещается с проверки кода на проверку постановки задачи.
Источники блока
- The Register, 3 утечки кода Samsung через ChatGPT, апрель 2023
- Bloomberg, Samsung запретил ИИ-инструменты после утечки кода, май 2023
- IBM Cost of a Data Breach Report 2025 (PDF)
- OWASP Top 10 для LLM-приложений 2025, официальная страница
- Сбер, AI-Disrupt PDLC, часть 8 «Российский корпоративный контекст»
- 152-ФЗ, ст. 18 и ст. 12, КонсультантПлюс
- Положение Банка России 851-П, обзор и новость УЦСБ о замене 683-П, Хабр
- Приказ ФСТЭК № 117, обзор и проект требований к ИИ в ГИС, август 2026