Компании не доверяют ИИ.
И правильно делают.

ИИ ускоряет разработку и эксплуатацию систем — но без контроля он выдумывает, сливает данные и не приносит эффекта, а атакующим достаётся тот же инструмент.

ИИ выдумывает
Галлюцинации в фактах, зависимостях и коде: уязвимости попадают в продукт, ответы без источника — в решения

Данные утекают
Сотрудники бесконтрольно передают конфиденциальную информацию во внешние LLM

Данные предприятия не задействованы
ИИ отвечает из интернета, а не из ваших СЭД, wiki и регламентов — эффект не достигается

AI-атаки — старое ПО под новой угрозой
ИИ кратно снижает стоимость поиска уязвимостей в существующих системах

Использовать опасно. Не использовать — дорого.
SAID разрывает этот круг: методология, которая делает ИИ управляемым — в разработке и эксплуатации.
Определите свой контур — 4 вопроса · С чего начать вашему типу организации

45%

AI-кода проваливает тесты безопасности OWASP

Отчёт Veracode, июль 2025

500 млн ₽

оборотный штраф за повторную утечку ПДн

420-ФЗ — КонсультантПлюс Разбор штрафов — Гарант

×10

рост security-находок в AI-коде за полгода

Исследование Apiiro, июнь 2025

35%

данных в AI-инструментах — чувствительные

Отчёт Cyberhaven, 2025

Цена ошибки: Один инцидент утечки ПДн через AI-ассистент может стоить компании от 25 до 500 млн ₽ (420-ФЗ), уголовной ответственности для руководителя (Указ №250) и до 10 лет лишения свободы для субъектов КИИ (ст. 274.1 УК).

Три маршрута по странице

Вектор: безопасность инвестиций в ИИ

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

SAID — безопасность внедрения

Данные не утекают, ответы проверяемы, действия агента под контролем. Отвечает на вопрос: как внедрить ИИ, не навредив себе.

Вектор — безопасность инвестиций

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

Две стороны одного решения. Провал ИИ-проекта одинаково реален с обоих концов: у SAID — от утечки и неконтролируемого агента, у «Вектора» — от выбора процесса, где эффект недоказуем. «Вектор» применяет те же принципы недоверенности ИИ и проверяемости результата, но к экономике внедрения: отбирает точку приложения и доводит её до измеримого эффекта. Открыть методологию «Вектор» →

Исследования и статьи

Разборы исследований и инцидентов 2024–2026 — часть доказательной базы методологии: каждая карточка подтверждает конкретный риск из реестра.

Аналитические материалы SAID

Теневой ИИ: почему запреты проиграли

SAID — сводный аналитический материал, июль 2026

Три корпуса данных (Netskope, Cyberhaven, MIT) плюс российский срез: тень — не проблема дисциплины, а сигнал спроса. Побеждает легальный канал, который удобнее личного аккаунта.

ИИ выдумывает: от судебной хроники к корпоративному контуру

SAID — сводный аналитический материал, июль 2026

Первый российский штраф за галлюцинации ИИ, Пленум ВС №15, мировая база 1 667 дел и стэнфордский замер — и почему ответ лежит в архитектуре, а не в памятках.

ИИ выдумывает: достоверность ответов

1 667 судебных дел с галлюцинациями ИИ: рост в 7 раз за год

SAID — по материалам базы Charlotin, июнь 2026

Глобальная база дел с выдуманными ИИ цитатами выросла с ~230 до 1 667 за год. В апреле 2026 — признание Sullivan & Cromwell, в июне — дисквалификация адвокатов на 2 года.

58–88% выдуманных ответов: галлюцинации LLM под замером

SAID — по материалам Stanford RegLab, 2024

800 тысяч проверяемых вопросов четырём моделям: выдумка в 58–88% случаев, и модели не видят собственных ошибок. Суды по делам Avianca и Air Canada возложили ответственность на людей и компании.

ИИ выдумывает: уязвимости в AI-коде

Почему AI пишет небезопасный код: результаты тестирования 100+ моделей

SAID — по материалам Veracode, июль 2025

45% AI-кода проваливает тесты OWASP. AI-код в 2.74 раза уязвимее человеческого. XSS — 86% провалов. Размер модели не решает проблему.

Скорость ×4, уязвимости ×10: обратная сторона AI-кодинга

SAID — по материалам Apiiro, июнь 2025

10 000+ новых security-находок в месяц. Рост в 10 раз за полгода. Разработчики слепо доверяют AI-коду и не проверяют его.

ИИ выдумывает: галлюцинация зависимостей (slopsquatting)

Взлом Amazon Q, три CVE в Cursor, захват через GitHub: хроника атак

SAID — по материалам Fortune, декабрь 2025

Реальные инциденты 2025: инъекция промпта (prompt injection) в Amazon Q (964 000 установок), RCE через одну строку в Cursor, эксфильтрация через GitHub Issues.

Все AI-модели галлюцинируют пакеты: как это становится оружием

SAID — по материалам arXiv, январь 2025

11 моделей, 3 языка. Все галлюцинируют. Кодовые модели хуже общих (26.9% vs 13.6%). Python — 23% галлюцинаций.

Когда AI-агент устанавливает вредоносный пакет: анатомия slopsquatting

SAID — по материалам Trend Micro, 2025

5-20% запросов содержат галлюцинации. Злоумышленники регистрируют эти имена с инфостилерами и бэкдорами.

Данные утекают: через AI-инструменты

Каждый второй — через личный аккаунт: теневой ИИ в 2026

SAID — по материалам Netskope, 2026

47% работающих с GenAI используют личные аккаунты; нарушения политики данных удвоились за год. Плюс EchoLeak: zero-click эксфильтрация через корпоративный AI-ассистент.

35% данных в AI-инструментах — конфиденциальные: анатомия утечек

SAID — по материалам Cyberhaven, 2025

73% AI-использования — через личные аккаунты, то есть теневой ИИ (shadow AI). Исходный код — 18.7% утечек. Рост объёма AI-данных на 485% за год.

$4.88 млн за утечку: как AI стал новым вектором атаки

SAID — по материалам IBM, июль 2025

13% организаций — взломы AI-систем. 97% без контроля доступа. Средняя стоимость утечки — рекорд. AI для безопасности экономит $2.2 млн.

Данные предприятия не задействованы

95% AI-пилотов без эффекта: данные предприятия не задействованы

SAID — по материалам MIT NANDA, август 2025

MIT: лишь ~5% корпоративных GenAI-пилотов дают измеримый результат — модели не подключены к данным и процессам компании. 90% сотрудников тем временем используют личный ИИ.

Контекст: российское законодательство

420-ФЗ: оборотные штрафы за утечки ПДн — что изменилось

SAID — по материалам КонсультантПлюс и Гарант

Штрафы выросли в сотни раз: до 500 млн ₽. 24 часа на уведомление РКН. AI-промпт с ПДн = утечка = штраф.

Практический разбор: как подготовиться к оборотным штрафам

SAID — по материалам RTM Group, июнь 2025

Кто попадает под 420-ФЗ, пошаговая подготовка, шаблоны уведомлений, AI-специфичные риски, экономика подготовки.

Контекст: безопасность AI-инструментов

Одна строка кода — полный контроль: prompt injection в AI-IDE

SAID — по материалам Lakera, 2025

CVE-2025-59944, CurXecute (CVSS 8.6). Unicode zero-width characters скрывают команды. Фундаментальная проблема всех AI-агентов.

Slopsquatting: практическое руководство по защите

SAID — по материалам Snyk, 2025

7 конкретных шагов: allowlist, lockfile, метаданные, SCA, запрет автоустановки, code review зависимостей, мониторинг.

OWASP Top 10 для LLM: 10 главных рисков и защита

SAID — по материалам OWASP, 2025

Инъекции промптов, утечки, цепочка поставок (supply chain), избыточная автономия агента (excessive agency) — разбор каждого риска с примерами и решениями SAID.

Anthropic auto-mode: классификатор доверенной среды для AI

Документация Claude Code, 2026

Реальная реализация принципа «постоянный контроль AI» (правило 13 SAID): декларативные разрешения на каждое действие AI-агента: доверенная среда, режимы разрешения, мягкого и жёсткого запрета (environment / allow / soft_deny / hard_deny).

Методология SAID

SAID переводит требования ISO/IEC 42001, NIST AI RMF и ФСТЭК России в конкретные практики. Адресат — предприятие, внедряющее ИИ, а не разработчик моделей. Это не чек-лист: применимость каждого правила определяется контуром организации.

Назначение методологии

Кому

Организации, встраивающей ИИ в свои процессы и разработку: своя команда и подрядчики, коммерческий и госсектор. Мировые стандарты обращены к разработчикам моделей — сторона внедрения покрыта слабее всего.

Зачем

Опросы 2024–2026 называют семь барьеров внедрения ИИ: недостоверные ответы, утечки данных, свои данные не задействованы, кадры, стоимость, интеграция, оргстратегия. Первые три — барьеры доверия; именно на них отвечает SAID, остальные закрываются теми же механизмами.

Что

Что должно быть: 6 принципов и 13 правил; что из них обязательно именно вам — определяют три контура. Как воплотить: архитектура средств и процессов, 16 карточек типовых решений. Как проверить себя: модель зрелости, KPI, SAID-аудит.

Результат

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

Три проблемы — ИИ выдумывает, данные утекают, данные предприятия не задействованы — устойчиво возглавляют причины недоверия к ИИ: опросы 2024–2026 выводят их в лидеры (McKinsey, Stanford AI Index, KPMG, ВШЭ). Остальные четыре барьера из тех же опросов — кадры, стоимость, техническая интеграция, оргстратегия — методология закрывает теми же механизмами: блок «Смежные барьеры» ниже.

Как устроена методология

Разделы выстроены цепочкой — каждый выводится из предыдущего и отвечает на один вопрос:

Термины — на каком языке говорим: контур, домен знаний, окно агента, управляющий слой.
Реестр рисков — что именно угрожает: 12 рисков, развёрнутых из трёх проблем по поверхностям контакта ИИ с предприятием; рядом — смежные барьеры внедрения.
Принципы — как отвечаем: шесть установок, из которых выводится каждое правило.
Роли — кто отвечает: без назначенных владельцев методология остаётся текстом.
Контуры — насколько строго: три набора требований к обработке данных, которые задают сами данные.
13 правил — что делать: каждое правило закрывает риски реестра и опирается на принцип.
Профиль применимости — что из этого обязательно в вашем контуре: 13 правил × 3 контура.
Результат — как проверить и доказать: самооценка, модель зрелости, SAID-аудит.

Вместе они проводят читателя от «почему ИИ не доверяют» до «что внедрить и как доказать»: проблемы → риски → принципы → правила → контуры → проверка.

Термины

Прежде чем строить методологию, договоримся о языке. Карта выше назвала опорные понятия — контур, домен знаний, окно агента, управляющий слой; здесь они определены строго, а термины из нормативных документов даны со ссылкой на источник. К этому словарю отсылают все дальнейшие разделы, и в него стоит вернуться, встретив незнакомое слово.

Контур — набор требований методологии к обработке данных и к правилам взаимодействия с другими контурами; какой контур применим, определяют категории обрабатываемых данных. SAID выделяет три типовых контура — открытый, гибридный и закрытый.

Домен знаний — сегмент корпоративных данных с единственным владельцем и документированной политикой выдачи, доступный средствам ИИ как неделимая единица управления доступом.

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

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

AI-шлюз (AI Gateway) — единственная дверь к моделям ИИ, внешним и внутренним: принимает каждое обращение, маршрутизирует его в допустимый контур и исполняет вердикт управляющего слоя (одна из точек принуждения, PEP). Обращения в обход шлюза блокируются на сетевом периметре.

Управляющий слой (Control Plane) — мозг архитектуры: классифицирует каждый запрос и действие, вычисляет вердикт политики (разрешить, запретить, эскалировать) и журналирует решение. Исполняют вердикт точки принуждения — AI-шлюз, RAG-слой, песочница агента.

AI-классификатор — компонент управляющего слоя (Control Plane), относящий запрос и содержащиеся в нём данные к категориям — персональные данные (ПДн), секреты, коммерческая тайна — до передачи модели.

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

Точка решения и точки принуждения (PDP / PEP) — компоненты управляющего слоя, реализующие политику как код: точка принятия решения (Policy Decision Point) вычисляет вердикт по каждому запросу, точки принуждения (Policy Enforcement Points) применяют его в местах выполнения действий.

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

Профиль внедрения — документ SAID, фиксирующий решение организации о распределении категорий данных по контурам; пересматривается при изменении состава данных или договорных условий.

Модель зрелости — инструмент самооценки SAID, в котором ответы на вопросы шестнадцати карточек применения (уровни 0–3 по каждому вопросу) складываются в профиль зрелости по каждому из тринадцати правил и по организации в целом; служит основой SAID-аудита и отправной точкой дорожной карты внедрения.

Нулевое доверие (Zero Trust) — модель безопасности, при которой ИИ-системе не выдаётся долгосрочное доверие: каждый промпт, каждое обращение к данным и каждое действие агента верифицируются в момент выполнения. В SAID применяется к поведению ИИ, а не только к сетевому доступу.

Галлюцинация — уверенная выдача моделью недостоверного результата, не подкреплённого данными; в SAID порождает два самостоятельных класса риска — галлюцинации фактов и галлюцинацию зависимостей (slopsquatting).

Инъекция промпта (prompt injection) — атака на ИИ-систему, при которой инструкция, встроенная во входной контент (документ, письмо, ответ внешнего инструмента), выполняется моделью как команда пользователя; текстовыми указаниями модели не устраняется и требует технических барьеров.

Галлюцинация зависимостей (slopsquatting) — атака на цепочку поставок программного обеспечения, при которой злоумышленник регистрирует вредоносный пакет под именем несуществующей зависимости, которое модель устойчиво галлюцинирует в генерируемом коде.

Теневой ИИ (shadow AI) — неучтённое использование ИИ, при котором корпоративные данные обрабатываются в личных аккаунтах внешних AI-сервисов вне корпоративных политик, журналирования и договорных гарантий; контрмеры SAID — реестр разрешённых AI-сервисов и легальный канал доступа, более удобный, чем личный аккаунт.

Генерация с опорой на документы (RAG, Retrieval-Augmented Generation) — механизм генерации ответа, при котором модель опирается на извлечённые документы организации, а не только на собственные обучающие данные.

Предотвращение утечек (DLP, Data Loss Prevention) — класс средств автоматической фильтрации, выявляющих и блокирующих защищаемую информацию в исходящих запросах до её передачи внешней модели.

Отказ от хранения запросов (Zero Data Retention, ZDR) — договорное условие, по которому провайдер модели не сохраняет запросы и ответы организации.

Анализ кода и зависимостей (SAST / SCA) — классы средств автоматической проверки кода: статический анализ на уязвимости (Static Application Security Testing) и анализ состава используемых зависимостей, включая их лицензии (Software Composition Analysis).

MCP-сервер — внешний инструмент, подключаемый к модели по Model Context Protocol — стандартному протоколу доступа модели к инструментам и данным.

Запись архитектурного решения (ADR) — документ, фиксирующий одно архитектурное решение и его обоснование; в SAID им также оформляется санкционированное отклонение от карточки применения.

ИИ-система — программное средство или комплекс средств, реализующие модель ИИ и обеспечивающие её применение в процессах организации (методика оценки угроз безопасности информации при применении ИИ, ФСТЭК России, 2026).

Доверенные технологии ИИ — технологии ИИ, при применении которых обеспечивается защита обрабатываемой информации (Приказ ФСТЭК России №117).

Физическая изоляция (air-gap) — построение среды, сеть которой не имеет соединений с другими сетями; обмен данными возможен только через носители или однонаправленные шлюзы (data diodes). Основа закрытого контура.

OWASP LLM Top 10 и NIST AI 600-1 — независимые каталоги угроз ИИ: рейтинг десяти главных угроз для систем на основе больших языковых моделей (сообщество OWASP, редакция 2025) и реестр рисков генеративного ИИ (профиль NIST AI 600-1, США); реестр рисков SAID привязан к обоим.

КИИ, ИСПДн, ГИС — критическая информационная инфраструктура (187-ФЗ), информационная система персональных данных (152-ФЗ) и государственная информационная система — регуляторные категории, влияющие на выбор контура: КИИ и ГИС — признак обязательного закрытого контура, статус оператора ИСПДн — требование обрабатывать ПДн моделями внутри периметра.

Реестр рисков

Реестр выводится из трёх проблем доверия, развёрнутых по поверхностям контакта ИИ с предприятием: промпт, домены знаний, агент, код, цепочка поставки, люди. Колонка «OWASP LLM / NIST» показывает место каждого риска в независимых международных каталогах угроз ИИ: OWASP LLM Top 10 — рейтинг десяти главных угроз для систем на основе языковых моделей, NIST AI 600-1 — реестр рисков генеративного ИИ (определения — в терминах выше). Найдите свой риск в первой колонке — в последней ссылка на решение.

Критерий включения: риск возникает в зоне ответственности внедряющего предприятия и закрывается правилами SAID. Три проблемы × поверхности контакта + сквозные риски = 12 рисков.

Риск	Определение	OWASP LLM / NIST	Решение SAID
Проблема 1 — ИИ отвечает недостоверно
Галлюцинации фактов	Уверенная выдача моделью недостоверных сведений, на основании которых сотрудники принимают решения без независимой проверки.	LLM09 Misinformation; NIST AI 600-1: Confabulation	Ответы с опорой на домены и обязательным источником
Галлюцинация зависимостей (slopsquatting)	Включение в AI-сгенерированный код несуществующей зависимости, имя которой зарегистрировано или будет зарегистрировано злоумышленником как вредоносный пакет.	LLM03 Supply Chain	Проверка каждой зависимости в конвейере
Размытие контекста	Деградация качества ответов и рост поверхности утечки при включении в контекст модели данных, не относящихся к решаемой задаче.	Частично LLM08 Vector and Embedding Weaknesses	Минимальный контекст, доменная сборка
Проблема 2 — данные предприятия уходят без контроля
Утечка защищаемой информации в промпте	Передача персональных данных, секретов или иной защищаемой информации внешней модели в составе запроса — в нарушение 152-ФЗ и п. 60 Приказа ФСТЭК России №117.	LLM02 Sensitive Information Disclosure	DLP-фильтрация каждого промпта до отправки
Кросс-доменная утечка знаний	Выдача пользователю одного подразделения данных другого подразделения через общий индекс знаний или общего ассистента, минуя политику выдачи владельца данных.	LLM08 Vector and Embedding Weaknesses	Сегментация доступа через доменного агента
Теневой ИИ (shadow AI)	Обработка корпоративных данных в личных аккаунтах внешних AI-сервисов сотрудниками или подрядчиками вне корпоративных политик, журналирования и договорных гарантий.	Вне OWASP (организационный риск); NIST AI RMF: функция GOVERN	Легальный канал и реестр сервисов; контур для подрядчика
Проблема 3 — данные предприятия не задействованы
Незадействованность данных предприятия	Работа модели без опоры на корпоративные знания, при которой решения принимаются на общих данных модели и ценность внедрения не реализуется.	Вне таксономий атак: не атака, а упущенная ценность — вклад SAID	Доменные индексы с окном агента; архитектура средств
Отравление домена знаний / модели	Внесение искажённых или вредоносных данных в домен знаний либо в дообучаемую модель, направленно меняющее ответы системы.	LLM04 Data and Model Poisoning	Карантин источников и откат индекса; жизненный цикл моделей
Сквозные — проявляются на всех поверхностях контакта
Инъекция промпта (prompt injection)	Перехват управления моделью через скрытые инструкции во входных данных — документе, письме, веб-странице, — заставляющий её нарушить заданные правила.	LLM01 Prompt Injection	Обработка недоверенного входа до контекста; нулевое доверие к агенту
Избыточная автономия агента	Выполнение агентом действий за пределами санкционированной задачи вследствие широких полномочий, доступных инструментов и отсутствия проверки политики перед действием.	LLM06 Excessive Agency	Песочница и минимум привилегий на задачу
Неконтролируемый AI-код в производстве	Попадание AI-сгенерированного кода в производственную среду без проверок, эквивалентных проверкам кода внешнего автора: SAST/SCA, ревью человеком, маркировка происхождения.	Частично LLM05 Improper Output Handling	Конвейер проверки всего AI-кода
Лицензионное заражение AI-кода	Воспроизведение моделью кода под копилефт- или иной несовместимой лицензией в проприетарном продукте без выявления происхождения фрагмента.	Вне OWASP (правовой риск); NIST AI 600-1: Intellectual Property	Сканирование лицензий и происхождения до merge

Риски зоны разработчика модели (обучающие данные, настройка поведения, его инфраструктура) в реестр не входят: ими управляют выбор контура и договор, а не собственные контроли предприятия.

Смежные барьеры

Реестр закрыл риски доверия — но внедрению мешают и четыре барьера вне доверия: кадры, стоимость, техническая интеграция, оргстратегия. Методология не заводит под них отдельных программ: те же механизмы, что снимают риски доверия, попутно снимают и эти барьеры. Как именно — ниже.

Кадры

Сотрудник осваивает не новый продукт, а новую кнопку в привычной почте и IDE (принцип 2). Единый корпоративный набор AI-инструментов вместо личного разнобоя: переобучение сводится к модулю безопасной работы (правило 9), глубокая подготовка нужна только узкому кругу владельцев платформы. → процессы «Обучение», «Пересмотр ролей»

Стоимость

Без единых требований каждое подразделение закупает своё — вырастает зоопарк несовместимых решений. Правила SAID работают как готовые требования к закупке, классификация данных — как критерий выбора класса решения: инструменты консолидируются на общем шлюзе и стеке, а категория «уже есть» переиспользует существующую инфраструктуру вместо параллельной.

Техническая интеграция

Вместо точечной интеграции каждого AI-инструмента с каждой системой — стандартные точки подключения: AI-шлюз (AI Gateway) как единая шина ко всем моделям, доменные RAG-индексы подключают данные без переделки систем-источников, MCP — стандартный протокол инструментов агента, управляющий слой (Control Plane) — единая точка политик. Новая система подключается к шине, а не дорабатывается под каждый инструмент. → техническая архитектура

Оргстратегия

Решение «внедрять ли и куда» методология не принимает — это предмет бизнес-стратегии. Требование SAID другое: применение ИИ обязательно признано и учтено — в реестре AI-сервисов, профиле внедрения, ролях и регламентах (правила 11, 12). Непризнанного использования не существует: либо в контуре, либо заблокировано. → реестр и роли

Принципы

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

Цифры в конце каждого принципа — номера правил SAID, которые его реализуют. Каждое из 13 правил опирается хотя бы на один принцип.

1. Минимальный доступ: контекст, домены, размещение

В контекст модели включаются только данные, необходимые для решаемой задачи: ИИ приходит к данным, а не данные к ИИ. Корпоративные знания сегментированы по доменам с назначенными владельцами; кросс-доменный доступ выполняется только через доменного агента («окно агента») — сырые данные домен не покидают, наружу передаётся санкционированный ответ. Место работы модели выбирается по классу обрабатываемых данных и проверяется до предоставления доступа. 1 2 3

2. Разрешить и контролировать, а не запрещать

Организация предоставляет легальный канал доступа к моделям, и этот канал обязан быть удобнее личного аккаунта: ИИ встраивается в привычные инструменты — почту, мессенджер, IDE, — а не живёт отдельным продуктом. Состав разрешённых сервисов определён в реестре и поддерживается в актуальном состоянии; доступ в обход легального канала перекрывается на сетевом периметре. Запрет без альтернативы и устаревшие регламенты выталкивают эффект в тень: теневое использование не журналируется и не поддаётся расследованию. 6 11 12

3. ИИ недоверенный по умолчанию

Вывод модели, сгенерированный ИИ код и действия агента считаются недоверенными, пока не прошли проверку. Применяется модель нулевого доверия: долгосрочное доверие не выдаётся, каждое действие верифицируется в момент выполнения. Модель и домены знаний рассматриваются не только как инструменты, но и как объекты атаки — их целостность определена и контролируется. 3 5 7 13

4. Политика как код

Правило, записанное только словами — в регламенте или в текстовой инструкции модели, — в работе с машиной не срабатывает: машина исполняет то, что может проверить, а не то, что написано для человека. Поэтому каждое правило SAID существует ещё и в машинно-читаемом виде — как политика, которую система проверяет автоматически до выполнения действия. Такое правило не нарушается по невнимательности, а попытка обхода оставляет след: политики версионируются и журналируются в управляющем слое. 6 13

5. Аудируемость и измеримость встроены

Каждый обмен с ИИ журналируется вместе с составом переданного контекста; журнал неизменяем и хранится дольше, чем живёт задача. Происхождение каждого артефакта — от исходного запроса до принятого результата — восстановимо по журналу. Метрики использования и срабатываний политик собираются непрерывно, и политики пересматриваются на их основе, а не только по календарю. 4 8 10

6. Ответственность не передаётся ИИ

Финальное решение по результату работы ИИ принимает человек, понимающий обоснование вывода, — это относится и к ответам модели, и к приёмке сгенерированного кода: ревью AI-кода не сокращается и не упрощается. Носитель ответственности — всегда конкретная роль в организации; модель субъектом ответственности не является. Принцип преемствен положениям Кодекса этики в сфере ИИ Альянса ИИ. 5 9 12

Роли и ответственность

Принципы и правила закрепляются за конкретными ролями — без назначенных владельцев методология остаётся текстом. Роль — это функция, а не штатная должность: её может исполнять существующая должность (директор по ИБ, тимлид, ответственный за защиту ПДн), а в крупной организации одну функцию делят несколько человек. Роли закрепляет руководство приказом; первым назначается Ответственный за безопасность ИИ, который вместе с руководством распределяет остальные и ведёт RACI. Полный состав обязанностей по процессам — в бизнес-архитектуре.

Пользователь ИИ — сотрудник или подрядчик, работающий с ИИ через легальный канал: прошёл обучение, соблюдает классификацию данных, проверяет критичные ответы и сообщает об инцидентах (правила 1, 9, 11).

Владелец данных — определяет категории данных своего участка и допустимость их обработки средствами ИИ (правило 1).

Владелец домена знаний — утверждает состав источников домена и политику выдачи, проводит ревизию; закреплён в RACI (правила 7, 12).

Аудитор ИБ — настраивает правила AI-классификатора и пороги аварийной остановки, проводит SAID-аудит по модели зрелости (правила 10, 13).

Ответственный за безопасность ИИ — отвечает за исполнение профиля внедрения и взаимодействие с регулятором (правила 4, 11).

Владелец AI-платформы — эксплуатирует AI-шлюз и управляющий слой, ведёт реестр AI-сервисов и моделей (правила 6, 8).

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

Матрица ответственности (RACI)

Кто что делает по ключевым действиям методологии. A — отвечает за результат (единственный в строке), R — выполняет, C — консультирует, I — информируется. Роли: ВД — владелец данных, ВДЗ — владелец домена знаний, ОБ — ответственный за безопасность ИИ, Ауд — аудитор ИБ, ВП — владелец AI-платформы, КР — контролёр результата, П — пользователь ИИ.

Действие	ВД	ВДЗ	ОБ	Ауд	ВП	КР	П
Классификация данных 1	A	C	I	C	I	–	I
Профиль внедрения: состав и пересмотр 1, 2	C	C	A	C	C	–	I
Домены знаний: состав и политика выдачи 7, 12	C	A	I	I	R	–	–
Реестр AI-сервисов 8, 11	–	–	C	I	A	–	I
Шлюз и управляющий слой: эксплуатация 6, 13	–	–	I	C	A	–	–
Классификатор и пороги аварийной остановки 13	–	–	C	A	R	–	–
Ревью и приёмка AI-результата и кода 5, 9	–	–	I	–	–	A	C
Обучение и легальный канал 9, 11	–	–	A	I	R	–	R
SAID-аудит и модель зрелости 10	I	I	C	A	C	I	–
Реагирование на AI-инцидент 13	C	C	A	R	R	C	I

Минимальный набор для малой команды

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

Пример Совмещение ролей в команде до 10–15 человек: техлид или директор по ИБ берёт на себя ответственного за безопасность ИИ, аудитора ИБ и владельца платформы; руководитель направления — владельца данных и владельца домена знаний; ревьюер — контролёра результата; пользователь ИИ — каждый.

Три контура: критерии отнесения

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

Граница проходит не между «внутренней» и «внешней» сетью — граница проходит по данным. Категория данных определяет, в каких зонах обработки они могут находиться и между какими перемещаться; внешняя модель — просто самая недоверенная зона. Тот же принцип действует внутри периметра: сеть сегментируется по обрабатываемым данным (выделенные сегменты, КИИ-контур), а знания делятся на домены — доменов может быть один или несколько, и делятся они по тем же категориям данных. Контур — общий набор требований к обработке данных и к правилам взаимодействия с другими контурами; внешние модели — тоже контур, только чужой и без гарантий. Какой набор требований применим, диктуют сами данные — категории, которые в контуре обрабатываются: в открытом обрабатываются только общедоступные данные — их можно передавать внешним моделям; гибридный держит чувствительное внутри и выпускает наружу только общедоступное после DLP-фильтра; закрытый не выпускает ничего. Нормативный фундамент — п. 60 Приказа ФСТЭК России №117: защищаемая информация не передаётся разработчикам моделей ИИ. Организация обычно работает в нескольких контурах одновременно — по категориям данных; решение фиксируется в профиле внедрения и пересматривается при изменении состава данных или договоров (см. карточку «Выбор контура»). Техническая реализация — в разделе «Техническая архитектура»; определить свой контур помогает определитель из 4 вопросов.

Контур	Данные в контуре (регуляторный признак)	Взаимодействие с внешними моделями	Требования к внутренней модели
Открытый	Только общедоступные данные; ПДн, коммерческая тайна и данные КИИ в контуре отсутствуют.	Разрешено через AI-шлюз с журналированием; договорные гарантии несохранения запросов рекомендованы, но контур на них не полагается — чувствительных данных в нём нет.	Внутренняя модель необязательна; при использовании RAG — доменные индексы и журнал состава контекста.
Гибридный	ПДн, конфиденциальная информация, проприетарный код — оператор ИСПДн (152-ФЗ).	Наружу — только общедоступное, и каждый запрос проходит DLP-фильтр: страховка от случайного попадания чувствительного. ПДн допустимы наружу после необратимого обезличивания — такие данные перестают быть ПДн (152-ФЗ); маскирование выполняет DLP-фильтр шлюза, псевдонимизация с возможностью восстановления субъекта не считается. В договоре с провайдером обязательно условие: запросы и ответы не сохраняются и не используются для обучения (Zero Data Retention).	Обязательна для чувствительных категорий: обработка ПДн внутри периметра, контроль доступа и доменные индексы, журналирование каждого обмена.
Закрытый	КИИ (187-ФЗ), ГИС, гостайна, специальные категории ПДн; запрет передачи разработчикам моделей — п. 60 Приказа ФСТЭК России №117.	Исключено архитектурно; взаимодействие с другими контурами — однонаправленное, с подтверждением человека.	Только проверенное/реестровое ПО; модели и обновления — через карантин с контролем целостности; аттестованная среда, контроль каждого действия внутри.

Взаимодействие контуров

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

Окно агента на границе контуров работает как между доменами, но фильтра два — по обеим осям. Запрос из мягкого контура в строгий — это вход: он проходит ось целостности (санитизация, детектор инъекций) и попадает не к данным, а к агенту контура, который отвечает своей моделью на своих доменах — в пределах политики выдачи владельца. Ответ — это выход: перед возвратом AI-классификатор проверяет его по оси конфиденциальности — категория ответа не выше допустимой в контуре запрашивающего, иначе ответ блокируется или выдаётся с изъятиями. Обе границы журналируются с двух сторон.

Закрытый контур — асимметричный случай: свободного обмена нет, но взаимодействие с другими контурами возможно — только однонаправленное и с подтверждением человека на каждую операцию. Ввод — контролируемой процедурой: носители или однонаправленные шлюзы (data diodes), контроль целостности, карантин — так доставляются модели и обновления. Вывод — санкционированные производные (журналы для ГосСОПКА, отчёты): обрабатываемые категории (КИИ, гостайна, специальные категории ПДн) не допустимы ни в одном другом контуре, поэтому каждую операцию вывода подтверждает владелец контура. Окно агента из закрытого контура недоступно — физическая изоляция исключает онлайн-обращения.

Отличие от AWS Generative AI Security Scoping Matrix (пять скоупов) — в оси классификации: AWS делит системы по владению моделью и данными обучения, SAID — по категориям данных: могут ли они покидать периметр. Сопоставление пригодится ИБ-специалистам, знакомым с матрицей AWS.

13 правил SAID

Термины, риски, принципы, роли и контуры очертили рамку — правила наполняют её содержанием. Каждое из тринадцати переводит принцип в проверяемое требование и закрывает конкретный AI-риск реестра. Строка SAID-N под названием — целевое состояние правила: то, что должно стать правдой, когда правило выполнено. Ссылки «→ Подробнее» ведут к детальным разделам и карточкам применения.

Процессы

Нормативные документы

Технологическая инфраструктура

1. Определи, что надо защищать

SAID-1. Категории защищаемых данных организации определены и задокументированы; для каждой категории определено и доведено до персонала, допустима ли её обработка средствами ИИ и какими именно.

Сначала пойми, какие данные в компании являются чувствительными активами. Без этого нельзя оценить риск их использования в AI. → Подробнее

2. Размещай ИИ рядом с обрабатываемыми данными

SAID-2. Место развёртывания ИИ — облако или собственный периметр — определяется классификацией обрабатываемых данных и фиксируется в профиле контура; чувствительные категории данных обрабатываются моделями внутри контролируемого периметра.

Не «всегда локально» — а соответственно классификации: чувствительное обрабатывается внутри контролируемого контура, открытое — где удобнее. → Подробнее

3. Не доверяй агенту больше, чем он должен знать

SAID-3. Полномочия AI-агента ограничены минимально необходимым для текущей задачи набором ресурсов; изоляция среды исполнения и недоступность секретов проверяются при каждом запуске агента.

Агента можно обмануть текстом, или он сам выйдет за рамки поставленной задачи. Минимум привилегий, изолированная песочница, нулевое доверие (Zero Trust) — не доверять по умолчанию и проверять каждое действие: агенту доступно только то, что нужно для текущей задачи. → Подробнее

4. История ИИ должна жить дольше задачи

SAID-4. Промпты, ответы и действия ИИ журналируются с привязкой к пользователю и времени, защищены от изменения и хранятся не меньше срока хранения обрабатываемых данных; журнал пригоден для расследования инцидентов.

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

5. Проверяй AI-код как чужой

SAID-5. AI-сгенерированный код маркирован по происхождению и проходит SAST, SCA и ревью человеком на каждом изменении до включения в основную ветку — по конвейеру, идентичному проверке кода внешнего автора.

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

6. Никаких прямых диалогов пользователей с ИИ

SAID-6. Все обращения пользователей к моделям проходят через корпоративный шлюз с контентной DLP-фильтрацией входа и выхода (блокировка обхода на периметре — правило 11).

Промпт идёт через шлюз: маскирование ПДн, удаление секретов, фильтр проприетарного кода — до того, как сообщение увидит модель. → Подробнее

7. Защити модель — она знает больше всех

SAID-7. Защита модели и доменов знаний обеспечивается по четырём векторам: недоверенный вход обрабатывается до попадания в контекст, целостность весов подтверждается при поставке, источники доменов валидируются до индексации, доступ через API квотируется и контролируется на аномалии.

Модель и домены знаний — концентрат знаний компании и самая ценная цель. Четыре вектора защиты: вход (инъекция промпта, prompt injection), веса (цепочка поставок — процесс «Управление жизненным циклом моделей»), домены знаний (отравление), API (кража — квоты и монитор поведения).

8. Прослеживаемость данных в AI-генерации

SAID-8. Происхождение каждого фрагмента AI-генерации (модель, версия, источники контекста) фиксируется и восстановимо; лицензионная чистота AI-кода проверяется до включения в продукт и задокументирована.

Знай, откуда AI взял каждый фрагмент — код, текст, изображение, данные. На этом строятся лицензионная чистота, доверие к источнику и защита от санкционных рисков. → Подробнее

9. ИИ обязан объяснить, человек — понять

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

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

10. Измеряй и адаптируй

SAID-10. Метрики безопасности, качества и использования ИИ определены и собираются непрерывно; политики и правила пересматриваются не реже одного раза в квартал по результатам измерений, инцидентов и изменений законодательства.

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

11. Разрешить и контролировать, а не запрещать и не видеть

SAID-11. Легальный корпоративный канал доступа к моделям предоставлен всем сотрудникам и подрядчикам; реестр разрешённых AI-сервисов ведётся и актуализируется, прямые обращения к внешним AI-сервисам заблокированы на периметре, договорные гарантии провайдеров (DPA, SLA, право аудита) задокументированы.

Запрет рождает теневое использование. Корпоративный AI должен быть удобнее личного: доступ есть — теневой ИИ (shadow AI) не нужен, контроль виден — компания знает, что происходит. → Подробнее

12. Старые роли и процессы = потерянная эффективность

SAID-12. Роли и регламенты, затронутые внедрением ИИ, пересмотрены и задокументированы; зоны ответственности новых ролей (включая владельца домена знаний) закреплены в RACI, а эффект изменений измеряется установленными метриками.

AI снижает порог входа: аналитик пишет SQL и Python, PM собирает прототип сам. Старые регламенты «передай в разработку, жди очереди» съедают AI-эффект или гонят его в теневой обход. Сжимай процесс там, где AI снял ограничение — добавь проверки на выходе, закрепи зону ответственности новых ролей. → Подробнее

13. Контролируй ИИ каждый шаг, а не на старте

SAID-13. Каждый промпт, каждое обращение к данным и каждое действие агента проверяются управляющим слоем (Control Plane) в момент выполнения; политики версионируются как код, состав контекста журналируется, а нарушение политики автоматически останавливает работу ИИ — аварийная остановка (kill switch).

AI не получает доверия одной проверкой. Каждый промпт, каждый источник данных, каждое действие агента проходит через движок политик (policy engine) в реальном времени. Аномалии останавливают агента автоматически. Нулевое доверие для AI: нет долгосрочного доверия, есть постоянная верификация. → Подробнее

Профиль применимости: 13 правил × 3 контура

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

Ядро одинаково для всех. Девять правил — 1, 3, 4, 5, 6, 8, 9, 11 и 13 — обязательны в любом контуре: классификация, минимальный доступ агента, журналирование, проверка AI-кода, шлюз, прослеживаемость, объяснимость, легальный канал и управляющий слой не зависят от строгости контура. Различается обязательность только четырёх правил:

Правило	Открытый	Гибридный	Закрытый
2. Размещай ИИ рядом с обрабатываемыми данными	рекомендовано	обязательно	обязательно
7. Защити модель — она знает больше всех	рекомендовано	обязательно	обязательно
10. Измеряй и адаптируй	рекомендовано	обязательно	обязательно
12. Старые роли и процессы = потерянная эффективность	рекомендовано	рекомендовано	рекомендовано

Пояснения к профилю. Правило 2 в открытом контуре — рекомендовано: внешним моделям передаются только общедоступные данные, требование локализации не является критическим. Правило 7 в открытом контуре — рекомендовано: веса и API защищает провайдер; на стороне организации остаются вход (инъекция промпта) и домены знаний при использовании RAG. Правило 12 — рекомендовано во всех контурах: оно повышает эффективность внедрения, но не входит в минимально необходимый защитный состав. Правило 10 в открытом контуре — рекомендовано: минимальный состав метрик покрывает журнал шлюза, полный цикл измерений становится обязательным с ростом контура. Общий принцип профиля: требование следует за риском, а не за ярлыком контура. Строгость границ и строгость контроля работы модели — разные оси: закрытый контур строже всех на границах, но часть требований к контролю модели внутри него мягче — утечка к внешним моделям исключена конструкцией, договорные гарантии и фильтрация исходящего трафика к провайдерам не нужны. Контроль в закрытом контуре концентрируется на внутренних рисках: границы доменов, отравление домена знаний, автономия агента, достоверность ответов.

Соответствие стандартам

Правила и профиль — внутренняя логика методологии; осталось показать, как она стыкуется с рамками, по которым организацию проверяют извне. Это делает таблица соответствия (crosswalk) — рабочий инструмент ИБ-специалиста и аудитора, для решения о внедрении не обязательный. Она связывает правила SAID с международными и российскими рамками: организация, отчитывающаяся по NIST AI RMF или внедряющая систему менеджмента ИИ по ISO/IEC 42001, видит, какие их требования закрывает каждое правило; для российских требований дана привязка к ГОСТ Р 56939-2024 и приказам ФСТЭК России.

Прочерк в таблице значит не меньше, чем совпадение. Домены знаний, окно агента и перестройка ролей (правило 12) аналога в существующих рамках не имеют — и это не пробел SAID, а разделение труда: NIST AI RMF и ISO/IEC 42001 регулируют ИИ-систему как продукт, который организация строит и выпускает, тогда как эти три механизма — про встраивание чужой, уже готовой модели в данные и процессы предприятия. Именно сторону внедрения мировые стандарты покрывают слабее всего, и именно она — вклад SAID.

Полная таблица соответствия — правило SAID → NIST AI RMF → ISO/IEC 42001 → ГОСТ Р 56939-2024 → приказы ФСТЭК России, по всем тринадцати правилам — вынесена на страницу «Нормативная база» вместе с разборами ГОСТ Р 56939-2024, Приказа №240 и маппингом «25 процессов ГОСТ × SAID». Коротко: каждое правило SAID имеет привязку минимум к одной международной рамке и одному российскому документу; вклад SAID без аналога в стандартах — домены знаний, окно агента и перестройка ролей (правило 12).

Соответствие ориентировочное — таблица показывает пересечение областей, а не эквивалентность требований. Приказ ФСТЭК №117 обязателен для ГИС и госучреждений, для коммерческих организаций пп. 60–61 — ориентир лучшей практики. Сокращения в таблице: НСД — несанкционированный доступ, РБПО — разработка безопасного программного обеспечения.

Результат применения

Всё предыдущее описывало, что должно быть; остаётся последний вопрос — как убедиться, что это есть, и доказать другим. На него методология отвечает измеримым и документированным состоянием, а не декларацией: каждая карточка применения несёт вопрос самооценки, из ответов складывается модель зрелости, журнал управляющего слоя даёт доказательную базу, а профиль внедрения фиксирует состав обязательных средств. Отсюда четыре способа применить результат — каждый с процедурой ниже:

Метрика зрелости

Каждая карточка применения содержит вопрос самооценки с четырьмя вариантами ответа — от «не делаем» (уровень 0) до «делаем системно» (уровень 3); ответы складываются в профиль зрелости по каждому правилу и по организации.

→ процедура самооценки и агрегация

Руководство внедрения

Профиль контура и таблица применимости определяют состав средств и последовательность внедрения; для каждого правила карточки описывают решение в технике и в процессе.

→ дорожная карта из 5 этапов

Основа аудита

Журнал управляющего слоя, реестр AI-сервисов и зафиксированный профиль внедрения образуют доказательную базу внутреннего аудита и внешних проверок.

→ процедура SAID-аудита

Язык закупок

Требования правил формулируются как проверяемые условия технических заданий и договоров с поставщиками AI-средств и подрядчиками, включая запрет личных AI-аккаунтов и право аудита.

→ обязательные артефакты

Процедура самооценки

Оценка начинается не с аудитора, а с самих владельцев. Каждый из шестнадцати вопросов карточек применения владелец соответствующей зоны — домена знаний, платформы, процесса — оценивает по шкале от 0 до 3, а ответственный за безопасность ИИ сводит ответы в единую картину. Периодичность привязана к жизни системы, а не к календарю отчётности: при внедрении оценка проводится на старте каждого этапа дорожной карты, в эксплуатации — раз в квартал и обязательно после каждого AI-инцидента, потому что инцидент почти всегда обнажает переоценённый контроль.

Один принцип отделяет честную оценку от самоуспокоения: уровень 2 и выше нужно подтвердить механизмом — политикой, записью в журнале, конкретной настройкой. Ответ «мы это делаем, но показать нечем» засчитывается как уровень 1. Оценка, которую нельзя предъявить, аудитору бесполезна — и, что важнее, не защищает.

Агрегация: от ответов к профилю зрелости

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

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

Сами уровни читаются по одной шкале — насколько контроль встроен в систему, а не в добрую волю людей. Уровни 0–1 — контроля нет или он держится на дисциплине и рассыпается под нагрузкой; уровень 2 — контроль закреплён политикой и проверяется, но требует ручного участия; уровень 3 — контроль встроен в систему, срабатывает сам и оставляет след в журнале. Отсюда критерий соответствия методологии: каждое обязательное для контура организации правило (по профилю применимости) — не ниже уровня 2, а цель — уровень 3 по всем обязательным. На этом оценка перестаёт быть отчётом и становится планом: правила с самым низким уровнем и есть первые пункты дорожной карты, а расстояние между сегодняшним профилем и целевым — её объём.

SAID-аудит: процедура

Подготовка. Фиксируются границы аудита (контуры, домены знаний, процессы) и актуальный профиль внедрения; собираются документы: политика использования ИИ, реестр AI-сервисов, RACI, регламенты.
Свидетельства. Журнал управляющего слоя за период не менее 90 дней; последняя самооценка с обоснованиями; выборочная проверка средств в действии — тест DLP-фильтра на подготовленном промпте, срабатывание аварийной остановки, попытка обращения к модели в обход шлюза.
Оценка. Каждое обязательное правило профиля сверяется с фактом; несоответствия классифицируются по трём степеням: критичное (обязательное правило на уровне 0–1), существенное (уровень 2 без подтверждающего механизма), незначительное (отклонение документации от практики).
Заключение. Шесть обязательных частей: подтверждённый профиль внедрения; профиль зрелости по 13 правилам; перечень несоответствий по степеням; план устранения со сроками и ответственными; вывод о соответствии процессов ГОСТ Р 56939-2024 и готовности к сертификации по Приказу ФСТЭК России №240; дата следующего аудита.

Профиль внедрения: состав документа

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

Обязательные артефакты

Документ	Что содержит	Правила
Политика использования ИИ	Что можно отправлять в модели, что нельзя, легальный канал, ответственность	9, 11
Профиль внедрения	Семь разделов выше; утверждён руководством	1, 2
Реестр AI-сервисов	Разрешённые сервисы и модели, владельцы, условия договоров, статус	8, 11
Журнал управляющего слоя	Запросы, ответы, действия агентов, решения политики; срок хранения — не менее года	4, 13
Регламенты процессов	Изменённые и новые процессы бизнес-архитектуры: разработка, закупки, инциденты, роли	5, 12
Заключение SAID-аудита	Шесть частей процедуры аудита; основа для ГОСТ Р 56939-2024 и Приказа №240	10

Сопровождение методологии

Методология версионируется: канон правил имеет номер версии и историю изменений (текущая — v2.2); состав правил, принципов и карточек пересматривается не реже раза в полугодие и внепланово — при изменении нормативных требований, появлении нового класса угроз или по результатам AI-инцидентов. Изменения проходят тот же тест, что и исходный состав: каждое правило закрывает риски реестра и опирается на принцип; предложения направляются через контакты.

Реализация правил в технике описана в разделе «Техническая архитектура», в организации — в разделе «Бизнес-архитектура», типовые ситуации применения — в карточках «вопрос → ответ».

Техническая архитектура

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

Разрез 1 — три контура: где живут модели

Один и тот же набор средств собирается в один из трёх контуров — в зависимости от того, разрешён ли организации доступ к внешним моделям. Ядро одинаково во всех трёх: AI-шлюз (AI Gateway) как единственная дверь к моделям плюс управляющий слой (Control Plane, правило 13), проверяющий каждый запрос в режиме нулевого доверия (Zero Trust). Контуры различаются лишь тем, куда шлюзу разрешено маршрутизировать. Контурам соответствуют модели развёртывания: открытый — облачный API через корпоративный шлюз, гибридный — шлюз с локальной моделью для чувствительного, закрытый — on-prem с физической изоляцией (air-gap). Выберите контур — состав средств ниже подсветится под него.

Определите свой контур: 4 вопроса

1. Обрабатываете данные КИИ, гостайну или ПДн специальных категорий — либо вы субъект КИИ, госорган или разработчик СЗИ?

Да Нет

2. В задачах с ИИ участвуют ПДн, коммерческая тайна или проприетарный код?

Да Нет

3. Провайдер внешней модели готов дать договорные гарантии: Zero Data Retention, юрисдикция, право аудита?

Да Нет / не знаю

4. С вашим кодом или данными работают внешние подрядчики?

Да Нет

Открытый контур

Внешние модели разрешены — но только через корпоративный AI-шлюз

Внешние модели: да — любые одобренные провайдеры (YandexGPT, GigaChat, Claude API) через шлюз с DLP и журналированием; прямой доступ с рабочих станций заблокирован

Кому: стартапы и коммерческие компании без КИИ и больших массивов ПДн (тип «Коммерческая» из «Найди себя»)

Сотрудник → запрос в IDE / AI-чате AI-шлюз — единственная точка выхода (список разрешённых адресов, egress-allowlist) DLP: ПДн и секреты блокируются или маскируются Внешний провайдер ← метаданные в журнал (SIEM) Ответ → выходной DLP-фильтр → сотрудник

Гибридный контур

Внешние модели — только для открытых данных; чувствительное обрабатывает on-prem LLM

Внешние модели: да, через шлюз — но только для «общедоступных» данных; конфиденциальное, ПДн и проприетарный код маршрутизируются на on-prem LLM и наружу не уходят

Кому: операторы ИСПДн (152-ФЗ), продуктовые компании и интеграторы с коммерческой тайной, банки/финтех

Задача / репозиторий несёт метку классификации AI-шлюз сверяет метку с политикой (PDP) Открытые данные → внешний провайдер; чувствительное → on-prem LLM DLP страхует маршрутизацию на входе и выходе Ответ и решение о маршруте — в журнал SIEM

Закрытый контур

Внешних моделей нет — только on-prem LLM в изолированном контуре

Внешние модели: запрещены (187-ФЗ, Указ №166, ст. 274.1 УК). Модели доставляются внутрь процедурой «чистого импорта»: носители / data diodes, контроль сумм, карантин

Кому: субъекты КИИ, госорганы/ГИС (Приказ ФСТЭК №17), разработчики СЗИ (Пр. №240), системы с гостайной

Доступ — только через VDI: код не покидает периметр Внутренний AI-шлюз; PEP проверяет каждое действие On-prem LLM на физически изолированном GPU-кластере DLP + поведенческий контроль, журнал → SIEM → ГосСОПКА AI-инциденты — уведомление ГосСОПКА за 24–72 ч

Особенность ИИ, которую SAID использует как союзника: минимальный контекст. Модель работает хуже с перегруженным контекстом (эффект «lost in the middle») — и каждый лишний документ в контексте увеличивает поверхность утечки. Поэтому контекст собирается адресно: окно агента ограничивает домены знаний, RAG отдаёт только релевантные фрагменты под задачу, .aiignore закрывает лишнее. Одна мера решает две проблемы: выше качество ответов + меньше данных под риском.

Разрез 2 — технические средства: есть / по-новому / новые

Идея SAID: большинство средств у предприятия уже есть — они просто попадают в контур ИИ. Часть существующих систем начинает применяться по-новому — получает AI-специфичную настройку. И лишь ограниченный набор компонентов появляется впервые. К каждому средству мы возвращаемся в детальных разделах — ссылки «→ подробнее» на карточках.

Уже есть — стандартное средство предприятия, попадает в концепцию

По-новому — существующее средство, новое применение

Новый — появляется с внедрением ИИ

ОГЗ — применимость в контуре: да частично нет

Уже есть на предприятии попадают в контур ИИ

ЕстьВнешние AI-провайдеры 2

ОГЗ

YandexGPT API / GigaChat API / Claude API
Только через корпоративный AI-шлюз
Прямой доступ с рабочих станций запрещён

Гибридный: только «общедоступные» данные; «внутренние» — с ограничениями режима КТ

Закрытый: запрещены — 187-ФЗ, Указ №166, ст. 274.1 УК

→ подробнее

ЕстьСетевой периметр 6

ОГЗ

Firewall / NGFW, forward proxy, VPN
Фундамент egress-контроля AI-трафика

Закрытый: усилен физической изоляцией (air-gap)

→ подробнее

ЕстьРепозитории и CI/CD 5

ОГЗ

GitLab / Gitea, Jenkins / Argo, Nexus / Harbor
Сюда встраиваются AI-гейты: SAST/SCA, provenance
Branch protection: AI не коммитит в main

→ подробнее

ЕстьХранилища знаний (wiki / СЭД) 1, 2

ОГЗ

Wiki (TEAMLY / Yonote / Outline), СЭД, справочные порталы, регламенты
Становятся источниками RAG-индекса
Перед индексацией — классификация и перенос прав доступа

Открытый: индексируются только общедоступные/внутренние материалы

→ подробнее

ЕстьРезервное копирование 4

ОГЗ

Корпоративная СРК покрывает AI-артефакты
Журналы промптов: срок хранения (retention) не менее 1 года, по классу данных — до 7 лет
Encryption at rest — логи содержат чувствительное

→ подробнее

ЕстьАппаратная изоляция (air-gap) 2, 7

ОГЗ

Физическая изоляция (air-gap), однонаправленные шлюзы (data diodes), реестровое железо и ПО
Физически изолированный GPU-кластер
Через diodes доставляются модели

Гибридный: только для отдельных выделенных сегментов

Закрытый: конструктивная основа контура

→ подробнее

ЕстьСертифицированные СКЗИ 7

ОГЗ

КриптоПро / ViPNet / Континент
Шифрование каналов внутри контура
Защищённая поставка моделей и артефактов

Гибридный: для сегментов с ПДн / ГИС по классу защищённости

Закрытый: обязательны — Приказы ФСТЭК №17/239

→ подробнее

Начинают работать по-новому существующие средства, AI-настройка

По-новомуКонтроль исходящего AI-трафика (egress) 6

ОГЗ

На существующем proxy: allowlist AI-эндпоинтов
Блокировка прямых походов в ChatGPT/Claude
TLS-инспекция AI-трафика — закрывает теневой ИИ (shadow AI)

Закрытый: полный запрет исходящего AI-трафика (плюс физическая изоляция)

→ подробнее

По-новомуIDM / RBAC для AI 3, 6

ОГЗ

Keycloak / FreeIPA: роли «AI user», «AI admin»
MFA для AI-инструментов
Доступ к ИИ — управляемая привилегия

→ подробнее

По-новомуSIEM / журналы AI-событий 4

ОГЗ

Wazuh / MaxPatrol / KUMA: корреляции AI-событий
Аномальные промпты, запросы вне рабочего времени
OpenSearch / Loki — индекс AI-логов, срок хранения по классу данных

Закрытый: плюс обязательная выгрузка в ГосСОПКА

→ подробнее

По-новомуVDI для подрядчиков 6, 11

ОГЗ

Termidesk / Basis.WorkPlace / Guacamole: профили с запретом теневого ИИ
Запись сессий, аудит AI-действий

Открытый: опционально — при наличии подрядчиков

Закрытый: единственный способ доступа — код не покидает периметр

→ подробнее

По-новомуVault для AI (секреты) 3, 6

ОГЗ

Vault / OpenBao / Deckhouse Stronghold (серт. ФСТЭК)
Политики для AI-агентов, эфемерные токены
Запрет .env в досягаемости AI
Production-секреты агенту недоступны

→ подробнее

По-новомуSAST/SCA gate для AI-кода 5, 8

ОГЗ

Semgrep / Bearer / Svace: правила под AI-паттерны
CodeScoring OSA против галлюцинации зависимостей (slopsquatting), GPL-детекция
Блокировка merge без AI-метки и провенанса

→ подробнее

По-новомуГосСОПКА для AI 4

ОГЗ

Категории AI-инцидентов в playbook НКЦКИ
Уведомления по 187-ФЗ (24–72 ч) расширены на AI

Гибридный: только если организация — субъект КИИ / оператор ГИС

→ подробнее

По-новомуКаталог данных / метки классификации 1, 2

ОГЗ

Метки чувствительности на уровне задачи / репозитория
По ним AI-шлюз и PDP маршрутизируют запросы
DataHub / OpenMetadata / метки в трекере

Открытый: упрощённая схема — 2–3 категории

Закрытый: с категориями КИИ / гостайна

→ подробнее

По-новомуРабочее место разработчика (IDE) 3, 6

ОГЗ

.aiignore / .copilotignore — первый уровень нулевого доверия
Allowlist авторизованных AI-плагинов
Permission layer IDE, контроль буфера обмена

Закрытый: только реестровое ПО, доступ через VDI

→ подробнее

По-новомуДашборд AI-метрик (KPI) 10

ОГЗ

Grafana: уязвимости AI vs human, DLP-блокировки, adoption
Основа ежеквартального PDCA-review

→ подробнее

Появляются новые компоненты AI-эпохи

НовыйКорпоративный AI-шлюз 2, 4, 6

ОГЗ

Единственная дверь ко всем моделям
LiteLLM / OpenWebUI: маршрутизация по классификации
DLP-фильтр, каждый промпт — в журнал

Гибридный: ядро контура — маршрутизация внешний/on-prem по метке данных

Закрытый: внутреннее исполнение — шлюз только к on-prem моделям

→ подробнее

НовыйOn-prem LLM 2

ОГЗ

vLLM / Ollama / TGI на корпоративном GPU
GigaChat / YandexGPT on-prem
Дообучение только на внутренних данных

Открытый: не требуется — все запросы уходят внешним провайдерам

Закрытый: единственный источник моделей в контуре

→ подробнее

НовыйVector DB / RAG-слой 2, 8

ОГЗ

Qdrant / Weaviate / pgvector
RAG-индекс с контролем доступа
Коллекции сегментированы по доменам знаний

Открытый: опционально — RAG только на открытых/внутренних материалах

→ подробнее

НовыйДомены знаний / окно агента 1, 2, 3, 13

ОГЗ

Знания сегментированы на домены с владельцами и ACL
Агент получает «окно» — явный набор доменов под задачу
PEP проверяет каждый RAG-fetch: домены не размываются, знания не мигрируют между доменами
Кросс-доменный доступ — через доменного агента: другое подразделение спрашивает агента, изучившего процессы и данные домена, а не сами данные
Минимальный контекст: только релевантный домен — выше качество, меньше утечек

Открытый: при использовании RAG — упрощённая доменная модель

Закрытый: обязателен — домены совпадают с мандатной моделью доступа

→ подробнее

НовыйПесочница AI-агента 3

ОГЗ

gVisor / Kata / Firejail
Read-only FS, network allowlist, seccomp
Технический барьер вместо промптовых «пожеланий»

→ подробнее

НовыйЗащита модели 7

ОГЗ

Garak / PromptFoo — adversarial-тесты
Rate-limit, детектор аномалий
Sigstore / in-toto — supply chain модели

Открытый: тестируются шлюз и промпт-интерфейсы; сама модель — у провайдера

Закрытый: обязательна, включая карантин обновлений модели

→ подробнее

НовыйРеестр моделей 8

ОГЗ

MLflow / ClearML (on-prem)
Версии, датасеты, метрики, lineage
Какая модель что сгенерировала и на чём обучалась

Открытый: реестр используемых внешних моделей и их версий

Закрытый: обязательный учёт, входной контроль моделей через карантин

→ подробнее

НовыйКонтроль происхождения (provenance gate) 8

ОГЗ

Sigstore — подпись AI-сгенерированных артефактов
Маркировка commit-trailers (Co-Authored-By: AI)
Реестр промптов, моделей, версий

→ подробнее

НовыйТесты на уязвимости AI 7, 10

ОГЗ

PyRIT / Garak — тесты на инъекции промптов (prompt injection)
Adversarial-датасеты в pipeline
Red teaming как этап CI

Закрытый: обязательны, входят в аттестационные проверки

→ подробнее

Управляющий слой (Control Plane) для AI нулевое доверие в реальном времени — правило 13

Политика проверяется на входе, на доступе к данным и на каждом действии — до выполнения, а не после. Аномалии останавливают агента автоматически. Правила и пороги настраивает аудитор ИБ через консоль политик, без разработчиков и перевыкатки. Аналог auto-mode классификатора Anthropic Claude Code, но для всех AI-операций компании.

НовыйAI-классификатор запросов и действий 1, 6, 13

ОГЗ

Классифицирует в реальном времени каждый запрос и действие: тип данных, домен знаний, уровень риска
Останавливает выполнение при нарушении политики (через аварийную остановку, kill switch)
Настраивается аудитором ИБ: правила, пороги, режимы allow / soft_deny / hard_deny

→ подробнее

НовыйТочка принятия решения (Policy Decision Point, PDP) 3, 13

ОГЗ

OPA / Cedar как движок политик
Декларативные правила: environment / allow / soft_deny / hard_deny
Версионирование политик как код (Git)

→ подробнее

НовыйТочки принуждения (Policy Enforcement Points, PEP) 13

ОГЗ

Хук в AI-шлюзе — проверка каждого промпта
Хук в RAG-слое — каждый fetch и границы доменов знаний
Хук в песочнице агента — проверка каждого действия

→ подробнее

НовыйНепрерывная DLP-фильтрация (continuous DLP) 6, 13

ОГЗ

Фильтр на входе и на выходе AI
Не разовая проверка — на каждом обмене (streaming)
Presidio / Bearer / InfoWatch / SearchInform КИБ

Открытый: критичен — весь трафик уходит внешним провайдерам

→ подробнее

НовыйМонитор поведения агента (behavioral monitor) 3, 7, 13

ОГЗ

Falco / Tetragon — runtime-аномалии действий агента
sysdig (OSS) / eBPF для kernel-уровня
Auto-quarantine при нетипичном поведении

→ подробнее

НовыйАварийная остановка (kill switch) / Circuit breaker 13

ОГЗ

Автоматическое отключение по триггеру классификатора; время реакции — секунды
Поэтапная деградация: только read-only → off
Ручной аварийный доступ (break-glass) для оператора

→ подробнее

НовыйДекларация доверенной среды 1, 13

ОГЗ

environment: что считается «своим» (репо, домены, бакеты)
allow: что разрешено всегда
soft_deny / hard_deny: что блокируется с/без override

Закрытый: совпадает с аттестованной границей контура

→ подробнее

Разрез 3 — слои контроля данных: от ввода до вывода

Средства из разреза 2 выстраиваются вдоль пути данных. Запрос и данные проходят шесть слоёв контроля — каждый слой отвечает на свой вопрос и опирается на свои правила. Пропуск любого слоя оставляет дыру, которую остальные не компенсируют.

Слой	Вопрос слоя	Механизмы контроля	Правила
1. Ввод	Что попадает в контекст модели?	DLP-маскирование секретов и ПДн до модели; детектор инъекций в запросе и документах; классификатор запроса — недопустимый отклоняется до начала генерации; пометка недоверенных источников	3, 6, 7
2. Доступ к данным	Какие данные видит модель в рамках задачи?	Минимальный контекст: явный перечень источников на задачу или проект; границы доменов знаний и окно агента; права на хранилища — «только чтение» или «чтение и запись»	2, 3
3. Полномочия действий	Что агент вправе сделать?	Разрешение на каждый инструмент: разрешить / спросить / запретить; изменяющие и необратимые действия — только после подтверждения человека; критичный класс (деплой в продуктив, массовое чтение или выгрузка данных) — подтверждение вторым человеком, инициатор и подтверждающий — разные люди; агент ставится на паузу до решения	11, 13
4. Исполнение	Где и как выполняются действия?	Песочница: изолированный контейнер на сессию; сеть «запрещено по умолчанию» плюс список разрешённых хостов; секреты в песочницу не попадают — код видит заглушку, реальное значение подставляется прокси на выходе	3, 13
5. Вывод	Что уходит пользователю или в другой контур?	Классификация ответа — категория не выше допустимой для получателя; фильтр вывода; остановка генерации при нарушении прямо посреди ответа; «нет источника — нет ответа»	6, 8
6. Сквозной	Видим ли мы всю цепочку?	Журнал каждого запроса, действия и решения политики; аварийная остановка по триггеру любого слоя; управляемый срок хранения данных; редактирование накопленной памяти задним числом	4, 10, 13

Состав слоёв — не умозрительный: те же уровни применяют современные агентские платформы. Например, в Claude Code сегодня работают классификатор запросов на входе и остановка генерации на выходе, разрешения на каждый инструмент с подтверждением человека, песочница с сетевым списком разрешённых хостов и подстановка секретов вне песочницы. SAID распространяет эту схему с одного инструмента на все AI-операции предприятия.

Каждое средство дальше разобрано в детальных разделах: классификация данных, DLP-фильтрация, нулевое доверие к агенту, проверки AI-кода, аудит и журналы, средства реализации. Контракт ИБ с провайдером — документ, а не техсредство: он живёт в бизнес-архитектуре, в процессе «Закупки и вендор-менеджмент».

Бизнес-архитектура

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

Меняется — существующий процесс получает обязательные AI-ветки

Новый — процесс появляется вместе с ИИ

Существующие процессы — получают AI-ветки

МеняетсяРазработка ПО (SDLC)

РазработкаРазработка1, 2, 3, 4, 6, 13

Конвейер «задача → код → прод» получает обязательные AI-ветки: метка чувствительности на задаче, выбор контура, кодирование через AI-шлюз (AI Gateway), агент в песочнице. Каждый переход — точка проверки управляющего слоя (Control Plane).

AI-шлюзПесочница агентаVaultPDP/PEP

→ пример «до/после» ниже

МеняетсяАрхитектура и моделирование угроз

РазработкаРазработка3, 7

Архитектура фиксирует место AI-компонентов и границы доступа агентов; модель угроз дополняется AI-угрозами: инъекция промпта (prompt injection), избыточная автономия агента (excessive agency), галлюцинация зависимостей (slopsquatting), отравление данных (data poisoning) — ГОСТ 5.6–5.7.

Декларация средыПесочницаPDP/PEP

→ ГОСТ-маппинг

МеняетсяРевью кода

РазработкаРазработка5, 8, 9

AI-код проходит ревью как код внешнего автора — без fast-track; ревьюер видит AI-маркировку и provenance, требует обоснование; ревьюеры обучены automation bias (ГОСТ 5.9).

Контроль происхожденияSemgrep / BearerCo-Authored-By: AI

→ подробнее

МеняетсяCI/CD и сборка ПО

РазработкаРазработка3, 5, 8

Pipeline получает обязательные гейты для AI-фрагментов: SAST/SCA, детекция галлюцинаций зависимостей, лицензионный GPL-контроль, блокировка merge без AI-метки; агенты в CI/CD изолированы от production-секретов (ГОСТ 5.10–5.16).

SAST/SCA gateCodeScoring OSAgitleaksSBOM

→ подробнее

МеняетсяТестирование ПО

РазработкаРазработка5, 9

AI-код тестируется расширенно (edge cases, негативные сценарии), AI-сгенерированные тесты верифицирует человек, DAST и фаззинг приоритетно для AI-кода, автодеплой AI-кода запрещён (ГОСТ 5.11, 5.18, 5.19).

DAST / фаззингSanitizersPyRIT / Garak

→ ГОСТ-маппинг

МеняетсяУправление конфигурацией и изменениями

ИТРазработка3, 13

В перечень элементов конфигурации входят версии LLM, системные промпты, правила агентов и .aiignore; их изменение проходит стандартный change management и версионируется как код (ГОСТ 5.4).

Git (политики как код)Реестр моделейДекларация среды

→ ГОСТ-маппинг

МеняетсяУправление инцидентами ИБ

ИБЭксплуатация и ИБ4, 13

Появляется класс инцидентов «утечка/атака через AI»: playbook расследования по журналам промптов, аварийная остановка (kill switch) как мера сдерживания, для КИИ — уведомление ГосСОПКА за 24–72 ч (ГОСТ 5.23).

SIEMЖурналы AI-шлюзаАварийная остановкаГосСОПКА

→ подробнее

МеняетсяМониторинг ИБ (SOC)

ИБЭксплуатация и ИБ4, 7, 13

SIEM дополняется AI-корреляциями — от аномально больших промптов до массовой выгрузки файлов в контекст: полный перечень с детекцией и реакцией — в таблице «Мониторинг аномалий».

SIEMИндекс AI-логовМонитор поведения

→ подробнее

МеняетсяУправление доступом (IAM)

ИБЭксплуатация и ИБ3, 6

Ролевая модель дополняется ролями «AI user» / «AI admin» с MFA; AI-агенты получают минимальные привилегии и эфемерные токены; branch protection — AI не коммитит в main (ГОСТ 5.14, 5.15).

IDM / RBACVault для AIVDI

→ подробнее

МеняетсяУправление данными (data governance)

ИТДанные1

Существующая классификация данных получает измерение «доступность для AI»: для каждой категории — правила, что можно отправлять в модель; метки чувствительности спускаются до уровня задач и репозиториев (ГОСТ 5.3).

Каталог данныхМетки в трекереOpenLineage

→ подробнее

МеняетсяЗакупки и вендор-менеджмент

ЗакупкиУправление и комплаенс2, 11

Закупка AI-сервиса получает обязательную ветку оценки: юрисдикция и санкционные риски, DPA и SLA на сроки хранения и удаление, право аудита; юристы и ИБ — обязательные согласующие. Контракт ИБ с провайдером — документ длительного хранения.

Контракт ИБ (DPA + SLA)Реестр AI-сервисов

→ дорожная карта

МеняетсяРабота с подрядчиками

ИТЛюди и организация6, 11

Подрядчик работает только через VDI (код не покидает периметр), NDA дополняется запретом внешних AI, отдельные AI-endpoints с усиленным логированием и ограниченным доступом к репозиториям (Трек Б — работа с подрядчиками).

VDIУсиленный DLPЗапись сессий

→ детали внедрения

МеняетсяОбучение персонала

HRЛюди и организация5, 9

Обязательный модуль безопасной работы с AI: галлюцинации, automation bias, инъекции промптов, лицензионные риски; тренинги не реже раза в полгода, учёт прохождения, ознакомление под подпись (ГОСТ 5.2).

Корпоративный AI-порталLMSПамятки по данным

→ дорожная карта

МеняетсяВнутренний аудит и комплаенс

ИБУправление и комплаенс10

AI-разработка включается в область РБПО и внутреннего аудита: проверяется фактическая работа AI-процессов и артефакты, подготовка к сертификации по Приказу ФСТЭК №240, регулярная переаттестация (ГОСТ 5.1).

Аудит-трейл SIEMДашборд KPIРеестр моделей

→ ФСТЭК №240

МеняетсяЮридическое сопровождение и ИС

ЮристыУправление и комплаенс8, 9

Оценка лицензионных рисков AI-кода (GPL-«заражение», совпадения с open-source), политика ответственности за AI-сгенерированный код в трудовых договорах и договорах с клиентами (ГОСТ 5.16).

OSS-сканер в SAST/SCAКонтроль происхожденияGit trailers

→ ГОСТ-маппинг

Новые процессы — появляются вместе с ИИ

НовыйКлассификация задач и выбор контура AI

ИБДанные1, 2

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

Каталог данныхAI-шлюзOPA-policy

→ подробнее

НовыйСогласование и реестр AI-сервисов

ИБУправление и комплаенс2, 11

Любой AI-инструмент проходит согласование и попадает в реестр разрешённых; неавторизованные блокируются на периметре. Принцип «разрешить и контролировать»: корпоративный AI обязан быть удобнее личного — иначе запрет рождает теневое использование.

Egress-контрольDLPAI-порталIDM

→ дорожная карта

НовыйDLP-контроль AI-промптов

ИБЭксплуатация и ИБ6, 13

Постоянная фильтрация входа и выхода модели: маскирование ПДн, вырезание секретов и проприетарного кода до того, как их увидит модель; операционный цикл — разбор блокировок, тюнинг правил, отчётность (процесс AI-1 SAID v2 — аналога в ГОСТ нет).

AI-шлюзНепрерывная DLPКонтроль буфера обмена

→ подробнее

НовыйУправление доменами знаний (RAG)

ИТДанные1, 7, 8

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

Vector DBДомены знаний / окно агентаPEP-хук в RAG

→ техархитектура

НовыйУправление жизненным циклом моделей

ИТЭксплуатация и ИБ2, 7, 8

Модель — элемент цепочки поставок: приёмка через карантин и контроль сумм, версионирование, тестирование перед прод, мониторинг дрейфа (drift), вывод из эксплуатации с зачисткой fine-tuning данных и отзывом credentials (ГОСТ 5.17, 5.25).

Реестр моделейSigstore / in-totoGarak / PromptFoo

→ ГОСТ-маппинг

НовыйНепрерывный контроль AI (управляющий слой)

ИБЭксплуатация и ИБ3, 7, 13

Каждый промпт, источник и действие агента проверяется движком политик в реальном времени — нулевое доверие (Zero Trust) вместо разовой проверки на старте; аномалии автоматически останавливают агента. Правила классификатора и пороги остановки настраивает аудитор ИБ — через консоль политик, без изменения кода.

AI-классификаторPDP / PEPАварийная остановкаМонитор поведения

→ подробнее

НовыйИзмерение и улучшение AI-безопасности

ИБУправление и комплаенс10

KPI-дашборд (уязвимости AI vs human, DLP-блокировки, code churn, инциденты), ежеквартальный PDCA-пересмотр политик, red teaming AI-инфраструктуры, мониторинг изменений законодательства (процесс AI-3 SAID v2).

Grafana KPIGarak (red teaming)SIEM-отчёты

→ PDCA-цикл

НовыйПересмотр ролей и регламентов под AI

Бизнес-руководствоЛюди и организация9, 12

Регулярная ревизия процессов, где AI снял ограничение: аналитик пишет SQL, PM собирает прототип — регламент сжимается, добавляются проверки на выходе, закрепляется ответственность новых ролей. Без этого AI-эффект съедается старыми очередями или уходит в теневой обход.

RACI-матрицаПолитика использования AIКаталог ролей в IDM

→ правило 12

Пример: как меняется существующий процесс — разработка ПО

Паттерн «до/после» применим к любому меняющемуся процессу из списка выше — разработка ПО просто самый детализированный пример. SAID не отменяет существующий процесс, а добавляет обязательные шаги в ключевых точках. На каждой стрелке между шагами работает управляющий слой (правило 13).

Сквозной контроль: каждый стрелочный переход (↓) проходит проверку политики в точке принятия решения (PDP). Работа с ИИ идёт в режиме нулевого доверия: проверяется каждый запрос, источник и действие на всём пути.

Стандартный процесс

Задача

↓

Разработка

↓

Ревью

↓

CI/CD

↓

Прод

↓

Эксплуатация

Процесс с SAID

Задача

↓

+ Классификация данныхметка чувствительности на уровне задачи / репозитория

метки в трекереdata catalogOpenLineage

Правило 1

↓

+ Выбор контура AIмаршрутизация запроса по классификации

LiteLLMOPA-policyOpenWebUI proxy

Правило 2

↓

Разработкачерез AI-шлюз, агент в песочнице, всё в журнал

LiteLLM gatewaygVisor / FirejailVault эфемерные токеныLoki + Vector

Правила 3, 4, 6

↓

РевьюAI-код проходит как чужой, provenance, объяснимость

Semgrep / BearerSigstoreCo-Authored-By: AIReviewer-bot

Правила 5, 8, 9

↓

CI/CDSAST/SCA на AI-фрагментах, проверка лицензий

CodeScoringOWASP Dependency-CheckOSV Scanner

Правила 5, 8

↓

Продмониторинг AI-вывода, fallback, защита модели

Wazuh / MaxPatrolGarak / PromptFooFalco runtimefallback-сценарии

Правила 4, 7

↓

Эксплуатацияконтракт ИБ с провайдером, VDI для подрядчиков, инциденты по playbook

DPA + SLATermidesk / GuacamoleГосСОПКА / РКН

Правила 6, 11

↓

+ Контроль и улучшениеKPI на дашборде, red teaming, PDCA, аттестация

Grafana KPIGarak red teamФСТЭК-аттестация

Правило 10

Каркас соответствует ГОСТ Р 56939-2024: полный маппинг «25 процессов ГОСТ × SAID» — в отдельном разделе; последовательность внедрения процессов — в дорожной карте.

Карточки применения

Жанр карточки: типовой вопрос из практики внедрения ИИ → как на него отвечают правила SAID. Карточка — типовое решение: анти-паттерн, принцип, техника, процесс, результат и вопрос самооценки с четырьмя уровнями зрелости. Карточка не является чек-листом; применимость определяется контуром и профилем внедрения организации. Отклонение от карточки не запрещено — оно оформляется как ADR со ссылкой на карточку и рассматривается архитектурным надзором.

01Агенту подключили «всё» — вики, почту, репозитории; ответы деградируют, в промпты утекают лишние данные. Как вернуть точность, не отключая источники?

Анти-паттерн: единый RAG-индекс на всю компанию. Каждый нерелевантный документ в контексте снижает качество ответа (эффект «lost in the middle») и одновременно расширяет поверхность утечки.

Принцип: минимальный контекст — единый принцип качества и безопасности (правила 1, 3): в контекст модели включаются только данные, относящиеся к решаемой задаче; состав контекста определён и воспроизводим.

Техника: доменные индексы вместо единого RAG; управляющий слой (Control Plane) собирает контекст по классификации запроса и удерживает бюджет контекста на запрос. Состав контекста каждого ответа записывается в журнал.

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

Результат: состав контекста воспроизводим и аудируем, точность ответов растёт; trade-off — латентность доменной сборки. Без внедрения: деградация качества и неконтролируемое попадание лишних данных в промпты.

Самооценка: как формируется контекст запросов к ИИ?

0 — все доступные источники подключены к модели без отбора.
1 — состав источников ограничен вручную, без документирования.
2 — контекст собирается по доменам, состав источников утверждён владельцем.
3 — сборка автоматизирована через управляющий слой, состав контекста журналируется по каждому ответу.

Правила 1, 3, 13 методика ФСТЭК 04.2026 (журналирование RAG-операций) → подробнее

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

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

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

Техника: agent-to-agent-запросы проходят через управляющий слой; AI-классификатор относит запрос к домену; все кросс-доменные обращения журналируются.

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

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

Самооценка: как ИИ обращается к данным чужого подразделения?

0 — единый ассистент видит данные всех подразделений.
1 — доступ ограничен ACL хранилищ, для ИИ отдельных правил нет.
2 — данные сегментированы по доменам, кросс-доменный доступ — по заявке.
3 — кросс-доменные запросы идут только через доменного агента и полностью аудируются.

Правила 1, 3, 11 152-ФЗ ст. 6, 7 (правовые основания и конфиденциальность ПДн) → подробнее

03Агент начал делать запрещённое — отправлять ПДн во внешнюю модель, менять прод. Кто и как его останавливает, и как доказать это регулятору?

Анти-паттерн: ограничения существуют только в system prompt. При инъекции модель их обходит; следов срабатывания и остановки не остаётся.

Принцип: политика существует как код, управляющий слой — точка принуждения (правила 6, 13); каждый шаг агента верифицируется, история действий сохраняется дольше задачи (правило 4).

Техника: inline-проверка политики до выполнения действия (allow/deny/escalate); при deny — автостоп и карантин сессии; классификатор ПДн и секретов на исходящем трафике; неизменяемый журнал инцидентов.

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

Результат: время от нарушения до аварийной остановки (kill switch) — секунды; журнал служит доказательной базой для регулятора. Без внедрения: агент завершает запрещённое действие раньше, чем его заметят.

Самооценка: что происходит при запрещённом действии агента?

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

Правила 4, 6, 13 Пр. ФСТЭК №117 п. 61; 187-ФЗ (реагирование на инциденты) → подробнее

04Сотрудники массово используют личные ChatGPT и DeepSeek для рабочих задач в обход политик. Запретить — уйдут глубже в тень. Что делать?

Анти-паттерн: полный запрет без легального канала. Использование не прекращается, а исчезает из зоны видимости; внутренняя избыточная выдача данных (oversharing) опаснее внешнего атакующего (Gartner).

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

Техника: корпоративный доступ к моделям через AI-шлюз (AI Gateway) и управляющий слой с DLP-фильтрацией и журналированием (открытый и гибридный контуры); блокировка прямых обращений к публичным AI-сервисам на периметре; реестр AI-сервисов.

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

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

Самооценка: как организация работает с теневым использованием ИИ?

0 — использование ИИ не регламентировано и не наблюдается.
1 — формальный запрет без технической блокировки и без альтернативы.
2 — корпоративный канал предоставлен, прямой доступ частично ограничен.
3 — легальный канал через шлюз с DLP, периметр блокирует прямые обращения, реестр AI-сервисов актуален.

Правила 2, 10, 11 152-ФЗ; Пр. ФСТЭК №117 п. 60 (запрет передачи защищаемой информации) → подробнее

05Разработчик вставил в запрос к модели выгрузку клиентской таблицы «для примера». Как предотвращать утечку ПДн, а не разбирать постфактум?

Анти-паттерн: контроль сводится к инструктажу и разбору инцидентов постфактум. К моменту разбора данные уже переданы внешней модели, и отозвать их невозможно.

Принцип: данные классифицированы до подключения ИИ (правило 1); прямых диалогов пользователя с моделью нет (правило 6) — исходящий промпт проверяется как канал утечки.

Техника: AI-классификатор управляющего слоя сканирует исходящий промпт (ПДн, секреты, коммерческая тайна) до отправки во внешнюю модель — блокирование, маскирование или эскалация. Для гибридного контура обязательно договорное условие Zero Data Retention.

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

Результат: запрет передачи защищаемой информации разработчикам внешних моделей (Пр. ФСТЭК №117 п. 60) исполняется технически, а не декларативно. Без внедрения: каждый промпт — потенциальная неконтролируемая трансграничная передача ПДн.

Самооценка: что мешает ПДн попасть в промпт внешней модели?

0 — ничего: доступ к моделям прямой, промпты не проверяются.
1 — инструктаж сотрудников без технических контролей.
2 — DLP-фильтр на типовые паттерны ПДн на исходящем трафике.
3 — классификация каждого исходящего промпта с блокированием или маскированием и журналом срабатываний.

Правила 1, 4, 6 152-ФЗ; Пр. ФСТЭК №117 п. 60 → подробнее

06AI-ассистент уверенно импортировал несуществующую библиотеку, а пакет с таким именем уже опубликован злоумышленником — галлюцинация зависимостей (slopsquatting). Как ловить?

Анти-паттерн: AI-сгенерированные зависимости устанавливаются из публичного реестра без проверки существования и происхождения пакета — галлюцинация модели становится точкой входа supply-chain-атаки.

Принцип: AI-код — недоверенный код (правило 5): каждая зависимость проверяется, а не принимается на веру; проверка выполняется на каждом шаге конвейера (правило 13).

Техника: SCA-проверка каждой AI-сгенерированной зависимости против allowlist и внутреннего прокси-репозитория; блок неизвестных пакетов в CI; маркировка AI-происхождения кода в коммитах как след для аудита.

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

Результат: несуществующие и вредоносные зависимости не доходят до сборки; закрывается класс supply-chain-угроз (OWASP LLM03). Без внедрения: одна галлюцинация имени пакета — рабочий канал внедрения вредоносного кода.

Самооценка: как проверяются зависимости, добавленные ИИ?

0 — устанавливаются напрямую из публичных реестров без проверки.
1 — SCA запускается периодически, вне CI-конвейера.
2 — SCA в CI, но без allowlist — неизвестные пакеты проходят.
3 — прокси-репозиторий с allowlist, блок неизвестных пакетов в CI, AI-происхождение кода маркируется.

Правила 5, 13 ГОСТ Р 56939-2024 (управление конфигурацией и внешними компонентами) → подробнее

07Ассистент воспроизвёл копилефт-код в проприетарном продукте; юристы узнали об этом при due diligence. Как не допустить лицензионного заражения?

Анти-паттерн: происхождение AI-сгенерированного кода не отслеживается. Лицензионное заражение обнаруживает покупатель или истец, а не конвейер сборки.

Принцип: прослеживаемость данных в AI-генерации (правило 8) и приёмка AI-кода как чужого (правило 5): происхождение каждого фрагмента установлено до merge.

Техника: сканер лицензий и происхождения кода в pipeline — поиск совпадений с open-source-корпусами для всего AI-кода до merge; настройки ассистента, отключающие дословное воспроизведение публичного кода, там, где вендор это поддерживает.

Процесс: политика допустимых лицензий; совпадение эскалируется юристам; AI-происхождение фиксируется в паспорте компонента.

Результат: правовой риск снимается до релиза, продукт готов к due diligence. Без внедрения: копилефт-обязательства распространяются на проприетарную кодовую базу.

Самооценка: как контролируется лицензионная чистота AI-кода?

0 — не контролируется.
1 — выборочная ручная проверка подозрительных фрагментов.
2 — сканер лицензий в pipeline для AI-сгенерированного кода.
3 — сканирование 100% AI-кода до merge, политика допустимых лицензий, паспорт компонента с AI-происхождением.

Правила 5, 8 ГОСТ Р 56939-2024 (прослеживаемость и управление конфигурацией) → подробнее

08Внешняя команда пишет ваш код и пропускает ваши данные через личные аккаунты AI-сервисов; договором это не покрыто. Как закрыть дыру?

Анти-паттерн: контур защищает только штатных сотрудников. Подрядчик работает в собственном контуре с вашими данными, и доказуемая цепочка обработки обрывается на границе договора.

Принцип: контур распространяется на всю цепочку поставки (правила 2, 11): подрядчик работает в вашем контуре, а не в своём; его код принимается как AI-код (правило 5).

Техника: доступ подрядчика — только через ваш управляющий слой: выданные ключи, запрет прямых внешних API из среды разработки, VDI или изолированная среда для закрытого контура; промпты подрядчика журналируются наравне со штатными.

Процесс: договор фиксирует допустимые AI-инструменты, запрет личных аккаунтов и право аудита; приёмка кода подрядчика идёт по конвейеру проверки AI-кода.

Результат: единая политика для своих и внешних исполнителей, цепочка обработки доказуема регулятору. Без внедрения: передача ПДн и кода третьей стороной вне контроля оператора (152-ФЗ; для субъектов КИИ — 187-ФЗ).

Самооценка: как регулируется использование ИИ подрядчиками?

0 — никак: подрядчик использует собственные инструменты и аккаунты.
1 — запрет прописан в договоре, технически не проверяется.
2 — подрядчик обязан использовать выданный доступ, контроль выборочный.
3 — доступ только через управляющий слой заказчика, журналирование наравне со штатными, право аудита реализовано.

Правила 2, 4, 5, 11 152-ФЗ (поручение обработки ПДн); 187-ФЗ → подробнее

09У нас ПДн, немного КИИ и желание использовать frontier-модели. В каком мы контуре и можно ли жить в нескольких сразу?

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

Принцип: контур определяют сами данные: их категория решает, допустим ли выход за периметр (правила 1, 2). Организация, как правило, живёт в нескольких контурах одновременно — по категориям данных.

Техника: дерево решений «категории данных → договорные гарантии → требования регулятора»: открытый контур — общедоступные данные; гибридный — коммерческие данные при Zero Data Retention и фильтрации; закрытый — ПДн специальных категорий, КИИ, гостайна. Управляющий слой маршрутизирует запрос в допустимый контур автоматически по классификации.

Процесс: решение о контурах фиксируется как профиль внедрения и пересматривается при изменении состава данных или договорных условий.

Результат: отнесение к контуру измеримо и воспроизводимо. Без внедрения: передача защищаемой информации разработчикам внешних моделей в нарушение Пр. ФСТЭК №117 п. 60.

Самооценка: как организация определяет свой контур?

0 — контур не определён, доступ к моделям стихийный.
1 — контур выбран интуитивно, без документированных критериев.
2 — контуры определены по категориям данных, маршрутизация ручная.
3 — маршрутизация в допустимый контур автоматическая, профиль внедрения документирован и регулярно пересматривается.

Правила 1, 2, 7 Пр. ФСТЭК №117 п. 60; 187-ФЗ (для КИИ) → подробнее

10Ассистенту дали доступ к внутренним API и MCP-серверам. Чем это грозит и как ограничить, не отбирая пользу?

Анти-паттерн: агент получает широкие постоянные права «чтобы работало». Компрометация одного MCP-сервера даёт латеральное движение по всем подключённым системам; кейс компрометации MCP-сервера зафиксирован в MITRE ATLAS (01.2026).

Принцип: не доверяй агенту больше, чем он должен знать (правило 3): песочница, минимум привилегий; каждый шаг верифицируется (правило 13), действия объяснимы человеку (правило 9).

Техника: песочница исполнения; allowlist инструментов на роль и задачу; валидация ответов MCP-серверов; подтверждение человеком изменяющих действий; полное журналирование действий и рассуждений агента.

Процесс: реестр агентов и их полномочий; ревью прав при изменении задач; учения на отзыв прав.

Результат: компрометация одного инструмента не даёт латерального движения. Без внедрения: агент становится универсальным ключом ко всем подключённым системам. Методика ФСТЭК 04.2026 покрывает RAG; требования к агентскому слою SAID формулирует до появления нормативных.

Самооценка: как ограничены инструменты агента?

0 — агент имеет постоянный широкий доступ ко всем системам.
1 — права выданы однократно при подключении и не пересматриваются.
2 — allowlist инструментов по ролям, изменяющие действия подтверждает человек.
3 — песочница, allowlist на задачу, валидация ответов инструментов, полный журнал действий и рассуждений.

Правила 3, 9, 13 методика ФСТЭК 04.2026 (контроль доступа RAG); 187-ФЗ (для КИИ) → подробнее

11Половина коммитов генерируется ассистентами, ревьюеры не успевают. Можно ли ослабить контроль для «простого» AI-кода?

Анти-паттерн: fast-track для «тривиального» AI-кода. Строгость контроля снижается именно там, где растёт объём недоверенного кода.

Принцип: AI-код — недоверенный код всегда (правило 5); меняется не строгость контроля, а его организация — роли и процессы перестраиваются под новый поток (правило 12).

Техника: обязательный SAST/SCA/secrets-скан для 100% AI-кода в CI; маркировка AI-происхождения; дифференцированный приёмочный порог по критичности компонента; автотесты как условие merge.

Процесс: ревьюер проверяет замысел и границы решения, машина — паттерны (правило 9); ведутся метрики плотности дефектов AI-кода в сравнении с человеческим (правило 10).

Результат: пропускная способность конвейера растёт без ослабления гарантий; процессы соответствуют РБПО по ГОСТ Р 56939-2024. Без внедрения: накопление непроверенного кода в production с неизвестной плотностью дефектов.

Самооценка: как AI-код попадает в production?

0 — наравне с человеческим, без маркировки и отдельных проверок.
1 — маркировка AI-происхождения есть, проверки выборочные.
2 — SAST/SCA в CI для всего AI-кода, единый порог приёмки.
3 — сканирование 100% AI-кода, дифференцированный порог по критичности, метрики плотности дефектов ведутся и анализируются.

Правила 5, 9, 10, 12 ГОСТ Р 56939-2024 (25 процессов РБПО) → подробнее

12Пришла проверка — чем подтвердить, что использование ИИ контролируется? Каких артефактов ждут по 152-ФЗ, 187-ФЗ и требованиям ФСТЭК?

Анти-паттерн: доказательства собираются перед проверкой из разрозненных систем. Журналов либо нет, либо их полнота недоказуема — для проверяющего это равнозначно отсутствию контроля.

Принцип: каждый промпт — это лог (правило 4): аудируемость встроена в архитектуру и подтверждается непрерывно, а не собирается постфактум.

Техника: неизменяемый журнал управляющего слоя — запрос, ответ, состав контекста, срабатывания AI-классификатора, кросс-доменные обращения; хранение не менее 1 года (методика ФСТЭК 04.2026); отчёт соответствия собирается из журнала автоматически.

Процесс: назначен ответственный за безопасность ИИ; регулярный внутренний SAID-аудит по модели зрелости; ведётся реестр AI-сервисов с паспортами.

Результат: пакет «политика + реестр + журнал + модель угроз + отчёт зрелости» — готовый ответ на проверку и заготовка под сертификацию процессов РБПО (Пр. ФСТЭК №240). Без внедрения: контроль есть, но доказать его проверке нечем.

Самооценка: что организация предъявит проверке завтра?

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

Правила 4, 10, 13 152-ФЗ; 187-ФЗ; Пр. ФСТЭК №240 → подробнее

13Модель уверенно выдаёт несуществующие факты — ссылки, цифры, положения документов. Сотрудники несут это в письма и решения. Как вернуть доверие к ответам?

Анти-паттерн: ответ «из головы модели» принимается как справка, а проверка происходит постфактум — когда ошибка уже вошла в письмо, отчёт или решение. Уверенный тон модели маскирует отсутствие источника.

Принцип: модель отвечает на основе данных предприятия, а не «по памяти» (домены знаний и минимальный контекст — правила 1, 3); ИИ обязан объяснить, человек — понять (правило 9): ответ без проверяемого обоснования не является ответом.

Техника: RAG на доменных данных с обязательным цитированием источников в ответе; управляющий слой помечает ответы без подтверждённого источника; для критичных сценариев — запрет ответа без источника (режим политики); состав контекста каждого ответа журналируется.

Процесс: регламент верификации AI-ответов вне кода — критичные решения проверяются по первоисточнику; обучение сотрудников (правило 9): галлюцинации, automation bias; владелец домена отвечает за актуальность своего домена — устаревшие знания порождают «правдоподобное враньё».

Результат: ответ проверяем по источнику за секунды; связка «модель не знает ваших данных → галлюцинации» разорвана. Без внедрения: уверенная галлюцинация уходит в договор или отчёт и обнаруживается уже по последствиям.

Самооценка: как проверяются фактические утверждения в ответах ИИ?

0 — ответы используются без проверки.
1 — проверка на усмотрение сотрудника, без регламента.
2 — RAG с цитированием источников, критичные ответы проверяются вручную.
3 — политика «нет источника — нет ответа» для критичных сценариев, состав контекста каждого ответа журналируется.

Правила 1, 3, 9, 13 ГОСТ Р 56939-2024 п. 5.8 (верификация AI-результатов) → подробнее

14Внедрили ИИ, а он отвечает общими словами: не знает наших регламентов, клиентов и кода. Как задействовать данные предприятия?

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

Принцип: данные предприятия — источник ценности ИИ, и открывать их модели нужно безопасно (правила 1, 2): классификация определяет, что можно индексировать; чувствительное обрабатывается внутри контура; знания сегментированы по доменам.

Техника: существующие хранилища знаний (wiki, СЭД, справочные порталы) индексируются в доменные RAG-коллекции с наследованием прав доступа; агент получает окно из доменов под задачу; ответы цитируют корпоративный источник.

Процесс: «Управление доменами знаний»: владельцы доменов утверждают состав домена, регулярная ревизия убирает устаревшее; новые роли закрепляются по правилу 12.

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

Самооценка: на чьих данных отвечает ваш ИИ?

0 — только на общих данных модели, корпоративные знания не подключены.
1 — сотрудники вручную вставляют документы в промпты.
2 — единый RAG-индекс на компанию, без доменов и наследования прав.
3 — доменные индексы с ACL и окном агента; доля ответов с корпоративным источником измеряется.

Правила 1, 2, 12 152-ФЗ (ПДн в доменах знаний — обработка внутри периметра) → подробнее

15В домен знаний попал искажённый документ — ИИ уверенно отвечает по нему. Как защитить домены знаний?

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

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

Техника: валидация и карантин новых источников до индексации в RAG и включения в дообучение; контроль целостности индекса домена; версионирование индекса с возможностью отката; PEP на границах доменов знаний ограничивает распространение искажения пределами одного домена.

Процесс: владелец домена утверждает источники до индексации; регулярная ревизия домена выявляет устаревшие и подозрительные документы; инцидент-процесс включает откат отравленной версии индекса и разбор пути попадания документа.

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

Самооценка: как контролируется состав доменов знаний?

0 — общие папки индексируются автоматически, контроля источников нет.
1 — состав домена ограничен вручную, целостность индекса не проверяется.
2 — новые источники утверждает владелец домена, индекс версионируется.
3 — карантин и валидация до индексации, контроль целостности, откат версии индекса по инцидент-процессу.

Правила 7, 12, 13 ГОСТ Р 56939-2024 пп. 5.17, 5.25 → подробнее

16Агент прочитал письмо со скрытой инструкцией и начал выполнять её как команду. Как защититься от инъекций промптов (prompt injection)?

Анти-паттерн: весь входной контент — документы, письма, веб-страницы, ответы MCP-серверов — попадает в контекст как доверенный. Инструкция, встроенная в данные, для модели неотличима от команды пользователя.

Принцип: недоверенность по умолчанию (правила 3, 7, 13): внешний контент — данные, а не команда; команды агент принимает только из санкционированного канала, каждое действие верифицируется.

Техника: пометка недоверенных источников и их обработка до попадания в контекст; PI-детектор на входе (LLM Guard); изоляция агента в песочнице; подтверждение человеком изменяющих действий; inline-проверка политики PDP до каждого действия.

Процесс: adversarial-тесты и red teaming — регулярная практика, новые техники инъекций пополняют набор тестов; срабатывание детектора запускает инцидент-процесс.

Результат: инъекция останавливается до выполнения действия, срабатывания журналируются и разбираются. Без внедрения: перехват управления агентом через любой читаемый им контент — риск №1 списка OWASP (LLM01).

Самооценка: как агент обрабатывает недоверенный контент?

0 — весь входной контент попадает в контекст без пометки и проверки.
1 — ограничения заданы в system prompt, технических барьеров нет.
2 — PI-детектор на входе, агент изолирован в песочнице.
3 — пометка недоверенных источников, inline-проверка PDP каждого действия, подтверждение человеком изменяющих операций, регулярный red teaming.

Правила 3, 6, 7, 13 OWASP LLM01; методика ФСТЭК 04.2026 → подробнее

Карточка и ADR. Карточка применения — типовое решение. Если требование карточки мешает конкретной реализации, оно не игнорируется: отклонение оформляется как ADR со ссылкой на карточку и рассматривается архитектурным надзором — так фиксируются и решение, и его обоснование. Ответы на вопросы самооценки шестнадцати карточек складываются в модель зрелости SAID (уровни 0–3 по каждому вопросу) — она служит основой SAID-аудита и отправной точкой дорожной карты внедрения.

Дорожная карта внедрения

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

Снижение издержек

Защита от утечек

Безопасность кода

Соответствие закону

Аудит и подготовка

Уровень: Предприятие

Издержки Утечки Уязвимости Закон

Задача	Что делаем	Результат	Трек А / Трек Б
Классификация данных	Инвентаризация, матрица 4 категорий (секреты — вне шкалы)	Реестр с маппингом "что AI видит"	Трек Б: +аудит данных подрядчиков
Политика использования AI	Разработка регламента с ИБ и юристами	Утверждённый документ	Трек Б: +пункт NDA об AI
Роли и ответственность	Назначение по Указу №250, RACI-матрица	RACI утверждена, владельцы назначены поимённо	Трек Б: +ответственный за подрядчиков
Оценка поставщиков AI	Анализ вендоров, санкционные риски	Выбор модели развёртывания	Трек Б: +оценка AI-инструментов подрядчика

Шкалы на этапах — экспертная оценка доли закрытых требований профиля применимости по каждой цели, не отраслевой бенчмарк.

Снижение издержек

10%

Защита от утечек

30%

Безопасность кода

Соответствие закону

40%

1-2 недТрек А

2-3 недТрек Б

Критерии готовности этапа (Definition of Done): Реестр данных утверждён, политика подписана, роли назначены, модель развёртывания выбрана.

Инфраструктура и защита

Уровни: Эксплуатация AI + Предприятие

Утечки Закон Издержки

Задача	Что делаем	Результат	Трек А / Трек Б
Развёртывание AI-инфраструктуры	On-premise / гибрид / физическая изоляция — по результатам этапа 1	ИИ работает внутри периметра	Трек Б: +VDI для подрядчиков, отдельные endpoints
DLP-фильтрация промптов	Настройка фильтров ПДн/секретов на AI-шлюзе (AI Gateway)	Утечки блокируются до отправки	Трек Б: +усиленные правила для endpoints подрядчиков
Контроль автономности AI — нулевое доверие (Zero Trust)	Контейнеры, NetworkPolicy, seccomp, output-фильтр	Выход AI-агента за периметр блокируется на уровне сети и контейнера	Одинаково для обоих треков
Контроль теневого ИИ (shadow AI)	Блокировка неавторизованных AI-сервисов, корпоративный портал	Вся AI-активность через контролируемые каналы	Трек Б: +мониторинг AI-трафика с VDI подрядчиков
Управление доступом	RBAC, лимиты по ролям	Минимально необходимый доступ	Трек Б: +ограниченные роли для подрядчиков
Управляющий слой (Control Plane)	PDP/PEP, AI-классификатор, аварийная остановка (kill switch)	Каждый запрос проходит проверку политики	Одинаково для обоих треков
Домены знаний / RAG-индексы	Выделение доменов по категориям данных, индексация с переносом прав	Кросс-доменный доступ только через окно агента	Одинаково для обоих треков

Снижение издержек

50%

Защита от утечек

80%

Безопасность кода

15%

Соответствие закону

70%

2-4 недТрек А

3-6 недТрек Б

Критерии готовности: AI-инфраструктура работает, управляющий слой (Control Plane) проверяет каждый запрос (PDP/PEP, аварийная остановка — kill switch), DLP фильтрует, домены знаний сегментированы в RAG-индексы, теневой ИИ заблокирован, доступ по ролям, подрядчики на VDI (Трек Б).

Процессы разработки

Уровень: Разработка

Уязвимости Издержки Утечки

Задача	Что делаем	Результат	Трек А / Трек Б
Безопасный SDLC	Изменение git flow: AI-код = недоверенный, обязательный review	AI-код попадает в main только после SAST/SCA и ревью	Одинаково
CI/CD pipeline	gitleaks → Semgrep → SCA → CodeScoring OSA → SonarQube	Уязвимости блокируются автоматически	Одинаково
Обучение команды	3 модуля: риски, практики, инструменты	Разработчики осознают риски	Трек Б: +обучение подрядчиков
Лицензионная чистота	Фильтр дубликатов, сканирование, маркировка	Исключён GPL-risk	Одинаково
Управление зависимостями	Allowlist + CodeScoring OSA + lockfile	Галлюцинация зависимостей (slopsquatting) заблокирована	Одинаково
Процедуры для подрядчиков	scope, exit-процедура, аудит	Контроль внешних разработчиков	Только Трек Б

Снижение издержек

80%

Защита от утечек

90%

Безопасность кода

85%

Соответствие закону

85%

1-2 недТрек А

2-3 недТрек Б

Критерии готовности: CI/CD pipeline настроен и блокирует уязвимости, 100% команды прошла обучение, подрядчики работают по процедуре (Трек Б).

Эксплуатация

Уровень: Эксплуатация AI в проде

Издержки Утечки Закон

Задача	Что делаем	Результат	Госсектор / Коммерческий
Мониторинг и аудит	Логирование промптов, SIEM-интеграция, алерты на аномалии	Полный аудит-трейл, время хранения по 152-ФЗ	Гос: SIEM внутри контура. Ком: возможен managed-SIEM по контракту
Контроль доступа	RBAC к моделям и данным, MFA, audit access	Только разрешённые роли работают с AI	Одинаково
Управление инцидентами	Playbook AI-инцидентов, эскалация, уведомление РКН/ГосСОПКА	Время реагирования <24ч	Гос: обязательное уведомление ГосСОПКА. Ком: 152-ФЗ ст.21
Жизненный цикл моделей	Обновления через карантин, версионирование, тестирование перед прод	Нет регрессий, известная версия в эксплуатации	Гос: только сертифицированные/реестровые модели. Ком: SLA провайдера
Резервный режим без ИИ (fallback)	Сценарии работы при недоступности AI или некачественном выводе	Сервис не падает при сбое модели	Одинаково
Контроль стоимости	Бюджет по командам, кэширование, роутинг моделей	ROI прозрачен, нет неконтролируемых трат	Одинаково
Контракты с провайдерами	SLA на хранение, удаление, юрисдикция, право аудита	Договор как документ ИБ	Гос: эксплуатация в контуре, минимум внешних. Ком: контракт + DPA
Доступ подрядчиков	VDI, NDA с пунктом об AI, аудит действий	Подрядчик не выносит код и не использует личный AI	Гос: только VDI, доступ через jump-host. Ком: VDI или supervised cloud

постоянноТрек А

постоянноТрек Б

Критерии готовности: AI работает в проде с мониторингом и playbook, доступ контролируется, модели версионируются, fallback-сценарии протестированы.

Контроль и непрерывное улучшение

Уровни: Предприятие + Разработка + Эксплуатация AI

Издержки Утечки Уязвимости Закон

Задача	Что делаем	Результат	Трек А / Трек Б
KPI безопасности	Dashboard: % уязвимостей, DLP-блокировок, покрытие обучением	Динамика KPI видна на дашборде	Одинаково
Red teaming	Ежеквартальная проверка: инъекции промптов (prompt injection), эксфильтрация данных, обход DLP	Слабые места найдены раньше атакующего: отчёт red team с планом устранения	Одинаково
Цикл PDCA	Ежеквартальный пересмотр политик, метрик, правил DLP	Непрерывное улучшение	Одинаково
Аттестация системы	Регулярная переаттестация по требованиям регулятора	Соответствие сохраняется во времени	Гос: ФСТЭК-аттестация. Ком: внутренний аудит

Снижение издержек

95%+

Защита от утечек

98%+

Безопасность кода

95%+

Соответствие закону

98%+

постоянноТрек А

постоянноТрек Б

Критерии готовности: KPI в зелёной зоне, первый red team проведён, PDCA-цикл запущен.

Трек Б: работа с подрядчиками

Дополнительные шаги

NDA с пунктом о запрете внешних AI

Юридическая защита: подрядчик не имеет права использовать сторонние AI-сервисы для работы с кодом заказчика.

VDI — код не на машине подрядчика

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

Отдельные AI-endpoints

Усиленное логирование всех AI-взаимодействий подрядчиков. Отдельные rate limits и DLP-правила.

Ограниченный scope репозитория

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

Потоки данных

Трек А: Внутренняя разработка

Корп. ноутбук→ IDE + AI-плагин→ Корп. proxy / DLP→ On-premise LLM→ Git→ CI/CD (SAST/SCA)→ Code Review→ Deploy

Трек Б: С подрядчиками

Личный ноутбук→ VDI (корп. среда)→ IDE + AI (усиленный лог)→ DLP (усиленный)→ On-premise LLM→ Git→ CI/CD→ Внутр. ревьюер→ Deploy

Подрядчик НЕ имеет: код на локальной машине, доступ к AI с личного устройства, полный доступ к репозиторию

Найди себя: с чего начать

Тип организации	Приоритетные этапы	Срок
Разработчик СЗИ	Все 5 этапов + сертификация по Пр.240	10-14 нед
Субъект КИИ	Этап 1-2: on-premise, DLP, закрытый контур	8-10 нед
Госорган / ГИС	Этап 1-2: классификация, on-premise	8-14 нед
Оператор ИСПДн	Этап 1-3: классификация, DLP, SAST	5-9 нед
Коммерческая	Этап 1+3: классификация + CI/CD pipeline	5-9 нед

Подробная матрица обязательности — в разделе нормативной базы.

Классификация данных

Определите категории данных до подключения AI-инструментов. Это основа всей системы защиты.

Категория	Примеры	Допустимый контур	Основание
Общедоступные	Open-source, публичная документация	Любой; разрешена передача внешним моделям	---
Внутренние	Бизнес-логика, архитектура	Гибридный и строже; наружу не передаются — только после переклассификации в общедоступные решением владельца данных	98-ФЗ (коммерческая тайна)
Конфиденциальные	ПДн клиентов, финансы	Гибридный и строже — только внутренняя модель; ПДн наружу — лишь после необратимого обезличивания	152-ФЗ
КИИ / Гостайна	Код критических систем	Закрытый	187-ФЗ, ст. 274.1 УК

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

DLP-фильтрация промптов

Контролируйте, что уходит в модель. Новый канал утечки, невидимый для классического мониторинга.

Что фильтровать

ПДн

ФИО, email, телефон, ИНН, паспорт

Секреты

API-ключи, пароли, токены, приватные ключи

SQL с данными

Production-запросы с реальными данными клиентов

Проприетарный код

Алгоритмы, составляющие коммерческую тайну

Пример конфигурации DLP-правил

dlp_rules:
  - name: "PII Detection"
    patterns: [email, phone_ru, inn, passport]
    action: block_and_alert
  - name: "Secrets"
    patterns: [api_key, password, token, private_key]
    action: redact_and_log
  - name: "Classified Code"
    patterns: [internal_markers]
    action: warn_and_log

Интерактивный DLP-симулятор

DLP-анализ промпта

Введите текст промпта и проверьте, что обнаружит DLP-фильтр:

Домены знаний и окно агента

Механизм, который заставляет ИИ работать на данных предприятия, не размывая границы доступа. Закрывает проблему 3 (данные не задействованы) и держит проблему 2 (утечки) под контролем внутри периметра.

Как выделяются домены

Домен знаний — единица управления доступом: один владелец, одна политика, один RAG-индекс. Выделение идёт в четыре шага:

Инвентаризация источников — wiki, СЭД, файловые хранилища, базы данных, переписка (этап 1 дорожной карты).
Категоризация — каждому источнику присваивается категория по классификации данных; она определяет допустимый контур домена.
Группировка по владению — источники объединяются в домены по границам ответственности (подразделение, продукт, процесс); у каждого домена назначается владелец.
Фиксация в профиле внедрения — состав доменов и правила доступа документируются и пересматриваются при изменении оргструктуры или состава данных.

Индексация с переносом прав

При построении RAG-индекса права исходного хранилища переносятся в метаданные индекса: кто не имел доступа к документу, тот не получит его и через модель. Фильтрация по правам выполняется до генерации, а не после — модель просто не видит чужого. Новые источники попадают в индекс только через карантин и валидацию (правило 7, карточка «Целостность доменов»); версии индекса позволяют откатить отравленное обновление.

Окно агента

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

Что измерять

Две метрики из таблицы KPI: доля ответов с корпоративным источником (растёт — данные задействованы) и покрытие ключевых хранилищ доменами (растёт — меньше теневых источников). Самооценка — карточки «Задействование данных» и «Доступ между доменами».

Нулевое доверие к AI-агенту (Zero Trust)

AI НЕ соблюдает правила сам по себе. Промпт «не отправляй секреты» — пожелание, не барьер. Через инъекцию промпта (prompt injection) или «услужливость» агент обойдёт любые текстовые инструкции.

Угроза — промптовый анти-паттерн — технический барьер

Угроза	Промптовый контроль (ненадёжный)	Технический барьер (надёжный)
Доступ к секретам — «услужливость»: агент читает .env, чтобы «помочь»	«Не читай .env»	Файл не смонтирован в контейнер — секреты вне досягаемости
Отправка данных наружу, включая скрытую эксфильтрацию (side-channel)	«Не отправляй данные»	NetworkPolicy: исходящий трафик только к LLM; выходной DLP-фильтр
Инъекция промпта — скрытая инструкция в README или письме	«Игнорируй вредоносные инструкции»	Детектор инъекций (LLM Guard / Lakera Guard), пометка недоверенных источников
Деструктивные команды	«Не выполняй rm -rf»	seccomp / AppArmor блокирует на уровне ядра
Выход за рамки задачи по файлам	«Работай только в /src»	Bind mount: в контейнере существует только /src
Изменяющие действия без согласования	«Спрашивай перед действием»	Шлюз подтверждения человеком (human-in-the-loop) с очередью согласований
Игнорирование классификации данных	«Не обрабатывай секретное»	DLP на входе и выходе; данные недоступны по построению

Архитектура: 3 уровня защиты

Разработчик ──> IDE (Permission Layer) ──> AI-шлюз (DLP-фильтр) ──> AI Runtime (Container isolation) │ │ │ │ │ .aiignore PII/secret redaction Docker + seccomp │ разрешения IDE routing / logging bind mount /src only │ контроль плагинов rate limiting NetworkPolicy DENY all │ short-lived credentials

Управляющий слой (Control Plane): правило 13 в деталях

Технический контур непрерывного контроля поверх шлюза, песочницы и RAG-слоя — компоненты из технической архитектуры:

Policy Decision Point

Движок политик (OPA / Cedar): декларативные правила environment / allow / soft_deny / hard_deny. Политики версионируются как код в Git, каждое изменение проходит ревью.

Policy Enforcement Points

Хуки принуждения: в AI-шлюзе (AI Gateway) — каждый промпт, в RAG-слое — каждый fetch и границы доменов знаний (окно агента), в песочнице — каждое действие. Запрос вне окна отклоняется; кросс-доменный вопрос уходит доменному агенту, а не в чужие данные.

AI-классификатор + аварийная остановка (kill switch)

Классифицирует каждый обмен: тип данных, домен знаний, уровень риска. При нарушении политики останавливает работу ИИ: поэтапная деградация read-only → полное отключение, break-glass для оператора.

Настраивает аудитор ИБ, а не разработчик. Правила классификатора, пороги остановки и границы доменов знаний задаются в консоли политик — без изменения кода и перевыкатки. Каждое срабатывание — событие в SIEM с полным контекстом: кто, какой промпт, какая политика, какое решение.

Проверки AI-кода (SAST/SCA pipeline)

CI/CD Pipeline безопасности

git push→ gitleaks (secrets)→ semgrep (SAST)→ pip-audit / npm audit (SCA)→ CodeScoring OSA (галлюцинация зависимостей, slopsquatting)→ sonarqube→ human code review→ merge

Чеклист ревьюера для AI-кода

Нет hardcoded credentials
Параметризованные SQL-запросы
Валидация пользовательского ввода
Нет eval/exec
Проверены все зависимости (не hallucination)
Нет устаревшей криптографии (MD5, SHA1)

Интерактивный SAST-сканер

Анализ уязвимостей в AI-коде

Выберите пример уязвимого кода для анализа:

# SQL Injection (CWE-89)
def get_user(username):
    query = f"SELECT * FROM users WHERE name = '{username}'"
    return db.execute(query)

Аудит и модель зрелости

Контроль использования ИИ подтверждается артефактами: журналом взаимодействий, измеримыми KPI и профилем зрелости по тринадцати правилам. Всё, что не журналируется и не измеряется, для аудита не существует.

Журнал как доказательная база

Каждый промпт — это лог. Без журналирования невозможно расследовать инциденты и подтвердить соответствие требованиям. Структура записи определена и задокументирована; полнота журнала проверяется на каждом внутреннем аудите.

Структура лога AI-взаимодействия

{
  "timestamp": "2026-03-28T14:30:00Z",
  "user_id": "dev-42",
  "model": "deepseek-coder-v2",
  "prompt_hash": "sha256:abc...",
  "prompt_size_tokens": 1200,
  "files_in_context": ["api/users.py"],
  "pii_detected": false,
  "secrets_detected": false
}

Для субъектов КИИ: утечка через AI-промпт — инцидент ИБ, требующий уведомления ГосСОПКА за 24-72 часа (187-ФЗ + Приказ ФСБ №367).

KPI

Для каждой метрики определены и задокументированы целевое значение, способ расчёта и источник данных. Значения ниже — целевые ориентиры методологии SAID, а не отраслевые бенчмарки; фактические значения фиксируются по журналам контура и пересматриваются на каждом цикле аудита.

Метрика	Целевое значение	Как считается	Источник данных
Доля AI-кода, прошедшего SAST/SCA до merge	100%	Число AI-маркированных коммитов со статусом «проверено» / общее число AI-маркированных коммитов за период	CI-конвейер, маркировка AI-происхождения в коммитах
Разбор DLP-блокировок промптов	100% за 5 рабочих дней	Доля срабатываний классификатора, по которым разбор завершён в срок	Журнал управляющего слоя (Control Plane), тикеты инцидент-процесса
Плотность дефектов AI-кода относительно человеческого	не выше 1,0	Дефекты на 1000 строк AI-кода / дефекты на 1000 строк человеческого кода за период	Багтрекер + маркировка происхождения кода
Доля промптов, прошедших через шлюз	100%	Запросы через AI-шлюз (AI Gateway) / все зафиксированные обращения к моделям (включая заблокированные прямые)	Журнал шлюза, логи периметра (firewall, DLP)
Время остановки агента при нарушении политики	секунды	Интервал от срабатывания deny-правила до фактического прекращения действий агента	Неизменяемый журнал инцидентов управляющего слоя
Доля ответов ИИ с подтверждённым корпоративным источником (критичные сценарии)	100%	Ответы с источником из доменного индекса / все ответы в критичных сценариях за период	Журнал состава контекста управляющего слоя
Покрытие приоритетных доменов знаний RAG-индексами	100%	Домены с актуальным индексом и владельцем / все домены из карты знаний	Реестр доменов знаний
Покрытие обучением	100% допущенных к ИИ	Сотрудники с действующей аттестацией по программе / все, кому выдан доступ к AI-инструментам	Реестр доступов + записи программы обучения

Мониторинг аномалий

Аномалия	Детекция	Реакция
Необычно большой промпт (>10K токенов)	Лог-анализ + алерт	Блокировка + расследование
Запросы вне рабочего времени	SIEM-правило	Уведомление ИБ
Попытка инъекции промпта (prompt injection)	Lakera Guard / regex	Блокировка + инцидент
Массовая выгрузка файлов в контекст	Мониторинг files_in_context	Алерт + ограничение
Обращение к заблокированным AI-сервисам	Firewall + DLP	Блокировка + уведомление

Модель зрелости SAID

Ваш профиль зрелости. Отметьте уровни 0–3 в карточках применения (клик по строке самооценки) — здесь автоматически соберётся профиль. Оценки хранятся только в вашем браузере.

Основа модели — шестнадцать вопросов самооценки из карточек применения. Каждый вопрос оценивается по шкале от 0 (контроль отсутствует) до 3 (контроль автоматизирован и журналируется). Зрелость — не единая цифра, а профиль по тринадцати правилам SAID: один и тот же вопрос закрывает несколько правил, и низкая оценка показывает, какие именно правила в контуре не реализованы. Полная шкала каждого вопроса (уровни 0–3) — в самой карточке.

Вопрос самооценки	Правила	Целевое состояние (уровень 3)
Формирование контекста	1, 3, 13	Сборка автоматизирована через управляющий слой, состав контекста журналируется по каждому ответу
Доступ между доменами	1, 3, 11	Кросс-доменные запросы идут только через доменного агента и полностью аудируются
Остановка агента	4, 6, 13	Inline-проверка каждого действия, автостоп с карантином сессии и неизменяемым журналом
Теневое использование ИИ	2, 10, 11	Легальный канал через шлюз с DLP, периметр блокирует прямые обращения, реестр AI-сервисов актуален
ПДн в промптах	1, 4, 6	Классификация каждого исходящего промпта с блокированием или маскированием и журналом срабатываний
Зависимости от ИИ	5, 13	Прокси-репозиторий с allowlist, блок неизвестных пакетов в CI, AI-происхождение кода маркируется
Лицензионная чистота AI-кода	5, 8	Сканирование 100% AI-кода до merge, политика допустимых лицензий, паспорт компонента с AI-происхождением
ИИ у подрядчиков	2, 4, 5, 11	Доступ только через управляющий слой заказчика, журналирование наравне со штатными, право аудита реализовано
Определение контура	1, 2, 7	Маршрутизация в допустимый контур автоматическая, профиль внедрения документирован и регулярно пересматривается
Инструменты агента	3, 9, 13	Песочница, allowlist на задачу, валидация ответов инструментов, полный журнал действий и рассуждений
AI-код в production	5, 9, 10, 12	Сканирование 100% AI-кода, дифференцированный порог по критичности, метрики плотности дефектов ведутся и анализируются
Доказательства проверке	4, 10, 13	Неизменяемый журнал с хранением не менее 1 года, отчёт соответствия собирается автоматически
Достоверность ответов	1, 3, 9, 13	Политика «нет источника — нет ответа» для критичных сценариев, состав контекста журналируется
Задействование данных	1, 2, 12	Доменные индексы с ACL и окном агента, доля ответов с корпоративным источником измеряется
Целостность доменов знаний	7, 12, 13	Карантин и валидация до индексации, контроль целостности, откат версии индекса по инцидент-процессу
Защита от инъекций промптов	3, 6, 7, 13	Пометка недоверенных источников, inline-проверка PDP каждого действия, подтверждение человеком изменяющих операций, регулярный red teaming

SAID-аудит. Результат аудита — заключение, включающее профиль контура (какие категории данных в каких контурах обрабатываются), оценку зрелости по каждому из шестнадцати вопросов и перечень несоответствий с привязкой к правилам SAID и нормативным требованиям. Заключение служит отправной точкой дорожной карты внедрения и предъявляется при внешней проверке вместе с журналом и реестром AI-средств.

Непрерывное улучшение

Цикл Plan-Do-Check-Act выполняется поверх модели зрелости: планируется устранение несоответствий из заключения аудита (Plan), обновляются политики, инструменты и обучение (Do), повторная самооценка и red teaming подтверждают сдвиг профиля (Check), процессы и чеклисты корректируются по результатам (Act). Политики, метрики и DLP-правила пересматриваются не реже раза в квартал; изменения законодательства (152-ФЗ, требования ФСТЭК, КИИ) отслеживаются с той же периодичностью, и каждое существенное изменение отражается в профиле внедрения.

Версионирование методологии

SAID v2.0 → v2.1 → ... Каждое обновление версии фиксирует изменения в правилах, политиках и инструментах; действующая версия указана в профиле внедрения, история изменений задокументирована.

Средства реализации

Изменения в процессах

Средство	Что даёт	Трек А	Трек Б
Политика использования AI	Юридическое основание, единые правила	Да	Да
Code Review чеклист	Снижение уязвимостей AI-кода	Да	Да
Программа обучения (3 модуля)	Осознанное использование AI	Да	Да + подрядчики
NDA + пункт об AI	Защита от утечек через подрядчика	---	Да
Процедура AI-инцидентов	Быстрое реагирование	Да	Да

Изменения в ПО

Инструмент	Назначение	Эффект
Ollama / vLLM (open-source)	On-premise LLM	Данные внутри периметра
LiteLLM / OpenWebUI (open-source)	AI-шлюз (AI Gateway)	Единая точка доступа к моделям, маршрутизация
Qdrant / pgvector (open-source)	Vector DB / RAG	Доменные индексы знаний с контролем доступа
OPA / Cedar (open-source)	Движок политик управляющего слоя (Control Plane)	PDP/PEP, политики как код, аварийная остановка (kill switch)
Semgrep (open-source движок)	SAST	Автодетекция CWE
gitleaks (open-source)	Secret scanning	Блокировка утечки ключей
InfoWatch / LLM Guard (OSS)	DLP промптов	Фильтрация ПДн/секретов
CodeScoring OSA	SCA + защита от галлюцинации зависимостей (slopsquatting)	Supply chain защита
MaxPatrol / KUMA	SIEM	Мониторинг AI

Изменения в инфраструктуре

Компонент	Назначение	Трек А	Трек Б
GPU-кластер под inference	On-premise LLM inference	Опционально	Опционально
AI-шлюз / proxy	DLP + маршрутизация + журналирование	Да	Да
Docker + seccomp	Изоляция AI-агента	Да	Да
VDI (Termidesk / Basis.WorkPlace)	Удалённый десктоп подрядчика	---	Обязательно
NetworkPolicy / firewall	Ограничение исходящего AI-трафика (встроено в K8s)	Да	Да

Матрица: доступность по категориям организаций

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

Сертификация и процессы

Категория	Сертификация (Пр.240)	Процессы ГОСТ	SAID AI-расширение
Разработчик СЗИ	Доступна	Обязательны	Рекомендуется
Субъект КИИ (своя разработка)	Не применяется	Best practice	Рекомендуется; для КИИ фактически необходима (187-ФЗ, ст. 274.1 УК)
Оператор ГИС	Не применяется	Рекомендуются	Рекомендуется
Оператор ИСПДн	Не применяется	Рекомендуются	Рекомендуется
Коммерческая компания	Не применяется	Добровольно	Добровольно

Обязательные меры по категориям

Требование	КИИ	ГИС	ИСПДн	Коммерческая
On-premise LLM (запрет зарубежных)	Обязательно	Обязательно	Рекомендуется	По выбору
Закрытый контур (air-gap)	Обязательно	По классу ГИС	Нет	Нет
Логирование AI-взаимодействий	Обязательно	Обязательно	Обязательно	Рекомендуется
DLP для AI-промптов	Обязательно	Обязательно	Рекомендуется	Рекомендуется
Уведомление ГосСОПКА (24-72ч)	Обязательно	Нет	Нет	Нет
Сертифицированные СКЗИ	Обязательно	По классу ГИС	Нет	Нет
Классификация данных для AI	Обязательно	Обязательно	Обязательно	Рекомендуется
Code review AI-кода	Обязательно	Обязательно	Рекомендуется	Рекомендуется

Ось этой таблицы — обязательность по нормативным требованиям (законы и приказы регуляторов). У методологии своя ось — профиль применимости 13×3: мера, которую закон лишь рекомендует, может быть обязательной по SAID — например, DLP и журналирование обязательны по методологии во всех контурах.

Для субъектов КИИ: использование зарубежных AI-сервисов не просто рискованно — это может квалифицироваться по ст. 274.1 УК РФ (до 10 лет). 187-ФЗ + Указ №166 (запрет иностранного ПО на КИИ с 2025) делают on-premise LLM единственным легальным вариантом.

Нормативные основания

Приказ ФСТЭК №240

Сертификация процессов РБПО. Вступил 01.06.2024, ред. 30.06.2025. До 5 лет.

ГОСТ Р 56939-2024

25 процессов безопасной разработки ПО. Заменил версию 2016. Введён 20.12.2024.

187-ФЗ + Указы №166/250

Безопасность КИИ, запрет иностранного ПО, ответственность руководителя за ИБ.

152-ФЗ + 420-ФЗ

Защита ПДн, локализация, оборотные штрафы до 500 млн ₽ за повторные утечки.

Профиль решения

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

Технологические возможности платформы

AI-шлюз — единственная дверь ко всем моделям, внешним и внутренним 6
Управляющий слой: AI-классификатор запросов и действий, движок политик, аварийная остановка 13
DLP на входе и выходе: маскирование ПДн и секретов, детектор инъекций 3, 6
Домены знаний с окном агента: RAG с переносом прав доступа, минимальный контекст 2, 3, 7
Песочница исполнения: изоляция действий агента, сеть по списку, секреты вне досягаемости кода 3
Каталог моделей по контурам: от внешних API до сертифицированных on-prem 2
Журнал каждого запроса, ответа и действия с управляемым сроком хранения 4, 8

Организационные меры предприятия

Классификация данных и назначение владельцев доменов знаний 1
Утверждённый профиль внедрения: контуры по категориям данных 2
Реестр AI-сервисов и согласование каждого нового 11
Роли: ответственный за безопасность ИИ, аудитор ИБ, владельцы доменов 12
Регламенты: ревью AI-кода, закупки с контрактом ИБ, реагирование на AI-инциденты 5, 12
Обучение и аттестация всех допущенных к ИИ 9
Самооценка зрелости по карточкам применения и регулярный SAID-аудит 10

Реализация профиля. Технологическую часть не обязательно собирать из десятка отдельных продуктов: AIlock — корпоративный LLM-движок, построенный по методологии SAID, — закрывает её ядро: единая точка доступа к моделям с каталогом по контурам (от внешних API до сертифицированных on-prem), журналирование каждой сессии, приём RAG-контекста с учётом прав доступа, работа в мультиарендном режиме. Организационная часть остаётся за предприятием — методология даёт для неё процессы, роли и модель зрелости, а аудит SAID подтверждает результат.

Начните внедрение SAID

Помогаем компаниям выстроить безопасный процесс AI-разработки

Аудит AI-практик

Оценка текущих рисков, gap analysis, рекомендации по приоритетам

Внедрение SAID

Полный цикл: от классификации данных до red teaming AI-инфраструктуры

Обучение команды

Тренинги по безопасному AI-кодингу для разработчиков и ревьюеров

db@implica.ru

Кому нужен SAID

Почему актуально

Почему работает

На что влияет

С чего начать

Как работает

Компании не доверяют ИИ.И правильно делают.

Три маршрута по странице

Руководителю

Начальнику ИБ

Архитектору

Вектор: безопасность инвестиций в ИИ

SAID — безопасность внедрения

Вектор — безопасность инвестиций

Исследования и статьи

Аналитические материалы SAID

Теневой ИИ: почему запреты проиграли

ИИ выдумывает: от судебной хроники к корпоративному контуру

ИИ выдумывает: достоверность ответов

1 667 судебных дел с галлюцинациями ИИ: рост в 7 раз за год

58–88% выдуманных ответов: галлюцинации LLM под замером

ИИ выдумывает: уязвимости в AI-коде

Почему AI пишет небезопасный код: результаты тестирования 100+ моделей

Скорость ×4, уязвимости ×10: обратная сторона AI-кодинга

ИИ выдумывает: галлюцинация зависимостей (slopsquatting)

Взлом Amazon Q, три CVE в Cursor, захват через GitHub: хроника атак

Все AI-модели галлюцинируют пакеты: как это становится оружием

Когда AI-агент устанавливает вредоносный пакет: анатомия slopsquatting

Данные утекают: через AI-инструменты

Каждый второй — через личный аккаунт: теневой ИИ в 2026

35% данных в AI-инструментах — конфиденциальные: анатомия утечек

$4.88 млн за утечку: как AI стал новым вектором атаки

Данные предприятия не задействованы

95% AI-пилотов без эффекта: данные предприятия не задействованы

Контекст: российское законодательство

420-ФЗ: оборотные штрафы за утечки ПДн — что изменилось

Практический разбор: как подготовиться к оборотным штрафам

Контекст: безопасность AI-инструментов

Одна строка кода — полный контроль: prompt injection в AI-IDE

Slopsquatting: практическое руководство по защите

OWASP Top 10 для LLM: 10 главных рисков и защита

Anthropic auto-mode: классификатор доверенной среды для AI

Методология SAID

Назначение методологии

Кому

Зачем

Что

Результат

Как устроена методология

Термины

Реестр рисков

Смежные барьеры

Кадры

Стоимость

Техническая интеграция

Оргстратегия

Принципы

1. Минимальный доступ: контекст, домены, размещение

2. Разрешить и контролировать, а не запрещать

3. ИИ недоверенный по умолчанию

4. Политика как код

5. Аудируемость и измеримость встроены

6. Ответственность не передаётся ИИ

Роли и ответственность

Матрица ответственности (RACI)

Минимальный набор для малой команды

Три контура: критерии отнесения

Взаимодействие контуров

13 правил SAID

1. Определи, что надо защищать

2. Размещай ИИ рядом с обрабатываемыми данными

3. Не доверяй агенту больше, чем он должен знать

4. История ИИ должна жить дольше задачи

5. Проверяй AI-код как чужой

6. Никаких прямых диалогов пользователей с ИИ

7. Защити модель — она знает больше всех

8. Прослеживаемость данных в AI-генерации

9. ИИ обязан объяснить, человек — понять

10. Измеряй и адаптируй

11. Разрешить и контролировать, а не запрещать и не видеть

Компании не доверяют ИИ.
И правильно делают.