Как выбрать подрядчика по внедрению ИИ: вопросы и приёмка

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

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

С чего начать: одна задача для всех кандидатов

Сформулируйте, где начинается и заканчивается работа. Например: из входящего сообщения нужно извлечь контакт и запрос, подготовить черновик ответа и передать его сотруднику. Отдельно укажите, какие действия разрешены после проверки человеком. Такая задача понятнее, чем «внедрить ИИ в продажи»: у неё есть вход, выход и место в рабочем процессе.

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

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

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

Десять вопросов подрядчику по внедрению ИИ

1. Какой результат входит в работу?

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

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

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

2. С чем будем сравнивать результат?

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

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

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

3. Что именно вы сделали в похожем проекте?

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

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

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

4. Какие данные и доступы понадобятся?

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

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

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

5. Что произойдёт, когда данных для ответа нет?

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

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

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

6. Какие действия система сможет выполнить сама?

Разделите подготовку результата и действие с последствиями. В рассматриваемом пилоте ИИ готовит черновик, а сотрудник подтверждает отправку. Если предполагаются изменения в CRM или другом сервисе, перечислите разрешённые операции и условия подтверждения.

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

Попросите показать фактические ограничения доступа. Одной текстовой инструкции модели «не удалять» недостаточно для проверки прав. Включите в пилот попытку запрещённого действия и убедитесь, что подключённая система его отклоняет. Проверку проводят в безопасной среде с заранее согласованными действиями.

7. Как будут устроены пилот и его приёмка?

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

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

В добровольной рамке NIST AI RMF есть отдельная функция проверки системы. Её раздел MEASURE рекомендует документировать наборы тестов, показатели и результаты, проверять до внедрения и наблюдать за системой в эксплуатации. Рамка не назначает число примеров для вашего пилота.

8. Из чего складываются расходы после запуска?

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

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

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

9. Кто узнает о сбое и что сделает?

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

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

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

10. Что останется у бизнеса после сдачи?

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

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

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

Опросник для первой встречи

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

ЗАДАЧА ДЛЯ ОБСУЖДЕНИЯ
Процесс и его владелец:
Вход и безопасные примеры:
Ожидаемый выход и место его получения:
Текущий порядок и источник замеров:
Цена ошибки и запрещённые действия:

ОТВЕТЫ ПОДРЯДЧИКА
1. Что входит в работу и что исключено?
   Подтверждение: описание состава и образец результата.
2. Как и с чем сравниваем результат?
   Подтверждение: формулы показателей и план замера.
3. Какова ваша роль в похожем проекте?
   Подтверждение: безопасный пример и разбор ограничений.
4. Какие данные, сервисы и права потребуются?
   Подтверждение: схема движения данных и список операций.
5. Как обрабатываются неизвестный ответ и пропуски?
   Подтверждение: пример передачи исключения человеку.
6. Какие действия доступны без подтверждения?
   Подтверждение: показ прав и отказ запрещённого действия.
7. По каким условиям принимаем пилот?
   Подтверждение: матрица, набор примеров, формат ошибок.
8. Какие расходы будут после запуска?
   Подтверждение: состав расходов и условия расчёта.
9. Кто увидит сбой или отсутствие результата?
   Подтверждение: доставка сигнала и ручной порядок.
10. Что передаёте после сдачи?
    Подтверждение: перечень материалов, аккаунтов и прав.

НЕРЕШЁННЫЕ ВОПРОСЫ
Пункт:
Кто отвечает:
Что требуется для решения:
Дата следующего обсуждения:
Решение о старте:

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

Пилот проверяет ограниченную задачу. Для примера возьмём подготовку ответа на входящую заявку: система извлекает контакт и запрос, создаёт черновик и передаёт его сотруднику. Отправка клиенту разрешается после подтверждения сотрудника. Следующая матрица относится именно к этому условному составу.

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

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

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

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

Открыть схему в полном размере

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

Матрица приёмки: условный пример обработки заявок

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

Сценарий с посторонней командой связан с риском подмены инструкций, который описывает OWASP. Команда может прийти из внешнего содержимого, например файла или страницы, и изменить поведение модели. При проверке смотрите на доступные действия и фактические последствия. Прохождение одного такого примера не подтверждает защиту от всех вариантов атаки.

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

Как сравнить предложения и принять решение

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

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

Для решения по пилоту используйте три исхода:

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

Критические ошибки оценивайте отдельно. Действие без разрешения или доступ к чужим данным нельзя скрыть средним процентом успешных ответов. Запишите их как отдельное основание остановить выпуск. Успешная приёмка относится к согласованной версии и условиям проверки; изменение правил, модели, источника или прав требует оценки того, какие сценарии нужно проверить снова.

Когда этого гайда недостаточно

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

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

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

С чего начать в Протоколе А

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

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

Источники

Факты о проверке и правах опираются на официальные материалы. Опросник, схема и матрица - практические рекомендации этого гайда. NIST и OWASP не подтверждают квалификацию выбранного исполнителя и не устанавливают условия его договора.

• NIST: AI Risk Management Framework, добровольная рамка управления рисками ИИ.
• NIST AIRC: AI RMF Core, разделы контекста, ответственности и проверки.
• OWASP: Excessive Agency, лишние функции, права и самостоятельность системы.
• OWASP: Prompt Injection, влияние инструкций из внешнего содержимого.