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, которые реально крутятся:
|
Workflow |
Зачем |
|---|---|
|
Google Sheet |
Главный pipeline: событие → LLM-разбор → Sheets → Telegram → amoCRM |
|
Payment_bot_menu |
Cron генерирует payment-события (симуляция/ops) |
|
Retry_runner |
Повтор из DLQ, если downstream упал |
|
Agent_Router_Filter |
LLM классифицирует intent → лид в CRM / автоответ / уточнение |
Это не «одна нода OpenAI ради демо». Это конвейер: событие проходит несколько систем, LLM — шаг в цепочке, как HTTP-запрос или запись в таблицу.
Для данного проекта ограничился ChatGPT: gpt-4o-mini и платформой для бесплатных генераций. Вы можете найти любой, это не так принципиально.
Как это выглядит на практике
Возьмём payment-succeeded — условные 9 752 ₽.
Раньше: событие где-то «принялось», дальше ops смотрит почту/личный кабинет провайдера, сам дописывает строку в таблицу, сам пишет в Telegram, sales сам заводит сделку в amoCRM.
Сейчас — одна цепочка в n8n:
-
Событие → gateway → workflow Google Sheet
-
gpt-4o-mini получает JSON и пишет короткий разбор для ops: что случилось, сумма, на что смотреть
-
Строка сама попадает в Google Sheets
-
В Telegram уходит готовое сообщение — не копипaстa из ЛК провайдера
-
В amoCRM создаётся сделка в нужной воронке
Человек не переносит данные между системами. Он один раз собрал pipeline — и проверяет, что цепочка жива.
Интерфейс n8n правда похож на Draw.io: ноды, стрелки, ветки. За вечер можно собрать webhook → Telegram.
No-code дал скорость. Docker, nginx, gateway и Grafana — чтобы pipeline не рассыпался при первом продакшен-событии.
Agent Router Filter — это не «AGI в чатике». Это маршрутизатор намерений: то, что раньше делал человек — «это лид или просто вопрос?».
Конечно не обошлось и без факапов.
Что происходит с таблицей технически
-
OAuth2 — в n8n credential к Google (Sheets API + Drive API). Один раз Connect → дальше нода пишет от имени сервисного аккаунта / Google-пользователя.
-
Append Row — не trigger, не «открой таблицу и допиши». Каждое новое событие добавляет строку вниз.
-
Маппинг колонок — данные берутся из сохранённого payload (Edit Fields), потому что после Redis-нод текущий $json уже другой:
timestamp — когда пришло событие
event — тип (payment_succeeded, payment_failed…)
amount — сумма
raw_payload — полный JSON события (архив на случай разбора)
На скрине видно: строка появилась сама — менеджер не создавал её и не копировал из webhook.
-
Порядок в workflow — запись в Sheets идёт после LLM-разбора и до Telegram и amoCRM. Сначала фиксируем факт в журнале, потом уведомляем и создаём сделку.
-
Дубликаты не плодят строки — на gateway idempotency, в workflow dedup через Redis. Повторное событие не доходит до Append Row → в таблице не появляется вторая одинаковая строка.
-
Если Sheets упал — событие не теряется: DLQ + Retry_runner пробует снова. После успешного retry в таблице может появиться строка с маркером retry — ops видит, что это повторная доставка, а не «два разных платежа».
Итог
AI-интегратор в 2026–2027 — однозначно не заменит backend (или не сразу), но привнесет понятную задачу: замкнуть loop «событие → AI → учёт → алерт → CRM» без ручной перекладки.
Источник: habr.com
Оцените материал:
