Безопасное применение ИИ для бизнес-задач

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

Пока ИИ только отвечает на запросы, многое можно контролировать на уровне данных, промптов и доступа к моделям. Но с появлением AI-агентов задача меняется: модель уже может обращаться к MCP-серверам, вызывать инструменты и выполнять реальные действия от имени пользователя или системы. Одного LLM/AI Firewall в такой архитектуре уже может быть недостаточно.

В эфире AM Live разберём, как обнаружить Shadow AI и выстроить контроль от запроса к модели до действий агента. Обсудим возможности и границы LLM Firewall, защиту MCP и tool calls, управление правами AI-агентов, интеграцию с IAM, PAM, DLP, SIEM и API Security. И отдельно поговорим о том, кто внутри компании должен отвечать за этот новый контур безопасности.

Программа

ИИ уже внутри, но видит ли его ИБ

Можно ли вообще составить полный реестр ИИ, который используется в компании, или часть сервисов всё равно останется невидимой?
Хватит ли SWG, CASB, DLP, EDR и контроля API, чтобы обнаружить Shadow AI, или нужен отдельный AI Discovery?
Что делать с несанкционированными AI-сервисами: блокировать или контролировать?
Допустим, мы обнаружили сотню AI-сервисов. По каким трём признакам понять, какие из них проверять и ограничивать в первую очередь?
Что сегодня считать AI-активом компании: только модель или всю цепочку - от промпта и RAG до памяти, API и инструментов агента?
Когда недостаточно защищать только доступ к модели и приходится отдельно защищать саму модель, её конфигурацию, инфраструктуру и цепочку поставки?
Если модель выдала опасный для бизнеса ответ, кто должен первым получить сигнал и иметь право остановить систему?
В какой момент AI-риск становится заметно выше: когда модель получает внутренние данные, память, доступ к API - или когда начинает действовать без подтверждения человека?

Модель отвечает. Агент действует

Какие функции сегодня обязательны для полноценного LLM / AI Firewall?
Как пилотировать LLM Firewall, чтобы проверить его в реальной инфраструктуре, а не на красивом демо?
Можно ли вообще обещать защиту от prompt injection или честнее говорить только о снижении риска успешной атаки?
Что LLM Firewall не видит, если стоит только между приложением и API модели?
LLM Firewall должен сам принимать решение allow / deny или передавать AI-контекст в существующие IAM, DLP, PAM, SIEM и API Security?
Нужно ли журналировать каждый промпт и ответ - или так компания сама создаёт хранилище самых чувствительных данных?
Что должен контролировать Agent Runtime Security?
Нужна ли AI-агенту собственная цифровая идентичность или он всегда должен действовать от имени пользователя?
Можно ли давать агенту постоянные привилегии или права должны выдаваться под конкретное действие и на ограниченное время?
Как проверять MCP-серверы и инструменты, которым агент получает право доверять?
Какие действия агенту нельзя разрешать без подтверждения человека?
Что вы считаете следующей большой поверхностью атаки в AI-системах?

Итоги и прогнозы

Через два-три года LLM Firewall и Agent Runtime Security останутся отдельными классами решений или их функции уйдут в DLP, SWG, IAM/PAM, API Security и крупные security-платформы?
Какое решение в AI Security, принятое сегодня, с наибольшей вероятностью окажется ошибкой к 2029 году?
Если компания сегодня почти не контролирует использование ИИ, какие три шага нужно сделать в первую очередь?