Как выбрать ИИ-подрядчика в 2026: 15 пунктов проверки и 7 красных флагов

С привычным ИТ-проектом всё понятно заранее. Вы знаете, что должно получиться: портал, интеграция, миграция базы. Есть ТЗ, есть критерии приёмки, результат либо работает по спецификации, либо нет. ИИ-проект устроен иначе, и эта разница — корень большинства провальных пилотов.

Во-первых, результат недетерминирован. Подрядчик не может на старте гарантировать, что модель будет отвечать с точностью 95% — потому что точность зависит не от него одного, а от ваших данных. Если документы в архиве лежат в трёх форматах, половина отсканирована криво, а актуальную версию регламента знает только один человек из юротдела, никакая модель это не вытянет. На схеме пилот выглядит просто: подключили данные, обучили, получили ответы. В реальности первые две недели уходят на то, чтобы понять, что данные к работе не готовы.

Во-вторых, проект целиком завязан на данные заказчика, а значит — на доступ к ним. И здесь начинается зона ИБ. Чувствительные документы нельзя выгружать в облако: для персональных данных это упирается в 152-ФЗ, для объектов критической инфраструктуры — в требования к КИИ. Подрядчик, который привык работать через публичный API внешней модели, на этом этапе либо честно говорит «мы так не умеем», либо начинает предлагать обходные схемы, которые ИБ-служба завернёт на первом же согласовании.

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

Зрелого интегратора видно по тому, как он разговаривает на первой встрече — ещё до всякой проверки документов.

Это видно по разговору. На «сделайте, чтобы модель не ошибалась» он не кивает, а объясняет, где проходит граница применимости и сколько ручной проверки останется. Предлагает пилот вместо сразу промышленного контракта — потому что результат заранее не известен и его надо измерить на ограниченном объёме. Спрашивает, где будут лежать данные и какие у вас ИБ-ограничения, — в первые десять минут, а не «потом». Магию не обещает: фраз вроде «ИИ полностью заменит ваш отдел» в его речи нет.

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

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

15 критериев, сгруппированных в три блока: лицензии и стек, процесс и команда, договор и эксплуатация

Короткий тест на зрелость — по поведению, а не по презентации.

Любой из этих признаков — повод насторожиться. Два и больше — повод не подписывать.

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

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

Чем конкретнее этот набор, тем точнее подрядчик оценит проект — и тем меньше сюрпризов будет потом. Порядок цифр по бюджету поможет прикинуть разбор стоимости пилота on-premise LLM, а если эффект пока сформулирован размыто — расчёт упущенной выгоды и ROI.

Логично, что чек-лист выше можно применить и к нам — мы на это рассчитываем. Поэтому коротко о том, как мы закрываем ключевые пункты.

AZONE AI — направление компании АЗОН, системного интегратора в сфере ИТ и информационной безопасности. У компании есть лицензии ФСТЭК России, ФСБ России и Минобороны РФ, что позволяет работать с проектами, где требования регулятора закрывают дорогу подрядчикам без соответствующих допусков (пункты 1 и 14 чек-листа).

Профиль направления — on-premise ИИ: развёртывание LLM и RAG-систем в закрытом контуре заказчика, без выгрузки данных во внешние сервисы. Это закрывает связку пунктов 2, 5 и 8 — опыт работы «на земле», совместимость с отечественным стеком и обработку данных внутри периметра. Работу мы строим от пилота: ограниченный по срокам и объёму проект с заранее согласованными метриками, по итогам которого видно, имеет ли смысл промышленный запуск (пункты 7, 11, 13).

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