Внедрение ИИ под ключ: что входит в проект, этапы и как проверять подрядчика

Компания с собственным производством работала в «1С:ERP Управление предприятием»: заказы, спецификации, снабжение и отгрузка жили в учётной системе, документы согласовывались в «1С:Документооборот», а переписка с поставщиками и задачи — в Битрикс24. Данные были, но связка «событие → решение» оставалась ручной: менеджер по снабжению открывал заявку, шёл в почту, сверял спецификацию со счетами и складскими остатками, собирал ответ вручную и переносил его обратно в систему. Компания решила закрыть этот разрыв ИИ-агентом и почти сразу упёрлась в вопрос, который возникает у каждого заказчика: что именно должно входить в проект, чтобы он закончился работающим контуром, а не демонстрацией модели.

Спрос на такие проекты растёт быстрее, чем умение довести их до результата. По исследованию «Искусственный интеллект в России — 2025: тренды и перспективы», которое подготовили консалтинговая компания «Яков и Партнёры» и Яндекс (декабрь 2025 года), 71% крупных российских компаний уже использует генеративный ИИ хотя бы в одной сфере бизнеса. При этом, по данным глобального опроса McKinsey (State of AI, ноябрь 2025), ИИ применяют 88% организаций, но большинство остаётся на стадии пилота: попробовали почти все, встроили в процесс — меньшинство. Разрыв между «попробовали» и «работает каждый день» и есть предмет проекта под ключ. Цена разрыва измерима: по отчёту MIT NANDA «The GenAI Divide: State of AI in Business 2025» около 95% корпоративных пилотов генеративного ИИ не дают измеримого эффекта в операционном результате, а Gartner ожидает, что не менее 30% проектов генеративного ИИ будут свёрнуты после пилота — из-за качества данных, слабого контроля рисков, растущей стоимости и неясной бизнес-ценности.

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

Коротко

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

Содержание

• Что входит в проект внедрения ИИ под ключ
• Этапы проекта: от диагностики до передачи в поддержку
• Какие риски это снимает
• Сколько это возвращает: расчёт на одном участке
• Что остаётся за человеком
• Как проверять подрядчика: вопросы до подписания
• Как это выглядит на практике
• Как внедрить поэтапно
• Что в итоге
• Источники

Что входит в проект внедрения ИИ под ключ

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

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

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

Двух пунктов из этой таблицы достаточно, чтобы отличить проект от демонстрации: метрики («до и после» на одном объёме операций) и артефактов (то, что формально остаётся у заказчика). Если подрядчик не готов назвать метрику пилота и не описывает, какие документы останутся у вас, дальше разговаривать не о чем.

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

Этапы проекта: от диагностики до передачи в поддержку

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

1. Диагностика участка (одна-две недели). Смотрим месяц реальной работы: сколько операций проходит через участок, сколько минут уходит на одну, какие данные уже в системе, а какие живут в почте и файлах. На выходе — карта процесса и метрика «до». Если выясняется, что процесс не описан и каждый сотрудник делает его по-своему, сначала фиксируется единый порядок работы, и только потом появляется агент.
2. Проектирование контура (около недели). Рисуется схема «источник → правило → действие → проверка»: откуда агент берёт данные, по какому правилу сопоставляет, куда кладёт результат и на каком шаге его смотрит человек. Здесь же определяется, какие данные вообще можно отдавать на обработку.
3. Доступы и защита данных (параллельно с проектированием). Согласуется чтение учётной системы, почты и файлового хранилища, настраиваются права, фиксируется, что уходит во внешнюю модель, а что остаётся внутри контура. Это этап, который чаще всего пытаются «доделать потом», и он же чаще всего тормозит запуск.
4. Сборка правил и пилот (две-четыре недели). Агент запускается на реальных данных, но рядом с человеком: сотрудник сверяет результат, расхождения разбираются и превращаются в правило. Пилот специально идёт на одном участке — так ошибки видны на ограниченном объёме и не задевают контрагентов.
5. Замер и решение по проекту (около недели). Считается та же метрика, что и на диагностике, по тому же объёму операций. Три исхода: результат подтверждён и участок расширяется, метрика не сдвинулась и сценарий пересобирается, экономика не сходится и проект закрывается. Все три исхода нормальны, если метрика была названа заранее.
6. Интеграция и регламент (две-три недели). Результат встраивается в рабочий процесс, описывается, кто подписывает и кто проверяет, настраивается журнал действий. Здесь же решается вопрос с дублями в справочниках: если номенклатура в учётной системе ведётся вручную, часть ошибок агента — на самом деле ошибки данных, а не модели.
7. Поддержка после передачи. Правила живут и меняются: появляются новые виды документов, поставщики, условия. Поэтому проект не заканчивается запуском — заканчивается передачей: сопровождение, контроль качества и порядок доработок должны быть описаны до того, как подрядчик ушёл.

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

Какие риски это снимает

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

Пилот, который не доходит до процесса

Самая дорогая неудача — не ошибка модели, а пилот, который понравился на презентации и тихо умер через месяц. Именно на этом рушатся проекты: по оценке MIT NANDA, около 95% корпоративных пилотов генеративного ИИ не дают измеримого результата, а Gartner ожидает сворачивания не менее 30% проектов после стадии пилота. Механика отказа почти всегда одна: мерили не ту метрику, а результат не возвращался в рабочую систему. Деньги, потраченные на такой пилот, не возвращаются — в отличие от проекта, где пилот ограничен одним участком и заранее названной метрикой.

Рост затрат без измеримого эффекта

По данным Института статистических исследований и экономики знаний НИУ ВШЭ, который проанализировал обследование Росстата по более чем 15 тысячам крупных и средних организаций, главным препятствием для внедрения ИИ остаются высокие затраты — об этом заявляют 58% респондентов, а 48% организаций вообще не видят потребности в технологиях ИИ. Показательно, что среди барьеров на равных стоят нехватка квалифицированных кадров и дефицит данных для работы с ИИ. Практический вывод для заказчика: бюджет проекта защищает не выбор модели, а отсутствие границ — понятный сценарий, ограниченный объём операций и решение останавливаться по метрике.

Данные, уходящие мимо политики компании

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

Зависимость от подрядчика и от одного человека

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

Цена ошибки в обязательстве

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

Простой участка в ожидании проекта

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

Сколько это возвращает: расчёт на одном участке

Часы — уже следствие: сначала снимаются риски, потом считается экономия. Ниже — типовой расчёт для участка обработки заявок снабжения: 200 заявок в месяц, каждая требует сверки спецификации, счёта и складских остатков.

Показатель	Вручную	С агентом
Разбор одной заявки (сверка спецификации, счёта, остатков)	12 минут	3 минуты на проверку спорных мест
200 заявок в месяц	40 часов	10 часов
Поиск истории поставщика и нужного документа	6 минут на заявку	меньше минуты
Освобождается в месяц	—	около 30 часов
В деньгах при стоимости часа 700 ₽	28 000 ₽	около 21 000 ₽ экономии

Такой расчёт намеренно оставляет человеку 3 минуты на заявку: агент не «закрывает» операцию, а готовит её к проверке. На трёх участках — заявки снабжения, сверка документов и контроль сроков поставки — те же пропорции дают около 60 часов и порядка 42 000 ₽ в месяц. Границы измерения важны не меньше цифр: считаем только операции с цифровым следом в системе, замер делаем на одном и том же объёме работ до и после, а экономию подтверждаем не оценкой сотрудников, а журналом действий агента.

Что остаётся за человеком

Агент снимает рутину, но не ответственность. В границы человека входят:

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

Как проверять подрядчика: вопросы до подписания

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

1. Какой процесс вы берёте первым и почему именно этот?
2. Какой метрикой измерим результат и по какому объёму операций?
3. Что вы делаете, если данных в системе не хватает для сценария?
4. Где живут правила проверок и кто их может изменить после запуска?
5. Какие данные уходят на внешнюю обработку, а какие остаются в контуре компании?
6. Что происходит, когда агент не уверен в результате?
7. Какие артефакты останутся у нас после пилота — схема, правила, журнал?
8. Что вы не берёте в проект и почему это за границей?
9. Как устроена поддержка после передачи: что входит, а что дорабатывается отдельно?
10. Как мы останавливаем проект — и что остаётся у нас после остановки?

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

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

Как это выглядит на практике

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

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

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

Как внедрить поэтапно

1. Выбрать один участок. Не «внедрить ИИ в компании», а один процесс с рутиной, измеримым объёмом и цифровым следом в системе.
2. Провести разбор. Собрать месяц работы участка, посчитать часы на операцию, зафиксировать метрику «до». Это и есть бесплатный разбор стратегии — первая встреча, после которой видно, есть ли смысл в проекте.
3. Описать правила и границы. Что агент читает, что сопоставляет, что возвращает и где останавливается. Обязательно — перечень операций, которые агент не выполняет без человека.
4. Закрыть данные и доступы. Определить, что можно обрабатывать во внешней модели, а что только в собственном контуре, и выдать права ровно на нужный объём.
5. Запустить пилот с человеком рядом. Ограниченный объём, реальные документы, ежедневная сверка результата. Расхождения — это не сбои, а материал для правил.
6. Замерить и решить. Сравнить метрику с исходной, посчитать часы и деньги, решить про расширение или закрытие. И только после этого — интеграция в процесс, регламент и передача в поддержку.

Что в итоге

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

Источники

• Исследование «Искусственный интеллект в России — 2025: тренды и перспективы» («Яков и Партнёры» и Яндекс, декабрь 2025): 71% крупных российских компаний используют генеративный ИИ хотя бы в одной сфере бизнеса — публикация с данными исследования.
• ИСИЭЗ НИУ ВШЭ по данным обследования Росстата (свыше 15 тыс. крупных и средних организаций, 2025): 58% называют главным препятствием высокие затраты, 48% не видят потребности в технологиях ИИ — Применение искусственного интеллекта в российских компаниях.
• McKinsey, The State of AI: Global Survey (ноябрь 2025): 88% организаций используют ИИ хотя бы в одной функции, большинство остаётся на стадии пилота — обзор и данные отчёта.
• MIT NANDA, «The GenAI Divide: State of AI in Business 2025»: около 95% корпоративных пилотов генеративного ИИ не дают измеримого результата — отчёт (PDF).
• Gartner: не менее 30% проектов генеративного ИИ будут свёрнуты после стадии пилота из-за качества данных, контроля рисков, стоимости и неясной бизнес-ценности — публикация с прогнозом.