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

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

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

В эфире разберём, как обнаружить 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 году?

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

Приглашенные эксперты:

Вячеслав Валькович

Руководитель развития облачных AI-сервисов, ITGLOBAL.COM, корпорация ITG

Никита Беляевский

Руководитель отдела аудита Безопасности ИИ-систем, HiveTrace

Денис Каракай

Владелец продукта Гарда AI Security, «Гарда»

Модераторы:

Илья Самофеев

CEO,red_mad_robot