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

О мероприятии

ИИ уже используется в компаниях шире, чем его видит ИБ. Сотрудники работают с публичными нейросетями, разработчики подключают 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 году?

Если компания сегодня почти не контролирует использование ИИ, какие три шага нужно сделать в первую очередь?