Исходная ситуация
Жалобы на статусы платежей и споры растут уже два квартала. Отзывы приходят из шести разрозненных каналов: интервью, обращения в поддержку, заметки продаж и аккаунт-менеджеров, эскалации операционной команды, запросы в Jira и отзывы от compliance и риск-отдела. Последствия:
- Продуктовая команда читает и сводит отзывы вручную, по одному.
- Задачи в бэклоге не удаётся связать с проверенными потребностями клиентов.
- Приоритеты расставляют по историям, а не по имеющимся доказательствам.
- Разработчики получают задачи без контекста и вынуждены переделывать.
Руководство попросило контролируемый пилот: перейти от интуиции к планированию на доказательствах, не отнимая у продакт-менеджеров право решать и не жертвуя безопасностью и compliance.
Предложение
12-недельный пилот в области платежей как Hybrid Agentic System. ИИ занимается только когнитивными задачами. Всё, что имеет последствия, выполняется детерминированно и под контролем человека. BigQuery на существующей ИИ-платформе — единый источник данных, а интерфейс в Appsmith заменяет таблицы.
Суть: одна и та же жалоба из интервью, обращения в поддержку и заметки в CRM становится одной приоритизированной возможностью с тремя подтверждениями, а не тремя отдельными записями в бэклоге.
Как это работает
- Очистка данных: сервис Google Cloud DLP удаляет персональные данные и финансовые идентификаторы, прежде чем текст попадёт к языковой модели. Это не ИИ, а фиксированный код.
- Разбор: ИИ делит интервью или обращение на отдельные проблемы, у каждой есть резюме, болевые точки, причина и теги, например серьёзность и продуктовая область. Если материала мало, он просит уточнить, а не гадает.
- Сопоставление: векторный поиск находит похожие уже известные темы и предлагает, та же это проблема или новая.
- Gate 1: продакт-менеджер подтверждает разбор, теги и сопоставление.
- Оценка: прозрачная формула с настраиваемыми весами считает балл по пяти входам: ценность клиента (Enterprise или SMB), срочность (самая тяжёлая серьёзность и частота), стратегическое соответствие, операционный риск и чувствительность для compliance. ИИ только объясняет число, а не считает его.
- Gate 2: продакт-менеджер решает, какие возможности сейчас стоят черновика.
- Черновик: ИИ пишет описание проблемы, user story, критерии приёмки и обоснование с подтверждениями.
- Gate 3: черновик сверяют с исходными подтверждениями и оценивают сложность. Только после этого скрипт, единственный компонент с доступом к Jira, отправляет задачу в Jira.
Дополнительно аналитический агент на основе Model Context Protocol отвечает на вопросы о сохранённых данных обычным языком, без SQL и выгрузок в CSV, только на чтение. Он показывает метрики продукта, процесса и ИИ. Система также замечает регрессии, то есть когда по уже исправленной в релизе теме продолжают приходить отзывы.
Четыре решения остаются за людьми
- Gate 1: разбор и сопоставление. Это единственная проверка, которая позже может стать выборочной, потому что у неё есть проверяемо верный ответ, а устойчиво высокое согласие это докажет.
- Gate 2: какие возможности делаем сейчас. Это зависит от ресурсов и сроков, поэтому нет показателя, к которому согласие могло бы сойтись. Проверка остаётся навсегда.
- Gate 3: одобрение черновика для Jira. Тоже остаётся навсегда.
- Решение после недели 12: продолжать, доработать или остановить, по замерам относительно исходных значений.
Безопасность по конструкции, а не по инструкции
- У ИИ нет доступа к Jira: ни один результат не попадёт к разработчикам непроверенным. Это структурная гарантия, а не правило.
- Нет пути к сырым данным: учётная запись ИИ не может читать сырые данные. Остаточный риск — остатки в свободном тексте, которые DLP пропускает. Против них проверка по шаблонам до загрузки и постоянные выборочные проверки.
- Прослеживаемость: каждое решение — сохранённая строка, доступ к данным BigQuery журналирует сам. Предложение ИИ хранится рядом с итоговым значением, по ним измеряют расхождения и дрейф.
- Совет работников: записывается роль (например Payment_PM), а не человек, чтобы не возникало контроля производительности (§ 87 BetrVG).
- Право: обработка в ЕС с определённым сроком хранения, по EU AI Act это внутренний вспомогательный инструмент вне категории высокого риска.
- Настройка вместо чёрного ящика: поскольку веса — параметры, систематическое расхождение при проверке показывает, какой вес неверен и кто может его изменить.
Пять участников, пять условий
Карта стейкхолдеров ранжирует всех по влиянию и интересу, а система построена так, чтобы каждое условие выполнялось технически:
- Head of Product (спонсор): хочет быструю приоритизацию с доказательствами для обзоров дорожной карты. Отчёты получают из дашборда или вопросом обычным языком.
- Risk & Compliance: может остановить пилот и требует защиты данных, прослеживаемости и проверки человеком.
- Engineering Lead: настроен скептически, хочет, чтобы неполные или выдуманные задачи не попадали в бэклог. Для этого Gate 3 и отсутствие у ИИ доступа к Jira.
- Senior Product Manager: ранний пользователь, который хочет ИИ как помощника, а не замену.
- Support Operations: хочет быть уверенным, что эскалации не потеряются под запросами на функции. Операционный риск — отдельный фактор формулы.
Матрица RACI определяет, кто за что отвечает, кто несёт ответственность, кого консультируют и кого информируют.
Риски и меры
Весь реестр рисков доступен как интерактивный Risk Hub. Пять главных рисков:
- Утечка данных (серьёзность 20): неполное скрытие. Мера: проверить правила DLP на реальных примерах и получить одобрение compliance до реальных данных.
- Автоматическое одобрение (16): проверяющие от усталости только подтверждают. Мера: обязательное обоснование на Gate 3 и случайная выборка 20 % с ручной проверкой сложности.
- Совет работников (15): журналы проверок как контроль производительности. Мера: журнал только с ролью, согласованный советом работников.
- Задержки одобрений (15): проверки длятся дольше 48 часов. Мера: автоматические уведомления и согласованная эскалация.
- Сбой интерфейса ИИ (15): мера: ручной режим в обход ИИ.
До старта нужны четыре решения: правила DLP, политика удаления данных по DSGVO, соглашение с советом работников и правило 48 часов.
Сроки и успех
- Недели 1–4 (основа): согласование шаблона DLP, схема базы данных, исходные значения, опрос участников, согласование RACI, Appsmith, обработка имеющихся данных по платежам.
- Недели 5–10 (пилот): ежедневные отзывы по платежам проходят все проверки.
- Недели 11–12 (оценка): замер относительно исходных значений, опрос о доверии, решение продолжать, доработать или остановить.
Сначала измерение: исходные значения фиксируют до первого шага с ИИ. Измеряют пять целей: меньше времени на ручной разбор, более единообразная документация, прослеживаемость от клиентского сигнала до задачи в Jira, более быстрый путь от отзыва до бэклога и больше доверия к приоритизации. Целевые значения: не менее 85 % совпадения по тегам, более 80 % попаданий при сопоставлении похожих тем, более 85 % принятия на Gate 3 и более 50 % экономии времени на работе с отзывами.
Проектный портал
В проект входит интерактивный прототип: процесс, три проверки, дорожная карта, стейкхолдеры, Risk Hub и портал мониторинга с аналитикой. Посмотреть прототип (на английском)
Результаты проекта
Проектный бриф, карта стейкхолдеров с матрицей RACI, анализ рисков, план мониторинга, модель данных из 11 таблиц в BigQuery и интерактивный прототип. Результатом проекта были концепция и документация. Мы представили их стейкхолдерам, чтобы на этой основе они решили, запускать ли пилот. Сам пилот не строился. В программе THRIVE концепция вошла в число 20 победивших работ среди 150 участников.