Что не нужно знать топ менеджеру, что бы провалить внедрение AI | ИИ

ИИ не внедряют. Его встраивают в дисциплину компании

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

После семинара легко было бы написать привычный текст про ChatGPT, Claude, Gemini, RAG, GraphRAG, агентов, рынок труда и кодогенерацию. Все эти темы действительно прозвучали. Но главная мысль оказалась не технической.

ИИ ломает не профессию программиста и не профессию преподавателя. Он ломает привычную организацию труда. И именно там начинается настоящая сложность.

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

Поэтому главная проблема внедрения ИИ — не про модели и не про инженеров. Она про доверие, узкие места и дисциплину процессов.

Технология здесь, как ни странно, последнее, о чём стоит беспокоиться.

ИИ не заменяет людей. Он перераспределяет рынок в пользу адаптивных

Хороший пример — преподаватель английского языка.

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

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

Но рынок редко убивает профессию целиком. Чаще он меняет структуру ценности внутри профессии.

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

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

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

То же самое происходит в разработке.

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

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

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

Код перестаёт быть главным дефицитом

На рынке труда уже видно: простая способность «писать код» дешевеет.

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

Ценность смещается выше по цепочке:

• понять бизнес-задачу;

• сформулировать проблему;

• выбрать архитектуру;

• описать ограничения;

• проверить результат;

• встроить решение в существующие процессы;

• довести продукт до пользователя;

• измерить эффект.

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

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

Но у этого есть обратная сторона: кода и «агентов» на рынке становится слишком много. Возникает кризис перепроизводства программных продуктов. Написать стало проще. Продать, внедрить и доказать пользу — нет.

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

LLM — это не магия и не источник истины

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

В бытовом объяснении LLM можно сравнить с очень развитой системой предсказания следующего фрагмента текста. Технически это, конечно, не просто T9. Современные модели основаны на сложных нейросетевых архитектурах, работают с токенами, контекстом, embeddings, механизмами внимания, инструкциями и инструментами.

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

Если контекст плохой, ответ может быть красивым, уверенным и неправильным.

Отсюда простое правило: нельзя спрашивать ИИ так, будто он обязан знать правду. Нужно строить вокруг него процесс проверки.

Особенно это важно для цифр. Чистый текстовый ответ модели не должен быть механизмом финансового расчёта. Для налогов, себестоимости, баланса, KPI, сверок и отчётов нужны Excel, SQL, Python, BI-системы, формулы, тесты и трассировка до исходных данных.

ИИ может помочь написать формулу, SQL-запрос или Python-скрипт. Но сам расчёт должен выполняться проверяемым инструментом.

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

От чата к RAG, GraphRAG и операционному слою

Личное использование ИИ обычно начинается с чата. Пользователь задаёт вопрос, получает ответ и радуется магии.

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

Дальше появляется RAG — Retrieval-Augmented Generation. Смысл простой: документы режутся на фрагменты, превращаются в векторные представления, сохраняются в индексе, а при вопросе система подтягивает наиболее релевантные куски в контекст модели.

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

Следующий шаг — GraphRAG. Здесь мы начинаем извлекать не только куски текста, но и сущности со связями: документы, проекты, клиентов, договоры, решения, показатели, подразделения, риски, ответственных.

Так появляется граф знаний. Уже можно спрашивать не только «что написано в документе», но и «какие решения связаны с этим проектом», «какие риски повторяются в протоколах», «какие подразделения затронуты инициативой».

А дальше возникает ещё более важная идея — онтология или операционный слой. Это не просто база документов и не просто граф. Это описание реальных объектов бизнеса и действий над ними.

Клиент. Договор. Заказ. Продукт. Склад. Завод. Бюджет. KPI. Риск. Ответственный. Решение. Событие.

Когда ИИ работает поверх такой модели, он перестаёт быть просто генератором текста. Он становится интерфейсом к управляемой операционной системе компании.

Именно в этом смысле интересны подходы класса Palantir Ontology: ценность не в том, что «там есть граф», а в том, что данные, модели, процессы и действия связаны с реальными бизнес-объектами.

Главная проблема внедрения — доверие

Теперь к самому важному.

В корпоративной среде доверие к ИИ рушится с одного тупого ответа.

Пока человек сам играет с ChatGPT, он терпим к ошибкам. Он понимает, что это личный эксперимент. Ошибся — переформулировал вопрос, проверил, пошёл дальше.

В компании всё иначе. Если внедрённый ИИ один раз уверенно выдаёт бред в рабочем процессе, сотрудники делают очень быстрый вывод: «Этой штуке доверять нельзя».

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

Административно загнать людей в ИИ-инструмент почти невозможно. Можно заставить открыть интерфейс. Нельзя заставить доверять результату.

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

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

Источник под каждой цифрой

Лучший способ поднять доверие — показывать источник.

Не абстрактную ссылку «по данным компании», а конкретный документ, таблицу, строку, версию, дату, владельца, правило расчёта.

Если ИИ говорит: «Плановая сумма — 100 рублей», пользователь должен иметь возможность провалиться в источник и увидеть, откуда взялись эти 100 рублей.

Если ИИ отвечает на вопрос по договору, нужно показать пункт договора.

Если ИИ делает вывод по протоколам встреч, нужно показать фрагменты протоколов.

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

Это кажется мелочью. Но именно это решает adoption.

Сотрудник не обязан верить модели. Он должен иметь возможность быстро проверить её. Чем проще проверка, тем выше доверие. Чем дальше ответ от источника, тем быстрее он превращается в «очередную фантазию нейросети».

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

Закон Голдратта: точечное внедрение прибыли не приносит

Вторая большая проблема — узкие места.

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

Но компания зарабатывает деньги не отдельными задачами, а цепочками процессов.

Если ускорить один участок, узкое место просто переедет дальше по трубе.

Аналитика стала быстрее готовить отчёты, но согласование всё равно занимает две недели.

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

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

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

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

Поэтому точечное внедрение ИИ часто не видно в деньгах. Оно даёт локальный комфорт, но не меняет экономику процесса.

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

Синхронно перестроить всю компанию под ИИ почти никто не готов. Поэтому после первых красивых пилотов часто наступает разочарование: «вроде все попробовали, а прибыли нет».

Проблема не в модели. Проблема в том, что оптимизировали не систему, а фрагмент.

Не воюй со средой пользователя

Ещё одна частая ошибка — попытка построить «интерфейс получше».

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

Он работает в CRM. Или в Excel. Или в корпоративном мессенджере. Или в Jira. Или в почте. Или уже в своём Claude/ChatGPT-процессе. Или в IDE.

Каждое переключение окна — это налог. Каждая новая вкладка — сопротивление. Каждый отдельный интерфейс — риск, что автоматизация не станет привычкой.

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

Если продавец живёт в CRM, агент должен помогать в CRM.

Если аналитик живёт в Excel или BI, подсказки и источники должны быть рядом с таблицами и отчётами.

Если разработчик живёт в IDE и Git, агент должен работать с кодовой базой, тестами и pull request.

Если руководитель живёт в календаре, почте и протоколах встреч, ИИ должен помогать с повесткой, решениями, задачами и follow-up именно там.

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

Готовность к ИИ не зависит от возраста

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

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

И можно встретить человека в 22, который использует GPT как «Google 2.0»: задаёт короткий вопрос, получает поверхностный ответ и идёт дальше без проверки.

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

Поэтому при внедрении не стоит делить людей по возрасту. Лучше смотреть на поведение:

• кто умеет формулировать задачи;

• кто проверяет результат;

• кто понимает свои процессы;

• кто готов делиться знаниями;

• кто видит ограничения инструмента;

• кто способен стать внутренним проводником изменений.

Именно эти люди станут ядром реального adoption.

ИИ — это операционный слой, а не магия

Самый опасный миф: «сейчас купим ИИ, и он наведёт порядок».

Не наведёт.

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

ИИ усиливает существующую систему. Хорошую — ускоряет. Плохую — делает более шумной.

Поэтому внедрение ИИ на самом деле требует довольно скучных вещей:

• вести доски задач;

• фиксировать решения;

• писать протоколы встреч;

• хранить документы с версиями;

• определять источники истины;

• назначать владельцев данных;

• описывать процессы;

• заводить критерии качества;

• проверять результаты;

• логировать действия агентов.

Это не выглядит как футуризм. Это выглядит как операционная дисциплина.

Но именно она превращает ИИ из игрушки в рабочий инструмент.

Что делать компании, которая хочет внедрять ИИ всерьёз

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

1. Начинайте не с технологии, а с цепочки процесса. Где реально застревают деньги, время, качество или решения?

2. Не оптимизируйте один участок в изоляции. Сразу смотрите, куда переедет узкое место после ускорения.

3. Для каждого сценария определите источник истины. Откуда агент берёт документы, цифры, правила и статусы?

4. Показывайте источник под каждым важным ответом. Особенно под цифрами, договорами, регламентами и управленческими выводами.

5. Не просите LLM считать «на доверии». Пусть она помогает писать код, SQL или формулы, но расчёт должен выполняться проверяемым инструментом.

6. Встраивайтесь в среду пользователя. Не плодите отдельные интерфейсы без необходимости.

7. Измеряйте не факт запуска пилота, а реальное использование: кто возвращается, какие задачи решает, где проверяет источники, где отказывается пользоваться.

8. Учите не «молодых» или «возрастных», а тех, кто реально готов менять процесс и брать ответственность за результат.

9. Стройте agent harness: правила, ограничения, роли, инструменты, логирование, проверки, маршрутизацию, контроль качества.

10. Относитесь к ИИ как к части операционной системы компании, а не как к волшебной кнопке.

В итоге

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

Но он всё ещё недостаточно силён, чтобы компенсировать управленческий хаос.

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

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

Не отдельным чатиком.

Не модной надстройкой.

А способом быстрее превращать знания компании в действия.

Подготовлено на основании семинара , который читается в рамках внедрения Slider-Ai.ru