Как подготовить данные 1С для искусственного интеллекта: AI-ready архитектура

Почему LLM нужна подготовленная основа

Большая языковая модель работает с теми связями и определениями, которые доступны ей в данных. 
Если в 1С выручка связана с несколькими показателями – продажами, отгрузками и оплатами – модель не знает, какой из них использовать для ответа.

Ошибки и неоднозначность

Возьмем выручку. В 1С:ERP ее можно рассчитывать по данным регистров продаж, отгрузок или оплат. Эти источники отражают разные хозяйственные операции, поэтому итоговые суммы могут различаться.

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

Для LLM выручка, отгрузки, оплаты и возвраты – это разные сущности, связи между которыми нужно задать заранее. Поэтому корпоративные данные для ИИ должны содержать не только суммы, но и правила расчета показателей: источник, период, состав операций, возвраты и корректировки.

Риски подключения ИИ напрямую к 1С 

Передача данных из 1С напрямую в модель создает три основных риска:
 

1. Ошибки в расчетах. Без описания полей и связей LLM может объединить несовместимые показатели или дважды учесть одну операцию. 
2. Нагрузка и утечка данных. Тяжелые запросы к рабочей базе замедляют 1С. В выгрузку могут попасть персональные данные, банковские реквизиты и коммерческая информация. 
3. Сложно проверить результат. Без информации об источнике, примененных фильтрах и правилах расчета трудно понять, как модель получила это значение и почему оно расходится с фактическими показателями. 

Чтобы избежать этих проблем, данные сначала очищают и описывают в контракте данных: что означает каждое поле, откуда берется значение и как его использовать. Затем собирают витрину данных для ИИ – проверенные показатели из нужных источников. LLM работает с этой витриной, а не с рабочей базой 1С. Ответ можно легко сверить с исходными значениями и выяснить причину расхождения.

Как сформировать контракт данных

Контракт данных – это документ с требованиями к информации, которую передают из источника в витрину или отчет для работы ИИ-модели. В нем вы описываете поля, правила расчета, частоту обновления и SLA (соглашение об уровне сервиса) по качеству. Вы задаете бизнес-логику, а инженер данных реализует ее в витрине – так ответы ИИ можно сверять с данными учетной системы. 

Источник и владелец 

Для каждого показателя вы фиксируете источник в 1С и владельца данных – специалиста, который отвечает за их корректность и смысл. 

Например (названия источников условные и зависят от конфигурации 1С): 

• Выручка: источник – регистр накопления «Продажи», владелец – руководитель отдела продаж. 
• Возвраты: источник – регистр «Возвраты», владелец – финансовая служба. 

1С:Бухгалтерия и 1С:ERP могут быть двумя источниками одного показателя с разными правилами учета. В контракте вы отмечаете, какой источник использовать для конкретной витрины и по каким правилам рассчитывать показатель. В итоге финансовая и управленческая отчетность показывают одинаковую выручку, рассчитанную по общим правилам. 

Временной срез

Предположим, LLM-агенту нужен ответ на вопрос «выручка за прошлый квартал». Но прошлый квартал относительно какой даты? Если витрина обновляется с задержкой в два дня, а модель строит ответ на устаревшем срезе, вы получаете сумму, не актуальную на момент запроса. 

AI-ready данные предприятия (с заданными правилами расчета и контроля качества) должны содержать дату последнего обновления и условие: какие данные за период уже закрыты, а какие еще могут измениться. 

Обязательные поля 

В финансовую витрину (набор финансовых показателей для отчетов и вопросов к ИИ) входят:

• Идентификатор документа и дата – чтобы найти операцию и определить отчетный период. 
• Контрагент и номенклатура – для анализа продаж по клиентам и товарам. 
• Сумма без НДС, сумма НДС и тип операции (продажа или возврат) – чтобы правильно рассчитать выручку с учетом возвратов. 
• Подразделение и ответственный – чтобы связать результат с конкретным отделом. 

В 1С для AI-аналитики даты приводят к единому формату, суммы – к одной валюте, а дубли контрагентов объединяют по «золотой записи» (единой эталонной карточке компании). Иначе ИИ может дважды учесть одну продажу или неверно рассчитать выручку. 

Но: обязательные поля – это минимум. Данные могут содержать дубли, ошибки в суммах и устаревшие записи. Для каждой проверки вы задаете допустимый порог и решаете, что делать при нарушении. 

Критерии качества данных:


Пороги в таблице – примеры, а не универсальные нормы. Для финансовой витрины расхождение 0,1% может быть строгим, для складской – избыточным. Порог выбирают владелец показателя и инженер данных, договариваясь, какое отклонение допустимо и что делать, если проверка его выявит. 

С помощью SLA вы определяете, какие задержки допустимы и в какие сроки команда должна реагировать на сбои и ошибки. 

Три параметра, без которых контракт будет неполным: 

• Допустимая задержка обновления – сколько витрина может отставать от учетной системы. 
• Время восстановления после сбоя – за какой срок информация снова становится доступна. 
• Срок исправления критической ошибки – сколько времени есть у команды, чтобы устранить расхождение. 

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

Целевая AI-ready архитектура 

При прямом запросе к ERP LLM-агент сам ищет нужную информацию, связывает документы и решает, какие поля использовать. Например, при расчете просроченной задолженности нужно учесть частичные оплаты и сроки платежей по договорам, поскольку ИИ может принять обычный долг за просроченный. 

AI-ready архитектура добавляет между 1С и моделью отдельный слой, где данные приводят к нужному виду и проверяют расчеты до того, как ИИ использует их в ответе. 

ИИ и Экстрактор 1С 

Первый элемент этого слоя – выгрузка. Экстрактор 1С автоматически выгружает данные из 1С во внешнюю базу данных или DWH по расписанию. После первой полной загрузки он забирает только новые и измененные записи. 

Экстрактор 1С работает в фоновом режиме и использует многопоточность, чтобы выгружать данные с минимальной дополнительной нагрузкой на рабочую базу 1С. Информация поступает в различные СУБД (PostgreSQL, MS SQL, ClickHouse и др.), откуда ее можно передавать в BI-системы и использовать для подготовки витрин для ИИ. 

Важно: MCP-сервер Экстрактора 1С позволяет управлять выгрузками через интерфейс ИИ-ассистента, поддерживающего MCP – протокол взаимодействия ИИ с внешними инструментами. Вы можете попросить ИИ прочитать метаданные 1С, создать или проверить проект выгрузки, запустить первичную загрузку или настроить расписание. Вы тратите меньше времени на настройки, сохраняя контроль над выгрузкой: перед запуском можно проверить, какие объекты 1С в нее попадут и какие фильтры применяются. 

Исходный код и инструкция по установке доступны в репозитории MCP-сервера Экстрактора 1С.

Очистка в ETL 

ETL/ELT (извлечение, преобразование и загрузка данных) помогает убрать дубли, согласовать справочники и рассчитать показатели по правилам из контракта данных. Для этого можно использовать DVT – визуальную ETL-платформу, которая объединяет сведения из 1С, CRM и других источников, очищает их, приводит справочники к единому формату и помогает готовить витрины для BI и ИИ. Примеры настройки процессов и правила работы с платформой описаны в официальной документации DVT. 

В визуальном редакторе вы задаете правила обработки, настраиваете запуск по расписанию и контролируете ход загрузки. Если процесс завершится с ошибкой, вы увидите, на каком этапе возникла проблема. 

Важно: без DWH модель видит только текущий срез данных и не может объяснить, почему изменился показатель. DWH хранит историю загрузок: например, если выручка за март отличается от значения в предыдущей выгрузке, вы можете сравнить информацию и выяснить причину расхождения. 

Витрины и модель 

Витрина данных для ИИ – это не «все таблицы 1С», а определенный набор сущностей под конкретные задачи: продажи, закупки, финансы, склад. Чтобы ИИ одинаково трактовал показатели в разных запросах, поверх витрины настраивают семантический слой. Он связывает поля данных с бизнес-понятиями: «выручка», «возврат», «активный клиент» – и задает правила расчета. 

Модель не пишет SQL-запрос к 1С напрямую – она обращается к семантическому слою, где уже описано, что означают показатели и как их считать. Это и есть отличие AI-ready архитектуры от прямого запроса к ERP: ИИ не нужно самостоятельно разбираться в структуре 1С и выбирать правила расчета.

С учетом описанных выше этапов подготовки данных схема AI-ready архитектуры выглядит так:

Подготовка смыслового слоя 

Смысловой слой связывает поля витрины с показателями, их значениями и правилами расчета. Например, поле «Сумма» в одном регистре 1С может содержать выручку, а в другом – себестоимость. По одному названию LLM не поймет разницу. Поэтому подготовка данных для LLM включает описание бизнес-смысла показателей, источников и связей между сущностями. 

Каталог KPI

Каталог KPI описывает каждый показатель: формулу расчета, источник, период, единицу измерения и ответственного. Для финансовых KPI также фиксируют финансовое определение: что именно считается выручкой – поступление денег или отгрузка товара, с НДС или без, как учитываются скидки и возвраты. 

Пример записей в каталоге KPI:


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

Синонимы терминов

В разных подсистемах 1С один и тот же объект может называться «Контрагент», «Покупатель» или «Клиент». LLM нужен словарь синонимов, который связывает слова из запросов пользователя с полями витрины. Иначе на вопрос о клиентах модель может обратиться только к справочнику контрагентов и не учесть связанные сделки из CRM. Но синонимы нужно согласовать с бизнес-логикой компании: похожие по смыслу термины не всегда означают одно и то же. 

Чтобы LLM собрала информацию о клиенте из 1С, CRM и других систем, в витрине должен быть единый идентификатор для каждой сущности – контрагента, номенклатуры, договора. Модель не сможет «догадаться», что «ООО Альфа» и «Альфа Трейд» – это одна компания, если у них разные ID. Поэтому в смысловом слое закрепляют, какой ID использовать в витрине и как сопоставлять с ним идентификаторы из разных источников. 

Контроль версий

Смысловой слой меняется: появляются новые KPI, уточняются формулы, добавляются подразделения. Контроль версий сохраняет историю правок и помогает понять, почему изменили формулу. 

Lineage (прослеживаемость данных) показывает, из каких источников и по каким правилам рассчитан показатель. Если через месяц руководитель спросит, почему изменилась выручка, вы сможете проверить, что стало причиной: новые данные или согласованное изменение формулы. 

Безопасность и доступ

Безопасность данных для ИИ начинается с ограничения доступа: агент должен получать только ту информацию, которая нужна для его задачи. 

1. Минимальные привилегии и разграничение доступа. Выдавайте агенту доступ к нужным витринам и полям. Подключение к 1С настраивайте через API, OData или HTTP-сервис с ограниченным набором методов (без прямого SQL-доступа к рабочей базе). Разграничивайте права по ролям и подразделениям: руководитель филиала должен видеть данные своего филиала, а не остальных. 
2. Обезличивание. Перед передачей сведений модели удаляйте лишние персональные данные или применяйте masking (маскирование) – например, заменяйте телефон токеном. Хеши подходят для сопоставления записей, но не исключают восстановления исходных данных. Если нужно сохранить связь с клиентом, храните таблицу соответствий отдельно и ограничьте к ней доступ. Проверяйте, чтобы после обезличивания суммы и идентификаторы, нужные для расчетов, оставались без изменений. 
3. Аудит запросов. Настройте логирование, чтобы фиксировать, кто, когда и к каким сведениям обращался, какие действия выполнил агент и какой результат получил. Неизменяемые логи помогут расследовать инциденты и проверить соблюдение правил доступа. Ограничьте доступ к журналам. Каждый прямой запрос к данным должен проходить проверку прав, чтобы агент не мог обойти установленные ограничения другим способом обращения к источнику.

 
Эти правила – часть более широкой системы управления данными (Data Governance), которая охватывает их качество, безопасность и жизненный цикл. 

Контроль и тестирование

Перед пилотом с LLM проверьте: сходятся ли расчеты с 1С, переносит ли инкрементальная загрузка все изменения без дублей и правильно ли модель отвечает на контрольные вопросы. 

Сверка с 1С

Сверьте каждый KPI из каталога с контрольным отчетом 1С за тот же период. Допустимое расхождение зафиксируйте в SLA – например, не более 0,1% по сумме, если такой порог подходит для показателя. Если разница выше, найдите причину до того, как подключать витрину к модели. Повторяйте проверку после изменений контракта и обновления конфигурации 1С. 

Проверка инкремента

Проверьте, как инкрементальная загрузка обрабатывает добавление и изменение документов, перепроведение, возвраты за прошлые периоды и повторный запуск после сбоя. К примеру, после изменения документа в 1С повторите загрузку: витрина должна обновить существующую запись, а не создать дубль или пропустить изменение. 

Эталонные вопросы

Подготовьте 10-20 вопросов с заранее известными ответами. Модель отвечает на них на естественном языке, а вы сравниваете результат с контрольными значениями из учетной системы. Проверьте расчет выручки, динамику показателей, сравнение подразделений и поиск клиента. 

Если модель правильно отвечает на 18 из 20 вопросов, но ошибается на запросах о возвратах, посмотрите, как возвраты учитываются в витрине и определены в смысловом слое. Так вы поймете, где именно возникает ошибка: в данных или в правилах расчета. 

Пошаговый старт

Выберите для пилота витрину продаж: на ней можно проверить, как LLM считает выручку, учитывает возвраты и объясняет расхождения с 1С. 

Пилотная витрина

Определите состав витрины: источники информации, владельца показателя, период учета и обязательные поля. Подключите Экстрактор 1С, настройте ETL и DWH, опишите правила расчета в семантической модели. Для пилота хватит одной витрины с показателями, которые можно сверить с учетной системой.

10 бизнес-вопросов 

Проверьте модель на типовых запросах руководителя: 

1. Какова выручка за прошлый месяц без НДС и с учетом возвратов? 
2. Как изменился объем продаж по сравнению с предыдущим месяцем? 
3. Какие товары принесли больше всего дохода за квартал? 
4. По каким товарам сильнее всего снизились продажи? 
5. Какие пять контрагентов принесли наибольшую выручку за квартал? 
6. Какой филиал показал наибольший рост продаж? 
7. В каких филиалах выше всего доля возвратов? 
8. Какие товары и контрагенты сильнее всего повлияли на динамику продаж? 
9. Какие документы объясняют изменение итоговой суммы за месяц? 
10. Почему показатель в витрине отличается от контрольного отчета 1С?

Для каждого вопроса подготовьте эталонный ответ по данным 1С, чтобы проверить модель и семантический слой.

Критерии приемки пилота:
 

• расчеты совпадают с 1С в пределах SLA; 
• загрузка не пропускает и не дублирует сведения; 
• модель правильно отвечает минимум на 18 из 20 вопросов (по 2 на каждый пункт из списка выше); 
• скорость и стоимость обработки не превышают заданных ограничений; 
• права доступа разграничены корректно, все обращения фиксируются в аудите запросов; 
• ошибки в финансовых расчетах исправлены до запуска. 

Масштабирование

После пилота переходите к другим задачам: закупкам, складу, производству и финансам. Для каждой витрины определите владельца KPI, правила расчета и проверьте результаты на контрольных вопросах. AI-ready данные предприятия можно постепенно расширять на новые направления бизнеса, сохраняя точность расчетов и возможность проверить ответы ИИ.

Пример: как LLM рассчитывает выручку

Разберем, почему LLM может неверно рассчитать выручку, если в данных не определены правила отбора периода и учета возвратов. Названия и суммы в примере условные. 

Исходная задача. Руководитель спрашивает: Какая выручка у клиента «Зима» за март 2026 года? 

Доступные данные. В витрине три таблицы: 

• Продажи – дата отгрузки, контрагент, сумма без НДС. 
• Возвраты – дата возврата, контрагент, сумма без НДС. 
• Контрагенты – идентификатор и название клиента. 

В марте у предприятия было две отгрузки на 100 000 и 50 000 ₽. В том же месяце зарегистрирован возврат на 30 000 ₽ по отгрузке за февраль. 

Расчет. Если LLM строит ответ только по таблице «Продажи» и не фильтрует по периоду, она суммирует все отгрузки клиента, включая февральские и апрельские. Если фильтрует по марту, но не вычитает возвраты, ответ – 150 000. Если учитывает возврат на 30 000, зарегистрированный в марте по февральской отгрузке, ответ – 120 000. 

Корректный ответ по контракту данных: 

150 000 - 30 000 = 120 000 (при условии, что возврат относится к марту по дате возврата, а не по дате продажи). 

Проверка результата. Сверим витрину с отчетом 1С по продажам и возвратам за март, учитывая возвраты по дате регистрации. Если оба источника показывают 120 000, расчет совпадает. Если витрина показывает 150 000, значит нужно проверить, вычитаются ли возвраты при подготовке данных в ETL. Если 90 000 – понять, не вычитается ли возврат дважды в ETL или смысловом слое. 

Ограничения. В 1С:ERP возврат может оформляться отдельным документом, а дата возврата – отличаться от даты исходной продажи. Поэтому в контракте нужно закрепить, по какому числу учитывать возврат и к какому периоду относить его сумму. 

На один запрос LLM может дать три разных ответа в зависимости от того, что считается периодом и как учитываются возвраты. Подготовка данных 1С для ИИ как раз и состоит в том, чтобы зафиксировать эти правила до того, как модель начнет отвечать.

Чек-лист готовности данных 1С для нейросети

Перед пилотом проверьте витрину по чек-листу. Каждый ответ «нет» покажет, что стоит доработать перед запуском или включить в план работ.