AI security пора перестать воспринимать как тему для конференций и исследовательских команд. Это уже практическая зона ответственности корпоративной ИБ.

Во многих компаниях внедрение искусственного интеллекта начинается примерно одинаково.

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

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

Этого уже недостаточно.

LLM-приложение состоит не только из модели. В нём есть prompts, embeddings, RAG, векторные хранилища, корпоративные документы, память, внешние источники, model outputs, API и инструменты агента.

В результате появляются вопросы, которых не было в обычной архитектуре:

— Может ли инструкция из документа изменить поведение модели? — Сохраняется ли исходная модель доступа при поиске через RAG? — Кто контролирует, какие инструменты вызывает агент? — Можно ли доверять output модели как команде для другой системы? — Сможет ли SOC восстановить контекст AI-инцидента? — Кто принимает остаточный риск всей цепочки?

На практике эти вопросы распределяются между несколькими функциями.

AppSec отвечает за код. IAM — за права. DLP — за данные. GRC — за требования. Архитектура — за интеграции. Владелец продукта — за бизнес-сценарий.

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

Я не согласен с подходом, при котором AI security пытаются полностью «растворить» в существующих процессах.

Да, Secure SDLC, IAM, DLP, SOC и управление поставщиками остаются обязательными. Но у AI есть специфические риски: prompt injection, отравление контекста, раскрытие данных через outputs, небезопасная обработка результатов, избыточная автономность агентов и компрометация цепочки retrieval.

Этим рискам нужны собственные модели угроз, требования и методы тестирования.

Особенно важен вопрос полномочий AI-агентов.

Когда модель только предлагает текст, человек остаётся точкой принятия решения. Когда агент получает доступ к API и корпоративным системам, model output становится основанием для реального действия.

И здесь нельзя полагаться только на то, что модель «правильно поняла задачу».

Полномочия агента должны ограничиваться технически:

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

Моя позиция: компании уже нужна отдельная практика AI security внутри ИБ и архитектуры.

Речь не обязательно о новом департаменте. На первом этапе достаточно создать управляемый контур:

— назначить владельца; — вести реестр AI-систем; — классифицировать сценарии по риску; — встроить AI threat modeling в архитектурный процесс; — определить требования к данным, RAG, prompts и агентам; — проводить adversarial testing; — собирать AI-specific telemetry; — подготовить сценарии реагирования на инциденты.

При этом задача ИБ — не закрыть доступ к AI.

Один запрет почти всегда ведёт к shadow AI: сотрудники продолжают использовать полезные инструменты, но компания теряет контроль над данными, интеграциями и результатами.

Зрелость заключается в другом: ИБ должна сформировать безопасный и достаточно быстрый путь от идеи до промышленного внедрения.

Главный риск AI — не отдельная ошибка модели. Риск возникает, когда её недетерминированное решение соединяется с чувствительными данными, широкими полномочиями и реальными бизнес-действиями.

Как вы считаете: AI security уже должна оформляться в самостоятельную практику или существующих процессов AppSec, GRC и архитектурного контроля пока достаточно?