ГЛАВА В. КАРТА КОМПЕТЕНЦИЙ AI-ПРОДАКТА

Инженерные инструменты -это важно. Но инструменты не отвечают на вопросы:

· Зачем бизнесу этот ИИ?

· Как измерить, что он работает?

· Как внедрить, чтобы не уволили после первой галлюцинации?

· Сколько это на самом деле стоит?

На эти вопросы отвечает продакт. Точнее - AI-продакт. Человек, который переводит с инженерского на бизнесовый, считает TCO, рисует HITL-стратегию и объясняет топ-менеджменту, почему ИИ - это не магия, а инженерия компромиссов.

Глава В - карта компетенций такого продакта. Без неё вы рискуете построить технологически совершенную систему, которая никому не нужна. Или, что ещё хуже, - нужна, но её никто не может внедрить, потому что не понимает как.

B.1 Природа ИИ (Ментальная модель)

Недетерминированность - это норма. В классической разработке функция при одних и тех же входных данных всегда выдает один результат. LLM (большие языковые модели) могут выдавать разные ответы. Внедрение ИИ - это управление вероятностями, а не написание жесткой логики.

Accuracy (точность) 99% не означает «готово». Последний процент - самый сложный. Добиться точности с 80% до 95% можно за месяц, а с 95% до 99% - за полгода, и это может быть экономически нецелесообразно. Нужно уметь определять порог достаточности для бизнеса.

ИИ - это не продукт, это функция. Редко когда ИИ продают как отдельный софт (хотя и так бывает). Чаще это «фича», встроенная в существующий процесс. Если процесс (бизнес-процесс) сырой, ИИ его не спасет, а только ускорит производство ошибок.

Garbage In, Garbage Out (GIGO) на стероидах. Качество данных важнее архитектуры модели. Если входные данные (история чатов, документы, CRM) грязные, несогласованные или противоречивые, никакая самая крутая модель не даст бизнес-результата.

B.2 Технический цикл жизни модели (MLLC): Почему код - это не главное

Здесь мы говорим о том, как меняется сам артефакт (модель) во времени. Про дрейф, про то, что модель «живая», и про инженерные практики (MLOps), которые удерживают её в узде.

Роль данных важнее роли кода. В классическом IT вы управляете разработчиками. В AI проекте вы управляете еще и разметчиками данных (labelers). Часто «узкое горлышко» проекта - это скорость разметки и проверки данных, а не скорость написания кода.

MVP (минимально жизнеспособный продукт) для ИИ - это «HITL» (Human in the Loop). Самый безопасный способ внедрения - сначала запустить модель в режиме ассистента (рекомендации оператору) или с постаудитом. Убирать человека из контура (full automation) можно только после долгого периода накопления статистики доверия.

B.2.1 HITL-стратегия: от человеческого контроля к полной автоматизации

1. Почему HITL - это MVP, а не «полумера»

В классическом IT MVP - это приложение с минимальным набором функций. В ИИ MVP - это система с максимальным контролем ошибок. Основная цель MVP не «удивить клиента», а накопить доверие (статистику) и отловить крайние случаи (edge cases), которые невозможно предсказать на тестовых выборках.

Три уровня внедрения (Pyramid of Automation):

1. HITL как Ассистент (Human in the Loop) - MVP.

2. HITL как Супервайзер (Human on the Loop) - Промежуточный этап.

3. Full Automation (Human out of the Loop) - Цель после доказательства надежности.

2. Уровень 1: ИИ как Ассистент (Human IN the Loop) - MVP

Сценарий: Модель работает, но её выходные данные - это просто совет для сотрудника. Сотрудник является единственным юридически значимым лицом, принимающим решение.

Как это выглядит в продуктах

Бот пытается ответить, но если уверенность < 95%, он не отвечает, а переводит диалог на живого оператора, предлагая ему проект ответа (подсказку). Оператор либо отправляет, либо правит.

Кредитный конвейер

ML-модель ставит скоринг (вероятность дефолта) и подсвечивает «красные флаги» в документах, но финальный «Одобрено» ставит кредитный инспектор.

Безопасность

Система детектирует подозрительную транзакцию, но блокировку инициирует только сотрудник службы безопасности (или бот блокирует временно, а сотрудник подтверждает).

Задачи РП на этом этапе

UX для оператора: Главная проблема на этом этапе - утомляемость оператора и игнорирование подсказок. Если интерфейс неудобен (всплывающее окно мешает), операторы будут отключать ИИ. РП должен обеспечить, чтобы использование подсказок ИИ сокращало время обработки заявки (AHT - Average Handling Time), а не увеличивало его.

Сбор парных данных (Human vs AI): Ваша главная задача - логировать расхождения. Если ИИ предложил вариант А, а оператор сделал вариант Б - это золотая руда для дообучения (fine-tuning). РП должен организовать пайплайн сбора этих «исправлений» обратно в контур Data Science.

Метрики качества: Вы измеряете не % автоматизации, а Acceptance Rate (сколько раз оператор согласился с ИИ) и Correction Rate (сколько раз оператор исправил ИИ).

3. Уровень 2: ИИ как Супервайзер (Human ON the Loop) - Промежуточный

Сценарий: ИИ действует автоматически, но человек (супервайзер/эксперт) получает сводку (dashboard) о том, что произошло, и может отменить действие постфактум или вмешаться в исключительных случаях.

Когда переходить

Переход возможен, когда на этапе HITL (Уровень 1) вы накопили статистику, что Accuracy (точность) и Precision (полнота) модели превышают показатели среднестатистического оператора, а количество «критических ошибок» (false negative/positive) стремится к нулю.

Как это выглядит

Автоматический ответ

Модель отвечает клиенту сама в 80% случаев. Но если клиент пишет мат, угрожает или пишет сложный юридический запрос - система эскалирует на человека.

Валидация транзакций

Бот блокирует подозрительный перевод, но у оператора есть 10 минут, чтобы разблокировать его, если система ошиблась (ложное срабатывание), до того, как клиент пожалуется.

Задачи РП

Настройка порогов (Thresholds)

Вы управляете не алгоритмом, а порогом уверенности. РП должен согласовать с бизнесом компромисс: «Мы готовы автоматизировать 60% задач, но допустим 0.5% ошибок» против «Мы автоматизируем 30% задач с 0% критических ошибок».

SLAs на эскалацию

Здесь появляются жесткие SLA. Если ИИ не справился, за сколько секунд оператор должен вступить в диалог? Если время реакции оператора больше, чем время работы ИИ, ценность продукта падает.

4. Уровень 3: Полная автоматизация (Human OUT of the Loop)

Сценарий

Человек исключен из операционного контура. ИИ принимает решения и совершает действия без участия человека.

Условия для перехода

РП не должен давать согласие на Full Automation, пока не выполнены три условия:

1.) Статистическая значимость

Модель отработала на живых данных (в режиме HITL) минимум 3-6 месяцев (зависит от частоты событий) без единого критического инцидента.

Совет

Вместо фиксированного срока используйте статистические критерии: верхняя граница 95% ДИ для критических ошибок < 0.1%, покрытие 99% известных edge-case сценариев и подтверждённый бизнес-эффект. Срок - следствие метрик, а не замена им.

2.) Предсказуемость краевых случаев

Вы уверены, что модель корректно обрабатывает 100% известных краевых случаев (edge cases). Если в базе знаний появляется новый продукт (новый тариф, новый закон), ИИ должен либо знать о нем, либо уметь корректно отказаться от ответа (fallback).

3.) Обратный контур

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

5. Роль РП в управлении статистикой доверия

Чтобы перейти от уровня 1 к уровню 2 и 3, РП должен организовать не просто внедрение, а систему накопления доказательств. Вот что должно быть в вашем проектном плане помимо кода:

6. Особый нюанс: «Человек в контуре» как часть архитектуры безопасности

Для РП важно понимать, что HITL - это не только про качество ИИ, но и про кибербезопасность и комплаенс.

К примеру, в банковской сфере существуют жесткие регуляторные требования:

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

Противодействие легализации доходов (115-ФЗ): ИИ может выявить подозрительную операцию, но уведомление в Росфинмониторинг подписывает сотрудник.

Вывод для РП

Вы не внедряете ИИ как замену человека. Вы внедряете оркестрацию: ИИ берет на себя рутину (где цена ошибки низкая), расширяет возможности эксперта (подсказки) и поднимает тревогу там, где сталкивается с нетипичной ситуацией. MVP с HITL позволяет вам сделать ошибки безопасными и получить тот самый датасет «исправлений», без которого невозможно дообучить модель до уровня, при котором руководство согласится отключить человека.