Автоматизация процессов — с ИИ только там, где вход грязный

Проектирую и внедряю автоматизацию там, где поставка упирается в ручные шаги — а не в нехватку дашбордов. Базовый путь всё ещё процесс: триггер, проверка, выполнение, наблюдение, восстановление. Модель входит, когда вход неструктурирован или решение неоднозначно. Она не входит потому, что «автоматизация» и «ИИ» теперь один слайд. Собирал бэкенды автоматизации, контентные пайплайны и продуктовые потоки с ИИ. Результат, который важен: процесс переживает плохой ввод, повторы и ночную смену — и человеческий путь, когда не переживает.

Кому это подходит

  • Операционным и продуктовым руководителям, у которых SLA съедает копипаст между системами.
  • Компаниям, которые тонут в неструктурированных документах, тикетах или контенте, где последние 10% всё равно за человеком.
  • Командам, которые купили no-code автоматизацию и упёрлись в обработку отказов.

Для каких проблем

  • Процесс работает на счастливом пути и разваливается на втором исключении.
  • Люди — слой интеграции между SaaS.
  • В процесс вставили LLM там, где нужны были форма и политика повторов.
  • Никто не может сказать, сэкономила автоматизация часы или создала тихие ошибки.

Что ставлю

  • Карта процесса, которая находит настоящее узкое место, а не самое громкое.
  • Детерминированная оркестрация с идемпотентностью, повторами и мёртвыми письмами.
  • Извлечение и классификация моделями только там, где вход грязный.
  • Очереди с человеком для случаев, которые нельзя коммитить автоматически.
  • Измерение: цикл, доля ошибок, стоимость прогона — против исходного ограничения.

Как идёт работа

Диагностирую ограничение. Отделяю правила, интеграции и настоящую неоднозначность. Сначала автоматизирую скучный путь, чтобы модель не компенсировала отсутствующую инженерию. Проверяю на живых случаях, включая некрасивые. Затем продакшен: типизированные полезные нагрузки, наблюдаемость и кнопка стоп.

Когда процессу не нужна модель

Большинство запросов «ИИ-автоматизации» — запросы на процесс. Это не меньшая работа. Обычно это правильная.

Если вход уже структурирован — пишите код

Смена статуса, оплаченный счёт, заполненная форма — это очереди и API. Модель здесь — задержка и новый класс ошибок.

Если выход — побочный эффект, нужен контракт

Создать тикет, двинуть деньги, опубликовать контент — это не chat completion. Сначала проверка, потом выполнение. Никогда не выполнять из прозы.

Если исключений много — сначала путь исключения

Автоматизация, которая закрывает 70% и сбрасывает остальное в общий ящик, делает работу хуже. Очередь, SLA, хозяин.

Если нельзя назвать часы, которые покупаете — подождите

Автоматизация ради нарратива — продуктовая фича. Операционной автоматизации нужна цифра, хотя бы грубая.

Как это ломается

  • Графы в духе Zapier, которые нельзя безопасно повторить.
  • Промпт модели «будь стажёром» на пять инструментов с сохранёнными паролями.
  • Нет ключей идемпотентности — таймаут отправляет дважды.
  • Успех измеряют как «демо прошло», а не долю ошибок на второй неделе.

Результат

  • Схема процесса с хозяевами, системами и путями исключений.
  • Рабочий процесс с повторами, наблюдаемостью и человеческой очередью.
  • Ясные правила, когда модель может предлагать, а когда — коммитить.
  • План измерения против исходного узкого места.

Избранные проекты

  • SynopsysПродуктовый UI в Synopsys для бенчмаркинга и сравнения больших языковых моделей, включая поверхности пробного вывода для экспериментов с генеративным ИИ.
  • Genie PlatformsРазговорная AI-платформа для продаж, RevOps и GTM – AI-SDR внутри существующих процессов выручки.
  • PlatSaaS для захвата, проверки и распределения лидов в реальном времени.

Связанные услуги

  • Интеграция ИИМодель внутри существующего процесса — с контрактами и выходом, а не чатбот рядом с продуктом.
  • ИИ-агентыАгенты с инструментами для ограниченного процесса, с правами и оценками — не автономный сотрудник.
  • Заказная разработкаПродуктовая инженерия для команд, которым нужен старший разработчик, а не цепочка подрядчиков.

Связанные заметки

Вопросы, которые задают

Это RPA?

Не в смысле «водить GUI приложения 1998 года». Автоматизирую через API, очереди и проверенный вывод модели. Если единственный интерфейс — хрупкий UI, стоит говорить, не заменить ли систему, вместо того чтобы ею управлять как марионеткой.