В чём суть риска
Защита, реализованная только текстом промпта или самопроверкой модели, ненадёжна: OWASP отмечает, что системные промпты не являются средством контроля безопасности. Если ограничения существуют лишь в инструкции, их соблюдение нельзя гарантировать и доказать аудитору.
Приложение спрашивает саму модель, допустимо ли действие, и исполняет её ответ. Внешней проверки политики при этом нет. Решение модели вероятностно и зависит от контекста, поэтому один и тот же запрос может быть разрешён и отклонён. Граница доверия нарушается там, где контролируемый компонент одновременно выступает собственным контролёром.
Чем риск оборачивается для компании
Ограничения обходятся, поскольку они не подкреплены принудительной проверкой.
На аудите нечем подтвердить, что правило соблюдалось в каждом случае.
Поведение системы в значимых операциях оказывается непредсказуемым.
Где риск наиболее вероятен
Кому и что решать
Требовать в архитектуре AI-систем внешний слой проверки политик, независимый от модели.
Обеспечить детерминированную проверку прав доступа и подтверждение значимых действий, а также их доказуемую запись.
Не принимать заверение «модель проинструктирована» как достаточную защиту процесса.
Что стоит наблюдать
Признаки сами по себе не доказывают инцидент. Их полезно сопоставлять с учётной записью, версией модели, решением политики, источником контекста и результатом вызова инструмента.
Какие меры создают границу
Меры работают в связке и не перекладывают ответственность на модель: важны границы полномочий, владелец, телеметрия и процедура безопасного отказа.
Требование многослойной защиты
Закрепить в стандартах, что промпт не считается мерой контроля и дополняется независимыми слоями.
Подтверждение значимых действий
Определить операции, которые исполняются только после утверждения человеком.
Внешний механизм политик
Проверять каждое действие во внешнем компоненте, решение которого модель изменить не может.
Детерминированная проверка доступа
Применять права пользователя на уровне системы, а не по суждению модели.
Стенд для проверки ограничений
Регулярно тестировать, удерживаются ли ограничения при попытках их обойти.
Журнал решений о допуске
Записывать каждое решение о допустимости действия и его основание для аудита.
Вопросы, показатели и первые шаги
Вопросы команде и поставщику
- Какие ограничения наших AI-систем существуют только в тексте промпта?
- Что остановит действие, если модель ошибочно сочтёт его допустимым?
- Можем ли мы показать аудитору записи проверок перед значимыми операциями?
- Проверяет ли поставщик ограничения независимо от модели?
Показатели контроля
- Доля значимых действий, проходящих внешнюю проверку политики
- Число ограничений, реализованных только в промпте
- Доля операций с записью решения о допуске
Первые 30 дней
- Выявить действия, которые сейчас разрешает сама модель
- Вынести проверку прав для них во внешний компонент
- Включить журналирование решений о допуске
Как проверить в пилотном проекте
Проверить видимость реестра AI, владельцев, изменений политик и доказательность принятого решения.
Реестр связывает AI-сценарий, владельца, класс данных и развёрнутую модель или поставщика.
Изменение политики или конфигурации поставщика имеет проверку и событие аудита.
Риск и исключение могут быть показаны владельцу процесса в понятной форме.
Какие классы решений рассматривать
Ниже — редакционные профили поставщиков, связанные с доменом угрозы. Это не рейтинг и не подтверждение применимости: заявленные функции следует проверить в вашем пилоте по указанным критериям.
INFERA AI Security portfolio
InfEra Security · AI Security / DevSecOps
INFERA AI.SafeCode · INFERA AI.FirewallSTRAZH AI Control
STRAZH · Corporate AI Security
Shadow AI Audit & Control · LLM Firewall
AIGATE / DevScore / AIPitch
Aitalon · AI Gateway
AIGATE · DevScoreИсточники и проверка
Сначала — объяснение для русскоязычной команды. Затем — первоисточники, по которым можно проверить границы, методологию и применимость в конкретной архитектуре.