Представьте: на демонстрации система уверенно отвечает клиенту. После запуска выясняется, что часть ответов сотрудник переписывает вручную, спорные обращения уходят без проверки, а по журналу нельзя восстановить, какие данные видела модель. Пилот выглядит убедительно, но бизнес не знает, снизились ли затраты, стало ли лучше качество или вырос риск ошибки.
Поэтому выбирайте не «самый AI-процесс», а одну повторяемую операцию. Сначала пройдите обязательные стоп-проверки, затем сравните кандидатов по шести критериям, зафиксируйте исходный замер, набор проверок и правила участия человека. Универсального лучшего процесса нет: выбор зависит от ваших данных и цены ошибки. Итогом станут матрица и одностраничный план, с которыми можно честно решить: внедрять, оставить в режиме помощника, заменить обычной автоматизацией или остановить гипотезу.
1. Короткий ответ: хороший первый процесс ограничен и проверяем
Первый кандидат должен быть не целым отделом и не ролью «AI-менеджера», а одной единицей работы с понятным входом и выходом. Например: подготовить черновик ответа на обращение по утверждённой базе знаний; извлечь поля из входящего документа и передать их сотруднику на проверку; распределить заявку по очереди с объяснимой эскалацией.
У процесса есть владелец, реальные исторические примеры, способ проверить результат и ручной маршрут на случай отказа. Ошибка обнаруживается до необратимого внешнего эффекта. А изменение можно сравнить с текущей работой на одном знаменателе: не «модель ответила быстро», а «обращение принято без переделки».
Одна операция
Не «автоматизировать поддержку», а подготовить черновик ответа для одной очереди и типа запроса.
Проверяемый выход
Есть эталон или экспертная рубрика, обязательные факты и запрещённые действия.
Ручной резерв
Сотрудник продолжает процесс, если данных недостаточно, система недоступна или качество ниже порога.
Безопасная остановка
Права ограничены, внешний эффект можно подтвердить, отменить или отключить.
Когда решение не нужно
Гипотетический пример: платёжный сервис прислал подтверждённое событие, после чего нужно изменить статус сделки в CRM и уведомить менеджера. Если API и правила стабильны, это обычная автоматизация. Языковая модель лишь добавит переменную стоимость, задержку и ещё один способ ошибиться. AI можно обсуждать отдельно — например, для разбора неструктурированного сообщения клиента, но не для самого переноса статуса.
Второй повод остановиться раньше: сотрудники не могут согласовать, каким должен быть правильный выход, и каждый исполняет процесс по-своему. Здесь сначала нужно спроектировать сам процесс. Модель не превращает противоречивую практику в стабильное правило; она только быстрее воспроизводит неопределённость.
2. Пять стоп-проверок до любой матрицы
Матрица оценки помогает сравнить только допустимых кандидатов. Сначала задайте пять вопросов. Отрицательный ответ не нужно компенсировать высоким объёмом или эффектным прототипом.
- Владелец: кто отвечает за процесс, эталон и решение о качестве?
- Данные: разрешено ли использовать именно эти поля, документы и журналы?
- Проверка: какой выход считаем принятым и с чем его сравниваем?
- Резервный маршрут: как человек завершит работу, если AI откажет или промолчит?
- Остановка: как отключить права, остановить действие и восстановить состояние?
Это редакционная рамка 13FOX, собранная из принципов управления риском, оценки и контроля человека у NIST, OpenAI, Microsoft и OWASP. Она не является сертификацией или универсальным отраслевым стандартом.
Проведите по схеме в сторону, чтобы прочитать её без уменьшения.
Практический шаг: возьмите не один любимый сценарий, а два-три процесса из реальной очереди. Пропустите их через стоп-проверки, затем заполните шесть критериев фактами из систем. Это уменьшает риск подобрать аргументы под уже выбранный инструмент.
3. Шесть критериев и сравнение трёх кандидатов
Критерии отвечают на разные вопросы. Объём показывает, увидим ли мы достаточно повторений. Повторяемость — существует ли стабильная единица работы. Данные — есть ли разрешённые входы и эталон. Вариативность — нужен ли вероятностный AI вместо условий. Цена ошибки объединяет последствия, обнаружимость и обратимость. Срок и очередь показывают, создаёт ли задержка реальную операционную проблему.
| Кандидат | Сильный сигнал | Что проверить | Предварительный формат |
|---|---|---|---|
| Оплата → статус CRM → уведомление | Повторяемость и понятный SLA | Есть ли хоть одна причина применять модель | Webhook и правила, не AI |
| Черновик ответа из утверждённой базы | Реальные обращения, эталон и очередь | Права на данные, неоднозначность, проверку фактов | AI-ассистент с подтверждением |
| Извлечение полей из разных документов | Повторяемый выход при вариативном входе | Форматы, пропуски, чувствительные поля, последствия ошибки | AI + валидация + ручная очередь |
Здесь намеренно нет числовых весов. Надёжные источники не дают универсальной формулы, а вес последствия зависит от контекста. Ошибка в черновике внутренней сводки и ошибочное внешнее действие нельзя честно свести к одинаковой шкале. Если два кандидата выглядят равно, выбирайте меньшую автономность, более чистый эталон и более обратимый результат.
4. Автоматизация, AI-ассистент или агент
В обычной автоматизации путь заранее задан разработчиком: событие запускает известные проверки и действия. AI-ассистент формирует черновик, классификацию или рекомендацию, а человек подтверждает результат. Агент получает ограниченную цель и динамически выбирает следующие шаги и инструменты. Именно право выбирать путь, а не слово «AI» в интерфейсе, отличает агента.
Первый пилот не обязан доказывать максимальную автономность. Если гипотезу можно проверить в режиме помощника, это обычно даёт более понятный журнал: видно, что предложила модель, что исправил эксперт и почему результат приняли. Права на запись и удаление, платежи, изменение учётных данных и иные необратимые действия оставляют за отдельным подтверждением.
Проведите по схеме в сторону, чтобы прочитать её без уменьшения.
5. Исходный замер: что зафиксировать до запуска
Исходный замер — это описание текущей работы, а не один средний показатель. Сначала определите единицу работы и допустимый объём: какие случаи вообще входят в сравнение. Затем отделите время активной работы сотрудника от общего времени в очереди. Запишите качество с первого раза, переделки, исключения, эскалации, нарушения SLA, типы ошибок и фактические расходы.
Сравнивайте один и тот же знаменатель. Стоимость генерации черновика ничего не говорит о стоимости успешно принятого ответа, если часть черновиков переписывают, отправляют на повторный запрос или эскалируют. Версии модели, промпта, источников и интеграций тоже относятся к измерению: без них изменение результата нельзя воспроизвести.
HM Treasury отдельно предупреждает: разница «до/после» не доказывает, что эффект вызван AI. Если возможно, оставьте параллельную или поэтапную группу с текущим способом работы. Если нет — честно назовите ограничение атрибуции и не превращайте наблюдаемую корреляцию в доказанный ROI.
6. Данные, права, приватность и журнал
Вопрос «данные есть?» недостаточен. Составьте карту: источник → цель → минимальные поля → основание использования → поставщик и точка подключения → срок хранения → регион размещения → удаление. Модель получает минимально необходимые поля и минимальные права; поиск по базе обязан учитывать доступ конкретного пользователя до передачи контекста.
До отдельного решения не отправляйте секреты и ключи, лишние идентификаторы и сырые персональные данные, чувствительные категории, клиентские базы и материалы под NDA, а также информацию с требованиями к локализации или специальному режиму обработки. Конкретную правовую допустимость проверяют с ответственным за данные и юристом: статья не заменяет такую оценку.
Журнал должен отвечать на вопросы расследования: какая версия получила какой разрешённый вход, какие источники и инструменты использовала, что предложила, кто подтвердил решение и какой внешний эффект произошёл. Это не означает автоматически хранить весь сырой контент: логирование тоже подчиняется минимизации, срокам доступа и удалению.
7. Набор проверок: реальные случаи вместо демо
Набор собирают из исторических случаев процесса. В нём должны быть обычные запросы, редкие форматы, пропуски, противоречивые данные, неоднозначные случаи, опасные ошибки, попытки внедрить инструкцию через входные данные, ожидаемый отказ и правильную передачу человеку. Для каждой строки фиксируют эталонный ответ или экспертную рубрику, обязательные и запрещённые факты, тип ошибки и её тяжесть.
Нет универсального количества тестов. Размер и распределение зависят от разнообразия входов и цены ошибки. Автоматические проверки подходят для формата, обязательных полей и запрещённых действий; смысл и риск калибрует эксперт. Модель-судья может дополнять эту работу только после сверки с человеческими метками, потому что у такой оценки тоже есть смещения.
Для агента одного финального ответа мало. Оценивайте выбор инструмента, аргументы и переданные данные, права, число вызовов, петли повторов, передачу человеку, задержку, переменную стоимость и полный журнал. Замороженный набор повторяют после изменения модели, промпта, базы знаний, инструмента или политики.
Проведите по схеме в сторону, чтобы прочитать её без уменьшения.
8. Где оставить человека и когда остановить пилот
Человек в контуре — не кнопка «проверить всё». Опишите конкретное решение человека: что он видит, какие источники доступны, что может исправить, как отклоняет результат и кому передаёт исключение. Для финансовых, юридических, медицинских, действий записи и удаления, изменения учётных данных и иных необратимых действий явное подтверждение особенно важно.
Правила остановки принимают до запуска. Остановите или верните систему в режим без внешних действий, если превышен лимит повторов, действий, задержки или стоимости; входы запрещены, недостаточны или противоречивы; качество ниже принятого порога; растут ошибки и переделки; произошёл инцидент безопасности или приватности. Изменение модели, промпта, источника или политики требует повторной проверки до расширения прав.
| Сигнал | Действие системы | Роль человека |
|---|---|---|
| Недостаточно или конфликтуют данные | Отказаться от догадки, объяснить нехватку | Уточнить вход или завершить вручную |
| Внешнее необратимое действие | Подготовить предложение без исполнения | Проверить основание и подтвердить |
| Порог качества не достигнут | Остановить маршрут или убрать внешние действия | Разобрать ошибки и решить: править или остановить |
9. Как посчитать экономику пилота без вымышленного ROI
Переменную стоимость полезно считать на принятый или успешно завершённый случай: (модель + инструменты + переменная инфраструктура + проверка человеком + повторы и переделки + ожидаемая цена ошибки) / принятые случаи. Это формула прозрачности 13FOX, а не отраслевой отраслевой норматив.
Отдельно стоят исследование задачи, интеграция, проверки, безопасность, юридическая оценка и поддержка. Не прячьте их в цену токенов. И разделяйте три эффекта: реальный исчезнувший расход, высвободившееся время и изменение качества/SLA/риска. Свободные часы становятся денежной экономией только тогда, когда бизнес действительно убрал расход или направил ресурс в измеримый результат.
Для подробного разбора ручного слоя и ФОТ используйте отдельный материал о стоимости ручного труда при автоматизации. Здесь экономическая задача уже: выбрать один процесс и не выдавать результаты короткого пилота за обещание годового ROI без проверки масштаба и контекста.
10. Что подтверждает опыт 13FOX — и чего он не доказывает
Проектные страницы 13FOX — собственное описание функций, а не независимые исследования эффективности. Они подтверждают опыт проектирования входов, контекста, интерфейсов и границ ответственности. Они не подтверждают точность, ROI, медицинский эффект или автономность, если на странице нет методики и результатов.
- Epicure AI: рекомендации рецептов, фото-вход, ингредиенты и предпочтения показывают мультимодальный продуктовый сценарий; не доказывают точность распознавания или бизнес-эффект.
- LightWeight: анализ пользовательского контента по фото и фитнес-сценарии показывают встраивание AI в продуктовую механику; не доказывают медицинский результат, точность калорий или рост вовлечения.
- Психея: диалог, контекст/память, голос и явная граница «не замена психотерапии» показывают работу с диалоговым интерфейсом и ограничениями безопасности; не доказывают клинический эффект или безопасную работу с кризисами.
Это полезная граница для любого подрядчика: просите отдельно показать реализованные функции, метод измерения и доказанный результат. Не переносите маркетинговый эпитет из портфолио в финансовую модель пилота.
11. Одностраничный план пилота
До выбора модели и архитектуры заполните восемь блоков. Если поле неизвестно, это исследовательский вопрос, а не разрешение подставить красивое число. План можно использовать как повестку встречи владельца процесса, операционной команды, безопасности и разработки.
Проведите по схеме в сторону, чтобы прочитать её без уменьшения.
- Сформулируйте одну операцию, результат и владельца.
- Опишите источник и формат входа, эталон выхода и исключения.
- Снимите исходный замер на одном знаменателе.
- Заморозьте набор проверок с обычными, крайними и опасными случаями.
- Выберите минимальный уровень автономности.
- Назначьте проверку, эскалацию, откат и ответственного человека.
- Зафиксируйте поля, права доступа, срок хранения, журнал и удаление.
- До запуска примите порог качества, правила остановки и критерии запуска.
После пилота доступны четыре честных решения. Расширить, если порог качества и операционная метрика подтверждены. Оставить помощником, если черновик полезен, но автономный эффект рискован. Заменить обычной автоматизацией, если правила оказались стабильными. Остановить, если данные, качество или экономика не выдерживают проверку. Закрытая гипотеза может быть хорошим исследовательским результатом, но сама по себе не является финансовой экономией.
Если идея ещё не дошла до проверяемой единицы работы, начните с материала о разработке MVP и проверке основной гипотезы. Он поможет отделить обязательный сценарий от будущей архитектуры и списка функций.
12. Источники и границы выводов
Источники проверены 30 июля 2026 года. Они поддерживают принципы выбора простейшего решения, оценки, контроля человека, минимальных прав и причинной осторожности. Они не задают универсальные веса матрицы, срок пилота, размер набора проверок или средний ROI.
- OpenAI, практическое руководство по созданию AI-агентов: когда достаточно детерминированного решения, агент не нужен; при риске важно вмешательство человека.
- OpenAI, рекомендации по оценке: проверки для конкретной задачи, реальные распределения, граничные и враждебные случаи, непрерывная проверка и калибровка экспертом.
- Anthropic, Building effective agents, 19 декабря 2024: заданный сценарий отличается от агента тем, кто выбирает путь; начинать следует с простого решения.
- NIST AI RMF Core и NIST GenAI Profile: границы, последствия, контроль человека, тестирование, переопределение и отключение.
- Microsoft, список проверок внедрения, обновлено 27 января 2026: границы автономности, подтверждения, проверенные знания, инструменты, доступ и ошибки.
- OWASP LLM06: Excessive Agency: минимум функций и прав, подтверждение, журналирование и ограничения.
- HM Treasury, Impact evaluation of AI interventions, обновлено 15 мая 2026: текущий способ работы, сравнение с альтернативой, поэтапный запуск и ограничения масштабирования. Annex A в руководстве прямо помечен как гипотетический, поэтому его числа здесь не используются.
FAQ
Что такое AI-автоматизация бизнеса простыми словами?
Это использование модели в конкретной операции, где недостаточно только заранее заданных правил: например, для классификации, извлечения смысла или подготовки черновика. Маршрут, который полностью описывается системным событием и условиями, остаётся обычной автоматизацией.
Какой процесс выбрать для первого AI-пилота?
Ограниченный, повторяемый и измеримый процесс с разрешёнными данными, владельцем качества, обратимой ошибкой и ручным резервным маршрутом. Сначала применяют обязательные стоп-проверки, затем сравнивают кандидатов по объёму, повторяемости, данным, вариативности, цене ошибки и сроку ответа.
Чем AI-ассистент отличается от агента?
Ассистент готовит черновик или рекомендацию, а человек подтверждает решение. Агент динамически выбирает шаги и инструменты в пределах цели. Для первого пилота разумно брать минимальную автономность, достаточную для проверки гипотезы.
Как понять результат пилота без вымышленного ROI?
До запуска фиксируют один знаменатель и исходный замер: объём, время активной работы и ожидания, качество с первого раза, переделки, эскалации, соблюдение срока и фактические расходы. После пилота отдельно показывают денежную экономию, высвободившееся время, изменение качества и риска.
Что должно входить в набор проверок?
Реальные обычные, граничные, опасные, неоднозначные и невалидные случаи; ожидаемые отказы и эскалации; эталон или экспертная рубрика; запрещённые действия и типы ошибок. Универсального количества нет.
Когда AI-пилот нужно остановить?
При недостижении порога качества, росте переделок или ошибок, запрещённых или противоречивых данных, превышении лимита действий, стоимости или задержки, инциденте безопасности либо изменении модели, промпта или источника до повторной проверки.
Разберите один процесс до выбора модели
Передайте 13FOX один процесс, примеры входов, текущую ручную схему и ограничения доступа. На разборе мы отделим обычную автоматизацию от задачи для модели, зафиксируем исходный замер, набор проверок, роль человека и правила остановки. Результат — заполненный одностраничный план и решение о следующем шаге. Если AI не нужен, так и запишем. Если модель не нужна, рекомендуем обычную автоматизацию.