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

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

URL: https://posts.danashkin.ru/guides/kak-prinimat-rabotu-podryadchika-po-ii
Обновлено: 2026-09-06

---

## Коротко

**Главное**

- Демонстрация на данных подрядчика ничего не доказывает. Единственная честная приёмка - когда решение воспроизводят на твоих файлах и твоей задаче при тебе.
- Четыре вещи фиксируются письменно до старта: что считается результатом, на каких данных проверяем, кто в компании принимает, что остаётся у тебя после окончания работ.
- Ответ ИИ невоспроизводим дословно, поэтому критерий приёмки формулируется через долю удачных случаев на контрольном наборе, а не через «работает или нет».
- После ухода подрядчика у компании должны остаться данные, промпты, инструкции и доступы. Если остаётся только логин в чужой сервис, ты купил не внедрение, а подписку.
- Красные флаги: обещание результата на следующей неделе, отказ работать на твоих данных, отсутствие человека, отвечающего за факты.

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

**Главное**

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

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

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

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

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

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

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

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

**Главное**

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

| Что фиксируем | Плохая формулировка | Рабочая формулировка |
|---|---|---|
| Результат | «повысить эффективность обработки заявок» | «из письма клиента формируется карточка с семью полями» |
| Проверка | «покажем на примерах» | «сто наших писем за прошлый месяц, отобранных нами» |
| Приёмщик | «согласуем с руководством» | «принимает руководитель отдела, срок три рабочих дня» |
| Что остаётся | не обсуждается | «данные, промпты, инструкции и доступы у нас» |

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

Четвёртая строка - про деньги в перспективе. Про то, как считать экономику таких проектов, у меня есть отдельный разбор про [оценку отдачи от внедрения ИИ](/guides/kak-ocenit-roi-ot-vnedreniya-ii-instrumentov-v-kompanii-metriki-i-formuly).

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

**Главное**

Через долю удачных случаев на контрольном наборе. [ИИ-агент](/concepts/ai-agent) не даёт дословно одинаковый ответ дважды, поэтому критерий «работает» заменяется на «на ста наших случаях приемлемый результат в стольких-то».

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

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

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

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

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

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

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

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

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

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

**Отдельный порог для выдумок**

Долю удачных случаев и долю выдуманных данных считают отдельно. Решение, которое в восьмидесяти случаях право, а в двух придумало несуществующий пункт договора, к работе не допускается. Как ловить такие случаи, разбирал в материале про [галлюцинации нейросетей](/guides/gallyucinacii-neyrosetey-kak-proveryat).

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

**Главное**

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

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

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

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

Смежная история про то, почему сам факт покупки инструментов ничего не меняет, - в материале про то, [что бывает после покупки подписок команде](/guides/kupili-chatgpt-komande-pochemu-ne-rabotaet).

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

**Главное**

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

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

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

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

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

Тот же принцип я разбирал применительно к обучению команды: как отличить программу-систему от подборки сервисов, писал в материале про [выбор корпоративного обучения](/guides/korporativnoe-obuchenie-neyrosetyam-kak-vybrat).

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

**Главное**

Тот, чей процесс меняется. Не ИТ-служба и не закупки: они проверяют формальности. Содержательную приёмку делает руководитель подразделения, которое будет этим пользоваться.

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

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

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

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

Про проверку самого результата, когда у тебя нет технического бэкграунда, есть подробный разбор - [как принимать работу без технического бэкграунда](/guides/kak-proveryat-ai-kod-bez-teh-bekgraunda).

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

**Главное**

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

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

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

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

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

**Главное**

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

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

**Сколько случаев нужно в контрольном наборе?**

Пятьдесят для простой задачи, сто и больше для сложной. Важнее не количество, а разнообразие: обязательно включить неудобные и пограничные случаи.

**Решение показало не тот процент, что обещали. Отказываться?**

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

**Нужен ли пилот перед полноценным внедрением?**

Почти всегда да. Пилот на одном подразделении и одном процессе стоит дешевле и отвечает на вопрос, который не закрывает никакая презентация.

**У нас нет своих специалистов. Как принимать?**

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

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

**Главное**

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

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

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

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

### Источники

- [Acceptance testing - обзорная статья о приёмочных испытаниях, Википедия](https://en.wikipedia.org/wiki/Acceptance_testing)
- [Vendor lock-in - обзорная статья о зависимости от поставщика, Википедия](https://en.wikipedia.org/wiki/Vendor_lock-in)
- [Service-level agreement - обзорная статья о соглашении об уровне услуг, Википедия](https://en.wikipedia.org/wiki/Service-level_agreement)
- [Техническое задание - обзорная статья о документе с требованиями, Википедия](https://ru.wikipedia.org/wiki/Техническое_задание)
- [AI Index Report 2025 - отраслевой отчёт Stanford HAI о внедрении ИИ в компаниях](https://hai.stanford.edu/ai-index/2025-ai-index-report)