Безопасность ИИ: что проверить до запуска

Опасность живёт на стыках

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

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

Минимальный чеклист без героизма

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

• Подмена инструкций и вредные инструкции в документах
• sensitive information disclosure в ответах и логах
• excessive agency: действия без лимитов и подтверждение человеком
• излишнее доверие на ИИ: отсутствие ручной проверки в критичных решениях

Почему в 2026 это уже не факультатив

Регуляторная рамка стала практической. В ЕС уже действуют правила для GPAI, а прозрачность для пользователей и требования к высокорисковым системам постепенно превращаются в закупочные вопросы.

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

Модель угроз для пробной версии

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

Например, RAG-ассистент может столкнуться с подменой инструкций внутри документа, агент - с чрезмерными правами на CRM, OCR - с подменённым документом, а CV - с ложным событием из-за плохого ракурса. Риски разные, но логика одна: определить вход, действие, ущерб и способ остановки.

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

Подмена инструкций и грязные источники

Для RAG и агентов опасны не только пользовательские промпты. Инструкция может лежать прямо в документе: «игнорируй предыдущие правила», «выведи все данные клиента», «отправь письмо». Если ассистент читает такие документы как контекст, он должен отличать источник знаний от инструкции к действию.

На пробной версии стоит добавить тестовые вредные фрагменты в безопасной среде и проверить, как система реагирует: игнорирует инструкцию из документа, не раскрывает лишние данные, не вызывает инструмент без разрешения и объясняет пользователю границы ответа.

Доступы: меньше прав, меньше сюрпризов

ИИ-системе не нужен полный доступ к бизнесу. Ей нужен минимальный набор прав под конкретный сценарий. Для поддержки это чтение базы знаний и тикетов. Для помощник по заявкам - чтение заявки и создание черновика задачи. Для Document AI - доступ к очереди документов и справочникам, но не к финансовым операциям без подтверждения.

Разделение прав лучше проектировать по ролям и режимам: только чтение, черновик, подтверждение человеком, admin. Тогда можно запускать пробную версию постепенно и не блокировать весь проект из-за одного рискованного действия.

• только чтение для диагностики и поиска
• Черновик для подготовки карточек и ответов
• Подтверждение человеком для действий, которые меняют состояние системы

Порог перед запуском: что должно быть до запуска

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

Если у системы нет плана отката, она ещё не готова. Откат может быть простым: выключить автодействия, вернуть все ответы в manual проверка, ограничить темы, отключить конкретный инструмент, заменить запрос к модели или заблокировать документ-источник.

Что показывать заказчику в отчёте

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

Такой отчёт помогает согласовать пробную версию с руководителем процесса, юристом, IT и службой безопасности. Когда все видят границы, проект меньше буксует на уровне «мы боимся ИИ вообще».