AI Automation: архитектура внедрения ИИ в операционные процессы
AI automation — не чат-бот и не демо на GPT. Разбираем архитектуру: где workflow, где модель, как считать эффект и почему большинство пилотов не доходит до продакшена.
Что на самом деле означает AI automation
AI automation — это не отдельный продукт и не «нейросеть вместо сотрудника». Это слой обработки неструктурированных данных и решений внутри уже существующего процесса: CRM, документооборота, поддержки, продаж или производства. Ценность появляется не от факта использования модели, а от того, что конкретный ручной шаг перестаёт требовать человека.
Граница ответственности должна быть явной с самого начала. Правила, которые можно записать как «если-то» — смена статуса после оплаты, расчёт скидки по прайсу, маршрутизация по региону — остаются в детерминированном коде. Модель отвечает за то, что требует понимания смысла: свободный текст письма, фото дефекта, голосовое обращение, неструктурированный документ.
Почему демо не доезжает до продакшена
Большинство пилотов AI automation умирает на переходе от чат-интерфейса к встроенному в процесс сервису. Демо показывает, что модель умеет отвечать; продакшен требует, чтобы система умела повторить запрос после сбоя, не терять события, соблюдать права доступа и не создавать дубликаты действий.
Второй частый провал — выбор технологии раньше процесса: компания покупает подписку на «AI-платформу», а затем ищет задачу под неё. Рабочий порядок обратный — сначала аудит процесса и данных, потом выбор архитектуры (workflow, интеграция, RAG, агент), и только затем модель.
Референсная архитектура автоматизации
Независимо от домена (CRM, документы, поддержка, продажи, производство) устойчивый паттерн один: событие → очередь → сервис оркестрации → сбор ограниченного контекста → вызов модели → валидация структурированного ответа по схеме → запись результата в систему-источник правды. Очередь отделяет медленный AI-вызов от пользовательской операции и позволяет безопасно повторять запросы.
Каждый сценарий получает собственный контракт данных и идемпотентный ключ, а не общий «универсальный агент». Классификация обращения, генерация черновика документа и next-best-action — это разные контракты с разными допустимыми полями, даже если под капотом используется одна модель.
Guardrails и постепенное расширение автономии
На старте AI automation должна готовить черновики и рекомендации, а не выполнять необратимые действия. Отправка письма клиенту, изменение цены, закрытие сделки, остановка производственной линии — операции, которые требуют подтверждения человеком или жёсткого бизнес-правила поверх модели.
Автономию расширяют только после накопления статистики ошибок на реальных сценариях, а не по расписанию проекта. Нужны allowlist полей и действий, лимиты значений, фильтрация входа (защита от prompt injection), валидация выхода и журнал аудита с версией prompt, моделью и источниками контекста для каждого результата.
Как измерять эффект и когда масштабировать
Технические метрики — задержка, доля валидных структурированных ответов, стоимость вызова, число повторов. Бизнес-метрики зависят от процесса: время обработки заявки, доля карточек с корректно заполненными полями, время подготовки документа, число ручных правок в черновике модели.
Безопасный путь — один процесс, контрольная группа и 2–4 недели сравнения с прежним способом работы. Если AI automation только переносит труд с написания текста на исправление плохих черновиков, сценарий не готов к масштабированию на соседние процессы.
Чек-лист перед переходом пилота в продакшен
- — Сценарий имеет собственный контракт данных и идемпотентный ключ — не общий «универсальный агент»
- — Необратимые действия (письмо клиенту, изменение цены, остановка линии) требуют подтверждения или жёсткого правила
- — Есть allowlist полей и действий, лимиты значений и фильтрация входа от prompt injection
- — Журнал аудита фиксирует версию prompt, модель и источники контекста для каждого результата
- — Пилот идёт на одном процессе с контрольной группой минимум 2–4 недели, а не сразу на весь отдел
- — Определены технические метрики (задержка, доля валидных ответов, стоимость) и бизнес-метрики процесса
RPA vs AI automation
| RPA | AI automation | |
|---|---|---|
| Вход | Структурированный, фиксированный формат | Неструктурированный: текст, фото, речь |
| Логика | Жёсткая последовательность кликов/полей | Модель интерпретирует смысл, правила остаются в коде |
| Устойчивость к смене интерфейса | Низкая — ломается при смене макета | Выше, если контракт данных не завязан на макет |
| Типичная задача | Перенос данных между системами по шаблону | Классификация обращения, извлечение из письма, черновик документа |
FAQ
AI automation — это то же самое, что RPA?
Нет. RPA автоматизирует фиксированную последовательность кликов и полей. AI automation добавляет слой понимания неструктурированных данных — текста, изображений, речи — там, где правило нельзя записать одной инструкцией.
Нужна ли отдельная AI-платформа для старта?
Обычно нет. Для одного сценария достаточно очереди событий, вызова модели с валидацией и записи результата в существующую систему — CRM, ERP или документооборот.
Сколько времени занимает переход от пилота к продакшену?
На одном процессе с понятным контрактом данных — от 4 до 8 недель, включая обработку ошибок, guardrails и передачу команде. Более широкие сценарии требуют отдельного аудита.