Можно построить очень умный чат, который красиво отвечает на вопросы о продажах, но не знает, сколько заказов пришло сегодня. Мы довольно быстро упёрлись в эту границу при развитии Agent Core.
Модель умеет рассуждать. Бизнес-интерфейс должен ещё и получать фактическое состояние из систем.
Общие знания и операционные факты — разные вещи
На вопрос «почему может падать конверсия» AI ответит без доступа к компании. На вопрос «где именно у нас сегодня потерялись заявки» нужны CRM, аналитика, логи или другие источники.
Если доступа нет, модель не должна заполнять пустоту правдоподобной версией.
Подключение данных важнее ещё одного промпта
Нужно решить, где находится источник истины, как часто данные обновляются, какие поля доступны, как определяется пользователь и как логируется обращение.
Для разных систем способы будут разными: API, база, файл, почта, браузерный интерфейс. Технология вторична по отношению к достоверности и правам.
Ответ должен сохранять путь к факту
Я предпочитаю, чтобы важный вывод можно было проверить: открыть сделку, увидеть метрику, перейти к документу или получить идентификатор события. Тогда AI ускоряет работу, но не становится единственным источником истины.
Ограничение очевидно: доступ к данным создаёт и требования безопасности. Поэтому подключать всё сразу — плохая идея; права должны соответствовать конкретному сценарию.
Качество ответа начинается до модели
Если CRM содержит дубли, сайт отдаёт разные статусы, а учёт обновляется с задержкой, AI получает противоречивую картину. Более дорогая модель не исправляет происхождение данных. Поэтому полезно хранить источник и время каждого важного факта, а при конфликте показывать неопределённость.
Для управленческого интерфейса это особенно важно: собственнику нужен не уверенный текст, а возможность понять, на каких системах основан вывод и насколько свежо состояние.
Отдельно я бы проверил свежесть данных. Правильный ответ на вчерашнем состоянии может быть опаснее явной ошибки, потому что выглядит убедительно. Важные операционные факты должны не только иметь источник, но и понятное время обновления.
Начинать стоит с отдельной технической роли
Я бы не подключал AI под учётной записью руководителя или администратора. Для интеграции нужна отдельная техническая идентичность с правами ровно на тот процесс, который автоматизируется. Тогда её доступ можно отключить, изменить и проверить независимо от человеческих аккаунтов.
Если CRM поддерживает роли, scopes или отдельные API-ключи, права лучше собирать из минимального набора: читать нужные сущности, создавать строго определённый тип объекта или менять ограниченный набор полей. Универсальный административный доступ удобнее на старте, но опаснее в эксплуатации.
Read-only — хороший первый этап
Большинство управленческих сценариев можно проверить без записи. AI способен собирать просроченные сделки, находить заявки без ответа, группировать причины потерь и готовить рекомендации, имея только чтение. Это позволяет оценить качество выводов и данных до того, как система получит право менять CRM.
Если read-only сценарий не приносит пользы, добавление write-доступа проблему не исправит. Если польза доказана, становится понятнее, какие конкретные действия действительно стоит автоматизировать.
Права лучше выдавать по эффектам, а не по разделам интерфейса
Формулировка «доступ к сделкам» слишком широкая. Что именно можно делать? Создавать заметку? Менять этап? Переназначать ответственного? Удалять? Отправлять сообщение? Каждый эффект имеет разную цену ошибки.
Я бы составлял таблицу действий и отдельно отмечал, какие из них разрешены автоматически, какие только готовятся AI для подтверждения, а какие вообще остаются человеку. Такая матрица понятнее абстрактной роли «оператор CRM».
Секреты не должны жить в prompt или истории диалога
API-ключ, пароль или refresh-token относятся к инфраструктуре. Модель должна получать возможность вызвать разрешённый инструмент, а не сам секрет в контекст. Тогда текст задачи, журнал рассуждения и пользовательский ввод не становятся местом хранения учётных данных.
Секреты стоит хранить в предназначенном для этого хранилище или защищённой конфигурации, ограничивать доступ к ним и иметь процедуру ротации. Если ключ скомпрометирован, его можно заменить, не переписывая весь AI-процесс.
Подтверждение нужно привязывать к риску действия
Создать внутреннюю заметку и удалить сделку — разные операции. Изменить служебный тег и отправить клиенту сообщение — тоже. Поэтому подтверждение человеком лучше назначать не на «весь AI», а на чувствительные эффекты.
Низкорисковые обратимые действия после тестирования можно выполнять автоматически. Для денег, удаления, внешних сообщений и важных статусов ручное подтверждение может оставаться постоянной частью процесса.
Перед записью нужно проверять состояние
Между чтением сделки и попыткой её изменить может пройти время. За это время менеджер уже поменял этап или ответственного. Поэтому write-инструмент должен по возможности проверять актуальное состояние и не применять действие, основанное на устаревшем контексте.
Это особенно важно для автономных цепочек. Агент может рассуждать правильно относительно старых данных и всё равно выполнить неверный эффект, если не перечитает объект перед записью.
После записи нужен read-back
CRM вернула успешный ответ — это ещё не окончательное доказательство. Где возможно, система должна снова запросить изменённый объект и проверить нужное поле. Если результат не совпадает, операция остаётся неподтверждённой и попадает в разбор.
Так журнал фиксирует не только попытку, но и фактический результат. Это упрощает поддержку и позволяет безопасно повторить действие при сетевой ошибке, не создавая дублей.
Нужна защита от массового эффекта
Даже безопасная операция становится опаснее, если применяется сразу к большому числу объектов. Поэтому я бы вводил лимиты: количество изменений за один запуск, допустимый тип выборки и отдельное подтверждение для массовой операции.
Это защищает от ошибки фильтра или неверно понятых условий. Система может сначала показать список объектов и только затем получить право на пакетное действие.
Аудит должен отвечать на простой вопрос «кто что изменил»
Для каждого эффекта полезно сохранять техническую идентичность, время, объект, параметры, основание, ответ CRM и результат read-back. Тогда при спорном изменении не нужно восстанавливать цепочку по переписке.
Если CRM хранит собственный журнал, его стоит использовать вместе с журналом AI-контура. Они показывают две стороны одного события: почему система решила действовать и что внешняя система фактически сохранила.
Расширять права нужно постепенно
Я бы начал с одного процесса: например, найти заявки без ответа и подготовить служебную задачу. После стабильной работы можно добавить создание заметки, затем ограниченное изменение поля. Каждый новый эффект проходит отдельную проверку рисков и read-back.
Так безопасный доступ строится не обещанием «AI не ошибётся», а архитектурой, в которой ошибка имеет ограниченный радиус и заметный след.
Мы начинаем AI-контур с карты систем и фактов, к которым нужен управляемый доступ: обсудить AI-контур
Если нужен не отдельный отчёт, а регулярный контроль по рабочим данным компании, см. AI-ассистента руководителя по продажам и управлению.