Разработку ИИ-агента легко закончить эффектной демонстрацией и трудно — работающим решением. Разница видна на приёмке: попросите показать не переписку с моделью, а запись в вашей системе и журнал действий.
Агент — программа, в которой языковая модель выбирает действия и вызывает разрешённые инструменты; при фиксированной последовательности шагов достаточно обычной автоматизации с одним обращением к модели — это различие описывает Anthropic. Проекты останавливаются не из-за модели: по оценке MIT NANDA (июль 2025), до эксплуатации доходят 5% корпоративных ИИ-инструментов, а 95% организаций не получили отдачи. Общая логика проекта — в материале Внедрение ИИ-агентов: от аудита до сопровождения; здесь — документ и приёмка.
Коротко
Разработка ИИ-агентов — шесть этапов вокруг одного процесса: обследование, задание, сборка и интеграции, тестовый набор, пилот, передача. Приёмка идёт не по впечатлению от ответа модели, а по согласованному набору заданий: проверяют запись в системе, журнал, соблюдение прав.
Содержание
- Что входит в разработку по этапам
- Что писать в каждом разделе задания
- Процесс, данные и права
- Критерии готовности
- Интеграции: 1С, CRM-система, почта, трекер
- Критерии приёмки: чеклист
- Типичные провалы проектов
- Сроки и состав работ
- Что получить при передаче
- Что в итоге
- Источники
Что входит в разработку ИИ-агента по этапам
Это шесть этапов вокруг одного процесса, и каждый заканчивается документом или проверкой. Внутри решения три части: модель, инструменты — разрешённые операции в ваших системах — и журнал каждого шага.
| Этап | Что делаем | Результат | Срок |
|---|---|---|---|
| Обследование процесса | Разбираем шаги, системы, поля, исключения | Карта процесса, пробелы в данных | 1–2 недели |
| Техническое задание | Фиксируем границы, права, критерии готовности | Задание с приложениями и набором для приёмки | 1–2 недели |
| Сборка и интеграции | Подключаем системы в режиме чтения, настраиваем шаги | Контур на тестовых данных | 3–6 недель |
| Тестовый набор | Собираем задания с эталонным результатом | Отчёт: что прошло, что нет | 1–2 недели |
| Пилот в режиме подсказок | Агент предлагает, сотрудник подтверждает | Отчёт по расхождениям, правки правил | 3–4 недели |
| Приёмка и передача | Принимаем по набору, передаём документацию | Инструкции и порядок сопровождения | 1 неделя |
Сроки — вилка для одного процесса с двумя-тремя интеграциями, а не обещание. Каждый этап начинается после приёмки предыдущего: ошибка в постановке стоит неделю обсуждения, а не переделку. Состав работ по проекту внедрения — в статье про этапы, сроки и бюджет.
Что писать в каждом разделе технического задания
Техническое задание — документ, по которому проводится и разработка, и приёмка. ГОСТ 34.602-2020 перечисляет обязательные разделы — от общих сведений до порядка контроля и приёмки; для агента они наполняются конкретным содержанием.
| Раздел задания | Что писать для ИИ-агента |
|---|---|
| Общие сведения | Заказчик, разработчик, основания, сроки |
| Цели и назначение | Какой показатель процесса меняется и как оценивается достижение |
| Характеристика объекта | Системы в контуре, объём обращений и документов в месяц |
| Требования к системе | Перечень шагов; для каждого — результат, время, поведение при сбое |
| Состав и содержание работ | Этапы работ и сроки, роль заказчика |
| Порядок разработки | Исходные данные, документы по этапам |
| Порядок контроля и приёмки | Виды испытаний, приёмочный набор, состав комиссии |
| Подготовка к вводу | Что меняется в обязанностях сотрудников, регламенты |
| Требования к документированию | Описание решения, инструкция, регламент сопровождения |
| Источники разработки | Материалы, на которых строилось задание |
Стандарт писался под автоматизированную систему, а не под модель, которая выбирает действие. Поэтому к требованиям добавляются четыре блока: процесс, данные, права и критерии готовности.
Процесс, данные и права
Раздел «процесс» отвечает на пять вопросов: что запускает агента, что он читает, что создаёт, что ему запрещено, кто отвечает за результат. «Автоматизировать обработку обращений» не проверяется: пишут событие запуска и результат. Рабочий пример: письмо клиента → контрагент найден в CRM (система управления взаимоотношениями с клиентами) → черновик запроса в карточке сделки → подтверждение менеджера. «Агент знает ассортимент» заменяется на «получает позиции из справочника 1С; если позиции нет — создаёт задачу», «агент отвечает клиентам» — на «готовит черновик письма; отправка — после подтверждения». Исключения описывают отдельно: повтор события, таймаут, отсутствие прав, расхождение справочников; при таймауте сначала проверяют результат операции по идентификатору, потом повторяют запрос. Обезличенные примеры для настройки и для приёмки — разные наборы, иначе проверка ничего не показывает; разбор сценариев — в материале ИИ-агенты для бизнеса.
Для каждого поля указывают источник, а не догадку. В задании перечисляют четыре списка: что агент читает (системы, поля, глубина истории); что создаёт (черновик документа, задачу); чего в данных нет; как проверяется качество. Примеры для настройки и для приёмки — разные наборы, иначе проверка не показывает ничего; сравнение сценариев — в материале ИИ-агенты для бизнеса.
Минимум прав — требование к решению, а не осторожность. Читать, готовить черновики и изменять рабочие данные — три разных уровня: доступ к интерфейсу не означает, что агенту разрешены все операции пользователя. OWASP относит избыточные разрешения и автономность к риску Excessive Agency и рекомендует оставлять значимые действия человеку. Агент читает договоры и историю обращений, но не отправляет письма и не проводит документы; сюда же — журнал и порядок остановки.
Критерии готовности
Критерий готовности — проверяемое условие, а не оценка «работает хорошо». ГОСТ перечисляет характеристики требований: единичность, непротиворечивость, актуальность, выполнимость, проверяемость, однозначность. Если по формулировке нельзя написать тест, её нельзя ни разработать, ни принять: «агент понимает контекст» заменяется на «не более 3% черновиков содержат поле не из источника», а «агент точнее человека» — на «95% заданий выполняются без правки сотрудника на выборке 200 обращений». Порог согласуется до разработки: после пилота «примерно хорошо» превращается в спор о деньгах.
Интеграции: 1С, CRM-система, почта, трекер
Каждая интеграция описывается как операция: входные поля, результат, права, поведение при сбое. Интерфейс обмена данными — только транспорт; важнее, что агент делает сам.
| Система | Читает | Делает сам | Подтверждает человек |
|---|---|---|---|
| Учётная система на 1С | Контрагентов, номенклатуру, счета, историю цен | Сопоставляет позиции, подсвечивает расхождения, готовит черновик | Проведение документа, изменения учётных данных |
| CRM-система (Битрикс24, RetailCRM) | Карточку клиента, сделки, историю обращений | Собирает карточку запроса, ставит задачу, готовит черновик ответа | Отправка ответа, смена стадии сделки |
| Почта | Письма, вложения, ветку переписки | Привязывает письмо к сделке, вынимает поля из вложения | Ответ клиенту и обещанные сроки |
| Трекер задач | Задачи, статусы, сроки, комментарии | Ставит задачу со ссылкой на источник, поднимает блокер | Изменение сроков, закрытие задачи |
Пример: заявка пришла письмом, агент нашёл контрагента, сверил цену с историей закупок и подготовил черновик — закупщик подтверждает. Подробные разборы по системам: планирование в 1С, Битрикс24, RetailCRM, документооборот, Яндекс Трекер. Для 1С уточняют конфигурацию и объекты учёта: одинакового коннектора для любой базы нет. нет.
Критерии приёмки: чеклист
Приёмка проверяет результат в системе, а не качество ответа модели. Оценка ответа и оценка выполненного действия — разные проверки: в материале Anthropic отдельно рассматриваются ход выполнения задачи и итоговое состояние среды. Набор собирают из пяти классов примеров: обычный запрос, недостаточные данные, противоречивые сведения, недоступная интеграция, попытка запрещённого действия. Проверяют правильность полей и ссылок, отсутствие дублей, соблюдение прав, время и стоимость задачи; порог согласован до тестирования.
- Задание подписано до сборки — со сценариями, полями и правами.
- Приёмочный набор согласован заранее и отделён от примеров настройки.
- Каждое задание проверено в системе: вход, ожидаемое поведение, запись, журнал.
- Критических ошибок — ноль. Запись не тому контрагенту блокирует приёмку.
- Права не превышены — проверяется отдельно от качества результата.
- Поведение при сбое соответствует заданию — таймаут, повтор, отсутствие прав.
- Метрики сняты на ваших данных, а не на стенде разработчика.
- Переданы документы: описание решения, инструкция, ограничения.
- Есть журнал и порядок остановки агента.
- Повторная проверка после смены модели описана — на том же наборе.
Типичные провалы проектов
Остановка на пилоте объясняется постановкой, а не моделью. MIT NANDA называет причинами хрупкие процессы, отсутствие контекстного обучения и несовпадение с повседневной работой; проекты с внешним партнёром доходят до результата вдвое чаще, чем собранные внутренней командой.
- Задание пишут после разработки: сначала смотрят, что умеет модель, и принимать нечего.
- Демонстрация вместо системы: критерием становится ответ в чате, а не запись и журнал.
- Тестовый набор собран разработчиком из примеров, на которых настраивали решение.
- Нет владельца процесса: расхождения не разбирают, агента перестают открывать.
- Слишком широкие права: одна ошибочная запись дороже всего эффекта.
- Передача без сопровождения: модель обновилась, проверки не повторили.
Как это выглядит в проекте целиком — в материале про внедрение ИИ в бизнес-процессы, планирование нескольких процессов — в статье про стратегию внедрения ИИ.
Сроки и состав работ
Срок и стоимость зависят от состава работ, а не от названия решения. На объём влияют четыре вещи: сколько систем в контуре и доступны ли их интерфейсы; состояние справочников; нужные права; глубина тестового набора. От заказчика нужны обезличенные примеры документов, доступ к справочникам, ответственный за процесс, тестовый контур и подтверждение от владельца данных.
Разовые работы и эксплуатацию считают отдельно: к первым относятся обследование, задание и подключение систем, ко вторым — модель, инфраструктура и сопровождение правил. Расход на один запрос к модели не равен стоимости завершённой задачи: в неё входят повторные попытки и время сотрудника.
Что получить при передаче
Передача — это не только код, но и средства управления. Нужны: состав решения (конфигурация, версии, инструкция развёртывания), управление доступами (владелец учётных записей, порядок выдачи и отзыва прав), проверки (набор для приёмки, известные ограничения), эксплуатация (журнал ошибок, уведомления, ответственный, порядок остановки) и правила изменений (обновление, повторная проверка, восстановление версии). Порядок сопровождения оговаривают в том же документе, что и состав работ.
Автоматизация выполняет правило: цена выше лимита — показать. Агент работает там, где правило не описать: читает письмо, сопоставляет позиции со справочником, выбирает следующий шаг. При фиксированной последовательности шагов агент не нужен.
Пять вещей: событие запуска, входные данные с указанием источника, результат в системе, разрешённые действия и исключения. Каждая функция описывается через результат: не «подготовить ответ», а «создать черновик письма в карточке сделки».
Для каждой интеграции указывают входные поля, результат, права и поведение при сбое. Три уровня доступа разделяют: чтение, черновик, изменение рабочих данных. Отдельно прописывают поведение при таймауте.
По согласованному заранее набору заданий, и проверяют не текст ответа, а результат в системе. Обязательны пять классов примеров: обычный запрос, недостаточные данные, противоречивые сведения, недоступная интеграция, запрещённое действие.
Считают состав работ: сколько систем в контуре, в каком состоянии справочники, какие права нужны агенту. Ориентир для одного процесса с двумя-тремя интеграциями — от двух до трёх с половиной месяцев.
Смотрим, какие системы работают, сколько обращений проходит через процесс и где теряется время. На выходе — какой процесс закрывается агентом первым и какой набор собрать для приёмки.
Что в итоге
Разработка ИИ-агентов держится на двух документах: задании, где зафиксированы границы задачи, источники данных, права и критерии готовности, и приёмочном наборе, по которому результат проверяют в системе. Первый шаг — бесплатный разбор стратегии внедрения ИИ: покажем, что попадёт в задание и как будет выглядеть приёмка.
Источники
- Обязательные разделы задания, характеристики требований (единичность, непротиворечивость, актуальность, выполнимость, проверяемость, однозначность), результат каждой функции, порядок контроля и приёмки — ГОСТ 34.602-2020.
- Избыточные разрешения и автономность агента как отдельный риск, ограничение полномочий, проверка человеком — OWASP, Excessive Agency (LLM06:2025).
- Агент против фиксированной автоматизации — Anthropic, Building effective agents; проверка хода задачи и итогового состояния среды — Demystifying evals for AI agents.
- До эксплуатации доходят 5% пилотов, 95% организаций без отдачи при 30–40 млрд долларов вложений; вдвое большая результативность проектов с внешним партнёром — MIT NANDA, «The GenAI Divide: State of AI in Business 2025», июль 2025.