Выбирая компанию для интеграции ИИ, оценивайте не эффектность демо, а то, как система будет измеряться, защищаться и сопровождаться в продакшене. Хороший подрядчик сначала уточняет сценарий использования, переводит точность в число на тестовом наборе, прозрачно показывает, куда уходят ваши данные, и строит архитектуру, не привязанную к одной модели. Если команда не может конкретно ответить по этим четырём пунктам, проект, скорее всего, так и застрянет на стадии пилота.
Это руководство для руководителей, владельцев продуктов и технических лидеров, которые выбирают подрядчика для корпоративных ИИ-решений. Разберём, какой тип проекта вам на самом деле нужен, что должен уметь показать компетентный партнёр, какие вопросы задать на первой встрече и почему так много демо не доходят до продакшена.
Какой тип ИИ-проекта вам нужен?
«Давайте внедрим ИИ в компании» - это не постановка задачи. До разговора с подрядчиками определите, к какой категории относится ваша потребность: каждая требует своей экспертизы, несёт свои риски и оценивается по своим критериям.
- Ответы на вопросы по корпоративным документам (RAG): системы, которые отвечают по договорам, регламентам, технической документации или базе знаний и указывают источник. Успех зависит от того, найден ли нужный фрагмент и видно ли, на какой документ опирается ответ.
- Автоматизация документов и процессов: извлечение структурированных данных из PDF, сканов и вложений писем, классификация и суммаризация документов. Ключевое условие: записи с низкой уверенностью уходят на проверку человеку.
- Агенты, выполняющие действия в системах: агенты, которые делают запросы к базам данных, вызывают API, создают и изменяют записи. Это самая рискованная категория, потому что модель уже не просто пишет текст, а выполняет работу.
- Поддержка клиентов: ассистенты, которые отвечают на типовые вопросы, распределяют обращения и при необходимости передают их оператору. Решают тон бренда, риск неверной информации и правила передачи.
- Внутренние копилоты: помощники, которые готовят черновики, кратко пересказывают записи и дают искать на естественном языке. Каждый пользователь должен видеть только то, что ему разрешено.
Некоторым задачам языковая модель вообще не нужна. В прогнозировании спроса, поиске аномалий или числовом скоринге классическое машинное обучение часто дешевле и точнее. Подрядчик, который говорит об этом прямо, заслуживает больше доверия, чем тот, кто предлагает большую языковую модель (LLM) для всего подряд.
Что должен уметь показать компетентный партнёр по интеграции ИИ?
Как он измеряет точность
Это главный критерий. Сильная команда собирает тестовый набор (golden set) из ваших реальных вопросов и ответов, которые вы считаете правильными, и автоматически прогоняет его при каждом изменении. Когда меняется промпт, обновляется версия модели или настройки поиска, сразу видно, упала ли оценка. Спросите: на каком наборе и каким методом измеряется точность? Как выявляются галлюцинации, то есть выдуманные моделью факты без источника? Что делает система, когда не уверена? В какой момент критичного процесса результат подтверждает человек (human-in-the-loop)?
«Обычно отвечает правильно» - это впечатление. «На этом наборе мы получили такую оценку, а вот на этих вопросах система ошибается» - это данные, на основе которых можно принимать решения.
Куда уходят ваши данные
Подрядчик должен уметь нарисовать путь пользовательского запроса: через какие сервисы он проходит, в какой стране обрабатывается и сколько хранится. Для процессов с персональными данными заранее решаются вопросы трансграничной передачи, правовых оснований и договоров обработки данных по применимому к вам законодательству, например 152-ФЗ в России, GDPR в ЕС или KVKK в Турции. Хороший партнёр сравнивает варианты:
- какой поставщик модели используется и обучает ли он свои модели на ваших данных;
- корпоративные соглашения с API, размещение в нужном регионе или запуск моделей с открытыми весами (open-weight) на ваших собственных серверах (on-prem);
- маскирование персональных данных в логах и сохранённых промптах;
- сроки хранения и процедура удаления.
Команда, которая отвечает «не волнуйтесь, всё безопасно», скорее всего, сама не рисовала схему потоков данных.
Как он ограничивает доступ агентов
В агентных системах главный вопрос не в том, насколько умна модель, а в том, к чему она имеет доступ. Компетентный партнёр работает по принципу минимальных привилегий: агент получает только нужные ему инструменты, с доступом на чтение или записью только в определённые записи. Необратимые действия (удаление, платежи, массовые изменения) требуют подтверждения человеком. Каждый запуск оставляет пошаговый журнал аудита: какой инструмент вызван с какими данными, что вернулось, на каком шаге принято решение. Подробнее об этом в нашей статье ИИ-агенты в продакшене: безопасный доступ к системам.
Как он интегрируется с вашими системами
ИИ-слой, который не связан с вашей ERP, CRM, системой документооборота или собственным приложением, остаётся игрушкой. Спросите, как подрядчик будет работать с вашими API, как решит вопрос аутентификации и актуальности данных. Для стандартного подключения моделей к внутренним системам всё чаще используется Model Context Protocol (MCP); что он меняет, мы разобрали в статье что такое MCP и что он меняет в корпоративной интеграции.
Как он контролирует стоимость инференса
Стоимость работы ИИ-функции важнее стоимости её разработки, ведь каждый запрос стоит денег. Основные факторы: объём запросов, длина передаваемого модели контекста, выбранный класс модели, кэширование повторяющегося контента и маршрутизация простых задач на более компактные модели. Компетентный партнёр задаёт бюджет на запрос, отслеживает расходы и может заранее спрогнозировать, как изменится счёт с ростом нагрузки. Если команда может сказать только «зависит от использования», значит, она стоимость не отслеживает.
Как он наблюдает за системой в продакшене
ИИ-систему нельзя запустить и забыть. Нужно постоянно отслеживать время ответа, стоимость запроса, долю ошибок и отказов, отзывы пользователей и долю ответов с низкой уверенностью. Когда поставщик выпускает новую версию модели, тестовый набор должен прогоняться заново, а падение оценки должно вызывать оповещение. Если на пилоте вам не показали дашборд мониторинга и правила алертов, в продакшене вы их тоже не увидите.
Как он избегает привязки к одному поставщику
Рынок моделей меняется быстро. Модель, подходящая сегодня, завтра может оказаться дорогой, медленной или устаревшей. В архитектуре, независимой от модели (model-agnostic), все вызовы модели проходят через один слой, и смена поставщика не требует переписывать приложение. Безопасной такую замену делает всё тот же тестовый набор: вы измеряете новую модель на тех же вопросах, сравниваете и только потом принимаете решение.
Кому принадлежат промпты, код и тестовые наборы
В договоре должно быть явно указано, что исходный код, промпты, наборы для оценки, конвейеры данных и описание инфраструктуры принадлежат вам. Если подрядчик держит промпты внутри своей платформы или не передаёт тестовый набор как «внутренний инструмент», передать систему другой команде будет невозможно. При приёмке убедитесь, что ваша команда действительно понимает код: долг знаний, накапливающийся при разработке с ИИ, - скрытая стоимость, которая позже осложняет сопровождение.
Какие вопросы задать на встрече с подрядчиком?
Таблицу ниже можно использовать как чек-лист на первых встречах с компаниями, которые занимаются интеграцией ИИ.
| Вопрос | Хороший ответ | Тревожный сигнал |
|---|---|---|
| Как вы измеряете точность? | Собираем тестовый набор из ваших реальных вопросов, прогоняем его автоматически при каждом изменении и передаём результаты в виде отчёта. | «Мы попробовали, работает хорошо». Нет ни метода, ни набора. |
| Что происходит, если модель не знает ответа? | Если источник не найден, система так и говорит, а ответы с низкой уверенностью уходят человеку. | «Модель умная, она не выдумывает». |
| Через какие сервисы и в какую страну уходят наши данные? | Схема потоков данных, варианты поставщиков, сроки хранения, оценка по применимому закону о персональных данных. | Общие заверения без схемы. |
| С какими правами будет работать агент? | Минимальные привилегии, подтверждение необратимых действий, журнал аудита по каждому шагу. | Агенту выдают учётную запись администратора или полный доступ к базе. |
| Что если мы захотим сменить поставщика модели? | Вызовы модели абстрагированы, новая модель проверяется на том же тестовом наборе. | Архитектура глубоко завязана на проприетарные инструменты одного поставщика. |
| Как вы контролируете стоимость работы? | Бюджет на запрос, кэширование, маршрутизация моделей, дашборд расходов. | Ответ, что стоимость просто «зависит от использования». |
| Что вы мониторите в продакшене? | Время ответа, стоимость, долю ошибок, отзывы пользователей, алерты при падении оценки. | Мониторинг откладывается «на потом». |
| Кому будут принадлежать промпты, код и тестовые наборы? | Всё ваше, это прописано в договоре, доступ к репозиторию у вас с первого дня. | Промпты заперты на платформе подрядчика. |
Чем демо отличается от продакшена?
Сделать ИИ-демо легко: ему достаточно один раз сработать в одном сценарии. Продакшен-система должна работать каждый день на тысячах разных входных данных, с известной стоимостью и подсчитанными ошибками. Причины, по которым многие ИИ-проекты застревают на пилоте, обычно не технические, а организационные:
- Нет определения успеха: заранее не договорились, что считать «достаточно точным», поэтому никто не может решить, завершён ли пилот.
- Нет измерений: без тестового набора каждое улучшение - догадка, а каждое обновление модели - риск.
- Не решён доступ к реальным данным и правам: демо работало на примерах, а продакшену приходится иметь дело с правами доступа, персональными данными и разрозненными источниками.
- Нет встраивания в бизнес-процесс: никто не спроектировал, на каком экране появится результат и чьё подтверждение для него нужно.
- Неожиданные расходы: стоимость работы на реальных объёмах не оценили, и масштабирование выглядит рискованным.
- Нет плана отката: неизвестно, будет ли процесс работать, если отключить ИИ-слой.
Спросите подрядчика: «Что осталось сделать, чтобы вывести это демо в продакшен?» Если в ответе по порядку звучат пункты из списка выше, вы говорите с правильной командой.
Как мы подходим к ИИ-проектам в Detartech?
В Detartech мы не обучаем модели с нуля. Мы встраиваем существующие языковые модели в продукт, которым вы уже пользуетесь, и в процесс, по которому уже работает ваша команда, при двух условиях: результат должен быть измеримым и обратимым. Измеримый значит, что точность отслеживается как число на тестовом наборе. Обратимый значит, что при отключении ИИ-слоя процесс продолжает работать как прежде.
Проекты мы ведём в три этапа: проверка концепции, пилот и продакшен. Работаем двухнедельными спринтами, и каждый спринт заканчивается рабочей версией и результатами измерений. Код проходит взаимное ревью, развёртывание идёт через автоматизированный CI/CD, а 30 дней поддержки после запуска входят в работу. Пример из нашей практики - Lextum AI, платформа управления юридическими документами на базе ИИ. Подробнее о RAG, автоматизации документов и агентных процессах читайте на странице ИИ-решения.
Если у вас уже есть сценарий, заполните форму быстрого запроса. На бесплатной консультации мы вместе определим, к какой категории он относится, что нужно измерять и как будут защищены ваши данные. Отвечаем в течение 24 часов.
Часто задаваемые вопросы
Как выбрать компанию для интеграции ИИ?
Сначала определите сценарий использования, затем попросите подрядчика показать, на каком тестовом наборе он измеряет точность, куда уходят ваши данные, как ограничиваются права агентов и насколько легко сменить модель. Закрепите в договоре, что промпты, код и тестовые наборы принадлежат вам. Команда, которая отвечает на это конкретно, строит продакшен-систему, а не демо.
На что обратить внимание в вопросах защиты данных?
Нужно чётко понимать, какому поставщику модели и в какую страну уходят персональные данные и сколько они хранятся. Трансграничная передача, договоры обработки данных и маскирование в логах оцениваются заранее по применимому законодательству. Для чувствительных данных есть вариант запуска моделей с открытыми весами на собственных серверах.
Почему многие ИИ-проекты застревают на пилоте?
Чаще всего потому, что заранее не определили критерии успеха и метод измерения, не решили вопросы доступа к реальным данным и правам и не встроили результат в бизнес-процесс. Демо работает в одном сценарии, а продакшен должен каждый день работать на разных данных с известной стоимостью.
Что такое RAG и когда он нужен?
RAG (retrieval-augmented generation) - это подход, при котором модель сначала находит нужные фрагменты в ваших документах и отвечает на их основе. Он нужен, когда ответы должны опираться на внутренние знания и показывать источник. Поскольку успех во многом зависит от того, найден ли правильный фрагмент, качество поиска нужно измерять отдельно.
Нужно ли обучать собственную модель ИИ?
В большинстве корпоративных проектов нет. Существующие языковые модели решают задачу, если их правильно соединить с доступом к данным, проверкой результатов и рабочим процессом. Обучение модели с нуля - дорогой путь, который оправдан только в очень узкой области при наличии достаточного объёма размеченных данных.
