AI-интегратор: профессия, которой нет в учебнике — я собрал её руками на n8n

Одна из самых востребованных профессий в Европе, США и РФ в 2026–2027, почему это не ML-инженер и не Data Science и как выглядит рабочий контур: webhook → LLM → CRM → Telegram — без команды из десяти человек.

Меня зовут Даниил. Я разработчик интеграций — до этого Kafka, REST, highload. В 2024–2025 мне первый раз поставили задачу, которую HR называет по-разному: AI automation, n8n integrator, applied AI engineer. Я называю это AI-интегратор: человек, который собирает бизнес-процесс из событий, API и LLM — в основном без классического релиза, на no-code/low-code оркестраторе.

Я не ML-инженер. Я не prompt-инженер в вакууме. Я впервые поднял и довёл до рабочего состояния self-hosted n8n с LLM внутри pipeline: событие приходит → модель что-то понимает → данные улетают в Google Sheets, Telegram, amoCRM / Bitrix24.

Тема — другое: на рынке уже ищут AI-интеграторов, а объяснить, как эта работа выглядит изнутри, почти некому. Видео на российском ютубе на данную тему почти нет, а n8n + LLM + CRM — неизведанная зона между «написал скрипт на Python» и «поставил ChatGPT менеджерам».

Цель заключалась в следующем: событие уже случилось, а бизнес всё ещё обрабатывает его руками — таблица, Telegram, CRM, уведомления. Платёжный провайдер или маркетплейс событие доставит — это их зона. А вот что делать дальше — строка в Google Sheets, сообщение в Telegram, лид в CRM — у огромного числа команд до сих пор делается вручную. По разным опросам sales‑отделы тратят четверть рабочего времени на ввод в CRM; почти половина компаний automation‑инструменты так и не внедрила. В зрелых продуктах core‑pipeline автоматизирован. «Последняя миля» для бизнеса — часто Excel, чат и copy‑paste. Именно её я и хотел убрать. Событие пришло — команда ничего не переносит руками: учёт, алерт и CRM обновляются сами. Любое внешнее событие должно за секунды превращаться в действие для бизнеса — с AI внутри процесса, а не вместо процесса. Мне хотелось сделать не разрозненный ingress событий, а единый production — контур для связки. Мне за пару дней удалось собрать self‑hosted контур в Docker:

• n8n — queue mode, PostgreSQL, 3 worker’а, Redis-очередь

• nginx — единая точка входа

• gateway — тонкий слой

• Observability — Prometheus, Grafana, Loki

Workflow, которые реально крутятся:

Это не «одна нода OpenAI ради демо». Это конвейер: событие проходит несколько систем, LLM — шаг в цепочке, как HTTP-запрос или запись в таблицу.

Для данного проекта ограничился ChatGPT: gpt-4o-mini и платформой для бесплатных генераций. Вы можете найти любой, это не так принципиально.

Как это выглядит на практике

Возьмём payment-succeeded — условные 9 752 ₽.

Раньше: событие где-то «принялось», дальше ops смотрит почту/личный кабинет провайдера, сам дописывает строку в таблицу, сам пишет в Telegram, sales сам заводит сделку в amoCRM.

Сейчас — одна цепочка в n8n:

1. Событие → gateway → workflow Google Sheet

2. gpt-4o-mini получает JSON и пишет короткий разбор для ops: что случилось, сумма, на что смотреть

3. Строка сама попадает в Google Sheets

4. В Telegram уходит готовое сообщение — не копипaстa из ЛК провайдера

5. В amoCRM создаётся сделка в нужной воронке

Человек не переносит данные между системами. Он один раз собрал pipeline — и проверяет, что цепочка жива.

Интерфейс n8n правда похож на Draw.io: ноды, стрелки, ветки. За вечер можно собрать webhook → Telegram.

No-code дал скорость. Docker, nginx, gateway и Grafana — чтобы pipeline не рассыпался при первом продакшен-событии.

Agent Router Filter — это не «AGI в чатике». Это маршрутизатор намерений: то, что раньше делал человек — «это лид или просто вопрос?».

Конечно не обошлось и без факапов.

Что происходит с таблицей технически

1. OAuth2 — в n8n credential к Google (Sheets API + Drive API). Один раз Connect → дальше нода пишет от имени сервисного аккаунта / Google-пользователя.

2. Append Row — не trigger, не «открой таблицу и допиши». Каждое новое событие добавляет строку вниз.

3. Маппинг колонок — данные берутся из сохранённого payload (Edit Fields), потому что после Redis-нод текущий $json уже другой:

   timestamp — когда пришло событие
   event — тип (payment_succeeded, payment_failed…)
   amount — сумма
   raw_payload — полный JSON события (архив на случай разбора)

На скрине видно: строка появилась сама — менеджер не создавал её и не копировал из webhook.

4. Порядок в workflow — запись в Sheets идёт после LLM-разбора и до Telegram и amoCRM. Сначала фиксируем факт в журнале, потом уведомляем и создаём сделку.

5. Дубликаты не плодят строки — на gateway idempotency, в workflow dedup через Redis. Повторное событие не доходит до Append Row → в таблице не появляется вторая одинаковая строка.

6. Если Sheets упал — событие не теряется: DLQ + Retry_runner пробует снова. После успешного retry в таблице может появиться строка с маркером retry — ops видит, что это повторная доставка, а не «два разных платежа».

Итог

AI-интегратор в 2026–2027 — однозначно не заменит backend (или не сразу), но привнесет понятную задачу: замкнуть loop «событие → AI → учёт → алерт → CRM» без ручной перекладки.