СейчасЧто должно появиться к тридцатому дню
- Что должно появиться к тридцатому дню
- Первая неделя: выбрать процесс и увидеть реальность
- День 1. Выберите один процесс
- Дни 2–3. Разберите процесс таким, какой он есть
- Дни 4–5. Снимите исходные показатели и назначьте владельца
- Вторая неделя: подготовить контекст, данные и доступы
- Дни 6–7. Определите источники правды
- Дни 8–9. Дайте минимум полномочий
- День 10. Соберите паспорт контура
- Третья неделя: научить систему останавливаться
- Сформулируйте контракт задачи
- Подготовьте проверочные сценарии
- Проведите линии остановки
- Включите журнал действий
- Четвёртая неделя: агент зарабатывает автономность
- Дни 21–24. Наблюдение
- Дни 25–27. Совет и черновик
- Дни 28–29. Действие с подтверждением
- День 30. Решение о следующем уровне
- Как это выглядит в моей текущей работе
- Шесть ошибок, которые ломают первый пилот
- Что делать после тридцатого дня
- Источники
- Следующий шаг
- Связанные материалы
Тридцати дней недостаточно, чтобы перестроить компанию. Этого времени вполне хватает, чтобы запустить один рабочий контур с ИИ-агентом и получить честный ответ: где он приносит пользу, какие ограничения ему нужны и готова ли организация дать ему больше самостоятельности.
Именно с одного контура я бы и начинал. Не с покупки «агентной платформы», не с большого проекта трансформации и не с попытки автоматизировать сразу весь отдел. Сначала нужен один процесс, один владелец результата, понятные данные, минимальные доступы и заранее определённые линии остановки.
Это третья практическая часть серии об ИИ-компании. В материале о том, кто отвечает за результат работы ИИ-агентов, я разбирал ответственность и контроль. В статье «Организация как граф задач» — новую логику распределения работы. Теперь соберём из этих принципов план первого внедрения.
Что должно появиться к тридцатому дню
Готовность компании к агентам не измеряется количеством купленных подписок. К концу месяца у вас должен работать один ограниченный процесс, в котором можно восстановить всю цепочку: от входной задачи до результата, проверки и решения человека.
Минимальный результат выглядит так:
- выбран один повторяемый процесс;
- зафиксировано его текущее состояние до внедрения;
- назначен человек, отвечающий за итог;
- описаны вход, ожидаемый выход и критерии завершения;
- агент получает только необходимые данные и полномочия;
- подготовлен набор проверочных сценариев;
- все значимые действия попадают в журнал;
- определены ситуации, в которых агент обязан остановиться;
- существует понятный возврат к ручной работе;
- назначена дата решения: остановить, изменить или расширить пилот.
OpenAI в своём практическом руководстве по агентам рекомендует заранее задавать проверки, ограничения и вмешательство человека для рискованных действий. Anthropic формулирует близкий принцип: начинать с простой конструкции и добавлять сложность только тогда, когда она даёт измеримое улучшение.
Первая неделя: выбрать процесс и увидеть реальность
Первые пять дней лучше провести без автоматизации. Задача недели — понять, что именно компания собирается поручить агенту.
День 1. Выберите один процесс
Для первого пилота подходит работа, которая:
- повторяется достаточно часто;
- имеет ясный вход и наблюдаемый результат;
- допускает проверку человеком;
- обратима либо не создаёт большого ущерба при ошибке;
- уже оставляет цифровой след: документы, карточки, письма, записи в системе;
- содержит достаточно примеров хорошего и плохого результата.
Хорошими кандидатами могут быть первичная классификация обращений, подготовка черновика ответа, сбор данных для отчёта, проверка комплектности документов или обновление внутренней карточки. Платёж, увольнение, юридическое обязательство, удаление данных и публичная отправка от имени компании для первого пилота слишком рискованны.
Дни 2–3. Разберите процесс таким, какой он есть
Не начинайте с регламента. Пройдите несколько реальных задач вместе с исполнителем и запишите фактический маршрут: откуда приходит запрос, где берутся данные, какие решения человек принимает по ходу работы, кому задаёт вопросы, что считает готовым результатом.
На этом этапе часто выясняется, что часть шагов существует по привычке. Их лучше убрать до внедрения. Агент способен быстро выполнять лишнюю работу, но от этого она не становится полезной.
Дни 4–5. Снимите исходные показатели и назначьте владельца
Зафиксируйте время прохождения задачи, число ручных касаний, возвраты на доработку, типичные ошибки и причины задержек. Не обязательно строить сложную систему аналитики. Нужна точка отсчёта, с которой можно сравнить пилот.
Одновременно назначьте владельца результата. Это не администратор модели и не человек, который умеет писать промпты. Владелец понимает смысл процесса, принимает итог и отвечает за последствия. Техническая команда может обслуживать агента, но не должна наследовать бизнес-ответственность только потому, что подключила инструмент.
Вторая неделя: подготовить контекст, данные и доступы
ИИ-агент отличается от обычного чат-бота тем, что получает цель, использует инструменты и совершает последовательность действий. В определении OpenAI агент складывается из модели, инструкций и инструментов. Значит, качество модели — лишь одна часть системы. Две другие части компания должна подготовить сама.
Дни 6–7. Определите источники правды
Для каждого типа данных ответьте на четыре вопроса:
- Где находится актуальная версия?
- Кто отвечает за её качество?
- Как агент понимает, что запись устарела или противоречит другой записи?
- Что делать, если надёжного источника нет?
Фраза «посмотри в CRM» недостаточна, если в CRM три карточки одного клиента, поля заполняются по-разному, а часть договорённостей живёт в переписке. До подключения агента организации приходится договориться о собственных сущностях: что считается клиентом, активной сделкой, подтверждённым платежом, обязательством и завершённой задачей.
Дни 8–9. Дайте минимум полномочий
Разделите инструменты по уровню риска:
- чтение данных;
- подготовка рекомендации;
- создание черновика;
- изменение внутренней записи;
- внешнее или необратимое действие.
Начинайте с чтения и черновиков. Отдельная идентичность агента, короткоживущий доступ и разрешения на конкретную задачу полезнее общего аккаунта сотрудника. OWASP называет сочетание избыточной функциональности, широких полномочий и высокой автономии excessive agency — избыточной агентностью. Общие учётные данные создают разрыв ответственности: потом трудно установить, кто именно совершил действие и на каком основании.
День 10. Соберите паспорт контура
Одна страница должна отвечать на основные вопросы:
- какую задачу получает агент;
- кто владеет результатом;
- что запускает работу;
- какие источники разрешены;
- какие инструменты доступны;
- что агенту запрещено;
- как выглядит готовый результат;
- когда нужен человек;
- что записывается в журнал;
- как отключить контур и вернуться к ручному процессу.
Этот паспорт важнее длинного общего регламента. Он описывает конкретную работу и становится контрактом между владельцем процесса, технической системой и агентом.
Третья неделя: научить систему останавливаться
Дни с 11-го по 20-й нужны для инструкций, проверок и границ. Сильный агентный контур определяется не только тем, что он умеет делать. Не менее существенно, где он прекращает действие и передаёт решение человеку.
Сформулируйте контракт задачи
Хорошая инструкция содержит:
- ожидаемый результат;
- допустимые источники и инструменты;
- порядок ключевых действий;
- критерии качества;
- запрещённые действия;
- условия эскалации;
- формат отчёта о выполнении.
Если для процесса уже существуют качественные регламенты, инструкции поддержки или политики, OpenAI советует использовать их как основу инструкций агента. При этом исключения и пограничные случаи нужно описывать явно: именно там чаще всего возникает ошибочная самостоятельность.
Подготовьте проверочные сценарии
Возьмите реальные исторические примеры и добавьте синтетические случаи для редких, но опасных ситуаций. В наборе должны быть обычные задачи, неоднозначные входы, пропущенные данные, конфликтующие источники и запросы, которые агент обязан отклонить или передать человеку.
Универсального числа сценариев нет. Для первого контура важнее покрыть разные классы поведения и зафиксировать ожидаемый результат. Anthropic в руководстве по оценке ИИ-агентов предлагает начинать с ясных критериев успеха и проверять не только финальный ответ, но и последовательность действий в многошаговой работе.
Проведите линии остановки
Агент прекращает работу, когда:
- отсутствует обязательный источник;
- данные противоречат друг другу;
- задача выходит за разрешённый контур;
- требуется платёж, публикация, удаление или юридически значимое действие;
- превышено допустимое число повторных попыток;
- проверка результата не пройдена;
- система не может надёжно установить пользователя, объект или полномочие.
Для каждой линии остановки нужен адресат и ожидаемое действие человека. Иначе эскалация превращается в ещё одну очередь, где задача просто зависает.
Включите журнал действий
Минимальная запись должна показывать: какую задачу получил агент, какими источниками пользовался, какие инструменты вызывал, что изменил, какие проверки прошёл и кто подтвердил итог. Такой журнал нужен не для тотального наблюдения за моделью. Он позволяет разбирать ошибки, спорные решения и постепенно расширять автономность на основании фактов.
Четвёртая неделя: агент зарабатывает автономность
Последние десять дней — это ступенчатый пилот. Агент получает дополнительные полномочия только после того, как предыдущий уровень показал приемлемое качество.
Дни 21–24. Наблюдение
Агент проходит реальные задачи параллельно с человеком, но ни на что не влияет. Команда сравнивает его маршрут и результат с обычной работой. Это режим тени: система уже видит реальность, однако риск остаётся минимальным.
Дни 25–27. Совет и черновик
Сначала агент предлагает решение. Затем готовит результат целиком, а человек проверяет и применяет его. Здесь становятся видны две разные проблемы: способен ли агент получить качественный ответ и способен ли встроиться в рабочий процесс без лишней нагрузки на проверяющего.
Дни 28–29. Действие с подтверждением
Агенту можно разрешить ограниченное изменение, если человек явно подтверждает конкретное действие и видит его последствия. Подтверждение должно относиться к текущей операции, а не быть общим согласием «делай дальше всё сам».
День 30. Решение о следующем уровне
Сравните пилот с исходной точкой:
- сократилось ли время прохождения задачи;
- уменьшилось ли число ручных касаний;
- как изменились ошибки и доработки;
- сколько времени заняла проверка;
- какие остановки и инциденты возникли;
- можно ли восстановить каждое значимое действие;
- оправдана ли стоимость моделей, инфраструктуры и контроля.
После этого принимается одно из трёх решений: остановить контур, изменить его и повторить пилот либо расширить полномочия. Сам факт работающей демонстрации не является основанием для масштабирования.
Как это выглядит в моей текущей работе
На pimenov.ai агент уже участвует в исследовании, подготовке текста, работе с визуалами и техническом контуре сайта. При этом состояния разделены. Черновик в Notion ещё не публикация. Разрешение на создание черновика не означает разрешение синхронизировать Directus или менять сайт. Будущий URL не доказывает, что материал доступен читателю. Публикация подтверждается только проверкой живой страницы.
Plane хранит карту проекта, решения и ссылки на созданные материалы. Notion остаётся редакционным источником. Directus и сайт образуют отдельный производственный слой. Такое разделение иногда выглядит избыточным, пока всё работает нормально. Но именно оно не позволяет агенту принять завершение одного этапа за разрешение на следующий.
Для меня это главный практический урок: автономность должна расти вслед за доказательствами. Сначала агент показывает, что умеет работать в ограниченном контуре. Потом получает новый инструмент или право. Каждый следующий уровень можно отозвать, а каждое значимое действие — восстановить.
Шесть ошибок, которые ломают первый пилот
- Покупка инструмента до выбора процесса. Команда ищет применение платформе вместо решения конкретной рабочей задачи.
- Слишком широкий контур. Формулировка «пусть агент ведёт продажи» скрывает десятки разных решений, данных и уровней риска.
- Автоматизация сломанного процесса. Неопределённые роли и противоречивые данные переходят в новую систему и начинают ошибаться быстрее.
- Общий аккаунт человека. Компания теряет возможность различать действия сотрудника, интеграции и агента.
- Проверка только красивых примеров. Демонстрация показывает лучший маршрут, а рабочая система должна выдерживать неполные и конфликтующие входы.
- Масштабирование до разбора ошибок. Если команда не умеет восстановить причину сбоя в одном процессе, увеличение числа агентов лишь расширит неизвестность.
Что делать после тридцатого дня
Если пилот доказал пользу, не спешите переносить ту же конструкцию на весь отдел. Сначала укрепите контур: добавьте недостающие проверки, разберите остановки, уточните права и оцените полную стоимость результата. Затем выберите следующий процесс либо поднимите текущий на одну ступень автономности.
Так компания постепенно переходит от отдельных ИИ-инструментов к агентной организации. Единицей внедрения становится проверяемый рабочий контур: задача, контекст, полномочия, ответственность и наблюдаемый результат.
Тридцать дней в этой логике — срок первого управленческого эксперимента. Его итогом должна стать работающая система, которой компания умеет доверять ровно настолько, насколько та это доверие уже заслужила.
Источники
- OpenAI: A practical guide to building agents
- Anthropic: Building effective agents
- Anthropic: Demystifying evals for AI agents
- OWASP: Excessive Agency
Следующий шаг
Права доступа и роли: почему агенту нельзя давать все ключи от квартиры
Связанные материалы
- Статья: Кто отвечает за результат, если работу сделали ИИ-агенты?
- Блог: Не стройте сверхмашину — соберите то, что поедет сегодня
- База знаний: AGENTS.md / SESSION_NOTES — проектная память для coding-агентов
Если вы готовите первый агентный пилот, такой контур помогает заранее увидеть ответственность, доступы и точки человеческого решения.
Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov
Если хотите разобрать свою задачу — напишите мне Если хотите разобрать свою задачу — напишите мне.
Можно прийти с идеей, черновым контекстом или уже живой задачей. Помогу быстро понять, где реальный следующий шаг, а где лишний шум.
Обычно хватает 2–3 сообщений, чтобы понять, могу ли я здесь реально помочь и в каком формате лучше двигаться дальше.
Дальше по теме
Консультации, аудит процессов, работа с контентом и сайтами, сессии для команд и решения под конкретную задачу.