Фраза «внедрить AI в компании» звучит масштабно и потому плохо подходит для первого проекта. У компании десятки процессов с разными данными, рисками и владельцами. Попытка охватить всё сразу делает результат трудно проверяемым.
Мы в Agent Core пришли к противоположной логике: bounded rollout — ограниченный контур, точные права, проверка и только потом расширение.
Первый процесс должен быть достаточно важным
Слишком игрушечная задача ничего не доказывает. Нужен процесс, где есть заметная ручная нагрузка, задержка или сложность доступа к информации, но ошибка при пилоте контролируема.
Хороший кандидат имеет понятный вход и выход. Например, собрать состояние из нескольких систем, найти исключения или подготовить следующее действие.
Граница пилота должна быть явной
Какие системы доступны? Что разрешено только читать? Что можно менять? Кто подтверждает внешние действия? Какие данные запрещено передавать модели?
Без этого «пилот AI» быстро превращается в бесконечное расширение scope.
После пилота нужен критерий решения
Сократилось ли ручное время? Быстрее ли обнаруживаются проблемы? Уменьшилось ли число переходов между системами? Какова цена поддержки и ошибок?
Ограничение пилота — он не доказывает эффект для всей компании. Но именно это и хорошо: решение о масштабировании принимается на фактах конкретного процесса, а не на впечатлении от демонстрации.
Почему узкий пилот легче защищать перед бизнесом
Когда scope ограничен, можно назвать стоимость, владельца процесса и ожидаемый эффект. Если результат слабый, ясно, что именно не сработало. В «AI-трансформации всей компании» отрицательный результат легко объяснить недостатком масштаба, данных или времени, и проект становится почти непроверяемым.
Я бы предпочёл несколько маленьких доказанных контуров одной большой инициативе. После них уже видно, где повторяется архитектура и какие компоненты имеет смысл стандартизировать для всей компании.
Такой подход ещё и упрощает обучение команды. Люди видят один новый сценарий, понимают его ограничения и могут сравнить с прежней работой. После этого расширение воспринимается не как абстрактная реформа, а как следующий понятный инструмент.
Чтение и запись должны быть разными полномочиями
Для аналитического запроса системе может быть достаточно доступа к CRM, метрикам или документам только на чтение. Это уже позволяет собрать картину, найти исключения и подготовить рекомендацию. Право записи для такой задачи не даёт дополнительной ценности, но увеличивает последствия ошибки.
Поэтому я бы выдавал write-доступ не «агенту вообще», а конкретному инструменту и конкретному действию. Чем уже разрешение, тем проще понять, что может произойти после ошибки модели или неверного контекста.
Между решением и эффектом нужен контракт
Когда AI считает, что нужно изменить внешний объект, полезно сформировать действие как структурированное намерение: какой объект, какое поле, новое значение и на каком основании. Затем отдельный слой проверяет, допустима ли операция, не устарело ли состояние и требуется ли подтверждение человека.
Это разрывает опасную связь «модель написала — сразу выполнили». Рассуждение остаётся гибким, а реальный эффект проходит через предсказуемый контракт.
Подтверждение должно зависеть от последствий
Не каждое действие требует одинакового контроля. Создать внутренний черновик и удалить данные — разные риски. Изменить внутренний тег и отправить сообщение клиенту — тоже. Я бы классифицировал эффекты по обратимости, внешней видимости, деньгам и юридической значимости.
Низкорисковые обратимые действия можно постепенно автоматизировать. Для значимых действий подтверждение человеком остаётся нормальным элементом архитектуры, а не признаком «недостаточно умного AI».
После записи нужен read-back
Самая важная проверка появляется после выполнения. HTTP-ответ или нажатая кнопка ещё не доказывают, что бизнес-состояние изменилось правильно. Поэтому система должна, где возможно, снова прочитать объект и сравнить ожидаемый результат с фактическим.
Для публикации это может быть публичный URL и нужный текст. Для CRM — новое значение поля. Для созданного заказа — идентификатор и возможность получить объект из системы. Если доказательство не найдено, корректный статус — неопределённость, а не «готово».
Сегодняшний сбой показал ценность такой границы
При работе с нашим контентным контуром мы обнаружили, что запросы к одному WordPress могли попадать в соседний сайт из-за коллизии Docker-имён. Сам API при этом отвечал. Если бы система доверяла только факту успешного HTTP-запроса, она могла бы записать контент не туда.
После ремонта мы добавили отдельную проверку identity origin перед записью: WordPress должен сам сообщить ожидаемый домен. Если отвечает другой сайт, публикация останавливается до POST. Это как раз пример того, почему «инструмент доступен» и «инструмент безопасно соответствует нужному объекту» — разные состояния.
Журнал нужен на уровне эффекта
Я бы сохранял не только диалог с моделью, но и факт действия: какой инструмент вызван, с какими параметрами, какой объект изменён, что ответила внешняя система и чем подтверждён результат. Такой журнал помогает разбирать не только ошибки AI, но и сетевые, интеграционные и авторизационные сбои.
Это также позволяет повышать автономность на фактах. Если определённый тип действия стабильно выполняется и read-back подтверждает результат, его можно переводить из ручного подтверждения в автоматический режим.
Как начать без опасной универсальной учётной записи
Для первого сценария я бы дал системе минимальный набор инструментов. Отдельно — чтение нужных данных. Отдельно — один безопасный write-инструмент с ограниченными параметрами. Для остальных действий AI только готовит предложение.
Так проще увидеть реальную пользу и реальные исключения. Универсальные права можно не выдавать вообще, если бизнес-процесс этого не требует.
Граница «видит/делает» — продуктовая, а не техническая
Пользователь должен понимать, когда система только анализирует, когда готовит действие и когда уже меняет внешний мир. Если эти состояния визуально и логически смешаны, человек начинает воспринимать предложение как выполненный факт или, наоборот, опасаться любого ответа AI.
Ясная граница повышает доверие не за счёт обещаний, а за счёт предсказуемости. Именно поэтому управление полномочиями я считаю частью продукта, а не внутренней настройкой разработчика.
Безопасное расширение начинается с доказанного low-risk сценария
Я бы сначала автоматизировал действие, которое обратимо, хорошо логируется и имеет простой read-back. После серии подтверждённых результатов можно расширять набор объектов или параметров. Так полномочия растут вместе с доказательствами, а не потому, что модель в демонстрации выглядела уверенно.
Если нужен стартовый AI-сценарий, мы сначала выбираем один процесс и границы, а не обещаем «трансформацию всей компании»: обсудить AI-контур
Если нужен не отдельный отчёт, а регулярный контроль по рабочим данным компании, см. AI-ассистента руководителя по продажам и управлению.
Связанный кейс Agency: Как мы проверяли контентную систему 14 виртуальных дней.