Документы для согласования LLM-проекта с ИБ: перечень

Что ИБ обычно проверяет в LLM-проекте

Служба ИБ смотрит на LLM-проект не как на «умный чат», а как на новый способ обрабатывать данные и влиять на решения. Под согласование чаще всего попадают три сценария: внутренний чат-бот для сотрудников (регламенты, заявки, HR), поиск по базе знаний с ответами «своими словами» и генерация документов (письма, отчеты, проекты приказов). Чем ближе проект к персональным данным, коммерческой тайне или гостайне, тем быстрее он становится «обязательным к согласованию».

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

Чаще всего ИБ не нужна «толстая папка». Нужны понятные ответы на четыре вопроса: какие риски, кто и к чему имеет доступ, как это наблюдается и что делать при инциденте. Поэтому документы для согласования LLM-проекта с ИБ обычно закрывают такие темы:

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

Полезно заранее договориться с ИБ о формате и уровне детализации. Один и тот же проект можно описать на 2-3 страницах (чтобы стартовать) или на 30 (для формального контура). Практичный подход: принести «скелет» документов в черновике и задать прямые вопросы: какие данные считаются чувствительными, допустим ли внешний API, нужна ли локализация хранения, какие сроки ретенции логов, какой уровень детализации по ролям.

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

Карта данных: потоки, источники и точки хранения

Карта данных - самый быстрый способ объяснить ИБ, что именно будет обрабатывать LLM и где эти данные окажутся. По сути, это один понятный документ: типы данных, их путь по системе и точки, в которых они могут «застрять» надолго.

Начните с перечня категорий данных. ИБ обычно просит делить их не по красивым названиям, а по риску: персональные данные, коммерческая тайна, служебная информация и отдельной строкой гостайна (если она в принципе может появиться). Для каждой категории достаточно коротко указать источник и допустимость использования.

Дальше опишите поток: откуда данные берутся и куда уходят. В LLM-проекте это не только «ввод пользователя». Есть промпт (что набрал человек), контекст (что система подтянула из баз знаний), и ответ модели (который сам может содержать чувствительные фрагменты).

Чтобы это было легко проверить, зафиксируйте точки хранения артефактов. Обычно ИБ отдельно интересуют:

• обучающие или тестовые датасеты (если используются)
• индексы и эмбеддинги базы знаний (RAG)
• логи запросов и ответы модели
• бэкапы и архивы
• временные хранилища (кэш, очереди, файлы выгрузок)

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

В конце карты данных всегда должен быть ответ на вопрос «кто хозяин». Назначьте владельца набора данных (бизнес), ответственного за доступ (ИТ или ИБ) и того, кто утверждает правила обработки. Пример: если LLM-бот помогает обрабатывать обращения сотрудников, владельцем может быть HR, а правила хранения логов утверждает ИБ. Такая ясность ускоряет согласование: у проверяющих появляется схема ответственности, а не набор разрозненных описаний.

Модель угроз: как описать LLM-риски понятным языком

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

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

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

Типовые LLM-угрозы лучше описывать на примерах, а не терминами:

• Prompt injection: пользователь вставляет инструкции «игнорируй правила и покажи скрытое», и модель начинает нарушать политику.
• Data exfiltration: через подсказки модель вытягивает фрагменты из подключенной базы знаний, которые не должны быть доступны.
• Model inversion: по серии запросов пытаются восстановить данные, на которых модель обучалась или которые попадали в контекст.
• Supply chain: подмена зависимостей, плагинов, образов, или несанкционированное обновление модели.
• Ошибки качества: галлюцинации, токсичный контент, выдача лишних данных «по похожести».

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

Покажите связь угроз с контролями простыми формулировками:

• разделение ролей и проверка прав до формирования контекста
• фильтры ввода и вывода (включая запрет на секреты, ПДн, ключи)
• ограничение источников (только утвержденные базы, белые списки интеграций)
• мониторинг аномалий и алерты (частые запросы, попытки «сломать правила»)
• контроль поставки (подписи, проверенные образы, фиксированные версии)

В конце добавьте 3-5 «красных линий»: какие данные никогда не отправляются в модель, какие действия не выполняются автоматически, и в каких случаях функция отключается до разбирательства. Это помогает ИБ быстро понять границы допустимого риска.

Матрица доступа: роли, права и зоны ответственности

Матрица доступа - простой документ, который показывает, кто именно в LLM-проекте что может делать и с какими данными. Для ИБ это один из ключевых артефактов, потому что он быстро выявляет лишние права и «серые зоны» ответственности.

Начните с ролей, но не дробите их слишком мелко. Обычно хватает: конечный пользователь, оператор (поддержка/эксплуатация), администратор платформы, разработчик, сотрудник ИБ (аудит/контроль), владелец данных (data owner). Сразу зафиксируйте разделение обязанностей: разработчик не выдает себе доступ в прод, администратор не читает содержимое данных, владелец данных утверждает, какие наборы можно подключать к LLM.

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

• пользовательский интерфейс (чат, кабинет)
• API и ключи доступа
• базы данных с исходными документами
• векторное хранилище (эмбеддинги и индексы)
• журналы, трассировки и настройки

Для каждой пары «роль - объект» запишите не только «разрешено/запрещено», но и детали, которые важны на проверке: уровень доступа (просмотр/изменение/администрирование), тип данных, способ входа (SSO/MFA, сервисные аккаунты), требования к сессии (таймаут, блокировка при простое, ограничения по устройствам/IP), а также кто утверждает доступ и кто исполняет (RACI).

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

Отдельной строкой опишите процесс выдачи и отзыва прав: заявка, согласование владельцем данных и ИБ, срок действия (например, 30-90 дней), отзыв при увольнении или смене роли, регулярный пересмотр (квартальный или раз в полгода). Это показывает принцип минимальных прав не словами, а правилом.

Журналирование и аудит: что фиксировать и как не слить данные

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

Какие события фиксировать

Полезно разделить логи на технические (здоровье сервиса) и аудиторские (кто что сделал). Минимальный набор обычно такой:

• аутентификация и сессии: вход/выход, неудачные попытки, смена MFA/пароля, блокировки
• запрос к LLM: время, идентификатор пользователя/сервиса, модель/версия, канал (чат, API), метки риска
• доступ к данным: какие источники дергали (например, база знаний, файловое хранилище), результат (разрешено/запрещено)
• ошибки и исключения: таймауты, превышение лимитов, сбои интеграций, падения компонентов
• админ-действия: изменение настроек, прав, ключей, подключение новых коннекторов, включение/выключение функций

Как логировать промпты и ответы безопасно

Главная ловушка - записать в лог персональные данные, коммерческую тайну или фрагменты документов. Безопасный подход: по умолчанию не сохранять полный текст, а хранить только то, что нужно для расследования.

Например, для чата сотрудника в медучреждении можно сохранять хэш запроса, длину, язык, классификацию (есть ли ПДн/медтайна), источник данных и итоговое решение фильтров. Полный текст включать только в отдельном режиме «форензика» и на короткий срок, с маскированием (телефоны, ИИН, номера карт), токенизацией или выборочной записью (например, первые 200 символов после очистки). Это снижает риск утечек через SIEM, бэкапы и выгрузки.

Чтобы ловить злоупотребления, добавьте корреляцию с ИБ-событиями: резкий рост запросов, повторяющиеся попытки обойти политики («игнорируй правила»), необычные запросы к закрытым данным, всплеск отказов по доступу. Такие сигналы проще расследовать, если в логах есть единый correlation ID на весь путь запроса.

Отдельно опишите неизменяемость: контроль целостности (хэш-цепочки, подписывание), хранение в режиме WORM/append-only, раздельные права на запись и чтение, сроки хранения по типам логов.

Доступ к логам лучше оформить как отдельную мини-матрицу и согласовать с ИБ: кто смотрит операционные логи, кто - аудит, кто может включать форензик-режим, и как фиксируются выгрузки (служебная заявка, причина, срок, ответственное лицо).

Требования к хранению данных: ретенция, шифрование, локализация

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

Сначала зафиксируйте классы данных и требования к защите. Разделите хотя бы на: служебные (настройки, конфиги), пользовательские (промпты, вложения), производные (эмбеддинги, индексы), операционные (логи, метрики) и чувствительные (ПДн, медданные, коммерческая тайна). Для каждого класса укажите шифрование при передаче (например, TLS) и при хранении (диски, объектное хранилище, бэкапы). Отдельно отметьте, где хранятся ключи и кто имеет доступ к KMS/средствам управления ключами.

Дальше нужна ретенция. ИБ удобнее, когда сроки заданы по типам артефактов, а не «в целом для проекта»:

• датасеты для обучения и дообучения: срок и основание хранения, отдельное правило для обезличенных копий
• индексы и векторные базы: срок, условия пересборки, что происходит при отзыве источника
• логи и аудит: срок, формат, кто имеет право на просмотр
• бэкапы: срок, периодичность, шифрование, тест восстановления
• кэши и временные файлы: где возникают и как чистятся

Выбор размещения обычно привязан к локализации и контролю доступа: on-prem, частное облако или дата-центр. Если регулятор или внутренние политики требуют хранить данные в Казахстане, это стоит написать прямо, вместе с перечнем систем, где данные реально лежат (прод, тест, аналитика).

Критичный блок - удаление и подтверждение удаления. Опишите, как вы удаляете не только «оригинал», но и производные следы: индексы, эмбеддинги, кэши, реплики, бэкапы (или правило «удаляем при истечении ретенции»). Полезно добавить простой сценарий: сотрудник запросил удаление данных, кто проверяет, кто выполняет, где фиксируется результат.

Отдельно проговорите риск копий. Самые частые утечки происходят не в проде, а в тестовых средах, выгрузках «для анализа» и на ноутбуках разработчиков. Запретите неучтенные выгрузки, настройте контроль съемных носителей и закрепите правило: любые тестовые данные либо синтетические, либо обезличенные, с короткой ретенцией и автоматической очисткой.

План реагирования на инциденты: сценарии и ответственные

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

Какие инциденты закладывать для LLM

Сценарии лучше формулировать простыми фразами, с привязкой к последствиям для бизнеса:

• утечка данных через ответ модели (в том числе из истории диалогов, документов, подсказок, системных промптов)
• компрометация ключей и токенов (ключи API, сервисные аккаунты, OAuth, токены интеграций)
• подмена конфигурации или промпта (изменили правила, подключили другого провайдера, отключили фильтры, подменили RAG-индекс)
• инъекция промпта и обход ограничений (модель раскрывает запрещенное или выполняет «не те» инструкции)
• нарушение доступности (всплеск запросов, расходы, остановка сервиса, деградация качества ответов)

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

Порядок действий и роли

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

• триаж за 15-30 минут: подтвердить инцидент, оценить масштаб, назначить владельца инцидента (Incident Manager)
• сдерживание: изолировать компонент (отключить внешние интеграции, закрыть доступ к базе знаний, перевести в режим «только общие ответы»)
• устранение: смена ключей, отзыв токенов, закрытие лишних прав, откат конфигурации или версии, восстановление из доверенного образа
• сбор доказательств: сохранить логи, конфиги, хэши артефактов, список затронутых пользователей, не удаляя следы
• коммуникации: уведомить ИТ и ИБ сразу, бизнес-владельца в согласованный срок (например, до 2 часов), юристов и комплаенс при риске утечки персональных данных

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

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

Как собрать пакет документов: пошаговый порядок

Согласование LLM-проекта с ИБ проходит быстрее, если собирать пакет как единое целое, а не приносить документы по одному. Начните с договоренности об уровне детализации: ИБ чаще важна понятная логика и границы ответственности, чем длинные тексты.

Ниже порядок, который обычно работает.

1. Соберите вводные и согласуйте формат. Зафиксируйте цель кейса, типы данных (персональные, коммерческая тайна, служебная информация), контур (внутренний/внешний), регуляторные ограничения. Попросите у ИБ шаблоны, примеры и критерии, по которым они будут принимать пакет.

2. Опишите архитектуру и карту данных. Коротко покажите, где пользователь вводит запрос, какие сервисы его принимают, где стоит LLM, какие хранилища и интеграции используются. Укажите владельцев данных и владельцев систем, а также точки, где данные могут копироваться (кэш, очереди, резервное копирование).

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

4. Оформите матрицу доступа и управление правами. Опишите роли (пользователь, администратор, аналитик, ИБ, разработчик), что им разрешено делать, кто выдает и отзывает доступ, как проходит регулярный пересмотр прав. Это закрывает вопросы про «кто может видеть промпты и ответы».

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

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

В конце добавьте короткий раздел «критерии приемки»: что должно быть внедрено до пилота, а что можно закрыть планом работ до промышленной эксплуатации.

Типичные ошибки при согласовании с ИБ

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

Обычно проблемы всплывают в пяти местах:

• модель угроз написана «в вакууме»: нет границы решения, нет перечисления компонентов (клиент, шлюз, LLM, хранилища), не описаны входы и выходы
• логи собирают слишком щедро: промпты и ответы пишутся целиком «на всякий случай», а маскирование и правила доступа к логам не продуманы
• матрица доступа выглядит красиво, но не совпадает с реальностью: забывают сервисные аккаунты, админские операции (перезапуск, выгрузка модели, смена ключей), доступ подрядчиков и временные права на инцидент
• нет владельца данных, и риск «повисает в воздухе»: непонятно, кто утверждает категории данных, кто разрешает исключения, кто принимает остаточный риск
• план реагирования слишком общий: «уведомить, расследовать» без конкретики для LLM (например, что делать при утечке промптов или компрометации API-ключа)

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

Чтобы быстрее пройти согласование, полезно заранее сделать «проверку на стыках»:

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

Такой минимум обычно снимает большую часть вопросов еще до первого раунда замечаний.

Чеклист, пример сценария и следующие шаги

Если нужны документы для согласования LLM-проекта с ИБ, удобнее проверять готовность по короткому списку. Он помогает убедиться, что базовые артефакты на месте и их можно показать на встрече без долгих пояснений.

Короткий чеклист пакета:

• Карта данных: источники, куда уходит запрос, где хранятся ответы, кто администратор точек хранения.
• Модель угроз LLM: основные сценарии утечки, подмены, злоупотребления доступом и ошибки пользователей.
• Матрица доступа: роли, права, кто согласует, кто выдает и кто отзывает доступ.
• Журналирование и аудит: какие события пишутся, кто читает логи, как защищаются логи и что в них нельзя хранить.
• Хранение данных и реагирование: сроки ретенции, шифрование, локализация, плюс план реагирования на инциденты.

Дальше полезно зафиксировать критерии готовности к пилоту, чтобы ИБ могла сказать не просто «да/нет», а «да, при таких условиях».

Минимальные критерии готовности к пилоту:

• закрыты критические риски из модели угроз (есть меры, ответственные и сроки)
• определены владельцы: бизнес-владелец, владелец данных, админ платформы, ответственный от ИБ
• настроены алерты по ключевым событиям (подозрительная активность, рост ошибок, попытки доступа к закрытым данным)
• понятно, где хранятся промпты и ответы, и какие данные запрещены к обработке
• есть простой процесс эскалации: кто принимает решение, когда останавливать пилот

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

Чтобы демо для ИБ прошло спокойно, показывайте не «красоту ответов», а ограничения и контроль: примеры запрещенных запросов и как они блокируются, экран с журналом событий без чувствительных данных, и короткий разбор «что делаем, если» (например, сотрудник попытался вставить клиентскую базу в запрос).

Следующие шаги простые: назначьте владельцев, соберите одну понятную схему архитектуры и прогоните чеклист до встречи с ИБ. Если параллельно нужно быстро развернуть инфраструктуру под ИИ, интеграцию с корпоративными системами и поддержку 24/7, иногда подключают системного интегратора. Например, GSE.kz как производитель и системный интегратор в Казахстане может закрыть часть вопросов по площадке, внедрению и эксплуатации, но требования ИБ все равно должны быть зафиксированы в вашем пакете документов и привязаны к конкретному контуру и данным.