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

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

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

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

Сначала определите, какого исполнителя вы ищете

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

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

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

Подготовьте задачу до общения с рынком

Качественный запрос подрядчику описывает бизнес-процесс, а не желаемую технологию. Формулировка «нужен ИИ-агент для продаж» не сообщает, какие действия должен выполнять сервис, какими данными пользоваться, где заканчиваются его полномочия и по каким показателям его будут принимать.

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

До запроса предложений заказчику полезно зафиксировать:

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

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

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

Как оценить опыт и команду подрядчика

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

Проверка кейсов

Просите разобрать один-два сопоставимых проекта по существу. Как были подготовлены данные? Что не сработало на первой версии? Как измеряли качество? Какие функции остались под контролем человека? Что команда изменила после пилота? Если подрядчик может показать только интерфейс, но не объясняет путь до эксплуатации, кейс не подтверждает зрелость внедрения.

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

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

Проверка фактической команды

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

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

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

Пилот, MVP и промышленное внедрение — разные результаты

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

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

Каким должен быть пилот

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

До начала пилота стороны согласуют:

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

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

Что отделяет демонстрацию от эксплуатации

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

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

Как проверить архитектуру, данные и безопасность

Архитектурная зрелость проявляется в том, что подрядчик сравнивает варианты и объясняет компромиссы. Выбор между внешним API, частным облаком и локальным размещением влияет на стоимость, задержку, масштабирование, доступность моделей и контроль над информацией. Универсально лучшей схемы не существует.

Данные и интеграции

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

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

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

Информационная безопасность

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

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

Если подрядчик обрабатывает персональные данные по поручению заказчика, договор должен определять перечень данных и операций, цели обработки, конфиденциальность, меры защиты и обязанности по запросу оператора. При этом ответственность перед субъектом персональных данных по общему правилу сохраняется за оператором, что следует из статьи 6 Федерального закона № 152-ФЗ. Конкретную схему обработки необходимо проверять с юристами и службой информационной безопасности заказчика.

Сертификат сам по себе не доказывает безопасность конкретного продукта. В качестве ориентира зрелости можно использовать ISO/IEC 42001:2023: стандарт описывает систему управления ИИ, включая распределение ответственности, управление рисками, оценку результатов и постоянное улучшение. Он применим и к разработчикам, и к организациям, использующим ИИ, но не заменяет требования законодательства.

Как сравнить экономику предложений

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

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

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

Коммерческие предложения удобно привести к единой структуре:

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

Что зафиксировать в договоре и приемке

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

Результаты и права

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

Vendor lock-in возникает не только из-за закрытого кода. Зависимость появляется, когда документация неполна, инфраструктура зарегистрирована на подрядчика, знания сосредоточены у одного специалиста или данные нельзя выгрузить в пригодном формате. Договор должен описывать передачу доступов, экспорт информации и поддержку перехода к другой команде.

Ответственность и эксплуатация

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

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

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

Красные флаги на переговорах

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

Тревожные признаки проявляются и в содержании разговора:

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

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

Практический сценарий выбора подрядчика

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

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

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

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

Об авторе

Игорь М.

Chief Editor

Игорь М. — Chief Editor в компании Полигант, отвечает за редакционную стратегию и качество публикуемого контента. Работает в сфере цифровых финансов, блокчейн-технологий и ИИ более 6 лет.

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