Роли и ответственность в AI-внедрении

Видео по теме

AI-внедрение ломается не только из-за модели. Часто проблема в том, что никто не назначил владельца процесса, владельца данных, проверяющего качество и человека, который принимает риск.

Таймкоды

Кто такой Юрий из CodeVibers
Почему ответственность важнее модели
Role map
RACI-матрица
Approval gate
Антипример
Проверки перед пилотом

Shorts

Практический материал из выпуска

Артефакт: RACI-матрица AI-внедрения: роли, действия, approval gate, acceptance checks и журнал решений для одной бизнес-задачи.

Что должно получиться: Шаблон, который можно перенести в таблицу или задачу: role map, RACI matrix, approval rules, pilot checks.

Как собрать

Выбрать конкретную AI-задачу: обработка входящей заявки с сайта.
Заполнить role map: process owner, data owner, AI integrator, quality reviewer, risk approver.
Заполнить RACI-матрицу по шагам процесса: принять заявку, классифицировать, обогатить данные, подготовить ответ, отправить клиенту, записать в CRM.
Отметить approval gate для внешних действий и изменений учетной системы.
Собрать acceptance checklist перед пилотом.

Шаблон: RACI-матрица для AI-внедрения

Скопируйте таблицу и заполните ее для одной конкретной AI-задачи до пилота.

Шаг процесса	Responsible	Accountable	Consulted	Informed	Approval gate
Принять входящую заявку	Менеджер / оператор процесса	Process owner	Data owner	CRM owner	Нет, если действие только внутреннее
Классифицировать запрос AI	AI integrator	Process owner	Quality reviewer	Команда продаж	Нужен для низкой уверенности или спорной категории
Отправить ответ клиенту	Менеджер	Process owner	Legal / risk approver при высоком риске	CRM owner	Всегда, если ответ видит клиент

Шаблон: approval gate и журнал решений

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

approval_rule: if action.external_visible == true or action.crm_write == true -> require_human_approval
log_fields: request_id, source_data, ai_recommendation, human_edit, final_action, rejection_reason

Чеклист перед пилотом

Every process step has Responsible and Accountable assigned.
Every external-visible action has human approval before execution.
Data owner has explicitly allowed sources and forbidden data classes.
Pilot report contains reviewed cases, error taxonomy and manual correction rate.

Требования и рекомендации

Требования

У AI-задачи должен быть один process owner, который принимает бизнес-результат.
Должен быть data owner, который отвечает за источники, права доступа, актуальность и запреты на использование данных.
Должен быть quality reviewer, который проверяет выборку результатов и описывает типовые ошибки.
Должен быть approval gate для действий, которые видит клиент или которые меняют учетные системы.
Должен быть журнал решений: вход, модельный вывод, правка человека, финальное действие и причина отказа.

Почему роли важны в AI-внедрении

В отличие от классической разработки, AI-внедрение требует синхронизации трёх слоёв: бизнес-процессов, данных и ИИ-моделей. Если ответственность не распределена — возникают пробелы: продакт думает, что интегратор реализует, интегратор ждёт данных от аналитиков, а аналитики ждут ТЗ. В результате пилот «живёт» 3 месяца, но не выходит в продакшн.

Схема ролей и потоков ответственности

flowchart TD
    A[Бизнес-заказчик
продукт / отдел] -->|ТЗ + KPI| B[Бизнес-аналитик]
    B -->|Сценарий + метрики| C[AI-архитектор]
    C -->|API-спека + архитектура| D[Интегратор]
    D -->|Интеграция + тесты| E[DevOps / SRE]
    E -->|Деплой + мониторинг| F[Бизнес-заказчик]
    
    C -->|Данные: сборка, очистка, разметка| G[Data Engineer]
    G -->|Пайплайн данных| H[ML-инженер]
    H -->|Модель + валидация| C
    
    style A fill:#e6f7ff,stroke:#1890ff
    style F fill:#f6ffed,stroke:#52c41a
    style C fill:#fff7e6,stroke:#fa8c16
    style D fill:#f9f0ff,stroke:#722ed1

Ключевые роли и их ответственность

Бизнес-заказчик (продукт / digital-директор): ставит задачу, определяет KPI, утверждает ROI, отвечает за внедрение в рабочие процессы.
AI-архитектор: проектирует архитектуру решения (агент / API / локально), выбирает подходящий тип ИИ (LLM, RAG, rule-based), определяет границы ответственности.
Интегратор: реализует интеграцию с внутренними системами (CRM, 1С, ERP), пишет обёртки, обрабатывает ошибки, логирует события.
Data Engineer: подготавливает данные: сбор, очистка, структуризация, создание пайплайнов для обучения и инференса.
ML-инженер: настраивает модель, проводит валидацию, управляет версиями, обеспечивает стабильность инференса.
DevOps / SRE: деплоит, настраивает мониторинг (логи, latency, error rate), управляет масштабированием.

Пример: AI-ассистент в отделе продаж

Бизнес-заказчик (продакт): «Нужно автоматизировать первичный отклик на лиды — генерировать письмо на основе brief-формы и CRM-данных, сортировать лиды по потенциалу».

AI-архитектор: решает использовать RAG-архитектуру с привязкой к базе знаний компании + rule-based фильтр по сегментам. API-интерфейс через REST-эндпоинт / webhook.

Интегратор: подключается к CRM (например, Bitrix24), пишет обработчик webhook, добавляет fallback на ручной ввод.

Data Engineer: собирает историю писем, чистит от дублей, размечает типы лидов по конверсии.

ML-инженер: обучает модель на 500+ примерах, тестирует на 100 новых лидов, настраивает порог доверия (0.85).

Типичные ошибки и как их избежать

«Один человек — всё»: если один разработчик делает и архитектуру, и интеграцию, и данные — риски качества и простоя растут в 3 раза. Решение: разделение по фазам — сначала архитектура, потом интеграция.
Бизнес не участвует в тестировании: модель работает идеально на тесте, но не учитывает внутренние правила компании. Решение: включать бизнес-пользователей в UAT с первых итераций.
Интегратор не знает бизнес-контекст: пишет API, но не учитывает ограничения CRM (например, лимиты запросов). Решение: совместная сессия «как работает система» перед началом.

Чеклист: готовность к запуску

[ ] Утверждённая карта процесса (см. «Карта процессов для AI-автоматизации»)
[ ] Определены SLA: latency, uptime, fallback-сценарий
[ ] Доступ к данным: разрешения, объём, частота обновления
[ ] API-спека подписана всеми сторонами (бизнес, архитектор, интегратор)
[ ] Чек-лист Human-in-the-loop: где требуется подтверждение (см. «Human-in-the-loop: где человек должен подтверждать действия»)
[ ] Метрики ROI: как считать эффект (см. «Как считать эффект от AI-автоматизации»)

Псевдокод: обработка интеграции с fallback

POST /api/ai/lead-response
  headers: { "X-CRM-Token": "..." }
  body: { lead_id: 12345, brief: "Интересуется SEO" }

  // 1. Получить данные из CRM
  lead = crm.get_lead(lead_id)
  
  // 2. Проверить, есть ли данные для генерации
  if not lead.has_required_fields():
    return fallback_response("Требуется заполнить: отрасль, бюджет, срок")

  // 3. Вызвать AI-сервис
  ai_response = ai_client.generate_email(
    brief=brief,
    context=lead,
    confidence_threshold=0.85
  )

  // 4. Если confidence < порог — вернуть draft + предложение ручного ревью
  if ai_response.confidence < 0.85:
    return {
      status: "draft",
      email: ai_response.email,
      confidence: ai_response.confidence,
      human_review_required: true
    }

  // 5. Иначе — сохранить в CRM и уведомить продавца
  crm.update_lead(lead_id, ai_response.email)
  notify_sales(lead_id, "Готовый шаблон сгенерирован")