Почему AI-сотруднику недостаточно просто уметь отвечать

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

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

Знания: откуда агент берёт факты

В реальной рабочей задаче ответ редко должен строиться только на общих знаниях языковой модели. Агенту требуется информация из документов, инструкций, регламентов и других источников организации.

RAG позволяет находить релевантные фрагменты в подключённой базе знаний и передавать их модели вместе с запросом. Это не делает каждый ответ автоматически правильным и не отменяет проверку источников. Однако такой подход помогает отделить корпоративный контекст от общих знаний модели.

До запуска необходимо определить:

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

Если источник отсутствует, устарел или противоречит другому документу, агент не должен достраивать уверенный ответ. В таких случаях задача передаётся человеку.

Память: какое состояние действительно нужно сохранять

Рабочий процесс может продолжаться несколько дней и состоять из нескольких обращений. Передавать весь предыдущий контекст вручную неудобно, поэтому агенту требуется память.

Но память полезна только тогда, когда заранее определены её назначение, владелец, срок хранения и правила удаления. Если сохранять каждую реплику и каждый вывод модели, память быстро превращается в непрозрачный источник состояния.

Например, подтверждённое предпочтение пользователя может быть полезным контекстом. Непроверенный вывод модели о причине ошибки, напротив, не должен автоматически становиться постоянным фактом.

Отдельно необходимо разделять управляющие инструкции, пользовательские сообщения, найденные документы и сохранённую память. Текст из внешнего источника не должен незаметно превращаться в команду для системы.

Инструменты: где заканчивается ответ и начинается действие

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

Для каждого инструмента необходимо определить:

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

Модель может предложить действие, но проверять и исполнять его должен отдельный сервисный слой. Это позволяет проверить параметры операции независимо от текста, который сформировала модель.

Особенно важно разделять подготовку и исполнение. Агент может подготовить письмо, изменение записи или другую операцию, но отправка либо сохранение должны выполняться только после предусмотренной процессом проверки.

Approval: человек должен видеть, что именно он подтверждает

Не каждое действие следует полностью автоматизировать. Если операция затрагивает внешнего адресата, права доступа, финансовые данные или другие значимые объекты, полезно встроить этап подтверждения человеком.

Approval — не декоративная кнопка «разрешить продолжить». Сотрудник должен видеть:

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

Если параметры действия изменились после согласования, необходимо запросить новое подтверждение. Иначе человек формально одобряет одну операцию, а система выполняет другую.

Для разных действий могут использоваться разные режимы. Черновик можно сохранить автоматически, внешнее сообщение — направить на согласование, а изменение прав доступа — полностью заблокировать до дополнительной проверки.

Аудит: как восстановить ход выполнения

Когда агент участвует в рабочем процессе, недостаточно сохранить только его итоговый ответ. При разборе ошибки необходимо понимать, какой контекст использовался, какие инструменты вызывались, что предложила модель и кто подтвердил действие.

В журнале могут фиксироваться:

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

При этом аудит не должен превращаться в бесконтрольный архив всех данных. Состав записей, сроки хранения и доступ к журналам также требуют отдельной политики.

Что меняет self-hosted-развёртывание

Размещение системы в собственной инфраструктуре позволяет организации самостоятельно управлять сервером, сетью, обновлениями и частью маршрута данных. Но self-hosted сам по себе не делает агентную систему безопасной.

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

Локальная модель тоже не решает автоматически вопросы качества источников, избыточных полномочий или ошибочных действий. Облачная модель, в свою очередь, не обязательно означает полный отказ от контроля. Архитектуру необходимо выбирать под конкретный процесс и требования организации.

Как начинать внедрение

Практичный старт — один узкий и воспроизводимый сценарий. Не «автоматизировать продажи», а, например:

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

Для такого сценария можно заранее определить допустимые источники, набор инструментов, точки согласования и события аудита.

Перед расширением системы стоит воспроизвести как минимум четыре ситуации:

1. Нормальное выполнение разрешённого действия.
2. Отказ из-за недостаточных полномочий.
3. Остановка критичной операции на подтверждение.
4. Восстановление после недоступности внешнего сервиса.

Для каждого теста фиксируются исходные данные, ожидаемое поведение, записи аудита и фактический результат.

Как это реализовано в AiHummer

В AiHummer RAG, память, инструменты, human approval и аудит образуют основу для создания управляемых AI-сотрудников.

Платформа доступна как SaaS и в self-hosted/on-prem варианте для Linux. Можно использовать облачные, локальные и OpenAI-совместимые модели. Конкретная конфигурация выбирается под процесс, инфраструктуру и требования организации.

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

Материал подготовлен командой AiHummer.

Подробнее о платформе: https://aihummer.ru/