Экспертное интервью | Джимшер Челидзе: «Автоматизация хаоса даёт автоматизированный хаос — только дороже и быстрее»
Продолжаем публикации большого интервью с Джимшером Челидзе — экспертом в области промышленного искусственного интеллекта, членом Комитета по промышленности ФБА ЕАС. В первой части разговора он объяснил, почему гонка фронтирных моделей — не наш путь, а конкурентное преимущество лежит в цеху: в данных, инженерии и доступе к реальным объектам. Во второй части Челидзе рассказал, как меняется роль инженера в эпоху ИИ-ассистентов и почему компании рискуют проиграть поколение экспертизы, выиграв три года производительности.
В третьей, самой объемной, части — о главных барьерах, мешающих промышленным предприятиям перейти от точечных пилотов к системному внедрению ИИ. Почему большинство цифровых проектов проваливаются, кто в этом виноват и что делать с данными, людьми и безопасностью.
Ответы публикуются без купюр.
Джимшер Челидзе — генеральный директор ООО «Челидзе и Партнеры», бизнес-партнёр по цифровому развитию ООО «Центр Горизонтального Бурения», член Комитета по промышленности ФБА ЕАС. Автор статей по философии технологий и пяти книг о цифровой трансформации, создатель двух ИИ-продуктов. Имеет практический опыт работы с «Газпром нефть», ЛУКОЙЛ, Минэнерго России, «Газпром бурение» и другими промышленными компаниями РФ, Казахстана и Китая.
Вы говорите, что начинать надо с процессов, а не с технологий, и что «многим цифровизацией заниматься противопоказано». Что мешает промышленным предприятиям перейти от точечных ИИ-решений к системам, встроенным в производственный контур?
Сначала уточню формулировку — она звучит резко, но за ней нет высокомерия.
Смысл простой: автоматизация хаоса даёт автоматизированный хаос — только дороже и быстрее. Если процесс не описан, не измерен и не стандартизован, ИИ не «наведёт порядок». Он зафиксирует беспорядок в коде и придаст ему легитимность цифры — а это хуже, чем беспорядок, потому что с ним теперь никто не спорит.
И дороже провала — только такой провал, после которого в компании перестают пробовать. Одна неудачная затея с ИИ на сто миллионов закрывает тему для совета директоров на пять лет вперёд.
Цифры тут упрямые: по разным оценкам, от 70 до 84% проектов внедрения цифровых технологий либо проваливаются, либо проблемные — срывают сроки, превышают бюджет, дают эффект в одном-двух процессах и повышают текучку. Я разбирал причины много лет и пришёл к тому, что почти всё сводится к небольшому числу типовых причин. И ни одна из них не техническая.
Здесь стоит оговориться про знаменатель. По более широким оценкам McKinsey и MIT, до 95% инвестиций в ИИ не дают ожидаемого эффекта, а около трёх четвертей пилотов не доходят до промышленной эксплуатации; 70–84% — это уже доля прямо провальных и проблемных. Оценки считают разное, но вывод один: до результата доходит меньшинство, и почти всегда по нетехническим причинам.
Корневая причина: нет стратегии — а значит, нет и портфеля
У подавляющего большинства компаний нет качественной стратегии цифровизации — той, поверх которой только и можно внедрять ИИ. Есть презентация с технологиями. Есть перечень инициатив. Стратегии нет.
Стратегия — это не документ, это конструкция. В ней должно быть четыре вещи.
Первое — разбор самого бизнеса. Каковы приоритеты, где ограничения системы, где реальное узкое место, которое сдерживает деньги. Не «где нам интересно применить ИИ», а «где у нас болит и сколько это стоит». Без этого любой перечень инициатив — список хотелок подразделений, отсортированный по красноречию их руководителей.
Второе — портфель с управлением взаимосвязями. Здесь горит больше всего денег, и об этом почти не говорят.
Проекты в цифровизации связаны жёстко. Ассистент технолога не поедет, пока не приведена в порядок конструкторская документация. Предиктивное обслуживание не поедет без нормального справочника оборудования. Сквозная аналитика не поедет без интеграционной шины. Когда портфель собран без карты зависимостей, происходит следующее: проект А стартует, упирается в отсутствие проекта Б, встаёт — а деньги уже освоены, команда занята, сроки идут. И так по десятку инициатив одновременно.
Портфель без управления зависимостями — это не портфель. Это склад незавершённого производства, только очень дорогой. Я держал в работе портфель из нескольких десятков инициатив и могу сказать: доля проектов, заблокированных ожиданием других проектов, — лучший индикатор здоровья портфеля. Если она выше двадцати процентов, портфелем никто не управляет. Им просто владеют.
Третье — связка трёх контуров. Любой ИИ-проект стоит на трёх опорах, и все три должны быть обеспечены отдельными проектами в том же портфеле: технологический контур (инфраструктура, данные, интеграции, безопасность), организационный (процессная зрелость, бережливое производство, управление проектами и сопротивлением) и кадровый (компетенции, цифровая грамотность, мотивация).
Если хотя бы одна опора не обеспечена — проект не взлетит, каким бы хорошим ни был алгоритм. Вот критерий, который я бы предложил любому инвесткомитету: прежде чем утвердить ИИ-инициативу, покажите, какими проектами закрыты все три контура. Если ответа нет — это не проект, это заявка на списание бюджета.
Четвёртое — модель финансирования общего слоя. И здесь корень корня.
Базовый технологический слой — нормативно-справочная информация, качество данных, интеграционная шина, платформа — не имеет заказчика. Его бенефициар — вся компания, то есть никто конкретно. Ни один начальник цеха и ни один директор департамента не отдаст свой бюджет на справочник, эффект от которого получит сосед. Поэтому общий слой не строится никогда, если его не финансировать централизованно — из бюджета трансформации, а не из бюджета подразделения-заказчика.
Что происходит, когда всего этого нет. Каждое подразделение начинает решать свою задачу само. Пять служб покупают пять разных ИИ-инструментов, платят пять раз, и данные между ними не сходятся. На общую технологическую базу ресурсов не остаётся — потому что её никто не заказывал. Синергии нет: эффект каждого проекта запирается внутри одного процесса, а кросс-функциональных эффектов, ради которых всё и затевалось, не возникает.
Это и есть лоскутное внедрение ИИ. И это не следствие глупости — это следствие отсутствия архитектуры. Если наверху нет карты, каждый рисует свою.
Две болезни тех, у кого стратегия всё-таки есть
Болезнь первая: стратегия цифровизации оторвана от стратегии бизнеса.
Самый частый рассинхрон выглядит так. У компании стратегия снижения операционных затрат и удержания позиций — режим защиты. А ИТ-служба в это время занимается инновационными проектами: витрины, цифровые двойники, эксперименты с генеративным ИИ. Работает не то и не туда. Бывает и зеркально: бизнес идёт в рост, в новые рынки и продукты — а ИТ занято оптимизацией серверов.
Цифровая стратегия не самостоятельна. Она производна. Если бизнес в режиме защиты, то и ИИ-повестка должна быть про себестоимость, потери, качество, планирование ремонтов, нормирование — то самое скучное и прибыльное. Если бизнес в режиме нападения — тогда про новые продукты и бизнес-модели. Перепутать эти два режима — значит потратить бюджет на технологически безупречное решение задачи, которая компании сейчас не нужна.
Тест, который занимает пять минут: возьмите три главные цели компании на год и три главных цифровых проекта. Если между ними нельзя провести линию — у вас нет стратегии цифровизации. У вас есть бюджет ИТ.
Отсюда же и перекос в фотогеничные проекты. Когда цифровая повестка не привязана к целям бизнеса, единственным критерием отбора остаётся то, как проект смотрится на совете директоров.
Болезнь вторая: стратегию написали — и не пересматривают.
Нет регулярного ритма: ни отслеживания хода проектов, ни отслеживания рыночной конъюнктуры. Документ утвердили, повесили, вернулись к нему через год при вёрстке бюджета. Два последствия, и оба дорогие.
Первое: ключевые проекты выпадают из поля зрения руководства. Портфель живёт по инерции, статус собирается раз в год, и проблемный проект всплывает тогда, когда спасать уже нечего. Причём выпадают, как правило, именно ключевые — они длинные, сложные и не дают быстрых новостей.
Второе, и для ИИ оно критично: проекты доезжают до финиша вне рынка. Цикл серьёзного промышленного проекта — два-три года. Технологический горизонт в ИИ сегодня — шесть-двенадцать месяцев. Мы рискуем запустить в 2028-м то, что проектировали в 2026-м под архитектуру, которой уже не существует. Я видел это не раз: компания полтора года строит своими силами решение, которое за это время превратилось в готовый продукт за небольшие деньги. Формально проект успешен — сроки, бюджет, ТЗ выполнены. Экономически он бессмыслен. Ответ на вопрос «строить или купить» имеет срок годности.
Ритм, который работает: ежемесячный операционный ревью по активным проектам, ежеквартальный стратегический ревью портфеля с реальным правом закрыть инициативу и передвинуть деньги, ежеквартальный обзор технологической конъюнктуры. И к этому — культурная норма: право убить проект должно быть таким же нормальным, как право его запустить. Если за закрытие инициативы наказывают, никто ничего не закроет, и портфель будет тащить мертвецов до конца бюджетного цикла.
Вы постоянно возвращаетесь к данным. Насколько это реальная проблема для промышленности?
Это не просто реальная проблема. Это условие, без которого всё остальное не имеет смысла.
Работа с данными имеет уровни зрелости. Первый — единая модель данных: политики сбора, критерии качества, владельцы, хранилище. Скучно и незаметно. Второй — управление на основе бизнес-аналитики: единые метрики, понятные всем подразделениям, культура решений на данных. Третий — гипотезы на данных, исследования, поиск новых источников прибыли. Четвёртый — новые продукты и бизнес-модели на данных.
Первые два уровня — это стратегия защиты: снизить риски, ускорить реакцию, повысить качество решений. Третий и четвёртый — стратегия нападения: новая выручка, новые продукты.
А теперь главное. ИИ — это игра третьего и четвёртого уровня. А подавляющее большинство промышленных компаний находятся на первом-втором. Часто — и не на первом.
Прыжок из первого уровня сразу в третий не работает никогда. Патронов не хватит: качественных данных нет, карты местности нет. Вы построите красивую модель на грязных и задублированных данных и получите уверенный, хорошо оформленный неверный ответ.
И здесь я скажу вещь, которая обычно вызывает возражения
За годы практики я не видел ни одной производственной компании, которая провела бы полноценную инвентаризацию своих данных. Ни одной.
Это не фигура речи. Спросите у себя на предприятии четыре вопроса. Есть ли модель данных — понимание, какие данные у нас есть, где они лежат, в каком виде, как связаны между собой? Кто владелец конкретного набора данных — не «отдел отвечает», а фамилия: кто отвечает за то, что в справочнике оборудования один насос записан трижды под разными наименованиями? Каков жизненный цикл данных — где они рождаются, кто их вносит, как они меняются, когда устаревают, кто их удаляет? Какие взаимосвязи между системами — что произойдёт с аналитикой, если завтра изменится справочник в ERP?
В подавляющем большинстве случаев внятного ответа нет ни на один. И это при том, что данные в компании есть — их избыток. Просто никто не знает, что с ними и чего они стоят.
И отдельно — инструменты обеспечения качества данных. Их не просто нет; чаще всего нет самого понимания, что качество данных — это не разовая уборка, а процесс: критерии, регулярная проверка, система управления мастер-данными, обучение тех, кто вносит первичные данные. Именно оператор в цехе и есть источник качества — не специалист по данным.
Без этого ИИ невозможен. Не «затруднён», не «менее эффективен» — невозможен. Вы можете построить сколь угодно продвинутую модель, но в её основе будут недостоверные данные. И вы получите уверенный, аккуратно оформленный неверный ответ — и примете на его основании решение.
И заметьте, откуда это растёт: данные — это общий слой. У него нет заказчика. Поэтому им никто и не занимается.
Что делать. Порядок здесь важнее скорости
● Оцифровать основные бизнес-процессы и провести инвентаризацию данных. Какие данные есть, где лежат, кто их порождает, чего не хватает.
● Назначить владельцев — по фамилиям, на каждый ключевой набор данных и каждый справочник.
● Построить модель данных и описать жизненный цикл: рождение, изменение, устаревание, удаление.
● Задать измеримые критерии качества и организовать регулярную проверку, а не разовую уборку перед аудитом.
● Внедрить систему управления мастер-данными. Это тот самый «скучный» проект, который никогда не попадёт в презентацию для совета директоров и без которого не поедет ни один ИИ.
● Обучить тех, кто вносит первичные данные. Самая недооценённая инвестиция во всей цифровизации.
● Визуализировать шаблоны перед сбором данных. Приём выглядит примитивно, а снимает до 70–80% ошибок ввода — люди ошибаются не потому, что глупы, а потому, что не понимают, что от них хотят.
И только после этого — разговор о моделях. Не раньше.
А что с людьми? Где главное сопротивление?
Барьер людей стоит сразу на трёх этажах, и на каждом он свой.
Этаж первый, топ-менеджмент. В большинстве случаев для первых лиц цифровизация — чёрный ящик. Отсюда три устойчивых искажения.
Первое: ожидание, что придёт волшебник и всё сделает — а вникать, формулировать запрос и меняться самим не придётся. Не придёт. Меняться придётся всем, включая генерального директора и собственника.
Второе: горизонт. Нормальная цифровая трансформация — это 4-10 лет, первые результаты не раньше девяти-двенадцати месяцев. А запрос звучит как «результат за полгода, с гарантиями, и скажите заранее, кого увольнять в случае неудачи». Под такой запрос невозможно спроектировать честный проект — можно только красивую презентацию. При этом важно понимать, что ИИ в отрыве от остальных ИТ-технологий даёт очень ограниченный эффект. Да, вы сможете решать локальные проблемы (распознавание документов, автопротоколы совещаний), но глобально на финансовые показатели это никак не повлияет.
Третье, самое дорогое: фокус на технологии и на «прямом» эффекте внутри одного процесса. Сэкономили тридцать миллионов, сократили время оформления бумаг вдвое. Это важно, но это оптимизация. Реальный эффект живёт в сквозных, кросс-функциональных показателях — а их никто не считает, потому что для этого нужны данные второго уровня, которых нет.
Что делать. Первых лиц — включать в изменения, а не информировать о них. Честно зафиксировать горизонт в уставе программы и признать, что часть инициатив не взлетит. И ввести хотя бы две-три кросс-функциональные метрики: не «сэкономили в цехе», а рентабельность передела, ритм производственного цикла, прибыль на сотрудника. Иначе вы навсегда останетесь в оптимизации и никогда не дойдёте до трансформации.
Этаж второй, средний и технический уровень управления. Здесь провал самый недооценённый. Спросите линейных руководителей, чем проект отличается от продукта. Что такое цикл «планируй — делай — проверяй — корректируй». Какие бывают типы сопротивления персонала и что с ними делать. Какой процент сотрудников примет изменения с радостью, а какой будет в оппозиции до конца.
Картину вы представляете. И вот эти люди — те самые, кто должен внедрять ИИ в цехе.
Что делать. Лечение — не то, о чём обычно думают. Обучать всех и сертифицировать не нужно: это не работает и это дорого. Нужны простые доступные программы и — вместо регламентов — памятки, в которые человек может нырнуть на три минуты и освежить знание. Регламент читают один раз, при приёме на работу. Памяткой пользуются. А еще лучше – инструменты (в том числе программные), которые не дают ошибаться.
Этаж третий, исполнители. Тут начинается самое отрезвляющее.
У меня был проект внедрения системы управления активами, где оперативный персонал не умел печатать на компьютере. Первое, что пришлось делать, — учить набирать текст, чтобы запись о дефекте не вносилась три часа с тридцатью опечатками. В другом проекте мастер на производстве, двадцати семи лет, не знал, как построить таблицу в Excel.
А самый частый запрос в техподдержку при внедрении любой ИТ-системы — 80–90% обращений — это «забыл пароль» и «не могу зарегистрироваться».
На одном комплексном проекте мы протестировали около 2500 пользователей, затронутых изменениями. Восьмистам пятидесяти из них требовалось обучение базовым навыкам работы с компьютером. Провели тридцатидвухчасовую программу — и это стало одним из факторов успеха всего проекта.
Человек не саботирует. Он не умеет. Это другая проблема, и лечится она по-другому.
И отдельно — про тех, кто умеет, но не хочет. Прежде чем ставить диагноз «саботаж», посмотрите на систему мотивации: если эффект от системы не попал в показатели того, кто ею пользуется, человек работает против собственных интересов — и защищается. Мы часто называем саботажем нормальную реакцию человека на кривую систему мотивации.
Барьер роли: CIO — это не CDTO
Отдельная и очень частая ошибка — отдать цифровизацию и внедрение ИИ классическому ИТ.
Классическое ИТ делает надёжные системы. Для CIO важны стабильность, соблюдение бюджетов и регламентов, снижение рисков, оптимизация затрат. У него нет задачи думать о прибыльности бизнеса и разговаривать с внутренним клиентом. Для руководителя цифровой трансформации важно обратное: эффективность бизнеса в целом, поиск новых источников доходности, работа с данными, а не с «железом», сохранение гибкости и принятие риска.
По Адизесу это буквально разные люди: у CIO доминируют функции администрирования и производства — «что надо» и «как надо». У CDTO — предпринимательства и коммуникации: «для кого, кем и когда надо». CIO — это операционный директор. CDTO — директор по развитию.
И вот наблюдение, которое многих обижает, но оно верное: чем выше классические ИТ-компетенции специалиста, тем, как правило, хуже у него с компетенциями для трансформации. Это не недостаток человека. Это несовпадение роли.
Что делать. Есть два рабочих пути. Первый — выделить функцию трансформации отдельно: человек со своей командой, своим бюджетом и своими показателями, работающий на стыке бизнеса и ИТ. Второй — развивать недостающие компетенции внутри ИТ и вводить институт ИТ-бизнес-партнёров: людей, которые сидят внутри бизнес-функции, говорят на её языке и переводят её потребности в требования к системам.
Что не работает никогда — назначить CIO ответственным за цифровую трансформацию, ничего не поменяв ни в его показателях, ни в его команде, и ждать другого результата.
И под всем этим — культура
Если в компании все относятся друг к другу с позиции «мне должны», если ждут, что придёт цифровизатор и всех осчастливит, — там даже самый талантливый цифровизатор выгорит за три-четыре месяца. И вместо клиентоориентированного партнёра станет обычным ИТ-шником, который не хочет никого видеть.
Цифровизация и внедрение ИИ с приемлемыми издержками возможны только тогда, когда бизнес-заказчик вовлечён, заинтересован и владеет базовым управлением проектами. Цифровизация и внедрение ИИ — это про умение договариваться. Иначе внедрены будут даже хорошие инструменты, но пользоваться ими не станут, и через три-шесть месяцев всё отторгнется.
Что делать. Определить тип организационной культуры компании и подразделений и под него подбирать ролевую модель: то, что сработает в цехе, не сработает в НИОКР. Сделать бизнес-заказчика совладельцем проекта, а не получателем: его фамилия в уставе, его показатели, его защита результата на комитете. И честное правило: если бизнес-заказчик не готов вкладывать в проект своё время — проект не запускается. Не потому что мы обиделись. Потому что он всё равно провалится, просто позже и дороже.
Отдельный вопрос — информационная безопасность. Насколько она мешает внедрению ИИ?
Это, пожалуй, самый недооценённый структурный барьер — и он ломает не процесс, а экономику.
Типичная позиция службы безопасности на промышленном предприятии: либо запретить, либо завести всё во внутренний контур. Обезличивание данных её, как правило, тоже не устраивает — «а вдруг восстановят». Формально возразить нечего.
Но посмотрите, что происходит с деньгами. Требование полностью изолированного контура означает: свои серверы, свои ускорители, своя инфраструктура, своя команда сопровождения, свои обновления, своя поддержка. Проект, который в облачном исполнении стоил бы 1 миллион, превращается в проект на 20-30 миллионов. И это не разовые затраты — это постоянные.
Экономика ИИ-проекта ломается не на модели. Она ломается на периметре.
В итоге бизнес-кейс не сходится. Инвесткомитет смотрит на цифры и — совершенно правильно — отказывает. Внедряются только отдельные инициативы, те, у кого хватило политического веса продавить бюджет. Всё остальное умирает на стадии согласования.
И вот здесь главный ущерб, который никто не считает: компания не набирает насмотренность. Не появляется опыта, не появляется компетенций, не появляется людей, которые понимают, как это вообще работает. Через три года такая компания будет вести переговоры с поставщиком, не понимая, что ей продают и сколько это должно стоить. Насмотренность нельзя купить. Её можно только набрать — и только на своих проектах.
Три причины, и ни одна не про злой умысел
Первая: служба безопасности сама не понимает, что такое ИИ.
Это надо называть вещами своими именами. Безопасник, который не понимает разницы между отправкой данных в публичный интерфейс и локальным исполнением модели на своём железе, не знает, что происходит с данными при обезличивании и остаются ли они в модели после запроса, — не может оценить риск. У него физически нет инструмента для оценки. А когда риск оценить нельзя, остаётся ровно одно действие. Запретить.
Запрет не требует компетенции. Разрешение при контролируемом риске — требует. Поэтому запрещают. Это не злая воля, это единственный доступный ход из той позиции, в которой человек находится.
Отсюда неприятный вывод для руководителя: обучение службы безопасности — такая же часть ИИ-проекта, как закупка серверов. И оно дешевле любого сервера. Если вы обучили бизнес и не обучили безопасность, вы построили проект, который будет остановлен на согласовании.
Вторая: в компании нет понимания, что вообще является тайной — и как долго.
Спросите на предприятии: какие данные составляют коммерческую тайну? Ответ, скорее всего, будет «все». А теперь второй вопрос, который почти никто не задаёт: как долго они ею остаются?
Чертёж узла, снятого с производства десять лет назад. Заявка на ремонт трёхлетней давности. Сводка выработки за позапрошлый квартал. Всё это защищается так же, как актуальная себестоимость и текущий портфель заказов — то есть вечно и одинаково.
Тайна имеет срок годности. Конкурентную ценность информация теряет иногда за месяцы, а порой и за дни. И если у грифа нет срока, вы защищаете всё вечно. А защищать всё вечно — значит не защищать ничего: ресурс размазывается по массиву, в котором 95% давно не представляет ценности ни для кого.
Классификация данных — это не бюрократия. Это то, что превращает разговор с безопасностью из идеологического в предметный. Пока классификации нет, безопасник обязан считать критичным всё. И он прав.
Третья: диалога между бизнесом, ИТ и безопасностью не существует.
Три службы говорят на трёх разных языках. Бизнес не формулирует, какую ценность он теряет от запрета. ИТ не переводит техническое решение на язык риска. Безопасность не слышит ни тех, ни других — да её никто и не спрашивает до последнего момента. Они встречаются один раз — на приёмке. А на приёмке у безопасности остаётся один инструмент. Переделывать поздно, и она это знает.
И под всем этим — асимметрия стимулов. За инцидент безопасника накажут. За отсутствие развития — не накажут никогда. Пока стимулы устроены так, он будет запрещать и будет действовать рационально в той системе мотивации, которую вы ему построили.
Что с этим делать — пять вещей, и все управленческие
● Обучить службу безопасности. Не «провести встречу», а именно обучить: что такое модель, где физически оказываются данные при разных архитектурах, что даёт и чего не даёт обезличивание. Безопасник, понимающий технологию, начинает торговаться о конфигурации, а не запрещать целиком.
● Провести классификацию данных — в двух измерениях. Не только «насколько чувствительно», но и «как долго». Гриф без срока — это гриф навсегда.
● Изменить постановку задачи. Безопасность должна отвечать не за «запретить», а за «сделать возможным при приемлемом уровне риска». Пока в её показателях нет ни одного пункта про развитие, она будет запрещать — и правильно сделает.
● Ввести правило альтернативы. Любой запрет должен сопровождаться работающей альтернативой. «Нельзя» без «а можно вот так» — это не работа службы безопасности. Это уклонение от неё.
● Создать трёхсторонний формат. Не согласование постфактум, а совместное проектирование: бизнес, ИТ и безопасность в одной комнате с первого дня. И дифференцированный контур как результат: нечувствительные задачи — во внешние модели, чувствительные — в закрытый периметр. Большая часть корпоративных задач, если честно посмотреть, нечувствительна.
И здесь важно не перевернуть маятник в другую сторону
Я не за то, чтобы безопасность убрать. Потому что у производственного контура принципиально иная цена ошибки. Ассистент, который в восьми случаях из десяти предлагает верный техпроцесс, — отличный инструмент. Модель, которая в восьми случаях из десяти верно управляет исполнительным механизмом, — это авария.
Отсюда правило: чем ближе к контуру управления, тем уже и тем верифицируемее должна быть модель, и тем обязательнее сценарий отказа и человек в петле принятия решения. Мы не будем ставить большую языковую модель в контур АСУ ТП. И не надо. «Встроенность в контур» означает не «ИИ управляет», а «ИИ встроен в процесс принятия решения человеком, и это решение прослеживается».