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