Почему набор AI-инструментов не меняет бизнес без выбранного процесса

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

Проблема не обязательно в модели или людях. Инструмент был выбран раньше единицы изменения. Не определены начало и конец работы, владелец результата, текущий baseline, исключения, цена ошибки, допустимые данные, место человеческого решения и критерий приёмки. В таком контуре новый сервис добавляет ещё один интерфейс, но не создаёт управляемого изменения.

По состоянию на 28 августа 2026 года Narayana AI Academy & Studio ↗ показана на публичной карте Narayana ↗ как направление «В развитии». Публичные материалы описывают намерение соединять обучение, ограниченные AI-сценарии и human review. Они не доказывают проведённые курсы, работу Studio, внедрённые пилоты, CRM или автоматизацию, кейсы, ROI, выпускников, партнёрства, связь с OpenAI либо достигнутый эффект. Из-за проверки регистратора публичный DNS домена сейчас указывает на loopback; редакционный фактчек выполнен через верифицированный production-origin `201.24.116.180`, где канонический адрес отвечает по HTTPS. Каноническая ссылка сохраняется, а доступность должна быть перепроверена перед публикацией.

Ниже — доказательная модель, по которой организация может выбрать и проверить один AI-сценарий. Это не описание уже внедрённой практики Narayana AI Academy & Studio и не обещание результата.

Сначала выбрать не инструмент, а единицу изменения

Разговор об AI становится точнее, если развести шесть уровней.

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

NIST AI RMF Core ↗ начинает `Map` с контекста, целей, пользователей, требований, риск-толерантности и бизнес-ценности. Отдельно требуется определить конкретные задачи, методы, границы знания и то, как выход будет использоваться и контролироваться человеком. После такого картирования должен быть возможен первоначальный `go/no-go`. Это полезная международная рамка, а не российское право и не подтверждение соответствия Narayana какому-либо стандарту.

Почему «зоопарк инструментов» не складывается в изменение

Локальная скорость может скрыть общий хвост работы

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

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

Сервис не получает право принимать решение

AI может предложить классификацию, формулировку или следующий шаг. Право утвердить выплату, отказ, найм, медицинское утверждение, доступ к данным или публичное обещание возникает из закона, договора и организационных полномочий, а не из уверенного ответа модели. Поле «human review» бесполезно, если не ясно, кто именно проверяет, что он видит, сколько у него времени и может ли безопасно отклонить предложение.

Исключения возвращают процесс к людям

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

Данные начинают путешествовать раньше решения

Сотрудник может перенести в личный AI-аккаунт письмо клиента или внутренний договор, чтобы «просто проверить идею». Британский NCSC ↗ относит неуправляемые AI-сервисы с корпоративными данными к shadow IT и подчёркивает: это часто не злой умысел, а попытка выполнить работу при неудобном официальном процессе. Полезная реакция — не поиск виноватого, а безопасный канал для запроса, реестр разрешённых сценариев и устранение причины обхода.

Паспорт процесса до первой лицензии

Для первого решения достаточно одной страницы, если каждое поле проверяемо.

1. Пользователь и потребность. Кто выполняет работу и чья проблема решается, а не кто заинтересован продать инструмент.
2. Начало и результат. Какой наблюдаемый вход запускает процесс и кто принимает конечный результат.
3. Границы. Какие подразделения, каналы, типы запросов, языки и периоды входят или не входят.
4. Владелец процесса. Человек с правом менять поток и отвечать за результат; технический администратор не получает это право автоматически.
5. Текущий маршрут. Реальные шаги, ожидания, передачи, обходы и точки повторной работы.
6. Исключения. Случаи, в которых сценарий обязан остановиться, передать работу человеку или вернуться к прежнему способу.
7. Baseline. Период, выборка, единицы измерения, качество исходных данных и диапазон, а не одно удобное среднее.
8. Цена ошибки. Возможный вред человеку, организации, данным, репутации и законным интересам.
9. Данные. Категории, источник, правовое основание, минимизация, доступы, место обработки, срок хранения и удаление.
10. Роль AI. Предложение, извлечение, классификация, генерация или действие; какие полномочия система не получает.
11. Human review. Кто проверяет, по каким критериям, с какими источниками, временем и правом отклонения.
12. Критерии приёмки. Что должно быть не просто быстро, а достаточно точно, полно, прослеживаемо, безопасно и удобно.
13. Fallback и stop. Как продолжить работу без AI и какие события немедленно останавливают тест.
14. Решение после пилота. `scale`, `rework`, `hold` или `stop`, владелец решения и требуемые доказательства.

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

Как выбрать первый use case

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

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

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

Baseline нужен до демонстрации

До пилота выбирают период и одинаково считают старый процесс. Минимальный baseline может включать:

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

Выбор метрики меняет поведение. Если наградить только скорость ответа, сотрудник может принять сырой текст и перенести время в жалобы. Если измерять только число сгенерированных документов, система поощрит объём, а не пригодность. Если скрыть время проверки, human review станет неоплачиваемой невидимой работой.

GAO AI Accountability Framework ↗ группирует вопросы вокруг governance, data, performance и monitoring и требует связать цели, данные, результаты и последующий контроль. Рамка разработана для федеральных агентств США, но её вопросы полезны как независимая проверка конструкции; она не является российским требованием.

Критерии приёмки описывают результат и отказ

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

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

Важно проверять не только правильный ответ, но и правильный отказ. Надёжный процесс умеет сказать «недостаточно данных», остановиться при изменившейся версии регламента и продолжить по fallback. NIST AI RMF ↗ связывает измерение с условиями, близкими к реальному использованию, документированием границ обобщения и механизмами отключения системы, если результат не соответствует назначению.

Human review — это спроектированная работа

Человек в контуре не является универсальной страховкой. Он может устать, не увидеть исходные данные, довериться уверенной формулировке или отвечать за слишком много случаев. Метаанализ Vaccaro, Almaatouq и Malone ↗ объединил 106 экспериментальных исследований и 370 эффектов: в среднем комбинация человека и AI не превосходила лучший из двух самостоятельных вариантов, а результат зависел от типа задачи и конструкции взаимодействия. Это не доказательство бесполезности human review; это запрет считать его эффективность автоматической.

Рабочая схема review отвечает на семь вопросов:

1. Что именно проверяет человек: факты, полноту, безопасность, права, тон или всё сразу?
2. Какие первичные материалы доступны рядом с предложением AI?
3. Видит ли reviewer неопределённость и границы, а не только финальный текст?
4. Может ли он отклонить результат без санкции за «медленную работу»?
5. Куда эскалируется спорный случай?
6. Как фиксируются причина исправления и новая категория ошибки?
7. Кто проверяет качество самого review и нагрузку на людей?

ISO/IEC 38507:2022 ↗ адресована органам управления и рассматривает эффективное, результативное и приемлемое использование AI. OECD AI Principles ↗ требуют прозрачности, возможности оспаривать затрагивающий человека результат, управления риском, прослеживаемости, override и безопасного вывода системы из работы. Это международные ориентиры, не сертификаты Narayana и не замена применимому праву.

Российские границы данных и автоматизированного решения

AI-пилот не создаёт исключение из законодательства о персональных данных. По состоянию на 28 августа 2026 года статья 5 закона № 152-ФЗ ↗ требует законной и справедливой обработки, конкретных заранее определённых целей, соответствия объёма данным целям, точности и ограничения хранения. «Модель может пригодиться позже» не является достаточным описанием цели.

Статья 18.1 ↗ требует необходимых и достаточных мер, документов по целям, категориям данных, срокам, уничтожению, внутреннему контролю и обучению работников. Статья 19 ↗ — правовых, организационных и технических мер безопасности. Перед пилотом нужны проверка фактического оператора, поручений обработки, хостинга, трансграничной передачи, журналов, обучения модели, доступов, удаления и инцидентов для конкретного сервиса. Название тарифа `business` или `enterprise` само по себе этого не доказывает.

Статья 16 закона № 152-ФЗ ↗ ограничивает решения, основанные исключительно на автоматизированной обработке персональных данных, если они порождают юридические последствия или иначе затрагивают права и законные интересы, кроме установленных законом случаев; она также предусматривает объяснение порядка и последствий и возможность возражения. Применимость к конкретному процессу должен оценивать квалифицированный специалист. Практический минимум шире: высокозначимое решение не передают модели только потому, что интерфейс позволяет нажать `approve`.

Пилот — временный договор с реальностью

Пилот не должен начинаться с обещания масштабирования. Его задача — проверить заранее записанную гипотезу при ограниченном риске. Возможна такая последовательность:

1. Discovery. Описать процесс, baseline, владельца, пользователей, исключения, данные и не-AI альтернативу.
2. Sandbox. Проверить обезличенные или синтетические случаи, ограничения модели, журналы и роль reviewer без влияния на реальных клиентов.
3. Параллельный прогон. AI создаёт предложение, но действующий процесс остаётся основным; результаты сравниваются по одинаковым случаям.
4. Ограниченное использование. Только разрешённая выборка, обученные роли, ручное утверждение и ежедневный разбор ошибок.
5. Решение. Независимо рассмотреть доказательства и выбрать `scale`, `rework`, `hold` или `stop`.

До начала фиксируют stop-условия: утечка или неразрешённая передача данных; систематическая фактическая ошибка; невозможность восстановить источник; небезопасный совет; дискриминационный паттерн; рост тяжёлых ошибок; скрытое автоматическое действие; отсутствие reviewer; недопустимая нагрузка; изменение условий поставщика; невозможность вернуть процесс в безопасный режим. Остановка — не провал команды, а предусмотренный результат проверки.

ISO/IEC 23894:2023 ↗ предлагает встраивать AI-риск в деятельность организации с учётом её контекста. ISO/IEC 42001:2023 ↗ задаёт требования к системе управления AI по циклу установления, внедрения, поддержания и постоянного улучшения. Здесь стандарты используются как карты вопросов; статья не заявляет их внедрение, аудит или сертификацию Narayana AI Academy & Studio.

Измерять пользу без рекламной арифметики

Исследования показывают, что эффект AI возможен, но не переносится автоматически между задачами.

Brynjolfsson, Li и Raymond ↗ изучили поэтапное внедрение ассистента у 5 172 операторов поддержки одной компании и обнаружили средний рост числа решённых вопросов в час на 15 процентов при неоднородном эффекте: меньше опытные сотрудники выиграли больше, а у наиболее опытных были небольшие изменения скорости и качества. Это сильное полевое исследование конкретного инструмента, процесса, компании и метрики, а не прогноз ROI для другой организации.

Brynjolfsson, Rock и Syverson ↗ объясняют «J-кривую производительности»: технологии общего назначения требуют сопутствующих нематериальных инвестиций — в процессы, навыки и организационный капитал — поэтому эффект может запаздывать и быть плохо виден в обычной отчётности. Работа относится к макроэкономическому измерению, а не даёт календарь конкретного AI-пилота.

ILO ↗ оценивает экспозицию профессий через задачи и подчёркивает, что из-за сохраняющейся роли человеческого труда большинство затронутых работ вероятнее трансформируются, чем исчезнут; переход требует социального диалога. Это оценка потенциальной экспозиции, не прогноз увольнений или роста производительности конкретной команды.

Следовательно, честная итоговая запись содержит не один процент, а:

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

Change management начинается с права сказать «нет»

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

Исследование Wessel и соавторов ↗ различает цифровую трансформацию, которая переопределяет ценностное предложение и организационную идентичность, и IT-поддерживаемое изменение существующей модели. Не вся автоматизация обязана быть «трансформацией». Иногда честный успех — убрать одно повторное копирование, сохранив прежние роли и договор. Иногда выбранный процесс показывает, что AI не нужен вовсе.

У пилота должны быть как минимум четыре различимые роли: владелец процесса отвечает за рабочий результат; технический владелец — за конфигурацию и интеграцию; владелец данных или правовая функция — за допустимость обработки; reviewer — за конкретное решение в пределах полномочий. Один продавец решения не должен единолично подтверждать собственное качество.

Как это относится к Narayana AI Academy & Studio

Для направления «В развитии» процесс-first может быть принципом дизайна, но не публичным утверждением о работе. Возможный маршрут выглядит так: Academy помогает команде описать один процесс и научиться проверять выход; Studio, только при отдельном решении и договоре, может поддержать ограниченный прототип; владелец организации сохраняет данные, права и окончательное решение; независимый review отделяется от продажи решения. Это гипотеза будущей модели, а не действующая услуга.

До любого запуска нужно документально подтвердить оператора, программу, роли, поставщиков, договоры, обработку и удаление данных, human review, безопасность, критерии, stop-процедуру, жалобу, цену и границы обещания. Публичная страница не даёт оснований заявлять курс, пилот, кейс, автоматизацию, CRM, ROI, выпускников, партнёров или связь с OpenAI.

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

Набор инструментов становится изменением только после выбора процесса. А процесс становится кандидатом на масштабирование только после baseline, владельца, критериев, безопасного pilot design, human review, права остановить и честного сравнения с альтернативой. До этого AI — возможность. После доказательств — ограниченное управленческое решение. Ни один из этапов не гарантирует экономию, прибыль, безопасность, качество без исключений или духовный результат.