Типовые ошибки

Большинство AI-инициатив в компаниях не проваливаются громко. Они затухают.

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

А потом через два-три месяца становится непонятно, что изменилось. Активность была. Эффект не закрепился. Причина обычно не в том, что модель плохая.

И не в том, что сотрудники “не готовы”. Чаще причина в том, что компания пытается внедрить ИИ старыми управленческими привычками: как еще один инструмент, еще одну подписку, еще один проект автоматизации, еще одну инициативу сверху. AI- Native переход требует другой дисциплины.

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

Ошибка 1. Начать с модели, а не с работы

Самая популярная ошибка звучит так:

Давайте выберем лучшую модель.

И начинается сравнение: ChatGPT, Claude, Gemini, DeepSeek, Qwen, Llama, Mistral, закрытый контур, облако, скорость, цена, качество ответов, поддержка русского языка, длина контекста. Все это

важно. Но не в начале. В начале нужно понять, какую работу компания хочет изменить.

Модель сама по себе не создает операционный эффект. Она создает способность: понимать текст, генерировать, искать, сопоставлять, рассуждать, вызывать инструменты. Эту способность еще нужно встроить в роль, процесс, source of truth, права, skills и правила качества.

Симптом ошибки:

много разговоров про модели;

мало описанных сценариев;

сотрудники спорят, какой инструмент лучше;

нет владельцев процессов;

нет исходных замеров;

нет понятия, где должен появиться эффект.

Последствие:

Компания может потратить месяц на выбор инструмента и не приблизиться к изменению работы.

Что делать иначе:

Сначала выбрать один рабочий контур.

Например:

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

проверка договора;

проектный статус;

обработка входящей заявки;

постановка инженерной задачи;

подготовка материалов к встрече.

И только потом выбирать, какая модель, инструмент и архитектура подходят для этого контура.

Правильный вопрос:

Какую повторяющуюся работу мы хотим изменить первой?

Ошибка 2. Раздать подписки и назвать это внедрением

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

Другой делает summary. Третий пробует код. Четвертый боится вставлять данные. Пятый разочаровался после первой ошибки.

Шестой стал сильнее, но его опыт остался личным. Через месяц руководитель видит хаотичную картину: кто-то пользуется, кто-то нет, где эффект — непонятно.

Симптом ошибки:

есть доступы, но нет утвержденных skills;

нет общего source of truth;

нет правил безопасности;

нет качества результата;

лучшие практики не переносятся между сотрудниками;

успех зависит от энтузиастов.

Последствие:

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

Что делать иначе:

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

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

роль + ассистент + skill + source of truth + правила качества + владелец результата

Тогда инструмент входит в работу, а не живет рядом.

Ошибка 3. Обучать промптам вместо проектирования skills

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

Другой придумал удачный запрос для проверки договора.

Третий умеет объяснять задачу агенту разработки. Но если это не оформлено как skill, знание остается в голове человека. Компания не может его масштабировать, проверять, улучшать и передавать

новым сотрудникам.

Симптом ошибки:

люди делятся “классными промптами”;

нет версий skills;

нет владельцев;

нет правил качества;

один и тот же процесс каждый делает по-своему;

после ухода сильного сотрудника практика исчезает.

Последствие:

Компания не накапливает операционное знание.

Что делать иначе:

Каждую удачную практику переводить в skill:

цель;

входы;

source of truth;

шаги;

ограничения;

правила остановки;

формат результата;

проверка качества;

владелец.

Промпт помогает человеку. Skill помогает компании.

Ошибка 4. Подключить слишком много систем сразу

Когда появляется MCP-шлюз и возможность подключать корпоративные системы, возникает соблазн сразу дать ассистенту доступ ко всему:

CRM;

трекер;

база знаний;

почта;

календарь;

файловое хранилище;

Git-репозиторий;

ERP;

телефония;

BI;

документооборот.

Архитектурно это выглядит мощно. Практически — часто ломает

первый этап. Чем больше систем, тем больше прав, ошибок данных, несовпадений, интеграционных проблем, вопросов безопасности и спорных ожиданий.

Симптом ошибки:

команда больше настраивает интеграции, чем меняет работу;

пилот ждет доступы неделями;

непонятно, какие данные действительно нужны;

каждый источник дает свою версию правды;

безопасность блокирует запуск.

Последствие:

Пилот превращается в тяжелый ИТ-проект.

Что делать иначе:

Начать с минимального набора источников. Для первого контура достаточно 1-3 source of truth.

Например:

для КП: CRM, база шаблонов, заметки встречи;

для проектного статуса: трекер, проектная страница, журнал решений;

для разработки: задача, репозиторий, ADR.

Остальные системы подключать по мере доказанного эффекта.

Ошибка 5. Дать ассистенту лишние права

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

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

Симптом ошибки:

общий токен на несколько пользователей;

непонятно, от чьего имени агент получил данные;

права агента шире прав сотрудника;

нет разделения чтения и записи;

нет журналирования;

нет правил остановки.

Последствие:

Компания получает риск утечки, ошибочного действия и потери доверия.

Что делать иначе:

Строить доступ через управляемый слой:

пользовательская авторизация;

роли;

scopes;

проверка прав на ресурс;

аудит вызовов;

разделение Read, Prepare, Review, Act;

отдельные подтверждения для опасных действий.

Если агенту нужен доступ, он должен быть объяснимым.

Ошибка 6. Не назначить владельца роли

AI-Native контур не может быть ничьим. Если ассистент помогает продавцу, владельцем должен быть руководитель продаж или владелец коммерческого процесса. Если ассистент помогает PM, нужен владелец проектного процесса. Если агент помогает

разработке, нужен технический владелец.

Если ассистент работает с договорами, нужен владелец договорного процесса. Без владельца никто не отвечает за качество skill, source of truth, обновление правил и принятие результата.

Симптом ошибки:

“это общий ассистент для всех”;

непонятно, кто утверждает skill;

никто не обновляет шаблоны;

ошибки повторяются;

пользователи спорят о правилах;

результат ассистента не становится стандартом.

Последствие:

Контур остается экспериментом, а не частью операционной модели.

Что делать иначе:

Назначать владельца на каждый контур.

Владелец отвечает за:

цель;

пользователей;

skills;

правила качества;

исходный замер;

обратную связь;

решение о масштабировании.

Техническая команда может помочь. Но владение процессом

должно быть у бизнеса.

Ошибка 7. Не собрать проверку качества

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

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

Симптом ошибки:

ассистент пишет, но никто системно не проверяет;

нет чек-листа качества;

нет тестовых сценариев;

нет review-режима;

ошибки исправляются вручную, но skill не улучшается;

руководитель видит красивые результаты, но не знает их надежности.

Последствие:

Компания ускоряет выпуск ошибок.

Что делать иначе:

У каждого важного skill должны быть правила качества:

что проверить;

какие поля обязательны;

какие источники сверить;

где нужны ссылки;

какие риски вывести отдельно;

где остановиться;

кто принимает результат.

Для сложных контуров нужны evals — регулярная проверка skills

на тестовых сценариях.

Ошибка 8. Перепутать использование с эффектом

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

Например:

запросов стало много, а КП готовятся так же долго;

документов стало больше, а качество не выросло;

сотрудники делают красивые summary, но решения не принимаются быстрее;

агент пишет код, но ревью стало тяжелее;

ассистент отвечает клиентам, но следующий шаг все равно теряется.

Симптом ошибки:

измеряется количество запросов;

нет исходного замера;

нет метрик скорости и качества;

нет сравнения “было / стало”;

эффект описывается словами “вроде помогает”.

Последствие:

Руководитель не может принять решение о масштабировании.

Что делать иначе:

Мерить процесс:

время;

качество;

возвраты;

потери;

пропускную способность;

деньги;

управляемость.

Использование — только входной показатель. Эффект — изменение работы.

Ошибка 9. Игнорировать сдвиг мышления

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

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

Это новая рабочая поза.

Симптом ошибки:

людям дали инструмент, но не объяснили новую роль;

сотрудники боятся ошибок ассистента;

не понимают, кто отвечает за результат;

продолжают делать работу вручную;

используют ИИ только для простых текстов;

скрывают неудобства и ошибки.

Последствие:

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

Что делать иначе:

Помогать людям пройти через сдвиг мышления:

объяснить, что ассистент усиливает роль, а не отменяет ответственность;

показать реальные сценарии;

дать безопасные первые skills;

обсуждать ошибки без наказания;

учить не только писать запросы, но и проверять результат;

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

Ошибка 10. Считать, что старые роли сохранятся без изменения

AI-Native переход меняет роли. Если компания пытается оставить все должности и процессы прежними, а сверху добавить ассистентов, эффект будет ограниченным. Некоторые старые функции сжимаются. Ручной перенос информации, механическая подготовка документов, поиск данных, первичная сверка, типовые черновики — все это постепенно уходит к ассистентам и агентам.

Сильные сотрудники начинают делать другую работу:

проектировать skills;

управлять ассистентами;

проверять качество;

владеть source of truth;

собирать контуры;

принимать решения на основе более полной картины.

Симптом ошибки:

роли описаны как раньше;

никто не отвечает за skills;

никто не отвечает за память;

никто не владеет агентным контуром;

сотрудники воспринимают ИИ как дополнительную нагрузку;

руководитель ждет эффекта без изменения ответственности.

Последствие:

Компания получает инструменты нового поколения, встроенные в старое разделение труда.

Что делать иначе:

Пересматривать роли.

В каждой усиленной роли должно быть понятно:

что теперь делает человек;

что делает ассистент;

какие skills используются;

где source of truth;

кто проверяет качество;

где человек принимает решение;

какие новые компетенции нужны.

Ошибка 11. Не закрепить source of truth

Ассистент без source of truth начинает угадывать. Он может отвечать уверенно, но не знать, какая версия документа актуальна, какой клиентский статус правильный, какой шаблон утвержден, какое решение принято последним.

Симптом ошибки:

ассистент опирается на загруженные вручную файлы;

сотрудники каждый раз пересказывают контекст;

разные люди дают разные версии правды;

документы лежат в нескольких местах;

нет владельцев источников;

память спорит с официальными данными.

Последствие:

Компания не может доверять результату.

Что делать иначе:

Для каждого контура составить карту source of truth:

где живут клиенты;

где живут проекты;

где живут задачи;

где живут документы;

где живут решения;

где живут шаблоны;

кто владелец каждого источника;

как ассистент получает доступ.

Если source of truth не готов, это не повод остановиться. Это повод ограничить сценарий и сделать источник частью плана внедрения.

Ошибка 12. Не думать о безопасности до пилота

Иногда безопасность откладывают:

Сначала попробуем, потом разберемся.

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

Симптом ошибки:

сотрудники сами решают, что можно отправлять в модель;

нет классификации данных;

нет обезличивания;

токены лежат в локальных файлах;

ассистент получает сырые данные без проверки;

нет аудита.

Последствие:

Даже успешный пилот может быть остановлен из-за риска.

Что делать иначе:

С самого начала определить:

какие данные можно использовать;

какие нужно обезличивать;

какие нельзя отправлять во внешний сервис;

где нужен закрытый контур;

кто имеет доступ;

что журналируется;

какие действия запрещены.

Безопасность не должна душить внедрение. Но она должна быть частью архитектуры.

Ошибка 13. Делать пилот без ритма улучшения

Первый skill почти никогда не идеален. Первый source of truth часто неполный. Первые ответы ассистента будут ошибаться. Это нормально.

Проблема начинается, когда компания не улучшает контур.

Симптом ошибки:

ошибки обсуждаются в чатах, но не попадают в backlog;

skills не обновляются;

source of truth не чинится;

пользователи повторяют одни и те же жалобы;

нет еженедельного обзора;

пилот оценивается только в конце.

Последствие:

Команда делает вывод: “ИИ не работает”, хотя на самом деле не работал цикл улучшения.

Что делать иначе:

Ввести короткий ритм:

еженедельный обзор;

список ошибок;

улучшения skills;

обновление источников;

проверка метрик;

решение о следующей неделе.

AI-Native внедрение — это не установка инструмента. Это цикл

обучения компании.

Ошибка 14. Строить все вокруг одного энтузиаста

Во многих компаниях есть человек, который первым “подружился” с ИИ. Он делает быстро, красиво, уверенно. Руководитель радуется: “Вот оно”. Но если весь успех держится на одном человеке, компания еще ничего не внедрила.

Симптом ошибки:

один сотрудник делает 80% AI-активности;

его промпты не оформлены как skills;

никто не может повторить его результат;

он становится внутренним “магом”;

остальные ждут, что он поможет.

Последствие:

Компания получает новый узкий ресурс вместо масштабируемой способности.

Что делать иначе:

Использовать энтузиаста как источник практик, но переводить его опыт в систему:

оформлять skills;

обучать роль;

создавать шаблоны;

фиксировать quality review;

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

включать обычных пользователей.

Сильный сотрудник должен стать не единственным исполнителем, а создателем контура.

Ошибка 15. Ждать идеальной платформы

Обратная ошибка — не начинать, пока не будет идеальной архитектуры. Нужен MCP-шлюз, единая авторизация, память, права, аудит, закрытый контур, все интеграции, админка, мониторинг, реестр skills, evals, дашборды. Все это действительно

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

Симптом ошибки:

много архитектурных обсуждений;

нет реальных пользователей;

нет рабочих skills;

нет исходных замеров;

команда строит платформу без проверки сценариев;

бизнес теряет интерес.

Последствие:

AI-Native программа превращается в долгий инфраструктурный проект.

Что делать иначе:

Двигаться двумя слоями:

Быстрый пилот в безопасном коридоре.
Постепенная сборка платформы под подтвержденные контуры.

Архитектура должна расти из работы, а не заменять ее.

Диагностика: вы на правильном пути?

Задайте десять вопросов:

У нас выбран конкретный рабочий контур?
Есть владелец этого контура?
Описана усиленная роль?
Есть хотя бы 2-4 рабочих skills?
Понятен source of truth?
Есть правила прав и безопасности?
Есть исходный замер?
Есть метрики скорости и качества?
Есть еженедельный цикл улучшения?
Понятно, кто владеет результатом?

Если на большинство вопросов ответ “нет”, вы, скорее всего, не внедряете AI-Native модель. Вы экспериментируете с ИИ- инструментами. Эксперименты полезны. Но их нужно честно называть экспериментами.

Что сделать руководителю

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

Спросите команду:

Мы начали с работы или с модели?
У нас есть skills или только промпты?
Где source of truth?
Кто владелец роли и результата?
Какие права есть у ассистента?
Что он может делать без подтверждения?
Как мы проверяем качество?
Как измеряем эффект?
Как обновляем skills?
Что должно измениться в ролях?

После этого выберите одну ошибку, которая сильнее всего тормозит движение, и исправьте ее в ближайшие две недели. Не все сразу. Одну. AI-Native переход строится не героическими рывками, а последовательным устранением слабых мест.

Вопросы для руководителя

Какая ошибка из этой главы больше всего похожа на вашу ситуацию?

Вы строите новый способ работы или просто раздаете инструменты?

Есть ли у вас контуры, которые зависят от одного энтузиаста?

Где у вас нет source of truth?

Какие skills существуют только как личные промпты сотрудников?

Какие права ассистента сейчас слишком широкие?

Что вы измеряете: использование или эффект?

Какие роли уже должны измениться, но вы пока делаете вид,

что они прежние?

Есть ли у внедрения еженедельный ритм улучшения?

Главная мысль главы

AI-Native внедрение срывается не потому, что ИИ “не умеет”. Чаще оно срывается потому, что компания не меняет работу вокруг ИИ. Начинают с модели, раздают подписки, обучают промптам вместо skills, подключают слишком много систем, дают лишние права, не назначают владельцев, не измеряют эффект, забывают про source of truth и ждут, что старые роли останутся прежними.

Зрелый подход проще и требовательнее одновременно: начать с конкретной работы, собрать контур, назначить владельца, описать skills, закрепить source of truth, защитить данные, измерить эффект и каждую неделю улучшать систему. Так ИИ перестает

быть инициативой энтузиастов и становится способом развития компании.