AI-readiness: как выбрать одну задачу, где пилот действительно измерим

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

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

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

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

Готовность бывает не «к AI», а к проверяемому решению

Полезно развести пять состояний, которые часто смешивают.

NIST AI RMF Core ↗ предлагает сначала картировать контекст, конкретную задачу, пользователей, ограничения, ожидаемые выгоды и затраты, human oversight и риск-толерантность. Только после этого возможен первоначальный `go/no-go`. Это добровольная международная рамка, а не российское право и не знак соответствия Narayana.

Peer-reviewed исследование Victoria Uren и John Edwards ↗ показывает, что для движения от эксперимента к устойчивому использованию одной технологической готовности недостаточно: нужны люди, процесс и данные, а техническая и бизнес-функции должны работать вместе. Рамка Jonny Holmström ↗ различает технологии, действия, организационные границы и цели. Оба источника помогают увидеть AI-readiness как социотехническую способность, но не дают универсального числового сертификата.

Сначала собрать список задач, потом исключить неподходящие

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

Для каждого кандидата достаточно короткой карточки:

1. Рабочая потребность. Какое наблюдаемое затруднение существует сейчас и для кого.
2. Ограниченная операция. Один вход, одно действие и один проверяемый выход.
3. Владелец результата. Кто отвечает за процесс и имеет право принять, изменить или остановить тест.
4. Текущий маршрут. Как задача выполняется без AI, включая ожидание, перепроверку и исключения.
5. Частота и выборка. Сколько сопоставимых случаев возникает и хватит ли их для осмысленного сравнения.
6. Эталон или adjudication. Как определяется приемлемый результат, кто разрешает экспертное расхождение.
7. Цена ошибки. Возможный вред человеку, правам, данным, договору, безопасности, репутации и работе команды.
8. Данные. Категории, происхождение, качество, минимизация, правовое основание, доступы, хранение и удаление.
9. Human oversight. Кто проверяет выход, какие первичные данные видит, сколько времени имеет и может ли отклонить предложение.
10. Обратимость. Как быстро вернуться к прежнему процессу без потери истории и незавершённых обязательств.
11. Метрики. Результат, полный цикл, человеческая нагрузка, исключения и guardrails.
12. Решение. Кто и по каким заранее записанным условиям выбирает `go`, `rework`, `hold` или `stop`.

Карточка не должна превращаться в арифметическую иллюзию. Высокая сумма баллов не отменяет жёсткое stop-условие. Нельзя «компенсировать» отсутствие законного основания красивой экономией времени.

Claim ladder: какое утверждение уже можно доказать

Один из главных источников самообмана — скачок от наблюдения к бизнес-обещанию. Полезна лестница утверждений.

1. Техническое наблюдение: модель сформировала ответ на конкретном наборе входов.
2. Повторяемая метрика: на зафиксированной выборке система достигла определённого значения с указанной неопределённостью.
3. Результат human–AI workflow: команда с AI выполнила задачу лучше или хуже сопоставимого маршрута по заранее выбранным показателям.
4. Операционный эффект: изменение сохранилось в ограниченном рабочем контуре с реальными исключениями и полным учётом труда.
5. Организационная ценность: эффект устойчив во времени, оправдывает совокупные затраты и не создаёт неприемлемого вреда.

Каждая ступень требует новых доказательств. Удачная демонстрация не подтверждает рабочий процесс; сокращение времени генерации не подтверждает сокращение полного цикла; пилот в одной команде не доказывает масштабируемость. OECD ↗ подчёркивает разные уровни цифровой зрелости, сложности и масштаба применения AI у малых и средних организаций, а также роль связности, данных, навыков и финансирования. Кейсы в отчёте — иллюстрации путей, не доказательство результата для другого объекта.

Baseline: сравнивать с реальной работой, а не с памятью

Baseline фиксируют до того, как команда увидела любимую демонстрацию и начала менять маршрут. Минимум включает:

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

Если разметчики расходятся, само расхождение — часть baseline. Нужно зафиксировать критерии, измерить согласие и определить adjudicator, а не объявлять мнение одного эксперта «истиной». Если случаи до и после отличаются по сложности, языку, каналу или сезону, сравнение теряет смысл.

Новый NIST TEVV-Athlon ↗, опубликованный 7 августа 2026 года как initial public draft, предлагает строить оценку вокруг целей организации и контекстных measurement concepts. Мы используем его только как свежую проектную рамку, открытую для комментариев, а не как окончательный стандарт. NIST AI RMF отдельно требует документировать test sets, метрики, инструменты, условия, похожие на deployment, ограничения обобщения и неопределённость.

Что именно измерять в пилоте

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

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

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

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

Guardrails. Утечки и лишние данные, дискриминационные различия, опасные рекомендации, потеря источника, недоступный маршрут обжалования, нарушение договора, security incident и выход за согласованные границы.

Систематический review и meta-analysis 106 исследований human–AI collaboration ↗ показал неоднородность: комбинация человека и AI в среднем уступала лучшему из них по отдельности, а тип задачи и разделение труда имели значение. Это не прогноз для конкретного пилота, а аргумент измерять как минимум три сопоставимых режима, когда это допустимо: человек без AI, AI на той же задаче и человек с AI. Если сравнивается только новый маршрут с воспоминанием о старом, нельзя отделить эффект технологии от отбора примеров и внимания команды.

Shadow-режим: увидеть разницу до передачи полномочий

Для обратимой и достаточно низкорисковой задачи полезна последовательность:

1. Offline evaluation. Система работает на заранее отобранных исторических или синтетических случаях; результат не влияет на живой процесс.
2. Shadow deployment. AI получает копию разрешённого входа и формирует предложение, но рабочее решение принимается обычным способом. Выходы сопоставляют позже.
3. Ограниченный assisted pilot. Reviewer видит предложение AI, первичный материал, критерии и может свободно изменить или отклонить его.
4. Решение о следующем шаге. Данные рассматривает уполномоченная группа; пилот не переходит в эксплуатацию по умолчанию.

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

Работа Dell’Acqua и соавторов с 758 knowledge workers ↗ показывает «рваную границу» возможностей: в одних задачах AI улучшал скорость и качество, в других — ухудшал результат, хотя задачи казались похожими. Переносить размеры эффекта на другую организацию нельзя; практический вывод скромнее — границу нужно искать на своих задачах и не превращать соседний успех в разрешение автоматизировать.

Human oversight должен менять решение

Фраза «всё проверяет человек» ничего не гарантирует. Reviewer должен:

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

Validated guidelines Amershi и соавторов ↗ рекомендуют заранее объяснять возможности системы, поддерживать эффективное исправление и позволять пользователю управлять влиянием AI. Они не являются законом или универсальной гарантией интерфейса, но помогают проверить, существует ли у человека реальная agency.

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

Российские границы данных не начинаются после пилота

Если пилот обрабатывает персональные данные, слово «тест» не выводит его из правового поля. Статья 5 Федерального закона № 152-ФЗ ↗ требует законной и справедливой обработки, совместимости с заявленной целью, достаточности без избыточности, точности и ограничения хранения. Это означает: в карточке задачи до загрузки примеров должны быть цель, состав данных, правовое основание, доступы, срок и удаление.

Статья 16 ↗ ограничивает решения, основанные исключительно на автоматизированной обработке и затрагивающие права или законные интересы человека; конкретная применимость зависит от процесса и требует юридической квалификации. Статья 18.1 ↗ требует организационных мер, политики, локальных актов, ответственности и контроля. Статья 19 ↗ — правовых, организационных и технических мер защиты и оценки их эффективности до ввода соответствующей информационной системы персональных данных в эксплуатацию.

Британский ICO AI toolkit ↗ связывает AI lifecycle с оценкой риска для прав и свобод; руководство сейчас пересматривается из-за изменений британского закона. Это сравнительный чек-лист, не российское требование. Российские обязанности нужно определять по российскому праву, конкретным данным, оператору, поставщику, договору и архитектуре.

No-go: что нельзя брать первым пилотом

Некоторые задачи следует отложить независимо от привлекательности демо:

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

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

Четыре решения вместо обязательного масштабирования

До старта фиксируют пороги и полномочия. После пилота возможны четыре нормальных решения.

Go. Критерии результата и guardrails выполнены в заданных условиях; появляется основание проектировать следующий ограниченный этап, но не автоматическое разрешение на масштаб.

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

Hold. Доказательств недостаточно либо внешнее условие — право, поставщик, безопасность, качество данных, компетенция — не подтверждено. Работа приостанавливается без подгонки выводов.

Stop. Вред, нестабильность, отсутствие ценности, неустранимый конфликт прав или неприемлемая совокупная стоимость делают продолжение неоправданным. Остановка — результат управления, а не поражение команды.

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

30 дней до честного пилота

Короткий readiness-цикл может выглядеть так.

Дни 1–5: собрать 5–7 задач, описать потребность и жёсткие no-go; выбрать не «самую инновационную», а самую проверяемую и обратимую.

Дни 6–10: зафиксировать текущий процесс и baseline на сопоставимых случаях; проверить качество разметки и расхождения экспертов.

Дни 11–15: квалифицировать данные, договоры, поставщика, доступы, хранение, удаление, human oversight и fallback. Неподтверждённое отмечать как `hold`, а не как «решим позже».

Дни 16–20: составить evaluation protocol: выборка, режимы сравнения, метрики, uncertainty, guardrails, stop-условия, reviewer и независимый участник разбора.

Дни 21–25: провести offline или shadow-тест без влияния на живое решение, если это допустимо; сохранить все исходы, а не только удачные.

Дни 26–30: разобрать результат, жалобы и исключения; вынести `go`, `rework`, `hold` или `stop`; закрыть доступы и удалить данные по установленным правилам, если продолжения нет.

ISO/IEC 42001:2023 ↗ описывает систему управления AI с постоянным улучшением, а ISO/IEC 23894:2023 ↗ — интеграцию AI-риск-менеджмента в контекст организации. Эти ссылки не означают внедрение, аудит или сертификацию направления. Они напоминают, что решение о пилоте живёт внутри ответственности организации, а не в отдельной лаборатории инструментов.

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

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

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

AI-readiness не отвечает: «готова ли организация купить AI». Он отвечает на более полезный вопрос: может ли она честно узнать, улучшает ли один ограниченный human–AI workflow реальную работу по сравнению с понятной альтернативой — и безопасно остановиться, если нет? Ни readiness-gate, ни pilot design не гарантируют скорость, экономию, ROI, лиды, прибыль, отсутствие ошибок, безопасность без исключений, замену людей, лечение или духовный результат.