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