n8n: 480 евро вместо 80 из-за одной единицы измерения

На форуме n8n один из участников разобрал простой пример.

Клиент просит 12 штук, в каталоге цена 40 € за упаковку из

Модель верно извлекла SKU и количество, а прямое умножение «количество × цена» выдало 480 €. По упаковкам счёт был бы 80 €.

Главная мысль статьи: ценность AI-автоматизации определяется валидатором между ответом модели и обязательством перед клиентом.

Сама модель точность расчёта не гарантирует.

Автор поста собрал небольшой пример на Python с синтетическими строками RFQ (запроса коммерческого предложения).

Для этой заявки система выдала статус `review: unit_mismatch` и пустую сумму: она отказалась считать и передала строку человеку.

Девять локальных тестов прошли, среди них битые цены, неизвестные SKU и два легитимных случая, которые валидатор обязан пропустить.

Извлечение отработало на 100%, сломалась бизнес-логика после него.

Заявка выглядела обычной, а цена из письма стала бы обязательством компании перед клиентом.

Большую часть сил команды обычно тратят на качество извлечения: промпт, выбор модели, эталонные примеры. Бизнес-правила при этом остаются в голове у менеджера.

Что такое «штука» для этого товара, кратна ли упаковка, можно ли продать неполную, знает менеджер, а в workflow этих правил нет.

Пока менеджер стоял в процессе, пробел был незаметен.

Когда компания убирает менеджера, каждое неописанное правило начинает стоить денег.

Похожий принцип описывает другой автор в ветке про поддержку клиентов.

Автоматические действия идут только через allow-list вызовов API, а всё, что касается денег, сначала попадает оператору.

Его триаж-конвейер устроен так: элементы классифицируются, LLM пишет черновик ответа, правиловый валидатор проверяет каждый черновик, при провале делается одна повторная попытка с указанием причины. Модель предлагает, правила решают.

В одной ленте за несколько дней три автора описали одну и ту же архитектуру. Маленькие тестируемые эндпойнты.

Поиск по базе и вызовы API вынесены в отдельные функции с тестами, а n8n оркестрирует диалог.

Логика лежит в коде, который можно проверить, а узлы с её скрытыми копиями автор не создаёт. Объяснимые оценки. В описании системы лидогенерации на около 5000 контактов оценка соответствия идёт по шкале от 1 до 10, и для каждой записи показаны факторы, по которым она выставлена.

Человек видит, почему запись помечена, и может поправить правило. Демо без доступов.

Отчёт о пересечениях в Google Calendar поставляется с режимом `demo_mode`.

Пять вымышленных событий превращаются в три занятых окна и одну пересекающуюся пару. Workflow можно импортировать и проверить до подключения учётных данных.

Задача сформулирована по тем же правилам: запись по телефону или прямо в календаре обходит форму бронирования, поэтому отчёт ищет именно то, что форма пропустила.

У автоматизации с ИИ две цены: стоимость сборки и стоимость одной незамеченной ошибки.

Ошибка в RFQ стоит разницы между 80 и 480 €.

Умноженная на поток заявок, она даёт убыток или потерянного клиента.

Бюджет на «ИИ в продажах» оправдан, когда у процесса есть предохранитель.

Без него компания получает красивую демонстрацию, которая не двигает метрику, а в худшем случае двигает её вниз, и отвечает за это тот, кто согласовал бюджет.

Кандидаты на рынке в тех же ветках пишут о себе так: «строю то, что работает, а не презентации о том, что могло бы работать».

Заказчики оценивают исполнителя по работающему контуру с проверками и смотрят на него раньше, чем на список технологий.

В интеграционных проектах KT.Team действует правило: модель не имеет права записи в учётную систему.

Между ней и 1С, Bitrix или Odoo стоит слой проверок, который мы строим вместе с процессом. -

Извлечение данных и бизнес-валидация разделены.

Единицы измерения, кратность упаковки, допустимые диапазоны и справочники проверяет код на Python или C#, который можно покрыть тестами. -

Действия агента ограничены списком разрешённых операций.

Через MCP мы публикуем агенту только инструменты, безопасные для автоматического вызова.

Операции с деньгами уходят в очередь на подтверждение. -

Запросы к моделям проходят через LLM & Security Gateway.

Он фиксирует журнал, лимиты и фильтрацию данных, поэтому любое решение можно восстановить. -

Для ответов по каталогу и регламентам мы используем RAG, где источник каждого утверждения виден и проверяем. -

Оркестрацию в n8n или на Kafka мы строим так, чтобы каждый шаг можно было отключить, не останавливая остальные.

Снаружу результат выглядит просто: заявка пришла, цена посчитана, спорная строка ушла менеджеру.

Эту простоту обеспечивают тесты, справочники и чётко распределённая ответственность между моделью, кодом и человеком.