Как подключить корпоративные данные к AI-агенту безопасно

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

Подключение корпоративных данных — это не разовая интеграция, а отдельный этап внедрения со своими решениями: что именно давать, в каком виде, с какими правами и как потом проверять, что агент отвечает правильно. Ниже разбираем этот этап по шагам. Материал продолжает разговор, начатый в статье о выборе процесса для первого AI-агента: там мы отбираем задачу, здесь — готовим под неё данные.

Почему агент без данных отвечает общими словами

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

Отсюда два типичных исхода неподготовленного пилота. Либо агент честно отвечает общими формулировками, и сотрудники перестают им пользоваться. Либо он формулирует уверенный ответ, опираясь на общие представления о том, как «обычно бывает», и этот ответ расходится с правилами компании. Второй случай опаснее: ошибку заметят не сразу, а доверие к системе упадёт надолго.

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

Какие источники обычно нужны

Набор зависит от сценария, но состав источников повторяется от проекта к проекту:

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

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

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

Подготовка данных до подключения

Определить актуальную версию

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

Привести к пригодному для поиска виду

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

Добавить метаданные

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

Убрать лишнее

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

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

Принцип простой: агент получает ровно те данные и действия, которые нужны его сценарию, и ничего сверх того.

Практические правила, которых стоит придерживаться:

1. Отдельная учётная запись для агента. Не общий административный доступ и не личный доступ сотрудника: иначе в журналах невозможно отличить действия агента от действий человека.
2. Чтение по умолчанию, запись — по отдельному решению. Многие полезные сценарии вообще не требуют изменения данных.
3. Ограничение области. Доступ к нужным сущностям и полям, а не ко всей базе: заявки конкретного типа, номенклатура конкретного направления.
4. Подтверждение человеком для значимых действий. Отправка клиенту, изменение статуса в учётной системе, любые финансовые операции — через явное подтверждение.
5. Журнал обращений. Что спросили, какие данные агент запросил, что ответил. Без журнала разбор ошибки превращается в реконструкцию по памяти.

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

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

Как проверить, что агент отвечает правильно

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

Что имеет смысл проверить на таком наборе:

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

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

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

Что делать после запуска

Данные компании меняются постоянно, поэтому подключение — не финальная точка. Минимальный набор регулярных действий:

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

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

Когда подключать данные рано

Иногда правильный вывод — отложить. Признаки, что контур ещё не готов:

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

В таких случаях подготовка данных полезна сама по себе, независимо от ИИ: актуальный регламент и заполненная CRM нужны компании и без агента. Подробнее о порядке работ — на страницах «ИИ для бизнеса» и «Подход». Готовый вариант развёртывания агента с доступом к рабочим системам описан в разделе OpenClaw и Hermes, а сценарий с данными маркетплейсов — в разделе AI-аналитик.

Подключение данных — это работа с источниками, правами и проверками, а не настройка одной интеграции. Если вы разбираетесь, с чего начать в своём случае, опишите задачу: разберём, какие источники нужны вашему сценарию и что стоит подготовить до разработки.