Всем привет, с вами Низамов Илья. Разберём, как выглядит внедрение ИИ-агентов в компании, где уже есть учётная система, склад и живые клиенты, а не демо-стенд с игрушечным чат-ботом. Я делаю такие проекты как программист 1С и разработчик ИИ, поэтому смотрю на них с двух сторон сразу: и со стороны модели, и со стороны базы, откуда агент берёт цифры. Дальше по шагам: как выбрать процесс, сколько на самом деле занимает пилот, что ломается на интеграции, из чего складывается смета и по каким числам понять, что агент работает. Цифры даю только те, за которые ручаюсь; где точной нет — называю порядок величины и то, от чего он зависит.
Сразу договоримся о словах. Агент — это не чат-бот со сценарием и не «умный автоответчик». Чат-бот отвечает текстом по базе знаний. Агент вызывает инструменты: смотрит остаток, берёт цену по договору конкретного контрагента, заводит документ. Разница не в модели, а в том, что у агента есть руки, и именно эти руки и составляют почти всю работу по проекту.
Какой процесс вообще стоит отдавать агенту
Внедрение ИИ-агентов в бизнес-процессы проваливается не на модели. Оно проваливается на выборе процесса: берут тот, который громче болит, а не тот, который агент способен закрыть.
Годный кандидат выглядит так:
- Обращения повторяются. Хотя бы 30–50 однотипных вопросов в неделю. На пяти обращениях любой агент дороже человека, и никакая экономика этого не спасёт.
- Данные для ответа лежат в системе. Остаток, цена по договору, статус заказа — всё это должно быть в базе, а не в голове менеджера и не в его переписке. Модель не угадает то, чего нет в данных.
- Есть письменный источник правды. Регламент, прайс, база знаний, набор эталонных ответов. Без него правильность ответа не с чем сверить — ни агенту, ни приёмке.
- Ошибка видна сразу и обратима. Неверная фраза в чате правится менеджером за минуту. Неверная проводка в учёте — уже инцидент, и такой процесс в первый пилот не берут.
- У процесса есть владелец на стороне заказчика. Человек, который читает диалоги, отвечает на вопросы по бизнес-логике и подписывает приёмку.
Признаки процесса, который отдавать не надо, ровно зеркальны, и три из них встречаются чаще всего. Первый: каждое обращение уникально — консультации, где половина ответа зависит от осмотра объекта или выезда. Второй: ответ требует юридической или финансовой ответственности — расчёт налога, гарантийное обязательство. Тут агент годится максимум на черновик, который проверит человек. Третий, самый частый: нужных данных просто нет в системе. Ни одна модель не расскажет про остаток на складе, если склад ведётся в тетради, а «остатки в 1С» расходятся с реальностью на треть.
Отдельно про мотив. Если задача звучит как «нам нужен ИИ, придумайте куда» — это не задача, а бюджет в поисках применения. Такие проекты доходят до красивой демонстрации и умирают, потому что мерить в них нечего.
Три этапа внедрения и честные сроки
Внедрение ИИ-агентов делится на три этапа, и они устроены не как «разработка → сдача», а как последовательное снятие неопределённости.
Этап 0. Разбор процесса. Несколько дней. Смотрим, на что реально уходит время: выгружаем переписку за месяц, считаем, какие вопросы повторяются и сколько их. Здесь же выясняется главное — есть ли нужные данные в базе и в каком они состоянии. Этот этап у меня бесплатный, и не из щедрости: без него нельзя назвать ни срок, ни цену, а называть их наугад — способ поссориться на втором месяце.
Этап 1. Пилот, 2–3 недели. Один канал, один тип вопросов, работа на реальных данных заказчика. Цель пилота — не «показать, что ИИ умеет», а увидеть агента на настоящих диалогах до того, как вкладываться в полный проект. На пилоте почти всегда всплывает то, чего не было в постановке: клиенты спрашивают не так, как думал отдел продаж, а половина вопросов оказывается не про товар, а про доставку.
Этап 2. Интеграция с учётной системой, 4–6 недель. Основная инженерная работа. HTTP-сервисы или расширение конфигурации на стороне 1С, права по контрагентам, оформление документов, подключение остальных каналов. Здесь же — обработка всех случаев, когда данных нет или сервис недоступен.
Этап 3. Продакшен и сопровождение, постоянно. Агент — не коробка, которую поставили и забыли. Первые месяц-два вы читаете диалоги и правите формулировки и сценарии почти каждую неделю. Дальше реже, но никогда не до нуля: меняется ассортимент, появляются новые вопросы, обновляется модель.
Про сроки честно: «две недели под ключ» бывает только там, где агент отвечает по выгруженному файлу и никуда не ходит. Как только появляется живая учётная система, срок определяется не скоростью написания промптов, а тем, сколько времени займёт согласование доступа к базе, публикация сервисов и разбор того, почему в справочнике номенклатуры три позиции с одинаковым артикулом.
Интеграция с учётной системой: где живёт основная работа
Модель в таком проекте — самая простая часть. Основное время уходит на слой инструментов: набор функций, которые агент вызывает вместо того, чтобы фантазировать. «Получить остаток по артикулу», «получить цену для контрагента», «найти аналог», «создать заказ». Именно этот слой отвечает за то, что агент говорит правду.
Со стороны 1С это обычный HTTP-сервис, опубликованный из расширения — типовую конфигурацию трогать не нужно, обновления после этого проходят штатно. Ключевая деталь, на которой ошибаются: контрагента нельзя брать из тела запроса. Иначе клиент, продиктовавший агенту чужой ИНН, получит чужие цены. Контрагент определяется по пользователю публикации, под которым агент подключился к базе:
Функция ОстаткиPOST(Запрос)
// Контрагент берётся из пользователя публикации, а не из тела запроса:
// иначе через диалог можно вытащить чужие цены и чужие заказы.
ИмяПользователя = ПользователиИнформационнойБазы.ТекущийПользователь().Имя;
Контрагент = ИнтеграцияАгента.КонтрагентПоПользователю(ИмяПользователя);
Если НЕ ЗначениеЗаполнено(Контрагент) Тогда
Возврат ОтветJSON(403, Новый Структура("error", "Пользователь не сопоставлен с контрагентом"));
КонецЕсли;
Тело = ПолучитьСтрокуИзДвоичныхДанных(Запрос.ПолучитьТелоКакДвоичныеДанные(), "UTF-8");
Данные = ПрочитатьДанныеJSON(Тело);
Артикул = Данные.Получить("article");
Результат = Новый Структура;
Результат.Вставить("article", Артикул);
Результат.Вставить("stock", ИнтеграцияАгента.ОстатокПоАртикулу(Артикул));
Результат.Вставить("price", ИнтеграцияАгента.ЦенаДляКонтрагента(Артикул, Контрагент));
Возврат ОтветJSON(200, Результат);
КонецФункцииТело читается двоичными данными и декодируется в UTF-8 руками — возьмёте строку напрямую, и кириллица приедет битой. Пользователь для агента заводится отдельный, с минимальным набором ролей: агент не ходит в базу под администратором, даже если так быстрее запустить пилот.
Со стороны Python инструмент — тонкая обёртка над этим сервисом. Важно в ней не удобство, а то, что она возвращает в плохих случаях:
@tool
def get_stock(article: str) -> str:
"""Остаток и цена по артикулу для текущего клиента. Данные берутся из 1С."""
try:
resp = requests.post(ONEC_URL, json={"article": article},
auth=AUTH, timeout=10)
resp.raise_for_status()
except requests.RequestException:
# «Сервис лежит» и «товара нет» — разные ситуации, и модель
# обязана их различать, иначе она сообщит клиенту «нет в наличии».
return "СЕРВИС_НЕДОСТУПЕН: получить остаток не удалось"
data = resp.json()
if data.get("stock") is None:
return f"НЕ_НАЙДЕНО: артикула {article} нет в базе"
return f"Артикул {article}: остаток {data['stock']}, цена {data['price']}"В системном промпте под это пишется жёсткое правило: увидел СЕРВИС_НЕДОСТУПЕН — скажи честно, что данные сейчас недоступны, и позови менеджера; увидел НЕ_НАЙДЕНО — уточни артикул, но не называй количество. Без такого разделения модель на любую ошибку инструмента отвечает бодрым «этой позиции нет в наличии», и это худший вариант из возможных: клиент уходит, а вы об этом не узнаете.
Операции записи (создать заказ, оформить возврат) выносятся отдельно и закрываются двумя вещами: подтверждением человека и идемпотентным ключом, чтобы повторный вызов не наплодил дубли документов. Механика цикла «агент ↔ инструменты» на LangGraph — с рабочим кодом графа, памятью и условными переходами — разобрана в статье про ИИ-агента на LangGraph для 1С. Если агенту нужны не операции, а ответы по документации и регламентам, это другой слой — RAG на LangChain. Какая из трёх архитектур подходит под вашу задачу, разобрано в статье про внедрение ИИ в 1С.
Что ломается на практике
Список короткий и на удивление устойчивый от проекта к проекту.
Качество данных. Самая частая причина буксующего пилота. Дубли номенклатуры, пустые характеристики, «остаток» с учётом резервов и без, цены в трёх разных регистрах. Пока человек отвечает клиенту, он молча компенсирует этот бардак опытом. Агент компенсировать не умеет — он показывает состояние данных как есть, и это первый по-настоящему полезный эффект внедрения, ещё до всякой автоматизации.
Галлюцинации на цифрах. Модель, у которой не получилось вызвать инструмент, охотно назовёт правдоподобное число. Лечится не «улучшением промпта», а архитектурой: любое число в ответе приходит из инструмента, никогда — из головы модели. Плюс проверка на выходе: если в ответе есть цифра, которой не было в результатах вызовов, ответ не уходит клиенту.
Права доступа. В B2B это вопрос номер один. Агент разговаривает одновременно с десятком контрагентов, и каждый должен видеть только своё: свою цену, свои заказы, свою задолженность. Изоляция делается на стороне учётной системы, а не на стороне модели. Инструкция в промпте «не показывай чужие данные» — не защита, а пожелание.
Нет владельца процесса. Технически проект может быть готов, а внедрение стоять. Некому сказать, правильный ли ответ дал агент в спорном диалоге, некому решить, что делать с вопросами про доставку, некому подписать приёмку. Роль владельца стоит 2–4 часа в неделю на время пилота, и её надо назвать поимённо до старта, а не «мы там посмотрим».
Сопротивление сотрудников. Ожидаемо и нормально. Проявляется в форме «агент отвечает ерунду» без единого примера. Лечится логами: все диалоги видны, спорные разбираются на еженедельной встрече, у менеджера есть кнопка забрать диалог себе. Когда становится видно, что агент снял ночные обращения и переписку про «а есть ли на складе», сопротивление обычно проходит само.
Риски внедрения ИИ-агентов и как их снимают
Риски внедрения ИИ-агентов делятся на технические и организационные, и снимаются они по-разному.
| Риск | Как проявляется | Чем снимается |
|---|---|---|
| Агент назвал неверную цену или остаток | Клиент требует продать по названной цене | Все числа только из инструментов; отказ отвечать при недоступности сервиса |
| Утечка данных в облачную модель | Переписка и данные клиентов уходят на чужие серверы | Локальная модель в своём контуре либо обезличивание; отдельный пользователь 1С с минимальными правами |
| Клиент видит чужие данные | В диалоге всплывают цены или заказы другого контрагента | Изоляция на стороне 1С: контрагент из сессии, а не из запроса |
| Лишние документы в базе | Дубли заказов после повторного вызова инструмента | Подтверждение человеком на операциях записи и идемпотентный ключ |
| Проект без владельца | Пилот висит месяцами, приёмка не наступает | Назначенный владелец процесса, 2–4 часа в неделю, критерии приёмки до старта |
| Зависимость от одного провайдера модели | Меняется цена или снимается версия модели | Слой абстракции над API и набор эталонных диалогов, на котором проверяется замена модели |
| Эффект есть, но не виден | Спор об окупаемости превращается в спор о вкусах | Замер метрик до внедрения: без цифры «до» доказать эффект нельзя |
Отдельно про приватность. Если переписка с клиентами или данные из базы не должны покидать контур компании — это не риск, который «снижают», а требование, которое определяет архитектуру: модель ставится локально, на своё железо. Тогда вопрос переходит из области безопасности в область экономики, и об этом ниже.
Сколько стоит внедрение и когда оно не окупается
Смета складывается из четырёх частей, и только одна из них разовая по-настоящему.
- Разбор процесса и постановка. У меня — бесплатно, и я считаю это правильным: пока не посмотришь на реальную переписку и на состояние базы, цена будет выдумкой.
- Пилот. Фиксированная сумма, известная до старта. У меня пилот на одном сценарии — от 150 000 ₽: один канал, база знаний по вашим товарам, без записи в 1С.
- Интеграция с учётной системой. Основная часть, считается по техническому заданию. Объём зависит от трёх вещей: сколько каналов подключаем, нужна ли агенту запись в базу или хватит чтения, и насколько сложна логика подбора товара. Одну цифру за «агента с 1С» назвать честно нельзя — поэтому вход прозрачный, а полную смету считаем после ТЗ.
- Сопровождение. Постоянная статья расходов. Диалоги читают, сценарии правят, ассортимент меняется.
Дальше — ежемесячные расходы на саму модель, и здесь два сценария. Облачные токены: один диалог из десятка реплик с вызовами инструментов на модели среднего класса стоит порядок единиц рублей. Тысяча диалогов в месяц — это тысячи рублей, а не десятки тысяч. Но цифра легко вырастает в разы, если к каждому запросу подмешивается длинный контекст: история переписки, куски документации, выдача поиска. Свой сервер: GPU-сервер под локальную модель — это сотни тысяч рублей единовременно плюс человек, который его обслуживает. Зато предельная стоимость запроса почти нулевая. Порог перехода проходит там, где поток измеряется тысячами запросов в день, либо там, где данные нельзя отдавать наружу вообще — тогда считать нечего, требование сильнее экономики.
Когда внедрение не окупается деньгами:
- поток меньше нескольких десятков обращений в неделю — экономия часов не покрывает даже сопровождение;
- каждый второй вопрос уникален и требует человеческого решения — агент заберёт слишком малую долю;
- нужных данных нет в системе — сначала проект по наведению порядка в учёте, потом агент;
- освободившееся время никуда не девается. Это самый неприятный пункт: часы сняли, но люди не взяли больше сделок и никого не перестали нанимать. Тогда экономия остаётся на бумаге.
Прикиньте свой случай на калькуляторе: он считает часы, деньги и срок возврата, а если не окупается — показывает, какой поток обращений для этого нужен.
Как понять, что агент работает
Мерить надо до, а не после. Если замера «до» нет, спор об эффекте превращается в обмен впечатлениями, и выигрывает тот, кто громче.
Что снять до внедрения: среднее время первого ответа клиенту; долю обращений, приходящих вне рабочего времени; число диалогов, оставшихся без ответа дольше часа; конверсию «обращение → заказ»; сколько часов в неделю менеджеры тратят на однотипные вопросы. Последнее считается не опросом, а по выгрузке переписки.
Что проверяется на приёмке. Берётся набор из 50–100 реальных диалогов, агент прогоняется по ним, ответы размечаются на три корзины: верно, неполно, неверно. Дальше — жёсткое требование: доля фактически неверных ответов по данным из базы должна быть нулевой. Не «низкой» — нулевой, потому что неверный остаток или цена дороже любой экономии. А вот доля «не знаю, зову менеджера» — нормальная, это правильное поведение агента, и торгуемся мы именно за неё: чем ниже, тем полезнее агент, но никогда за счёт первой цифры.
Что смотреть в проде: доля диалогов, закрытых без человека; время ответа; доля эскалаций к менеджеру; расход токенов на диалог (растёт — значит контекст распух); и раз в неделю — выборочное чтение десятка диалогов глазами. Последний пункт нельзя автоматизировать, и он ловит больше, чем все метрики вместе.
Чего мерить не стоит: «рост эффективности», «удовлетворённость» без методики и любые проценты, взятые из чужих отраслевых отчётов. У себя вы меряете свои диалоги и свои часы.
С чего начать
Порядок, который работает: выгрузить переписку за месяц → посчитать, какие вопросы повторяются → проверить, есть ли ответы на них в базе → взять один сценарий и сделать пилот на реальных данных. Не «внедрить ИИ в компанию», а закрыть один конкретный процесс и измерить результат.
Пример того, как это выглядит в законченном виде — кейс ИИ-агента продаж автозапчастей в Avito: агент ведёт переписку с покупателем и отвечает по реальным остаткам из 1С, получая их через очередь RabbitMQ. Один канал, один тип вопросов, честная интеграция с учётной системой. Если нужен такой же под свои процессы — посмотрите условия и состав работ на странице разработка ИИ-агента с доступом к 1С: разбор процесса бесплатный, пилот с фиксированной ценой.
Хотите собирать таких агентов сами? На курсе «ChatGPT и нейросети для 1С» есть группа уроков про ИИ-агентов: цикл «агент ↔ инструменты» на LangGraph, RAG по своей базе знаний и подключение к 1С через HTTP-сервисы — то есть ровно тот слой, в котором и живёт внедрение.
Главное, что стоит унести из статьи: внедрение ИИ-агентов — это на 20 % работа с моделью и на 80 % работа с данными, правами и процессом. Компании, у которых получается, начинают с одного узкого сценария и с замера «до». Компании, у которых не получается, начинают с покупки платформы.