Что должно входить в техническое задание на внедрение AI

Многие AI-проекты начинаются одинаково: компания понимает, какую проблему хочет решить, находит подрядчика и получает предварительную оценку. На старте всё кажется простым — есть задача, решение и бюджет.

Сложности появляются уже во время разработки. Выясняется, что CRM устроена иначе, чем предполагалось, нужны дополнительные интеграции, в документах не хватает информации, а сотрудники работают не совсем так, как описывалось на первой встрече. В результате появляются новые задачи и расходы.

Часто проблема не в подрядчике, а в том, что до начала работ никто подробно не зафиксировал, что именно нужно создать, какой результат ожидается и где заканчивается первоначальный объём проекта.

Почему обычного описания задачи недостаточно

Фраза «нужно внедрить AI для обработки заявок» для руководителя может звучать достаточно понятно. Для разработки этого мало: непонятно, какие заявки поступают, откуда они приходят, что именно должна определить система, какие данные ей доступны и что происходит после анализа.

Нужно заранее определить, отвечает ли AI клиенту, создаёт ли задачу менеджеру, какие обращения передаются человеку и что происходит при ошибке. Если этого не сделать, участники проекта начинают по-разному представлять конечный результат, а разница обнаруживается уже в процессе разработки.

Техническое задание должно описывать не AI, а бизнес-процесс

Одна из частых ошибок — начинать ТЗ с названия нейросети или модели. Для бизнеса гораздо важнее не то, какая технология используется внутри, а какую часть процесса она выполняет.

Например, процесс можно описать так:

Клиент отправляет заявку → система получает данные → AI определяет тип обращения → проверяет информацию → формирует результат → передаёт его менеджеру → создаёт задачу в CRM.

Такая схема сразу показывает границы проекта, необходимые интеграции и точки, где требуется участие сотрудника.

Что обязательно зафиксировать в ТЗ

1. Какую проблему решаем

Сначала нужно описать текущую ситуацию и цель проекта. Например, сотрудники вручную обрабатывают обращения, тратят на это несколько часов в день и регулярно сталкиваются с неполными данными.

Цель должна быть измеримой: сократить время обработки, уменьшить количество ручных операций, ускорить ответ клиенту или увеличить пропускную способность команды. Иначе после запуска будет сложно понять, действительно ли внедрение дало результат.

2. Что именно делает AI

Функции лучше перечислять максимально конкретно. Например, система может:

·       анализировать текст обращения;

·       определять категорию клиента;

·       извлекать необходимые данные;

·       проверять информацию;

·       формировать резюме;

·       предлагать ответ;

·       создавать задачу;

·       передавать результат сотруднику.

Чем точнее описаны действия, тем меньше пространства для разных трактовок.

3. Что AI делать не должен

Ограничения не менее важны, чем функции. В ТЗ стоит заранее указать, какие действия система не может выполнять без участия человека.

Например, AI может быть запрещено самостоятельно отправлять определённые сообщения, изменять финансовые данные, принимать решения без проверки сотрудника или использовать неподтверждённую информацию. Такие правила задают реальные границы автоматизации и снижают риск проблем после запуска.

4. Какие данные используются

Нужно перечислить источники информации: CRM, таблицы, документы, корпоративную базу знаний, почту, записи разговоров, формы на сайте и внутренние системы.

Но самого списка недостаточно. Важно понимать, какие именно сведения используются, где они хранятся и насколько они актуальны. Если AI работает с историей клиента, например, это должно быть отдельно зафиксировано в требованиях.

5. Какие системы нужно интегрировать

Интеграции напрямую влияют на стоимость и сроки, поэтому их лучше определить заранее. В ТЗ стоит указать все системы, участвующие в процессе: CRM, почту, мессенджеры, телефонию, базы знаний, аналитику и другие сервисы.

При этом нужно отдельно обозначить, какие интеграции входят в проект, а какие нет. Иначе одна сторона может считать подключение конкретной системы очевидной частью внедрения, а другая — дополнительной работой.

6. Какие действия выполняются автоматически

Процесс полезно разделить на автоматические и ручные этапы.

Автоматически:

·       получить заявку;

·       классифицировать обращение;

·       найти данные клиента;

·       сформировать резюме;

·       создать задачу.

С участием сотрудника:

·       проверить сложное обращение;

·       согласовать коммерческое предложение;

·       подтвердить отправку клиенту.

Так становится понятно, насколько автономной должна быть система и где остаётся человеческий контроль.

Что происходит при ошибке

AI может ошибаться, поэтому в ТЗ нужно описать не только нормальный сценарий, но и проблемные ситуации. Например, данные могут отсутствовать или противоречить друг другу, запрос может не подходить ни под одну категорию, внешняя система может оказаться недоступна.

Для каждого важного случая должен быть предусмотрен следующий шаг: повторная обработка, передача сотруднику или остановка процесса. Чем раньше эти сценарии определены, тем меньше неожиданностей возникает при тестировании.

Как проверяется качество результата

Критерии приёмки лучше определить до начала разработки. Нужно заранее понимать, что именно считается корректной работой: заявка правильно классифицирована, необходимые данные извлечены, задача создана в CRM, ответ соответствует установленным правилам, а информация взята из разрешённых источников.

Без таких критериев приёмка легко превращается в спор. Заказчик может считать, что система работает не так, как ожидалось, а подрядчик — что выполнил всё согласно исходному заданию.

Отдельно фиксируйте реальные примеры

Для AI-проектов примеры особенно полезны. Недостаточно написать, что система должна определять тип обращения — лучше показать несколько реальных запросов и ожидаемый результат.

Например:

Входящий запрос: клиент хочет узнать стоимость услуги. Ожидаемый результат: категория «Запрос стоимости».

Входящий запрос: клиент сообщает о проблеме после покупки. Ожидаемый результат: категория «Претензия».

Такие примеры помогают разработчику точнее понять логику, а бизнесу — объективно проверить результат после запуска.

Что делать с пограничными случаями

Именно на нестандартных ситуациях часто появляется дополнительный объём работ. Одно обращение может одновременно относиться к двум категориям, клиент может не указать необходимые данные, а один и тот же вопрос можно трактовать по-разному.

Поэтому в ТЗ стоит выделить раздел «Исключения и нестандартные сценарии». При этом не нужно пытаться предусмотреть абсолютно всё: для неизвестных случаев можно задать общее правило, например передавать запрос сотруднику, если AI не уверен в результате.

Безопасность и доступы

Если система получает доступ к корпоративной информации, требования к безопасности нужно определить ещё до разработки. В ТЗ стоит зафиксировать, какие данные доступны AI, какие запрещены, кто видит результаты и какие действия требуют подтверждения сотрудника.

Особое внимание нужно уделить финансовой, клиентской и другой чувствительной информации. Безопасность лучше проектировать вместе с системой, а не добавлять после её запуска.

Что делать с изменениями по ходу проекта

Даже хорошо составленное ТЗ не исключает новых требований. Во время пилота может выясниться, что компании нужен дополнительный источник данных, новая интеграция или ещё один сценарий.

Это нормально, но такие изменения не должны автоматически попадать в первоначальный бюджет. Заранее стоит определить, что считается доработкой и как оцениваются новые функции, интеграции и дополнительные сценарии.

Три уровня требований, которые полезно разделять

Обязательные

Это функции, без которых решение не выполняет основную задачу. Например, интеграция с CRM или автоматическая классификация заявок.

Желательные

Они делают систему удобнее, но не нужны для первого запуска. Сюда могут относиться дополнительные отчёты или расширенная аналитика.

Будущие

Это идеи для следующих этапов. Такое разделение помогает не перегружать первый запуск и одновременно сохранить перспективные задачи.

Для AI-проектов особенно полезно сначала запускать минимально необходимую версию, а затем расширять её на основании реальных результатов.

Как ТЗ влияет на стоимость проекта

Чем точнее описан объём работ, тем меньше неопределённости остаётся в оценке. Подрядчик заранее понимает, сколько будет интеграций, какие функции нужно разработать, какие сценарии протестировать, какие данные подготовить и какие ограничения реализовать.

Это не гарантирует, что бюджет никогда не изменится. Но если появляется новая интеграция или дополнительный функционал, обе стороны понимают, почему потребовались дополнительные ресурсы.

Минимальная структура хорошего ТЗ

Если нет необходимости создавать большой документ, для старта достаточно зафиксировать:

1.       Цель проекта

2.       Текущий бизнес-процесс

3.       Что должно измениться

4.       Роль AI

5.       Функции системы

6.       Ограничения

7.       Источники данных

8.       Интеграции

9.       Автоматические и ручные этапы

10.  Основные сценарии

11.  Исключения

12.  Критерии качества и приёмки

13.  Требования к доступам и безопасности

14.  Что входит в первый этап

15.  Что считается дополнительной работой

Этого уже достаточно, чтобы предметно обсудить с подрядчиком объём проекта, сроки и бюджет.

ТЗ не должно превращаться в бюрократию

Есть и обратная крайность — потратить несколько недель на согласование огромного документа, а после запуска обнаружить, что реальный процесс устроен иначе.

Для новых AI-сценариев часть требований действительно невозможно проверить без рабочего прототипа. Поэтому иногда разумнее сделать короткое ТЗ для пилота, протестировать решение на реальных данных и уже после этого уточнить требования.

Вывод

Техническое задание на внедрение AI нужно не только разработчику. Это прежде всего способ договориться между бизнесом и подрядчиком о том, что именно создаётся, для какого процесса, какие данные и системы используются и какой результат считается успешным.

Хорошее ТЗ снижает неопределённость, помогает точнее оценить бюджет и заранее обозначает границы проекта. При этом не стоит пытаться описать каждую возможную ситуацию: для сложных решений эффективнее разделять внедрение на этапы, начиная с понятного пилота.

Если компания планирует внедрение AI, разумнее начать не с выбора нейросети, а с разбора конкретного процесса. Нужно понять, что сейчас работает неэффективно, какие действия можно автоматизировать, где необходим человек и каким должен быть измеримый результат.

Так ещё до разработки становится видно, что действительно нужно бизнесу, какие функции можно отложить, какие интеграции потребуются и где проходит реальная граница бюджета. В результате AI с большей вероятностью становится частью рабочего процесса, а не очередным сервисом, которым сотрудники перестают пользоваться через несколько недель.