Аналитика · Управление AI

Контур политик для корпоративного AI: где принимать решение до обращения к модели и инструментам

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

Иллюстрация к материалу «Контур политик для корпоративного AI: где принимать решение до обращения к модели и инструментам»
Темы:контроль доступауправление AIзащита данныхнулевое доверие

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

01

Принимайте решение вне модели

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

02

Опишите действия как контракт

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

03

Свяжите исключения с владельцем

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

04

Покажите решение в журнале

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

Граница применимости. Это защитно-ориентированное объяснение, а не гарантия предотвращения инцидентов. Контроли следует адаптировать через моделирование угроз, требования к данным и процессы реагирования вашей организации.

Продолжите исследование

Связанные риски

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

A01 · Высокий

Direct Prompt Injection

Недоверенный ввод или внешний контент влияет на поведение модели, нарушая границы заявленной задачи.

Открыть карточку
A32 · Высокий

Unauthorized access to model endpoints

Нагрузка, endpoint или инфраструктурный ресурс AI используется в обход ограничений доступности, сегментации или доверия.

Открыть карточку
A34 · Критический

Excessive agency / tool permissions

AI-агент получает или использует tools, память и автономность шире, чем необходимо для подтверждённой бизнес-задачи.

Открыть карточку
A35 · Критический

Confused deputy in agentic workflows

AI-агент получает или использует tools, память и автономность шире, чем необходимо для подтверждённой бизнес-задачи.

Открыть карточку
A38 · Высокий

Unsafe output handling into downstream systems

Модельный вывод или AI-assisted development создают риск для downstream приложений, кода, секретов или зависимостей.

Открыть карточку
Открыть интерактивную карту угроз
Первоисточники

Международные источники и практики

Сначала мы объясняем практический смысл материала на русском. Ниже — первоисточники для проверки и детального изучения границ применимости.

NISTAI 100-2e2025: Adversarial Machine LearningТаксономия атак и mitigations для adversarial ML.MITREMITRE ATLASТактики и техники против AI-систем.CISA / NSACareful Adoption of Agentic AI ServicesКонтроли для agentic AI.