Техническое задание на ИИ-агента связывает задачу бизнеса с разрешёнными действиями, входными данными и проверяемым результатом. Для заказа разработки подготовьте описание одного процесса, матрицу требований и условия приёмки. Такой пакет позволяет сравнивать предложения исполнителей по одинаковому объёму работ.
Граница процесса
Для каждого требования заполните пять полей: вход, выход, исключение, доказательство и проверяющий. Формулировка «умный помощник отдела» требует уточнения до запроса предложений.
Начните с события, которое запускает работу. Например, поступление обращения в CRM, появление документа в папке или запрос сотрудника. Затем обозначьте точку завершения: сохранённый черновик, заполненная карточка либо задача ответственному. Между этими точками перечислите решения агента и действия человека. Если покупатель описывает сразу весь отдел, исполнители могут заложить разные процессы и представить внешне похожие предложения.
Владелец процесса описывает текущий порядок работы: кто получает обращение, где ищет информацию, какие поля заполняет и кому передаёт результат. Приложите разрешённые примеры исходных материалов и ожидаемых ответов. Для каждой системы укажите владельца доступа и доступную тестовую среду. Пробелы отмечайте вопросами с ответственным за ответ, чтобы предположения подрядчика оставались видны при сравнении.
Назначьте обязательный результат первого этапа и отделите его от будущих возможностей. Подготовка черновика и самостоятельная отправка клиенту требуют разных полномочий. Расширение перечня документов тоже меняет объём проверки. Общая последовательность сборки описана в материале о создании ИИ-агента; задача ТЗ — закрепить именно ваш предмет заказа до выбора технологии.
Входы и результаты
Опишите вход через состав полей, происхождение и условия доступности. Для карточки обращения это идентификатор, текст вопроса, категория и ссылки на разрешённые документы. Укажите, какие поля обязательны, какие могут отсутствовать и какие доступны только определённым ролям. Вместо копирования рабочих баз передайте обезличенные или синтетические образцы, сохранив структуру и характер сложных случаев.
Выход задавайте так, чтобы сотрудник мог проверить его без объяснений разработчика. Для черновика нужны ответ, ссылка на основание, список вопросов и статус проверки. Для изменения записи нужны идентификатор объекта, перечень изменённых полей и подтверждение системы. Свободный текст модели и успешное выполнение операции проверяются отдельно: уверенная фраза о сохранении карточки сама по себе ничего в CRM подтверждать неспособна.
В приложении к ТЗ заведите словарь полей. Одно название должно означать одинаковую сущность в исходной системе, журнале и результате. Зафиксируйте допустимые форматы дат, правила пустых значений и порядок выбора версии документа. Если источники противоречат друг другу, выходом становится запрос уточнения ответственному. Исполнитель должен видеть такое условие до оценки работ, иначе обработка исключений легко останется за рамками предложения.
Отдельно опишите хранение материалов: кто видит исходные документы, где сохраняются журналы, кто удаляет учебные копии после проверки. Сроки и права согласуются с владельцами данных. Пароли и ключи доступа передают по принятому защищённому порядку; в текст задания включают названия доступов и ответственных, без самих секретов.
Демонстрационная матрица
Демонстрационный сценарий: агент готовит ответ на вопрос о комплектности заявки. Все обращения и документы для такого демо синтетические; описание служит образцом задания, без заявления о проведённом внедрении. На вход поступают учебная карточка и утверждённый перечень документов, на выход — черновик и отметка о требуемом уточнении. Отправку сохраняет за собой сотрудник.
| Требование | Вход и выход | Исключение | Доказательство | Проверяющий |
|---|---|---|---|---|
| Найти основание | Вопрос и инструкция → черновик со ссылкой | Источник отсутствует → уточнение | Сохранённый вход и версия источника | Редактор базы знаний |
| Сохранить черновик | Идентификатор → запись в той же карточке | Ошибка доступа → остановка записи | Журнал вызова и карточка CRM | Владелец интеграции |
| Учесть повтор | Повторный вход → прежний результат | Статус записи неизвестен → ручная сверка | Сопоставление идентификаторов | Ответственный отдела |
Каждую строку разверните в проверочный пример. Укажите исходную карточку, разрешённые вызовы, ожидаемый статус и признаки провала. Для поиска основания провалом будет выдуманная ссылка; для записи — изменение чужой карточки. Попросите исполнителя объяснить, какие доказательства он сохранит. Это позволяет обсуждать результат ещё до появления рабочего агента и отделять готовую функцию от обещания её добавить.
Число учебных обращений выбирайте по разнообразию маршрутов. Включите обычный вопрос, пустое обязательное поле, конфликт источников и повтор события. Демо показывает проверяемость требований, а выводы о качестве будущей системы требуют согласованной выборки и реального прогона. Порядок таких испытаний раскрывает статья о тестировании и откате.
Какие действия вашего агента нужно закрепить в ТЗ?
Полномочия и исключения
Составьте список операций по уровням доступа: чтение, подготовка результата, запись после подтверждения и действия, полностью закрытые для агента. Для подтверждения определите роль сотрудника и срок актуальности решения. Одобрение черновика относится к конкретной версии текста и карточке; после существенного изменения результат возвращается человеку. Такое правило защищает от выполнения старого согласования над новым содержимым.
Зафиксируйте остановку при попытке доступа к чужим сведениям, выходе за разрешённый маршрут или неизвестном результате записи. Опишите, куда попадает задание после остановки и кто продолжает его вручную. Текст входного документа рассматривается как данные: содержащаяся внутри просьба изменить настройки сама по себе полномочий агенту давать неспособна. Проверку этого ограничения внесите в обязательный объём.
Укажите зависимости от заказчика: подготовка базы знаний, доступ к тестовой системе, ответы владельца процесса и согласование примеров. Если часть условий пока открыта, исполнитель отмечает влияние на состав работ и предлагает способ уточнения. В ТЗ полезен журнал решений: вопрос, согласованный вариант, автор и дата. Изменение требований после согласования проходит через обновление версии и повторную оценку затронутых проверок.
Сравнение и приёмка
Передайте кандидатам одинаковую версию задания. Попросите ответить по строкам матрицы: входит ли требование в предложение, каким способом проверяется, какие материалы нужны от заказчика и что остаётся отдельной опцией. Ответ «сделаем под ключ» раскрывается только через этот перечень. Для спорного пункта запросите пример будущего протокола, чтобы сравнить глубину проработки до выбора исполнителя.
Согласуйте порядок приёмки: кто запускает проверку, где лежат результаты, какие отклонения блокируют допуск и кто принимает остаточные ограничения. Пакет передачи включает инструкции запуска, карту доступов без секретов, версии настроек и журнал известных ограничений. Заказчик получает возможность повторить согласованный сценарий. Учебный разбор с операторами служит поддержкой внедрения ИИ-агентов: сотрудники осваивают проверку результата и передачу спорных заданий.
Для обсуждения разработки ИИ-агента под процесс подготовьте схему маршрута и заполненную демонстрационную матрицу. Стоимость обсуждаем на Discovery-созвоне. ТЗ готово к запросу предложений, когда у обязательных действий есть вход и выход, у исключений — владелец решения, а у приёмки — доступное заказчику доказательство.