Главная ошибка: внедрять инструмент вместо нового способа работы

Когда в компании появляется новая сильная технология, первый управленческий импульс почти всегда один и тот же: купить

инструмент и раздать доступ.

Так было с корпоративной почтой. Так было с мессенджерами. Так было с CRM, таск-трекерами, базами знаний, BI-системами и облачными хранилищами. Иногда это работало. Инструмент был

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

С ИИ этот подход дает сбой.

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

готовить черновики, сравнивать варианты, писать инструкции, находить ошибки и предлагать следующий шаг.

Именно поэтому ее легко недооценить.

Руководитель смотрит на нее как на очередной инструмент: “Дадим людям доступ, пусть пользуются”.

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

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

Почему подписка не меняет компанию

Представим компанию, которая купила сотрудникам доступ к сильной модели. Формально шаг сделан. Люди могут пользоваться ИИ. Руководитель может сказать, что компания начала внедрение.

Но что происходит на практике?

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

не понимает, где это применить. Шестой боится загрузить лишний документ. Седьмой получает плохой ответ и делает вывод, что “это игрушка”.

Каждый действует по-своему.

У компании нет общего понимания:

какие задачи мы хотим ускорить;

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

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

какие результаты требуют проверки;

кто отвечает за качество;

где хранится удачная практика;

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

Подписка дала доступ к возможности. Но возможность еще не стала способом работы.

Это похоже на ситуацию, где компания купила всем сотрудникам профессиональный инструмент, но не изменила процесс, не

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

Через некоторое время сильные сотрудники станут еще сильнее. Слабые почти не изменятся. Разрыв внутри команды увеличится.

Руководитель увидит всплеск активности, но не получит управляемого эффекта.

Почему обучение промптам — только первый шаг

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

Это полезно. Человек должен научиться формулировать задачу, давать контекст, просить структуру ответа, уточнять ограничения и проверять результат. Без этого ИИ действительно кажется случайным собеседником.

Но обучение промптам решает только часть проблемы.

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

Например, менеджера научили писать хороший запрос:

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

Запрос может быть хорошим. Но где лежит история клиента? Можно ли загружать ее в модель? Какие поля являются достоверными? Какой формат результата нужен руководителю?

Нужно ли сохранить вывод в CRM? Кто проверит, что предложенный следующий шаг не противоречит коммерческой стратегии? Что делать, если модель нашла риск, которого нет в регламенте?

Промпт не отвечает на эти вопросы.

Именно поэтому промпт должен быть частью skill, а не заменой skill.

Skill описывает не только то, что сказать модели, но и весь рабочий

контур:

какую задачу решаем;

кто владелец роли;

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

где source of truth;

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

как выглядит хороший результат;

что проверяет человек;

что сохраняется после работы.

Промпт помогает сформулировать запрос. Skill помогает повторить хороший способ работы многими людьми.

ИИ должен входить в процесс, а не жить рядом с ним

Главное отличие зрелого подхода от эксперимента — место ИИ в процессе.

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

В сильной модели ассистент встроен в конкретный рабочий момент.

Например, в тендерном процессе:

приходит документация;

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

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

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

готовит вопросы заказчику;

формирует краткое резюме для руководителя;

человек принимает решение об участии.

В закупочном процессе:

закупщик готовится к встрече с поставщиком;

ассистент собирает досье;

показывает предыдущие договоренности;

предлагает переговорную позицию;

после встречи готовит протокол;

человек подтверждает условия и следующие действия.

В разработке:

задача описывается как проверяемая спецификация;

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

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

создается запрос на внесение изменений;

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

знание остается в задаче, коде и документации.

Во всех этих примерах ИИ не является “умной вкладкой рядом”. Он занимает место внутри процесса. У него есть вход, выход,

правила и точка передачи человеку.

Это и есть начало AI-Native подхода.

Почему руководитель должен проектировать не инструмент, а контур

Слово “контур” здесь важно.

Контур — это не один инструмент и не одна модель. Это связка элементов, которая позволяет задаче проходить предсказуемо:

роль → задача → данные → ассистент → проверка → решение → память

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

Есть ассистент, но нет данных — он начинает угадывать.

Есть данные, но нет прав — появляется риск утечки.

Есть права, но нет проверки — растет риск неверных решений.

Есть проверка, но нет памяти — компания снова теряет знание

после каждой задачи.

Есть память, но нет владельца роли — непонятно, кто отвечает за результат.

Поэтому руководитель должен перестать задавать вопрос “какой ИИ внедрить?” и начать задавать другой вопрос:

Какой рабочий контур мы хотим усилить?

Это меняет порядок действий.

Сначала выбирается роль и процесс. Потом описывается результат.

Потом находится source of truth. Потом задаются правила доступа. Потом собирается skill. Потом запускается ассистент. Потом измеряется эффект.

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

Закрытый контур не отменяет AI-Native подход

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

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

Из этого иногда делают неверный вывод: “Если мы не можем отправлять данные во внешний сервис, значит, AI-Native подход

нам не подходит”.

Это не так.

AI-Native модель можно реализовать и в закрытом контуре.

В этом случае компания использует открытые модели или модели,

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

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

Правильная постановка другая:

Как собрать контур, в котором компания получает пользу

от ИИ и при этом сохраняет контроль над данными?

Для одних сценариев подойдет внешний сервис. Для других — закрытый контур. Для третьих — смешанная модель:

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

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

Как меняется роль технического руководителя

Для технического руководителя AI-Native переход — это не просто “подключить API модели”.

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

В нее входят:

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

права доступа;

журналирование действий;

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

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

работа с памятью;

защита чувствительных данных;

возможность разворачивать часть моделей внутри периметра;

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

Технический руководитель становится не поставщиком “ИИ- функций”, а архитектором операционного слоя, в котором люди и ассистенты работают вместе.

Это важный сдвиг.

Если CEO отвечает на вопрос “какие роли и процессы мы усиливаем?”, то CTO отвечает на вопрос “как сделать это

безопасно, надежно и масштабируемо?”.

Один без другого не работает.

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

Если есть только техническая архитектура, компания получает платформу без принятия людьми и без бизнес-эффекта.

AI-Native переход требует совместного владения.

Что меняется в ролях

Когда ИИ становится частью рабочего контура, меняются не только инструменты, но и сами роли.

Старые роли, построенные на механической работе с информацией, начинают исчезать или сжиматься.

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

Но это не значит, что сильные сотрудники становятся ненужными.

Наоборот, у них появляется новая зона роста.

Они становятся владельцами агентных контуров.

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

Продавец перестает быть только человеком, который “ведет клиента”. Он становится владельцем коммерческого контура: ассистент помогает помнить историю, готовить встречу,

фиксировать договоренности, собирать предложение и контролировать следующий шаг.

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

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

В этом смысле AI-Native компания не просто автоматизирует старую работу. Она создает новые роли поверх старых.

Практический пример: счет, акт и договор

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

Наивный подход:

Давайте подключим ИИ, чтобы он генерировал документы.

Звучит разумно, но быстро появляются вопросы.

Откуда брать реквизиты? Какая версия шаблона актуальна? Какие условия можно менять? Какие пункты договора обязательны? Кто проверяет сумму? Что делать с персональными данными? Где

сохранить готовый документ? Как понять, что ассистент не пропустил критичный пункт?

Если этих ответов нет, ИИ может ускорить написание текста, но не сделает процесс надежным.

AI-Native подход задает контур:

Владелец процесса: например, финансовый менеджер или

юрист.

Источники истины: карточка клиента, шаблон договора, реестр

реквизитов, согласованные условия.

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

проверки.

Проверка: человек утверждает сумму, реквизиты и

нестандартные условия.

Память: результат и отклонения сохраняются для будущих

похожих документов.

Теперь ассистент не просто “пишет договор”. Он работает в понятном контуре.

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

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

Выберите один процесс, который сейчас кажется “простым”, но постоянно отнимает время.

Например:

подготовка счета;

проверка счета-фактуры;

подготовка акта;

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

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

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

первичный анализ договора;

разбор тендерной документации.

Затем не спрашивайте “как нам применить ИИ?”.

Спросите:

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

Если вы ответили на эти вопросы, вы начали проектировать не

инструмент, а новый способ работы.

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

Где в компании ИИ сейчас живет рядом с процессом, а не внутри него?

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

Какие роли в вашей компании держатся на ручном переносе информации и типовых документах?

Какие из этих ролей могут стать владельцами агентных контуров?

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

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

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

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

Сначала нужно выбрать рабочий контур, описать роль, source of truth, права, skill, проверку качества и ответственность человека. Только после этого модель становится не игрушкой и не отдельной вкладкой, а частью новой операционной системы компании.