«У нас всё в 1С — загрузите её в нейросеть, и агент будет всё знать» — самая частая формулировка задачи и самая дорогая ошибка в проектах, где AI работает с данными 1С. Цена у неё конкретная: агент называет клиенту вчерашний остаток или прошломесячную цену, менеджер извиняется, а проект через два месяца признают неудачным, хотя модель тут ни при чём. Дело в том, что 1С содержит два принципиально разных типа данных, и агент должен работать с ними разными механизмами. Я разберу, где проходит граница, через что идёт обмен и что проверить в своей базе до старта.
Два слоя данных 1С, которые AI читает по-разному
Внутри 1С лежат вещи, которые кажутся однородными, но для AI-агента различаются радикально. Первый слой — оперативные данные: остатки, цены, статусы заказов, взаиморасчёты, номенклатура, контрагенты. Второй — справочные тексты: регламенты, условия работы, описания услуг, правила возврата.
Разница не в формате хранения, а в двух свойствах: как часто данные меняются и допускают ли они пересказ. Оперативные меняются ежечасно и требуют точности до копейки. Справочные меняются раз в месяцы и допускают изложение своими словами.
Оперативные данные агент спрашивает у 1С в момент ответа. Справочные — заранее кладутся в базу знаний. Смешивать эти два механизма нельзя: получите либо устаревшие цифры, либо неработающий поиск.
Слой первый: то, что спрашивают живьём
Остаток на складе, цена для конкретного контрагента, статус заказа, сумма задолженности — это данные, которые нельзя «запомнить». Любая попытка зафиксировать их заранее означает, что агент будет называть вчерашние цифры.
Поэтому агент обращается к 1С прямо во время разговора. Клиент спрашивает «есть ли товар на складе» — система выполняет запрос и отвечает актуальным числом, а не воспоминанием. Механизм называется вызовом инструментов: модель понимает, что для ответа нужны данные, формирует запрос, получает результат и излагает его человеческим языком.
Практическое следствие для проекта: этот слой требует не «обучения», а рабочего канала обмена с 1С. Если канала нет, никакая настройка модели проблему не решит.
Слой второй: то, что становится базой знаний
Условия доставки, правила возврата, описания услуг, требования к оформлению документов — это текст, который агент должен уметь пересказать. Он загружается в базу знаний заранее и обновляется по мере изменения.
Неприятная новость, которую лучше узнать до старта: в типовой 1С этого слоя часто почти нет. Система прекрасно хранит числа и плохо — текстовые регламенты. Их приходится собирать из полей-описаний номенклатуры, из внешних документов или из голов сотрудников. Это реальная часть работы, и её стоит заложить в срок.
Четыре механизма обмена между 1С и агентом
Выбор механизма — инженерное решение, а не вопрос вкуса: он определяет, насколько свежими будут данные, сколько разработки понадобится и какую нагрузку получит рабочая база.
| Механизм | Для чего | Особенности |
|---|---|---|
| HTTP-сервисы 1С | Живые запросы: остаток, цена, статус | Пишутся под конкретные сценарии, дают полный контроль над форматом |
| OData-интерфейс | Чтение справочников и документов | Включается штатно, не требует разработки под каждый запрос |
| Регламентная выгрузка | Наполнение базы знаний справочным текстом | По расписанию, обычно раз в сутки |
| Слой-посредник над 1С | Сведение 1С, CRM и телефонии в один контур | Нужен, когда данные для ответа лежат в разных системах |
Общее для всех четырёх: агент читает данные через штатные интерфейсы обмена и ничего не меняет внутри 1С. Это снимает главное опасение любой компании с боевой учётной системой — что внедрение её сломает.
Пять вопросов к своей команде до старта
Эти вопросы мы задаём до того, как обсуждать сроки и стоимость: от ответов зависит объём работ сильнее, чем от выбора модели.
- Какая конфигурация. Управление торговлей, ERP, Бухгалтерия, Комплексная или самописная — от этого зависит объём работ по обмену.
- Коробка или облако. В арендованных конфигурациях доступ к обмену бывает ограничен провайдером.
- Есть ли уже интеграции. Если 1С уже обменивается с сайтом или CRM, канал наполовину готов.
- Насколько чисты справочники. Дубли номенклатуры и пустые описания придётся чистить до, а не после.
- Кто сопровождает 1С. Свой специалист, франчайзи или подрядчик — с ним предстоит стыковаться.
Три ошибки, после которых агент бесполезен
Выгрузить всё и «скормить» модели. Дамп таблиц — худшее сырьё для языковой модели: она увидит поток однообразных строк и не научится ни фактам, ни поведению.
Положить цены в базу знаний. Кажется удобным и гарантирует, что через неделю агент будет называть неверные суммы.
Отложить чистку справочников. Агент не улучшает данные, он их озвучивает. Дубли и пустые описания он воспроизведёт уверенно и дословно.
Если на вопрос «где у вас записаны условия возврата» никто не может показать документ, то базы знаний пока нет — и первым шагом будет её сборка, а не подключение модели.
Что делать, если конфигурация сильно доработана
Типовая конфигурация — исключение, а не правило: у большинства компаний 1С дорабатывалась годами, и стандартные механизмы обмена в ней работают не так, как в документации.
Практическое следствие — сроки. Работы по обмену с доработанной конфигурацией занимают заметно больше, чем с типовой, и оценивать их до знакомства с конкретной базой бессмысленно. Первый вопрос подрядчику здесь не «умеете ли вы работать с 1С», а «как вы оцените объём после того, как посмотрите нашу конфигурацию».
Второе следствие — зависимость от вашего специалиста по 1С. Он единственный, кто знает, где что доработано и почему. Его участие нужно планировать в часах и согласовывать заранее: типичная задержка проектов — не сложность задачи, а занятость этого человека.
Как не создать лишнюю нагрузку на базу
Живые запросы к 1С означают, что каждое обращение клиента превращается в запрос к рабочей базе. При заметном потоке это уже нагрузка, и она приходит в те же часы, когда база нужна бухгалтерии и складу.
Снижается это несколькими приёмами. Кэширование того, что меняется редко: цены прайса можно обновлять раз в час, а не спрашивать при каждом вопросе. Ограничение частоты обращений. Отдельная точка входа для внешних запросов, чтобы их можно было выключить, не трогая остальное.
И обязательное условие: нагрузочная проверка до запуска, а не после первой жалобы на то, что база «стала тормозить». Она недорогая и снимает самый неприятный класс конфликтов — когда AI-проект обвиняют в проблемах, к которым он может не иметь отношения. Проверять стоит в часы пиковой работы бухгалтерии и склада, а не ночью, когда база свободна.
Когда данные в 1С неполные
Расчёт на то, что в учётной системе всё есть, обычно не оправдывается. Часть сведений живёт в почте, часть в таблицах, часть в голове менеджера, а в 1С попадает только то, что нужно для учёта.
Обнаруживается это на конкретных вопросах. Статус заказа в системе есть, а причина задержки — нет. Цена есть, а условия персональной скидки — в переписке. Агент, отвечающий строго по 1С, будет формально прав и практически бесполезен.
Порядок действий: до интеграции пройти двадцать реальных вопросов клиентов и по каждому проверить, есть ли ответ в базе. Список вопросов без ответа и есть план работ — иногда это доработка учёта, иногда отдельный справочник, иногда решение отвечать на такие вопросы человеком.
Что с персональными данными
Данные контрагентов из 1С почти всегда содержат персональные данные. Отсюда два требования, которые стоит зафиксировать до начала работ: контур разворачивается так, чтобы данные не покидали периметр компании или как минимум оставались в российской юрисдикции, а в базу знаний карточки клиентов не попадают вообще — там место только справочному тексту.
Когда агент поверх 1С не нужен
Подключение агента к 1С — это канал обмена, база знаний, чистка справочников и сопровождение. Всё это имеет смысл, только если клиенты или сотрудники действительно задают много однотипных вопросов, ответы на которые лежат в учётной системе.
Агент не нужен, если таких вопросов в день единицы и менеджер отвечает на них за минуту, открыв карточку. Он не окупится, если ответы на большую часть вопросов не лежат в 1С вовсе, а живут в переписке и головах: тогда сначала придётся наводить порядок в учёте, и эта работа полезна сама по себе, без всякой модели. И рано внедрять, если у 1С нет человека, который сопровождает базу и может выделить время на обмен: проект встанет на его занятости, а не на технологии.
Иногда задача решается проще: отчёт по остаткам, который склад рассылает менеджерам утром, или личный кабинет клиента со статусом заказа. Если такое решение закрывает большую часть вопросов, мы на разборе так и говорим — модель здесь лишняя.
С чего начать проверку на своей базе
Главное, что меняет разделение на два слоя, — постановку задачи. Вместо «подключите нейросеть к 1С» получается два отдельных вопроса: какие оперативные данные агент должен запрашивать живьём и есть ли у вас справочный текст, из которого собирается база знаний. На первый отвечает ваш специалист по 1С, на второй — владелец процесса.
Проверить готовность можно за неделю без подрядчика. Возьмите реальные вопросы клиентов за последний месяц и разложите их на три группы: ответ лежит в оперативных данных 1С, ответ есть в документах, ответа нет нигде. Соотношение групп покажет и объём работ, и то, какую долю вопросов агент сможет закрыть. Эта доля и становится метрикой пилота: сколько вопросов агент закрывает без человека и сколько раз назвал устаревшую цифру.
Что именно класть в базу знаний и чего нельзя — в разборе базы знаний AI-агента. Почему нельзя «обучить модель на 1С» — в статье про дообучение против базы знаний. Как идёт работа по этапам с проверкой на ваших данных — на странице внедрения ИИ.
