Почему ИИ не доходит до производственного контура: 8 барьеров и что с ними делать
- Джимшер Челидзе
- 16 июл.
- 17 мин. чтения
Введение: почему я говорю, что многим ИИ противопоказан
Начну с тезиса, за который меня регулярно критикуют.
Значительной части компаний внедрять ИИ противопоказано. Не потому, что они плохие. А потому, что автоматизация хаоса даёт автоматизированный хаос — только дороже и быстрее.
Если процесс не описан, не измерен и не стандартизован, ИИ не «наведёт порядок». Он зафиксирует беспорядок в коде и придаст ему легитимность цифры. А это хуже, чем беспорядок, потому что с цифрой уже никто не спорит.
И дороже провала — только такой провал, после которого в компании перестают пробовать. Одна неудачная затея на сто миллионов закрывает тему для совета директоров на пять лет вперёд.
Цифры тут упрямые. По разным оценкам, от 70 до 84% проектов внедрения цифровых технологий либо проваливаются, либо проблемные: срывают сроки, превышают бюджет, дают эффект внутри одного-двух процессов, повышают текучку персонала.
По более широким оценкам McKinsey и MIT (NANDA), до 95% инвестиций в ИИ не дают ожидаемого эффекта, а около 75% пилотов так и не доходят до промышленной эксплуатации. 70–84% — это доля прямо провальных и проблемных; знаменатель у оценок разный, но вывод один: до результата доходит меньшинство, и почти всегда по нетехническим причинам.
Я разбираю причины этого много лет — в книгах, в проектах, в портфелях на несколько десятков инициатив; первый системный разбор — в статье «7 причин большинства проблем на пути цифровизации». Эта статья — её продолжение применительно к ИИ. И пришёл к простому выводу: почти всё сводится к небольшому числу типовых причин. И ни одна из них не техническая.
Разрыв между пилотом и производственным контуром — не технологический. Он управленческий.
Пилот доказывает, что работает модель. Контур требует, чтобы работала организация. Между ними лежит не код, а ответственность.
Ниже — восемь барьеров, которые я вижу системно. По каждому: в чём проблема, чем она заканчивается и что с ней делать.
Барьер 1. Нет стратегии — а значит, нет и портфеля
Это корневая причина, которая порождает большинство остальных.
У подавляющего большинства компаний нет качественной стратегии цифровизации — той, поверх которой только и можно внедрять ИИ. Есть презентация с технологиями. Есть перечень инициатив. Стратегии нет.
Стратегия — это не документ. Это конструкция. В ней должно быть четыре вещи.
1.1. Разбор самого бизнеса
Каковы приоритеты. Где ограничения системы. Где реальное узкое место, которое сдерживает деньги.
Не «где нам интересно применить ИИ», а «где у нас болит и сколько это стоит».
Без этого любой перечень инициатив — это список хотелок подразделений, отсортированный по красноречию их руководителей.
1.2. Портфель с управлением взаимосвязями
Здесь горит больше всего денег, и об этом почти не говорят.
Проекты в цифровизации связаны жёстко:
ассистент технолога не поедет, пока не приведена в порядок конструкторская документация;
предиктивное обслуживание не поедет без нормального справочника оборудования;
сквозная аналитика не поедет без интеграционной шины;
любая ИИ-модель не поедет без качества данных.
Когда портфель собран без карты зависимостей, происходит следующее. Проект А стартует, упирается в отсутствие проекта Б, встаёт — а деньги уже освоены, команда занята, сроки идут. И так по десятку инициатив одновременно.
Портфель без управления зависимостями — это не портфель. Это склад незавершённого производства, только очень дорогой.
Метрика, которую стоит посчитать сегодня: доля инициатив, заблокированных ожиданием других инициатив. Если она выше 20% — портфелем никто не управляет. Им просто владеют.
1.3. Связка трёх контуров
Любой ИИ-проект стоит на трёх опорах, и все три должны быть обеспечены отдельными проектами в том же портфеле:
Технологический контур — ИТ-инфраструктура, управление данными, интеграции, информационная безопасность.
Организационный контур — процессная зрелость, бережливое производство, управление проектами, управление изменениями и сопротивлением.
Кадровый контур — компетенции, цифровая грамотность, мотивация.
Если хотя бы одна опора не обеспечена — проект не взлетит, каким бы хорошим ни был алгоритм.
Критерий для инвесткомитета: прежде чем утвердить ИИ-инициативу, покажите, какими проектами закрыты все три контура. Если ответа нет — это не проект. Это заявка на списание бюджета.
1.4. Модель финансирования общего слоя
И здесь корень корня.
Базовый технологический слой — нормативно-справочная информация, качество данных, интеграционная шина, платформа — не имеет заказчика. Его бенефициар — вся компания, то есть никто конкретно.
Ни один начальник цеха и ни один директор департамента не отдаст свой бюджет на справочник, эффект от которого получит сосед. Это не жадность. Это рациональность.
Поэтому общий слой не строится никогда, если его не финансировать централизованно — из бюджета трансформации, а не из бюджета подразделения-заказчика.
Чем это заканчивается
Каждое подразделение начинает решать свою задачу само:
пять служб покупают пять разных ИИ-инструментов, платят пять раз, данные между ними не сходятся;
на общую технологическую базу ресурсов не остаётся — её никто не заказывал;
синергии нет: эффект каждого проекта запирается внутри одного процесса, а кросс-функциональных эффектов, ради которых всё и затевалось, не возникает.
Это и есть лоскутное внедрение ИИ.
Лоскутное внедрение — не следствие глупости. Это следствие отсутствия архитектуры. Если наверху нет карты, каждый рисует свою.
Барьер 2. Стратегия есть, но она мёртвая
Наличие документа ещё ничего не гарантирует. У живых стратегий есть две болезни.
Болезнь первая: стратегия оторвана от стратегии бизнеса
Самый частый рассинхрон выглядит так.
У компании стратегия снижения операционных затрат и удержания позиций — режим защиты. А ИТ-служба в это время занимается инновационными проектами: витрины, цифровые двойники, эксперименты с генеративным ИИ.
Бывает и зеркально: бизнес идёт в рост, в новые рынки и новые продукты — а ИТ занято оптимизацией серверов и наведением порядка в лицензиях. Тоже полезно. Тоже не про то.
Цифровая стратегия не самостоятельна. Она производна.
Бизнес в режиме защиты — ИИ-повестка про себестоимость, потери, качество, планирование ремонтов, нормирование. Скучное и прибыльное.
Бизнес в режиме нападения — ИИ-повестка про новые продукты и бизнес-модели.
Перепутать эти два режима — значит потратить бюджет на технологически безупречное решение задачи, которая компании сейчас не нужна.
Тест на пять минут: возьмите три главные цели компании на год и три главных цифровых проекта. Если между ними нельзя провести линию — у вас нет стратегии цифровизации. У вас есть бюджет ИТ.
Отсюда же, кстати, растёт перекос в фотогеничные проекты. Когда цифровая повестка не привязана к целям бизнеса, единственным критерием отбора остаётся то, как проект смотрится на совете директоров. А смотрится всегда лучше цифровой двойник на большом экране, чем нормирование и планирование ремонтов — где, собственно, и лежат деньги.
Болезнь вторая: стратегию написали и не пересматривают
Нет ритма. Ни отслеживания хода проектов, ни отслеживания рыночной конъюнктуры. Документ утвердили, повесили, вернулись к нему через год при вёрстке бюджета.
Два последствия, и оба дорогие.
Первое: ключевые проекты выпадают из поля зрения руководства. Портфель живёт по инерции, статус собирается раз в год, проблемный проект всплывает тогда, когда спасать уже нечего. Причём выпадают именно ключевые — потому что они длинные, сложные и не дают быстрых новостей. Громкие мелочи внимание получают. Фундамент — нет.
Второе, и для ИИ оно критично: проекты доезжают до финиша вне рынка.
Цикл серьёзного промышленного проекта — 2–3 года. Технологический горизонт в ИИ сегодня — 6–12 месяцев.
Я видел это не раз: компания полтора года строит своими силами решение, которое за это время превратилось в готовый продукт за небольшие деньги. Формально проект успешен — сроки, бюджет, ТЗ выполнены. Экономически он бессмыслен.
Ответ на вопрос «строить или купить» имеет срок годности.
Если вы не пересматриваете его регулярно, вы отвечаете на него один раз — и живёте с этим ответом три года.
Что делать
Ритм, который работает:
ежемесячный операционный ревью активных проектов — сроки, бюджет, качество, красный-жёлтый-зелёный, без косметики;
ежеквартальный стратегический ревью портфеля — с реальным правом закрыть инициативу и передвинуть деньги;
ежеквартальный обзор технологической конъюнктуры — что изменилось на рынке, какие наши решения обесценились, где Build пора менять на Buy.
И культурная норма, без которой ритм не работает:
Право убить проект должно быть таким же нормальным, как право его запустить.
Если за закрытие инициативы наказывают, никто ничего не закроет. Портфель будет тащить мертвецов до конца бюджетного цикла, потому что признать ошибку дороже, чем доосвоить деньги.
Барьер 3. Прыжок через две ступени зрелости
Работа с данными в компании имеет уровни зрелости:
Уровень 1.0 — единая модель данных: политики сбора, критерии качества, владельцы, хранилище. Стратегия защиты.
Уровень 2.0 — управление на основе бизнес-аналитики: единые метрики, культура решений на данных. Защита.
Уровень 3.0 — гипотезы на данных: исследования, поиск новых источников прибыли. Нападение.
Уровень 4.0 — новые продукты и бизнес-модели на данных. Нападение.
Первые два уровня — про снижение рисков, скорость реакции, качество решений. Третий и четвёртый — про новую выручку.
А теперь главное.
ИИ — это игра третьего и четвёртого уровня. А подавляющее большинство промышленных компаний находятся на первом-втором. Часто — и не на первом.
Прыжок из первого уровня сразу в третий не работает никогда. Патронов не хватит: качественных данных нет, карты местности нет. Вы построите красивую модель на грязных и задублированных данных — и получите уверенный, хорошо оформленный неверный ответ.
Желание прыгнуть сразу в нападение понятное: деньги нужны сейчас, а не через два года наведения порядка. Но каждый такой шаг создаёт новые риски, они копятся, и в какой-то момент приходится переделывать всё сделанное.
Если стратегия защиты не реализована, переходить в нападение бессмысленно.
Барьер 4. Данных нет — есть их видимость
Здесь я скажу вещь, которая обычно вызывает возражения.
За годы практики я не видел ни одной производственной компании, которая провела бы полноценную инвентаризацию своих данных. Ни одной.
Это не фигура речи. Задайте у себя на предприятии четыре вопроса:
Есть ли модель данных — понимание, какие данные у нас есть, где они лежат, в каком виде, как связаны между собой?
Кто владелец конкретного набора данных? Не «отдел отвечает» — фамилия. Кто отвечает за то, что в справочнике оборудования один насос записан трижды под разными наименованиями?
Каков жизненный цикл данных — где они рождаются, кто их вносит, как они меняются, когда устаревают, кто их удаляет?
Какие взаимосвязи между системами? Что произойдёт с аналитикой, если завтра изменится справочник в ERP?
В подавляющем большинстве случаев внятного ответа нет ни на один.
И это при том, что данные в компании есть — их избыток. Просто никто не знает, что с ними и чего они стоят.
Отдельно — инструменты обеспечения качества данных. Их не просто нет. Чаще всего нет самого понимания, что качество данных — это не разовая уборка перед аудитом, а процесс: критерии, регулярная проверка, MDM-система, обучение тех, кто вносит первичку.
Ведь именно оператор в цехе и есть источник качества. Не дата-сайентист.
Чем это заканчивается
Без этого ИИ невозможен. Не «затруднён», не «менее эффективен» — невозможен.
Вы можете построить сколь угодно продвинутую модель, но в её основе будут недостоверные данные. И вы получите уверенный, аккуратно оформленный неверный ответ — и примете на его основании решение.
Плюс типовые последствия, которые я вижу в каждом втором проекте:
невозможна сквозная аналитика между процессами и подразделениями (а если возможна — то через «костыли» и ручной труд дорогих специалистов);
невозможна интеграция ИТ-систем: непонятно, откуда и какие данные брать;
проекты стартуют долго и срывают сроки в 3–4 раза от плана;
данные дублируются между системами, растёт нагрузка на инфраструктуру.
И заметьте, откуда это растёт. Данные — это общий слой. У него нет заказчика. Поэтому им никто и не занимается.
Что делать. Порядок здесь важнее скорости
Оцифровать основные бизнес-процессы и провести инвентаризацию данных. Что есть, где лежит, кто порождает, чего не хватает.
Назначить владельцев — по фамилиям, на каждый ключевой набор данных и каждый справочник.
Построить модель данных и описать жизненный цикл: рождение, изменение, устаревание, удаление.
Задать измеримые критерии качества и организовать регулярную проверку.
Внедрить MDM — систему управления мастер-данными. Тот самый «скучный» проект, который никогда не попадёт в презентацию и без которого не поедет ни один ИИ.
Обучить тех, кто вносит первичные данные. Самая недооценённая инвестиция во всей цифровизации.
Визуализировать шаблоны перед сбором данных. Приём выглядит примитивно, а снимает до 70–80% ошибок ввода. Люди ошибаются не потому, что глупы, а потому, что не понимают, что от них хотят.
И только после этого — разговор о моделях. Не раньше.
Барьер 5. Люди на трёх этажах
Барьер людей стоит сразу на трёх этажах, и на каждом он свой.
Этаж первый: топ-менеджмент
Для первых лиц цифровизация — чёрный ящик. Отсюда три устойчивых искажения.
Ожидание волшебника. Придёт кто-то и всё сделает, а вникать, формулировать запрос и меняться самим не придётся. Не придёт. Меняться придётся всем, включая генерального директора и собственника.
Горизонт. Нормальная цифровая трансформация — 4–10 лет, первые результаты не раньше 9–12 месяцев. А запрос звучит как «результат за полгода, с гарантиями, и скажите заранее, кого увольнять в случае неудачи». Под такой запрос невозможно спроектировать честный проект. Можно только красивую презентацию. И здесь же корень завышенных ожиданий: ИИ в отрыве от остальных ИТ-технологий даёт очень ограниченный эффект. Локальные задачи — распознавание документов, автопротоколы совещаний — он закроет, но на финансовые показатели компании в целом это не повлияет. Эффект появляется только тогда, когда ИИ встроен в приведённые в порядок процессы и данные.
Фокус на «прямом» эффекте. Сэкономили тридцать миллионов, сократили время оформления бумаг вдвое. Это важно — но это оптимизация. Реальный эффект живёт в сквозных, кросс-функциональных показателях. А их никто не считает, потому что для этого нужны данные второго уровня, которых нет.
Что делать: включать первых лиц в изменения, а не информировать о них. Честно зафиксировать горизонт в уставе программы и признать, что часть инициатив не взлетит. Ввести 2–3 кросс-функциональные метрики: не «сэкономили в цехе», а рентабельность передела, ритм производственного цикла, прибыль на сотрудника.
Этаж второй: средний и технический уровень управления
Здесь провал самый недооценённый.
Спросите линейных руководителей: чем проект отличается от продукта? Что такое цикл «планируй — делай — проверяй — корректируй»? Какие бывают типы сопротивления персонала и что с ними делать? Какой процент сотрудников примет изменения с радостью, а какой будет в оппозиции до конца?
Картину вы представляете. И вот эти люди — те самые, кто должен внедрять ИИ в цехе.
Что делать: лечение не то, о чём обычно думают.
Обучать всех и сертифицировать не нужно. Это не работает и это дорого.
Нужны простые доступные программы и — вместо регламентов — памятки, в которые человек может нырнуть на три минуты и освежить знание. Регламент читают один раз, при приёме на работу. Памяткой пользуются. А ещё лучше — инструменты (в том числе программные), которые просто не дают ошибиться: валидация на вводе, подсказки, подстановка значений. Это надёжнее любого обучения.
Этаж третий: исполнители
Тут начинается самое отрезвляющее.
У меня был проект внедрения системы управления активами, где оперативный персонал не умел печатать на компьютере. Первое, что пришлось делать, — учить набирать текст, чтобы запись о дефекте не вносилась три часа с тридцатью опечатками.
В другом проекте мастер на производстве, 27 лет, не знал, как построить таблицу в Excel.
А самый частый запрос в техподдержку при внедрении любой ИТ-системы — 80–90% обращений — это «забыл пароль» и «не могу зарегистрироваться».
На одном комплексном проекте мы протестировали около 2500 пользователей, затронутых изменениями. 850 из них требовалось обучение базовым навыкам работы с компьютером. Провели 32-часовую программу — и это стало одним из факторов успеха всего проекта.
Человек не саботирует. Он не умеет. Это другая проблема, и лечится она по-другому.
Что делать: обучение, базы знаний, инструкции — и виртуализация цифровых навыков. Когда нет единого «гуру», к которому все ходят за выгрузкой, а каждый сотрудник, работающий с данными, умеет это сам. Иначе вы упираетесь в бутылочное горлышко из одного человека — и он же становится точкой отказа.
Отдельная тема — как ИИ перестраивает саму работу инженера и почему программу подготовки придётся переписывать под верификацию, а не под генерацию. Разбираю её в статье «Инженер через 5 лет: от генерации к верификации».
Барьер 6. CIO — это не CDTO
Отдельная и очень частая ошибка — отдать цифровизацию и внедрение ИИ классическому ИТ.
Классическое ИТ делает надёжные системы. Для CIO важны стабильность работы систем, соблюдение бюджетов и регламентов, снижение рисков, оптимизация затрат. У него нет задачи думать о прибыльности бизнеса и разговаривать с внутренним клиентом.
Для CDTO важно обратное: эффективность бизнеса в целом, поиск новых источников доходности, работа с данными, а не с «железом», сохранение гибкости и принятие риска.
По Адизесу это буквально разные люди:
Доминирующие функции. CIO — администрирование (A) и производство (P); CDTO — предпринимательство (E) и интеграция (I).
Ключевой вопрос. CIO — «что надо» и «как надо»; CDTO — «для кого, кем и когда надо».
Аналогия. CIO — операционный директор; CDTO — директор по развитию.
И наблюдение, которое многих обижает, но оно верное: чем выше классические ИТ-компетенции специалиста, тем, как правило, хуже у него с компетенциями для трансформации. Это не недостаток человека. Это несовпадение роли.
Что делать
Два рабочих пути:
Выделить функцию трансформации отдельно — человек со своей командой, своим бюджетом и своими KPI, работающий на стыке бизнеса и ИТ.
Развивать недостающие компетенции внутри ИТ и вводить институт ИТ-бизнес-партнёров — людей, которые сидят внутри бизнес-функции, говорят на её языке и переводят её потребности в требования к системам.
Что не работает никогда: назначить CIO ответственным за цифровую трансформацию, ничего не поменяв ни в его KPI, ни в его команде, — и ждать другого результата.
Барьер 7. Служба безопасности
Самый недооценённый структурный барьер. И он ломает не процесс, а экономику.
Типичная позиция: либо запретить, либо завести всё во внутренний контур. Обезличивание данных тоже не устраивает — «а вдруг восстановят».
Посмотрите, что происходит с деньгами. Требование полностью изолированного контура означает: свои серверы, свои GPU, своя инфраструктура, своя команда сопровождения, свои обновления, своя поддержка. Проект, который в облачном исполнении стоил бы 1 млн рублей, превращается в проект на 20–30 млн. И это не разовые затраты — постоянные.
Экономика ИИ-проекта ломается не на модели. Она ломается на периметре.
Бизнес-кейс не сходится. Инвесткомитет смотрит на цифры и — совершенно правильно — отказывает. Внедряются только отдельные инициативы: те, у кого хватило политического веса продавить бюджет.
И вот главный ущерб, который никто не считает: компания не набирает насмотренность. Не появляется опыта, компетенций, людей, которые понимают, как это работает. Через три года такая компания будет вести переговоры с вендором, не понимая, что ей продают и сколько это должно стоить.
Насмотренность нельзя купить. Её можно только набрать — и только на своих проектах.
Три причины — и ни одна не про злой умысел
Причина 1. Служба безопасности сама не понимает, что такое ИИ.
Безопасник, который не понимает разницы между отправкой данных в публичный API и локальным инференсом на своём железе, не знает, что такое RAG, что происходит с данными при обезличивании и остаются ли они в модели после запроса, — не может оценить риск. У него физически нет инструмента.
А когда риск оценить нельзя, остаётся ровно одно действие.
Запрет не требует компетенции. Разрешение при контролируемом риске — требует. Поэтому запрещают.
Отсюда вывод для руководителя: обучение службы безопасности — такая же часть ИИ-проекта, как закупка серверов. И дешевле любого сервера. Обучили бизнес и не обучили ИБ — построили проект, который будет остановлен на согласовании.
Причина 2. В компании нет понимания, что является тайной — и как долго.
Спросите: какие данные составляют коммерческую тайну? Ответ будет «все».
А теперь второй вопрос, который почти никто не задаёт: как долго они ею остаются?
Чертёж узла, снятого с производства десять лет назад. Заявка на ремонт трёхлетней давности. Сводка выработки за позапрошлый квартал. Всё это защищается так же, как актуальная себестоимость и текущий портфель заказов — вечно и одинаково.
Тайна имеет срок годности. Гриф без срока — это гриф навсегда. А защищать всё вечно — значит не защищать ничего.
Ресурс размазывается по массиву, в котором 95% давно не представляет ценности ни для кого.
Классификация данных — это не бюрократия. Это то, что превращает разговор с ИБ из идеологического в предметный. Пока классификации нет, безопасник обязан считать критичным всё. И он прав.
Причина 3. Диалога между бизнесом, ИТ и ИБ не существует.
Три службы говорят на трёх разных языках. Бизнес не формулирует, какую ценность теряет от запрета. ИТ не переводит техническое решение на язык риска. ИБ не слышит ни тех, ни других — да её никто и не спрашивает до последнего момента.
Они встречаются один раз — на приёмке. А на приёмке у ИБ остаётся один инструмент.
И под всем этим — асимметрия стимулов: за инцидент безопасника накажут, за отсутствие развития — никогда. Пока стимулы такие, он будет запрещать. И будет действовать рационально в той системе мотивации, которую вы ему построили.
Что делать — пять вещей, и все управленческие
Обучить службу безопасности. Не «провести встречу», а обучить. Безопасник, понимающий технологию, начинает торговаться о конфигурации, а не запрещать целиком.
Провести классификацию данных в двух измерениях — чувствительность и срок.
Изменить постановку задачи. ИБ отвечает не за «запретить», а за «сделать возможным при приемлемом уровне риска». Пока в её KPI нет ни одного показателя про развитие, она будет запрещать.
Ввести правило альтернативы. Любой запрет сопровождается работающей альтернативой: «нельзя» без «а можно вот так» — это не работа службы безопасности, это уклонение от неё.
Создать трёхсторонний формат. Не согласование постфактум, а совместное проектирование: бизнес, ИТ и ИБ с первого дня. И дифференцированный контур как результат: нечувствительные задачи — во внешние модели, чувствительные — в закрытый периметр. Большая часть корпоративных задач, если честно посмотреть, нечувствительна.
Регуляторная рамка здесь, кстати, мягче, чем принято думать: принятый в июле 2026 года закон касается только больших фундаментальных моделей. Разбор по тексту — в статье «Закон об ИИ: что на самом деле приняли».
Барьер 8. Культура
Если в компании все относятся друг к другу с позиции «мне должны», если ждут, что придёт цифровизатор и всех осчастливит, — там даже самый талантливый цифровизатор выгорит за три-четыре месяца. И вместо клиентоориентированного партнёра станет обычным ИТ-шником, который не хочет никого видеть.
Цифровизация с приемлемыми издержками возможна только тогда, когда бизнес-заказчик вовлечён, заинтересован и владеет базовым управлением проектами. А цифровизаторы помогают выбрать технологию и поставщика, координируют, сопровождают как партнёры.
Цифровизация — это про умение договариваться. Иначе внедрены будут даже хорошие инструменты, но пользоваться ими не станут, и через 3–6 месяцев всё отторгнется.
Что делать
Определить тип организационной культуры компании и отдельных подразделений — и под него подбирать ролевую модель поведения. То, что сработает в производственном цехе, не сработает в НИОКР.
Сделать бизнес-заказчика совладельцем проекта, а не получателем: его фамилия в уставе, его KPI, его защита результата на комитете.
Институт ИТ-бизнес-партнёров как постоянный канал связи, а не разовые встречи по требованию.
И честное правило для руководителя:
Если бизнес-заказчик не готов вкладывать в проект своё время — проект не запускается. Не потому что мы обиделись. Потому что он всё равно провалится — просто позже и дороже.
Отдельно: цена ошибки в контуре
Всё сказанное выше — про то, что мешает ИИ дойти до контура. Но важно не перевернуть маятник в другую сторону.
У производственного контура принципиально иная цена ошибки.
Ассистент, который в 8 случаях из 10 предлагает верный техпроцесс, — отличный инструмент. Модель, которая в 8 случаях из 10 верно управляет исполнительным механизмом, — это авария.
Отсюда правило:
Чем ближе к контуру управления, тем уже и тем верифицируемее должна быть модель, и тем обязательнее fallback-сценарий и человек в петле принятия решения.
Мы не будем ставить большую языковую модель в контур АСУ ТП. И не надо.
«Встроенность в контур» означает не «ИИ управляет». Она означает: ИИ встроен в процесс принятия решения человеком, и это решение прослеживается.
И ещё одно, что обычно относят к техническим деталям, а оно определяет всё. Требовать от инженера верификации, выдавая ему голый ответ модели, — бессмысленно. Верификация физически возможна только тогда, когда система показывает, откуда она это взяла: ссылка на конкретный пункт вашего техпроцесса, на конкретный чертёж, на конкретную рекламацию.
Ассистент без прослеживаемости источника — это генератор правдоподобия. Никакой инженер его не проверит: он просто нажмёт «принять».
Прежде чем требовать от людей нового поведения, дайте им инструмент, который делает это поведение возможным. Иначе вы получите ритуал вместо контроля.
Решение: три столпа
Если свести всё сказанное, получится вот что.
Управление
Стратегия, производная от бизнес-стратегии
Портфель с каИскусственный интеллект. Практическое руководство для внедрения (с дополнениями 14.07.2026)ртой зависимостей и централизованным финансированием общего слоя
Ритм ревью: проекты — ежемесячно, портфель и технологическая конъюнктура — ежеквартально
Право закрыть проект без наказания
Go/No-Go и базовый уровень «до» по каждой инициативе
Технология
Инвентаризация данных — владельцы — модель данных и жизненный цикл
Измеримые критерии качества и MDM
Интеграционный слой
Архитектура, спроектированная под контур и под масштабирование с первого дня, а не «докрученная» после пилота
Прослеживаемость источника в каждом ИИ-решении
Люди
Первые лица включены в изменения, а не проинформированы
Средний уровень вооружён памятками, а не регламентами
Исполнители доучены базовым навыкам
Служба безопасности обучена технологии
Носители знания получили новый статус, а не угрозу
Платим за использование, а не за результат
Провал в любом из трёх столпов обнуляет два остальных.
Именно поэтому ИИ — это не ИТ-проект. Это проект изменения компании, у которого просто есть ИТ-часть. А мы упорно вкладываем 70% бюджета в один столп, технологический, и потом удивляемся результату.
Чек-лист готовности: 24 вопроса
Каждый вопрос требует ответа «да» — с фамилией и цифрой, а не «в целом да».
Уровень стратегии
Можно ли провести линию между тремя главными целями бизнеса на год и тремя главными цифровыми проектами?
Соответствует ли цифровая повестка режиму бизнеса — защита или нападение?
Есть ли ритм пересмотра: проекты ежемесячно, портфель и рынок — ежеквартально?
Может ли кто-то в компании закрыть проект и не быть за это наказанным?
Уровень портфеля
Есть карта зависимостей между проектами? Какая доля инициатив заблокирована ожиданием других? (Выше 20% — портфелем не управляют.)
Для этой ИИ-инициативы закрыты все три контура — технологический, организационный, кадровый — конкретными проектами?
Кто финансирует общий технологический слой? Если «подразделение-заказчик» — он не будет построен.
Уровень данных
Проведена ли инвентаризация данных? Есть ли модель данных?
Есть фамилия владельца каждого ключевого набора данных?
Описан ли жизненный цикл данных?
Есть ли критерии качества и инструменты их регулярной проверки?
Уровень безопасности
Понимает ли ваша ИБ, что такое локальный инференс, RAG и обезличивание? Обучение ИБ заложено в бюджет проекта?
Проведена ли классификация данных — по чувствительности и по сроку?
Заведена ли ИБ в проект с первого дня — или её позовут на приёмку?
Действует ли правило альтернативы?
Есть ли в KPI службы безопасности хоть один показатель про развитие?
Уровень людей
Включены ли первые лица в изменения лично — а не просто проинформированы, — и зафиксирован ли честный горизонт (годы, а не полгода)?
Обучены ли средний уровень и исполнители под свои роли, и заменены ли регламенты памятками и инструментами, которые не дают ошибиться?
Получили ли носители знания новый статус, а не угрозу, — и платите ли на этапе адаптации за использование, а не за результат?
Уровень проекта
Процесс описан и измерен? Есть базовый уровень «до»?
Есть фамилия владельца модели после запуска?
Эффект от системы попал в KPI того, кто будет ею пользоваться?
Определены недопустимые события и fallback-сценарий?
Есть критерии Go/No-Go, по которым пилот можно честно признать неудачным? Посчитан ли бюджет масштабирования до старта пилота?
Если хотя бы на три вопроса ответа нет — вы не готовы к контуру. Вы готовы к ещё одному пилоту.
Это экспресс-версия для быстрой самопроверки. Полная диагностика готовности — по флаговой методологии (зелёный / жёлтый / красный), с отдельными опросниками готовности к пилоту и к масштабированию — в книге «ИИ. Практическое руководство для внедрения» (глава 7).
Итоговые рекомендации
Начните со стратегии, а не с технологии. Не «где применить ИИ», а «где болит и сколько это стоит». Если между целями бизнеса и цифровыми проектами нельзя провести линию — остановитесь и проведите её.
Профинансируйте общий слой централизованно. Данные, НСИ, интеграции. У них нет заказчика, значит, заказчиком должны стать вы.
Проведите инвентаризацию данных. Это скучно, долго и незаметно. И без этого всё остальное — театр.
Сначала Lean, потом ИИ. Наведение порядка в процессе даёт основную часть улучшения ещё до всякой технологии. ИИ поверх приведённого в порядок процесса даёт следующий скачок. ИИ поверх хаоса не даёт ничего — кроме отчёта об инновационности.
Обучите людей — всех трёх этажей. И безопасность тоже. Это не расходы. Это условие.
Измеряйте. Базовый уровень «до». Целевой эффект. Порог качества. Критерии Go/No-Go, по которым пилот можно честно признать неудачным.
Пилот, который нельзя честно признать неудачным, не должен запускаться.
P.S.
Меня часто спрашивают: а что, если у нас ничего из этого нет — нам вообще не браться за ИИ?
Браться. Но начинать не с модели.
Точечное решение — это проект. Его можно купить. Встроенное в контур — это изменение системы управления. Его можно только построить.
Технологию можно купить. Данные можно собрать. Способность честно посмотреть на свою готовность — нельзя. С этого и стоит начинать.
Джимшер Челидзе — практик цифровой и AI-трансформации, автор книг «Искусственный интеллект. С неба на землю» и «ИИ. Практическое руководство для внедрения».
