Внедрение ИИ

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

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

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

Чем отличается от пилота и от соседних понятий

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

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

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

От разработки. Программный робот поверх чужого интерфейса (RPA), сборка сценария без программиста (Low-code и no-code) и написание кода через диалог с моделью (Вайб-кодинг) это способы сделать систему. Внедрение происходит вокруг любого из них.

Цифровой сотрудник, нейросотрудник и похожие названия

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

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

Откуда взялось

Отдельная фаза с названием «внедрение» появилась в методиках анализа данных задолго до нынешних моделей. Методология CRISP-DM была задумана в 1996 году, в 1997 стала проектом Европейского союза по программе ESPRIT, а первая версия была представлена в марте 1999 года на рабочей встрече в Брюсселе. Шесть фаз CRISP-DM заканчиваются фазой Deployment, то есть развёртыванием у заказчика.

В середине 2010-х годов, когда модели машинного обучения начали переезжать из лабораторий в работающие продукты, у этой фазы появилось своё имя, MLOps (от machine learning operations). Определение и разбор практики собраны в работе Кройцбергера, Кюля и Хиршля от 4 мая 2022 года. Авторы начинают с того, что вывести продукт на машинном обучении в промышленную работу сложно, поэтому многие начинания не оправдывают ожиданий.

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

Что добавляется к пилоту

Ниже то, чего в пилоте обычно нет вовсе.

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

Роли и зоны ответственности

Работа 2022 года про MLOps перечисляет семь ролей. Список удобен как чек-лист, даже когда людей в проекте трое.

Роль	За что отвечает
Заказчик со стороны бизнеса (business stakeholder)	деловая цель и разговор про отдачу от вложений
Архитектор решения (solution architect)	архитектура и выбор технологий после сравнения
Специалист по данным (data scientist)	перевод деловой задачи в задачу машинного обучения, алгоритм и параметры
Инженер данных (data engineer)	конвейеры данных и признаков, загрузка в хранилище
Программист (software engineer)	превращение сырой модели в инженерно пригодный продукт
Инженер эксплуатации (DevOps engineer)	сборка, выкладка, наблюдение за работающей системой
Инженер MLOps (ML engineer)	сквозная роль поверх предыдущих: инфраструктура, автоматические конвейеры, наблюдение за моделью

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

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

Данные и связь с учётными системами

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

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

1. Чтение. Система забирает данные из CRM, склада или бухгалтерии и ничего в них не меняет. Самый дешёвый уровень.
2. Запись служебных полей. Метка, тег, комментарий, статус. Ошибка обратима и правится руками.
3. Запись учётных данных. Документ, проводка, платёж. Здесь появляется норма: статья 9 Федерального закона № 402-ФЗ «О бухгалтерском учёте» перечисляет обязательные реквизиты первичного учётного документа, и среди них подписи лиц с указанием фамилий и инициалов. На границе учёта в цепочке остаётся названный человек, и поток проектируют так, чтобы ему было что проверить.

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

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

Своя команда или подрядчик

Решает не размер бюджета, а частота будущих изменений и ответ на вопрос, кто будет чинить систему в понедельник утром.

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

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

Процента в этом разделе не будет, и почему именно, сказано ниже, в ограничениях. При собственном разборе двенадцати страниц топа 19 сентября 2026 года слово «подрядчик» не встретилось ни на одной.

Договор: задание, приёмка и сопровождение

Что пишут в задании

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

• Предмет. Какая операция, на каком потоке, какая доля потока обрабатывается без человека.
• Критерий качества числом. Доля ответов, принятых без правки, на эталонной выборке согласованного размера. Статья 721 Гражданского кодекса говорит, что качество работы должно соответствовать условиям договора, а при отсутствии или неполноте условий требованиям, обычно предъявляемым к работам такого рода. Общепринятых требований к качеству ответов модели не существует, поэтому число в договоре заменить нечем.
• Эталонная выборка. Кто собирает, из чего, у кого хранится, кто вправе менять. Выборка, которую подрядчик видел при настройке, приёмку не проверяет. На рынке ту же вещь называют контрольной выборкой и контрольным набором; путать её с контрольной группой нельзя, та нужна для сравнения людей, а не ответов.
• Поведение при отказе. Что делает система, когда модель недоступна, отвечает слишком долго или отказывается отвечать.
• Права на результат. Пункт 1 статьи 1296 Гражданского кодекса относит исключительное право на программу или базу данных, созданную по договору заказа, заказчику, если договором не предусмотрено иное. Оговаривают поимённо: код обвязки, схемы данных, тексты инструкций для модели (промпты), дообученные веса.
• Выход. В каком виде и в какие сроки передаются данные, журналы и настройки, если стороны расходятся.

Как принимают работу

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

Отсюда прикладной вывод: демонстрация на подготовленных примерах приёмкой не является. Проверка системы с моделью состоит из пяти шагов.

1. Прогон на эталонной выборке, которую подрядчик не видел. Результат сравнивают с числом из договора.
2. Наблюдение на живом потоке согласованный период. Первая неделя показывает интерес людей к новинке, поэтому период берут от месяца.
3. Проверка поведения при сбое. Поставщика отключают намеренно и смотрят, что стало с очередью.
4. Проверка журналов и прав. Видно ли, кто что спросил и что ответила система. Не видит ли сотрудник через неё документы, к которым доступа у него нет.
5. Передача документации и доступов. Инструкции, схемы, учётные записи, порядок обновления. Без этого сопровождение достаётся тому, кто систему построил, независимо от договора.

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

Что входит в сопровождение

Работающая система с моделью портится сама, даже когда её никто не трогает. Причин две, и обе внешние.

Первая называется дрейфом (drift): поток данных постепенно перестаёт походить на тот, на котором систему настраивали. Меняется ассортимент, приходят новые формулировки в заявках, сезон приносит другие вопросы. В работе 2022 года непрерывное наблюдение и обратные связи стоят двумя из девяти опорных принципов практики MLOps, и повторное обучение запускается именно по сигналу наблюдения.

Вторая причина в поставщике модели. Версии выводятся из эксплуатации, и это видно в открытой документации. На странице обновлений моделей GigaChat, обновлённой 24 июля 2026 года, перечислено шесть выпусков, и у трёх из них (от 13 марта 2025 года, 31 октября 2024 года и 1 октября 2024 года) стоит статус «Недоступна». Инструкция, отлаженная под конкретное поведение модели, после такой смены даёт другой результат, и заметить это можно только повторным прогоном эталонной выборки.

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

Почему проекты не доходят до промышленной работы

Числа по этому вопросу есть, и они самоотчётные, что честнее назвать сразу. В главе про экономику отчёта AI Index 2026 Стэнфордского института HAI собраны данные ежегодного опроса McKinsey & Company за 2025 год про стадию, на которой находится работа с ИИ. Распределение по выручке компании выглядит так.

Выручка компании	Не используют	Эксперименты	Пилот	Масштабирование	Полностью масштабировано
до 100 млн $	9 %	39 %	22 %	25 %	5 %
от 100 до 499 млн $	8 %	33 %	32 %	23 %	4 %
от 500 до 999 млн $	5 %	31 %	32 %	29 %	3 %
от 1 до 4,9 млрд $	6 %	22 %	31 %	32 %	9 %
от 5 млрд $	доля в диаграмме не подписана	17 %	31 %	39 %	10 %

Та же глава приводит, что применение ИИ хотя бы в одной рабочей функции назвали 88 % опрошенных организаций против 78 % годом раньше. Разрыв между «пробуем» и «работает во всей компании» виден на одном материале: применяют почти все, полностью масштабировали от 3 до 10 процентов. Составители предупреждают, что данные основаны на самооценке респондентов и годятся как указание направления. Размер выборки в главе не назван, поэтому он не называется и здесь.

Ходовые цифры вроде «80 % проектов проваливаются» встречаются в выдаче без указания на источник, а разбор самой известной из них собран в соседней статье про нейросети для бизнеса.

Механика остановки повторяется и описывается без процентов. Базовую линию не сняли, поэтому спор «стало лучше» разрешать нечем. Эталонной выборки нет, поэтому качество после обновления модели никто не сравнивает. Данные лежат в трёх системах, и связывание их оказывается отдельным проектом. Владельца не назначили, и через квартал настройка ветшает. Сопровождение не оплачено, поэтому чинить некому.

Что меняется у малого бизнеса

Разница не только в бюджете, и таблица выше это подтверждает: у компаний с наименьшей выручкой доля экспериментирующих выше всех (39 %), а доля полностью масштабировавших ниже, чем у самых крупных (5 % против 10 %).

Прикладных отличий четыре.

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

Чем измеряют

Метрики пилота (доля ответов без правки, характер правок, доля отказов модели) разобраны в статье Нейросети для бизнеса. У работающей системы к ним добавляются другие.

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

Связь этих чисел с деньгами считается отдельно, приёмы собраны в статьях Юнит-экономика и Сквозная аналитика.

Частые ошибки

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

Не зафиксировать версию модели в настройке. Обращение без указания версии означает согласие работать на той, которая станет актуальной завтра.

Записать в договор «повышение эффективности». Формулировку без числа нельзя ни проверить, ни оспорить. Обеим сторонам она удобна ровно до первого спора.

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

Оставить систему без владельца. Настройка без хозяина ветшает за квартал, и это верно и для правил, и для моделей.

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

Внедрять то, что надо отменить. Лишнее согласование, закреплённое в коде, оплачивается при каждой переделке.

Ограничения и спорные места

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

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

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

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

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

Долгого горизонта у этих проектов пока нет. Массовая работа с генеративными моделями идёт около трёх лет, и данных о стоимости владения на пятилетнем сроке не накоплено ни у кого.

Что здесь быстро устаревает

• Состав и статусы версий моделей у поставщиков. Проверяется на странице обновлений моделей самого поставщика. Признак протухания: версия из статьи помечена как недоступная или исчезла из списка.
• Числа по стадиям внедрения. Опрос и сводка AI Index выходят ежегодно, распределение меняется от выпуска к выпуску.
• Набор ролей. Сквозная роль инженера MLOps за несколько лет вобрала части соседних, и процесс продолжается.
• Готовые связки с учётными системами. Коннекторы к CRM, складу и бухгалтерии появляются и переименовываются без объявлений, и вчерашняя оценка стоимости интеграции стареет вместе с ними.
• Нормы про ИИ. Отложенные статьи закона о поддержке развития технологий искусственного интеллекта вступают в силу позже основного текста, даты и состав перечислены в соседней статье про нейросети для бизнеса.
• Рыночные названия. «Цифровой сотрудник» и «нейросотрудник» это слова сегодняшнего каталога, через год на их месте окажутся другие.

См. также

• Нейросети для бизнеса
• Автоматизация бизнес-процессов
• ИИ-ассистент
• ИИ для работы с документами
• ИИ в продажах
• Речевая аналитика
• Предиктивная аналитика
• Услуга агентства Optimism: внедрение ИИ в процессы бизнеса

Источники

1. Stanford HAI. The 2026 AI Index Report, глава 4 «Economy»: организационное применение ИИ 88 % против 78 % годом ранее, рисунок 4.3.6 «Stage of AI deployment by organization revenue, 2025» по данным опроса McKinsey & Company за 2025 год, оговорка о самоотчётном характере данных. https://hai.stanford.edu/assets/files/ai_index_report_2026_chapter_4_economy.pdf (открыто и разобрано 19 сентября 2026 года).
2. Kreuzberger D., Kühl N., Hirschl S. Machine Learning Operations (MLOps): Overview, Definition, and Architecture. arXiv:2205.02302, подано 4 мая 2022 года. Семь ролей (R1-R7), девять принципов практики (P1-P9), наблюдение за дрейфом и повторное обучение. https://arxiv.org/abs/2205.02302 (19 сентября 2026 года).
3. Cross-industry standard process for data mining. Английская Википедия: замысел 1996 года, проект ESPRIT 1997 года, первая версия представлена в марте 1999 года, шесть фаз с завершающей Deployment. https://en.wikipedia.org/wiki/Cross-industry_standard_process_for_data_mining (19 сентября 2026 года).
4. Статья 720 Гражданского кодекса Российской Федерации «Приемка заказчиком работы, выполненной подрядчиком»: обязанность осмотреть и принять, явные и скрытые недостатки. КонсультантПлюс. https://www.consultant.ru/document/cons_doc_LAW_9027/48e02faf6357243a0fa7806dd7ca2dc2493301a8/ (19 сентября 2026 года).
5. Статья 721 Гражданского кодекса Российской Федерации «Качество работы»: соответствие условиям договора, а при их неполноте обычно предъявляемым требованиям. КонсультантПлюс. https://www.consultant.ru/document/cons_doc_LAW_9027/e3c9f494588eba84349f9aaf8082c329384eb340/ (19 сентября 2026 года).
6. Статья 1296 Гражданского кодекса Российской Федерации «Произведения, созданные по заказу», пункт 1. КонсультантПлюс. https://www.consultant.ru/document/cons_doc_LAW_64629/e1a2a66199f94c314b8613a44d2abbad7203f7ee/ (19 сентября 2026 года).
7. Статья 9 Федерального закона от 06.12.2011 № 402-ФЗ «О бухгалтерском учете»: обязательные реквизиты первичного учётного документа, включая подписи лиц с указанием фамилий и инициалов. КонсультантПлюс. https://www.consultant.ru/document/cons_doc_LAW_122855/b24121ba7152f33673608559f2ca844ef5b6a74c/ (19 сентября 2026 года).
8. Сбер. Документация GigaChat API, раздел «Обновления моделей»: шесть выпусков, статусы «Доступна» и «Недоступна», страница обновлена 24 июля 2026 года. https://developers.sber.ru/docs/ru/gigachat/models/updates (19 сентября 2026 года).
9. Собственный разбор выдачи 19 сентября 2026 года: двенадцать прочитанных страниц топа по запросам «внедрение ии в бизнес», «внедрение ии» и «внедрение искусственного интеллекта». Считалось наличие слова «подрядчик», наличие раздела про приёмку готовой системы и наличие именованного внешнего источника у приведённых чисел. Ссылки на разобранные страницы не приводятся: справочник не ссылается на материалы прямых конкурентов как на источник знания.