Пока в компании нет политики, ИИ-безопасностью занимается каждый сотрудник сам: менеджер вставляет клиентскую базу в бесплатный чат-бот, аналитик загружает выручку в облачный сервис «просто посмотреть». Один такой эпизод — инцидент с персональными данными; десяток — системная проблема. Организовать ИИ-безопасность — значит перейти от стихии к управляемому режиму: знать, какие системы используются, разрешить безопасное и заблокировать опасное. Гайд даёт план на 30 дней.
Это организационный уровень: политики, роли и регулярные проверки. Технические ограничители поведения моделей разобраны в гайде по guardrails, атакующее тестирование — в гайде red teaming своего ИИ; здесь они — элементы общей системы.
Затраты-ориентиры сентября 2026: ревизия ИИ-активов и Shadow AI — от 70 000 ₽, аудит ИИ с проверкой защищённости — 150 000 ₽ за 1–2 недели, красная команда (имитация атак) — 300 000 ₽, пакет защиты контура — 400 000 ₽. Штрафы за нарушение закона о персональных данных достигают по корпусу дел миллионов рублей, поэтому политика дешевле последствий.
Восемь шагов ниже выстроены в логике цикла: сначала факты (что уже используется), затем правила (матрица и политика), затем контроль (техника и обучение), затем учёт (реестр) и проверка (аудит). Такой порядок важен: политика без инвентаризации запрещает неизвестно что, контроль без политики запрещает всё, а реестр без владельцев пуст. Каждый шаг занимает от пары дней до недели — весь первый цикл укладывается в месяц.
Пошаговый план
Проведите ревизию фактического использования
Начните не с документа, а с инвентаризации: какие нейросети и сервисы уже применяют сотрудники, какие данные в них попадают, что официально, что нет. Источники — опрос подразделений, анализ исходящего трафика и прокси-логов, учёт корпоративных подписок. Результат — список Shadow AI: сервисов, используемых мимо политики. Не наказывайте за признание: задача первого шага — увидеть реальную картину, а не загнать её глубже.
Назначьте владельцев
У ИИ-безопасности должен быть один ответственный — обычно это руководитель направления информационной безопасности или директор по цифровому развитию. Владельцы назначаются и на каждый сценарий ИИ: кто отвечает за ассистента поддержки, за генерацию отчётов, за CRM-интеграции. Без личной ответственности политика остаётся файлом: инцидент обнаруживается, когда уже поздно. Роли зафиксируйте приказом, а не договорённостью на совещании.
Классифицируйте данные и разрешённые режимы
Постройте матрицу: класс данных — от публичных и внутренних до персональных и особых категорий — против режима обработки (запрещено, облачный сервис с договором, только собственный контур). Персональные данные клиентов и коммерческая тайна не должны покидать периметр без договорных гарантий. Матрица — ядро политики: любой новый сценарий ИИ получает ответ «можно, нельзя, можно при условиях» за минуты, без созыва совещания.
Напишите политику использования ИИ
Политика — короткий документ на 3–5 страниц: какие сервисы разрешены и для каких классов данных, что запрещено всегда, что требует согласования, как сообщать об инцидентах. Пишите конкретно: «черновики публичных текстов — в одобренном сервисе; любые персональные данные — только в корпоративном контуре». Абстрактные формулировки про «осмотрительность» не работают. Утвердите политику у руководителя, который подписывает бюджет на инциденты.
Закрепите технический контроль
Политика без техники не исполняется. Минимальный набор: шлюз к одобренным моделям с журналированием запросов, блокировка или ограничение неавторизованных сервисов на уровне прокси, guardrails на корпоративных ассистентах, обучение на обезличенных данных. Контроль должен объяснять, а не только запрещать: если сотруднику удобно в запрещённом сервисе, дайте разрешённую альтернативу той же задачи — иначе вернутся к теневым инструментам.
Обучите команду и соберите подписи
Проведите короткие практические сессии по подразделениям: что можно, что нельзя, как выполнять типовые задачи безопасно. Проверяйте не знание документа, а поведение: дайте практические кейсы «куда пойти с этой таблицей». Ознакомление под подпись фиксирует ответственность, но работает оно вместе с удобной разрешённой альтернативой и примерами от руководителей — от верхнего уровня вниз.
Заведите реестр ИИ-активов
Реестр (AI BOM) — перечень всех систем ИИ компании: назначение, модель, режим данных, владелец, риски, статус соответствия политике. Он нужен и для порядка, и для отчётности по требованиям о критических ИИ-системах: контролирующие органы спрашивают перечень, а не ощущение. Ведение реестра — процесс: каждая новая система вносится до запуска, изменения фиксируются. Как это делается по требованиям заказчиков госсектора — в гайде ведения реестра по 243-ФЗ.
Назначьте регулярный аудит
Раз в полгода-год — проверка соответствия: жива ли политика, не разросся ли Shadow AI снова, работают ли технические контроли, актуален ли реестр. Для значимых контуров добавьте красную команду — имитацию атак на ассистенты и RAG-системы. Результаты аудита превращайте в задачи: разрыв без срока и ответственного не закрывается сам. Так цикл замыкается: инвентаризация — политика — контроль — проверка.
| Элемент | Владелец | Периодичность |
|---|---|---|
| Ревизия использования и Shadow AI | ИБ-ответственный | раз в полгода |
| Матрица «класс данных × режим» | ИБ + юрист | при изменениях требований |
| Политика использования ИИ | руководитель компании | пересмотр раз в год |
| Технический контроль (шлюз, guardrails) | ИТ-подразделение | постоянно |
| Реестр ИИ-активов (AI BOM) | владельцы сценариев | при каждом изменении |
| Аудит и красная команда | внешний аудитор | раз в год для значимых систем |
Что влияет на зрелость ИИ-безопасности
Зрелость определяется не толщиной документов, а тремя вещами: полнотой картины использования (включая теневые сервисы), удобством разрешённых альтернатив (люди идут туда, где удобно, а не где разрешено) и регулярностью проверки (аудит по плану, а не по инциденту). Компании с высокой зрелостью отвечают на вопрос «можно ли эти данные в этот сервис» за минуты — и ответ подтверждён контролем.
Чек-лист
Проверьте систему по списку после первого цикла и далее — при каждом аудите.
- Проведена ревизия, список Shadow AI известен и не пуст
- Назначен ответственный за ИИ-безопасность приказом
- У каждого сценария ИИ есть владелец
- Матрица «класс данных × режим» существует и применяется
- Политика утверждена, конкретна и коротка
- Есть разрешённая альтернатива для типовых задач
- Технический контроль не только запрещает, но и журлирует
- Команда обучена на практических кейсах, подписи собраны
- Реестр ИИ-активов ведётся до запуска систем
- Аудит запланирован, разрывы превращаются в задачи
- Инциденты проходят по регламенту, а не по чату
- Есть владелец процесса ИИ-безопасности с полномочиями через подразделения
- Инциденты разбираются без поиска виноватых — фокус на причине
Ошибки новичков
Типовые провалы организации — почти всегда один из этих пяти.
- Политика до инвентаризации. запрещают то, чем уже пользуются, не зная этого; документ дискредитируется в первый день
- Запрет без альтернативы. сотруднику не дали разрешённый инструмент для задачи — он вернулся к теневому сервису
- Ответственность «на всех». когда за ИИ-безопасность отвечают все, не отвечает никто; инцидент выявляется постфактум
- Политика ради галочки. абстрактные формулировки, никто не может сказать, можно ли конкретную таблицу в конкретный сервис
- Разовый проект вместо цикла. систему построили, проверили один раз и забыли; через год Shadow AI отрос обратно
Инструменты и сроки
Документы: приказ о ответственных, матрица классов данных, политика 3–5 страниц, реестр активов. Сроки: первый цикл — 30 дней; внешние работы быстрее — ревизия Shadow AI от 70 000 ₽, аудит ИИ 150 000 ₽ за 1–2 недели, красная команда 300 000 ₽.
- Приказ о владельцах и ролях
- Матрица «класс данных × режим обработки»
- Реестр ИИ-активов (AI BOM)
Что получится в итоге
Через месяц у компании работающая система: известна реальная картина использования, действует конкретная политика с техническим контролем, ведётся реестр, назначен аудит. ИИ перестаёт быть зоной неуправляемого риска: новые сценарии проходят по матрице за минуты, инциденты отрабатываются по регламенту, а перед проверками вы показываете документы, а не сочиняете их ночью.