Ко всем статьям
Через полгода после запуска корпоративных ИИ-агентов обычно видно главное: где LLM экономит часы, а где просто красиво перекладывает ответственность на пользователя. Внутри периметра это различие особенно дорогое, потому что ошибка агента может затронуть документы, заявки, доступы и коммерческие данные.
Мы смотрим на ИИ-агентов не как на чат с модной надстройкой, а как на новый слой автоматизации. Он должен иметь владельца, права, журнал действий, понятный контур данных и измеримые ограничения. Без этого пилот быстро превращается в набор демонстраций.
Что реально работает
Лучше всего себя показали сценарии, где агент не принимает финальное бизнес-решение, а сокращает путь до него. Например, поиск по регламентам, подготовка черновика ответа в поддержку, разбор внутренней базы знаний, сводка по инциденту, классификация заявки и проверка комплекта документов.
RAG по корпоративным документам закрывает заметную часть типовых обращений, если документы подготовлены к поиску. Нужны актуальные версии, нормальная структура, метаданные, права доступа и понятные правила устаревания. Если загрузить в индекс папку с файлами «как есть», агент начнет уверенно ссылаться на старые инструкции.
Рабочий паттерн выглядит так: пользователь задает вопрос, LLM получает фрагменты из разрешенного набора документов, формирует ответ и показывает источники. Важная деталь — агент не должен отвечать, если не нашел опору в базе знаний. Фраза «нет достаточных данных» в корпоративной системе ценнее убедительной фантазии.
Хорошо работает и автоматизация вокруг заявок. Агент может извлечь сущности из письма, определить тип обращения, предложить маршрут, подготовить комментарий для Service Desk. Но подтверждение действия остается за сотрудником или workflow-системой с жесткими правилами.
Корпоративный ИИ-агент должен быть не самым разговорчивым участником процесса, а самым проверяемым.
Что не работает после демо
Плохо живут сценарии, где от агента ждут автономного управления сложным процессом без формализованных правил. «Пусть сам разберется с договором», «пусть согласует доступ», «пусть найдет проблему в инфраструктуре» — такие задачи на демо выглядят эффектно, но в эксплуатации упираются в ответственность.
Еще одна слабая зона — документы без владельцев. RAG не лечит хаос в базе знаний. Если регламент лежит в трех версиях, владелец процесса ушел два года назад, а актуальность подтверждается устно, агент только ускорит распространение ошибки.
Не взлетает и идея одного универсального агента для всех отделов. У службы поддержки, ИБ, юристов и эксплуатации разные источники, риски и критерии качества. На практике лучше работают узкие агенты с ограниченными правами и понятным набором действий.
Отдельная проблема — ожидания по точности. LLM может хорошо формулировать, но это не равно достоверности. Для корпоративного контура нужно разделять языковую способность модели и фактологическую гарантию системы. Гарантия появляется не в модели, а в архитектуре: источники, права, логирование, проверки, откат.
Безопасность данных внутри периметра
LLM внутри периметра не означает автоматическую безопасность. Модель, векторная база, очередь задач, логи, промпты и пользовательские вложения становятся частью контура обработки данных. Их нужно описывать так же, как любую другую ИТ-систему.
Ключевой принцип — агент видит только то, что мог бы увидеть пользователь. Это требует связки с корпоративной IAM-моделью, фильтрации документов на этапе retrieval и проверки прав перед выполнением действий. Нельзя дать модели общий индекс всех документов и надеяться, что она сама не раскроет лишнее.
Логи тоже требуют внимания. В них попадают пользовательские вопросы, фрагменты документов, ответы модели и иногда персональные данные. Для промышленной эксплуатации нужны маскирование, сроки хранения, разграничение доступа и понятный режим расследования инцидентов.
Prompt injection перестает быть академическим риском, когда агент читает письма, тикеты и wiki-страницы. Враждебная инструкция может попасть в документ и попытаться изменить поведение агента. Поэтому системные инструкции, пользовательский ввод и найденные документы должны иметь разные уровни доверия.
Как измерять пользу
Метрика «сколько раз спросили агента» почти ничего не говорит. Нужны показатели процесса: доля ответов со ссылками на источники, процент эскалаций человеку, время обработки заявки, количество исправлений, повторные обращения, ошибки доступа.
Для первых шести месяцев разумно запускать не больше трех сценариев. Один — справочный RAG по хорошо подготовленной базе знаний. Второй — помощник для классификации и маршрутизации заявок. Третий — ассистент аналитика или инженера, который собирает контекст, но не меняет состояние систем без подтверждения.
ИТ-директору важно заранее зафиксировать границы пилота. Какие данные доступны, кто владелец агента, какие действия запрещены, как проверяется качество, кто отвечает за инцидент. Тогда внедрение LLM становится управляемым проектом автоматизации, а не экспериментом с непредсказуемым эффектом.
Через полгода обычно остается меньше магии и больше инженерии. И это хороший результат: агент, который честно закрывает 30-40 % типовых обращений и не нарушает контур безопасности, полезнее универсального помощника, которому нельзя доверить ни одного действия.