Как принимать работу подрядчика по внедрению ИИ

Коротко

Почему демонстрация ничего не доказывает?

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

Проблема в том, что документ был его. Подобранный, чистый, в удобном формате.

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

Что обычно ломает решение на реальном материале:

• Формат. Сканы вместо текста, таблицы с объединёнными ячейками, экспорт из старой системы.
• Исключения. Двадцать лет накопленных «а вот в этом случае мы делаем иначе».
• Объём. На десяти документах работает, на десяти тысячах упирается в лимиты и стоимость.
• Права. Данные лежат там, куда подрядчику доступ не дадут.

Отсюда правило номер один: приёмка идёт на твоих данных, в твоём окружении, при твоих людях. Всё остальное - реклама.

Четыре вещи, которые фиксируют до старта

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

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

Как формулировать критерий, если ответы каждый раз разные?

Это главное отличие приёмки ИИ-решения от приёмки обычной программы. Обычная считает сумму одинаково всегда, ИИ - нет.

Как выглядит рабочий критерий:

1. Собери контрольный набор своими руками

   Пятьдесят-сто реальных случаев, отобранных вами, а не подрядчиком. Обязательно включи неудобные: нестандартные, с ошибками, пограничные.

2. Определи, что такое приемлемый результат

   Не «правильно», а конкретно: какие поля обязательны, какая ошибка допустима, что считается провалом.

3. Назови порог

   Например: приемлемый результат в восьмидесяти случаях из ста, при этом ни одного случая с выдуманными данными.

4. Прогоняй набор при себе

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

Что должно остаться у компании после работ?

Разложу список, потому что его почти никогда не обсуждают заранее.

1. Данные. Всё, что подрядчик собрал или разметил в ходе работы, в понятном формате и у вас.
2. Формулировки. Промпты, шаблоны, правила обработки. Это и есть основная интеллектуальная часть работы.
3. Инструкции. Как это запускать, что делать при ошибке, кого звать. На человеческом языке, не в переписке.
4. Доступы. Учётные записи оформлены на компанию, а не на сотрудника подрядчика и не на его личную почту.
5. Контрольный набор и результаты замеров. Чтобы через полгода можно было проверить, не деградировало ли решение.

Отдельно про зависимость от поставщика. Она не всегда зло: иногда проще платить за готовый сервис, чем содержать своё. Важно, чтобы это было осознанным выбором, а не сюрпризом при попытке сменить подрядчика.

Смежная история про то, почему сам факт покупки инструментов ничего не меняет, - в материале про то, что бывает после покупки подписок команде.

Красные флаги в предложении подрядчика

Флаг первый: сроки без объяснения физики. «Через неделю всё заработает». Спроси, что именно изменится за эту неделю и от чего это зависит. Внятный ответ есть только у того, кто делал это руками.

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

Флаг третий: нет ответственного за факты. Спроси прямо: кто проверяет, что выдало решение, и что происходит, если оно ошиблось. Здоровый ответ звучит так: автономность - в производстве, решения и проверка фактов остаются за человеком.

Флаг четвёртый: метрики загрузки вместо результата. Количество обработанных документов, число публикаций, часы работы - это отчёт о деятельности. Результат измеряется тем, что изменилось у вас: время цикла, доля ручной работы, количество ошибок.

Тот же принцип я разбирал применительно к обучению команды: как отличить программу-систему от подборки сервисов, писал в материале про выбор корпоративного обучения.

Кто внутри компании принимает работу?

Ошибка распределения ответственности стоит дороже технических ошибок.

Как выглядит рабочее разделение:

• Руководитель подразделения. Принимает по существу: решает, годится ли результат для работы.
• Сотрудник, который будет пользоваться. Проверяет удобство и ловит то, чего не видит руководитель.
• ИТ или безопасность. Проверяют доступы, хранение данных, соответствие правилам компании.
• Юрист. Смотрит договор, права на результат и передачу данных третьим лицам.

Ключевое: подписывает приёмку тот, кто потом с этим живёт. Если приёмку подписывает тот, кто решением не пользуется, через месяц выяснится, что им никто не пользуется вовсе.

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

Порядок приёмки за один рабочий день

Как это выглядит по шагам:

1. Утро: контрольный набор. Ваши случаи, ваш человек за клавиатурой, подрядчик рядом. Результаты записываются в таблицу.
2. Отдельно: неудобные случаи. Десять самых кривых. Смотрим не на результат, а на поведение: решение честно говорит, что не смогло, или выдумывает.
3. После обеда: передача. Открываем всё, что должно остаться у компании, и проверяем, что оно открывается без подрядчика.
4. Проверка ролей. Заходим под учётной записью обычного сотрудника и смотрим, что он видит.
5. Фиксация. Что принято, что в доработку, когда повторная приёмка. Письменно, в тот же день.

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

Частые вопросы

Главный вывод

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

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

Возьми последнее коммерческое предложение по ИИ, которое лежит у тебя на столе. Написано ли там, на чьих данных будет проверяться результат?