LLM + SQL: почему нельзя давать нейросети прямой доступ к базе 1С

Когда компании начинают экспериментировать с AI-аналитикой, один из первых вопросов звучит так: «А почему бы просто не дать нейросети доступ к базе 1С?»

Технически идея понятна. Есть база данных, есть SQL, есть большая языковая модель, которая умеет писать SQL-запросы. Пользователь задаёт вопрос обычным языком, модель генерирует запрос, получает результат и формулирует ответ.

Для прототипа такой подход может быть полезен. Для корпоративной системы между LLM и базой нужен дополнительный слой, который понимает права, бизнес-термины, допустимые операции, владельцев данных и правила расчётов.

Почему схема «LLM → SQL → 1С» выглядит так привлекательно

Представим простой сценарий. Руководитель пишет:

Покажи выручку за август по менеджерам и сравни с июлем.

В теории LLM может получить описание таблиц, сгенерировать SQL, выполнить его и вернуть:

Менеджер       Июль       Август       Изменение
Иванов         8,2 млн    9,4 млн       +14,6%
Петров         7,8 млн    6,9 млн       -11,5%
Сидоров        5,1 млн    5,7 млн       +11,8%

Для демонстрации это отличный сценарий. Но в реальной 1С возникает следующий вопрос: что именно считать выручкой?

Продажи по документам? Реализацию? Оплаченные заказы? С НДС или без НДС? По дате документа или по дате отгрузки? С возвратами или без них? По какой организации? Как учитывать корректировки?

SQL видит таблицы и поля. Бизнес видит сущности, правила и показатели.

1С — это не просто набор SQL-таблиц

В базе 1С физическая структура хранения не является удобным бизнес-контрактом для AI. В зависимости от конфигурации и режима работы там находятся регистры, документы, справочники, табличные части, служебные структуры и внутренние механизмы платформы.

Даже если инженер способен написать SQL к конкретной базе, это ещё не означает, что запрос будет корректно отражать бизнес-показатель.

Поэтому задача AI-аналитики — не просто перевести русский вопрос в SQL. Нужно перевести вопрос руководителя в разрешённую бизнес-операцию над корректно определёнными данными.

Главная проблема №1: LLM может написать правильный SQL для неправильного показателя

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

Запрос выполняется. SQL синтаксически корректен. База возвращает данные. AI красиво объясняет результат.

Но сам показатель может быть рассчитан неверно.

Например, руководитель спрашивает:

Какая у нас маржинальность по товарам?

LLM должна знать не только названия таблиц, но и определение маржи именно в этой компании:

• какую выручку использовать;
• какую себестоимость учитывать;
• как обрабатывать возвраты;
• как учитывать скидки;
• как учитывать бонусы;
• на каком уровне агрегировать данные;
• за какой период считать показатель.

Это уже не задача генерации SQL. Это задача semantic layer — слоя бизнес-смыслов над физическими данными.

Главная проблема №2: права доступа нельзя решать промптом

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

Пользователь спрашивает:

Покажи задолженность клиентов.

Если LLM получила прямой доступ к SQL, она потенциально может сформировать запрос по всей таблице.

Можно написать в system prompt:

«Показывай пользователю только данные его подразделения».

Но prompt — не механизм безопасности.

Контроль должен происходить до выполнения запроса:

Пользователь
    ↓
Authentication
    ↓
Role / ACL
    ↓
Разрешённый scope данных
    ↓
Business Tool
    ↓
SQL / 1С API
    ↓
Результат
    ↓
LLM

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

Главная проблема №3: прямой SQL превращает базу в API

Если разрешить приложению и LLM свободно работать с внутренней схемой базы, физическая структура постепенно превращается в неофициальный API.

Это создаёт сильную связанность:

LLM
 ↓
SQL
 ↓
внутренняя структура 1С

Теперь изменение конфигурации, регистра или структуры хранения потенциально влияет на AI-слой.

Правильнее иметь стабильный контракт:

LLM
 ↓
Business Tool
 ↓
Semantic Layer
 ↓
1С API / controlled SQL
 ↓
Data

Тогда AI знает не о физических таблицах, а о доступных бизнес-операциях:

get_sales_summary
get_overdue_debt
get_stock_turnover
get_order_status
get_profitability
get_plan_fact

Внутри каждого инструмента можно менять способ получения данных, не меняя интерфейс для AI.

Главная проблема №4: LLM не должна самостоятельно решать, какие данные ей разрешены

Хороший AI-ассистент сначала определяет намерение пользователя, а затем вызывает конкретные инструменты.

Например:

Вопрос:
«Какие клиенты увеличили просрочку за последние 30 дней?»

Intent:
overdue_debt_growth

Tool:
get_overdue_debt_growth

Parameters:
period = 30 days
scope = current user's allowed companies

Result:
structured data

LLM:
объясняет результат

В таком варианте модель не получает произвольный доступ к базе. Она получает ограниченный набор возможностей.

Главная проблема №5: запись через SQL — особенно плохая идея

Если прямой SQL-доступ для аналитики уже требует осторожности, то возможность выполнять UPDATE, INSERT или DELETE через AI значительно повышает риск.

Представим запрос:

Исправь цену товара X на 1500 рублей.

Нельзя превращать это в:

UPDATE ... SET price = 1500 ...

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

Для AI правильнее использовать отдельную команду:

prepare_price_change
    ↓
validation
    ↓
preview
    ↓
human approval
    ↓
business operation in 1C
    ↓
audit

Для первого production-релиза я бы вообще оставлял AI в режиме: Read → Analyze → Recommend → Human approval.

Что делать вместо прямого доступа LLM к SQL

На практике есть несколько архитектурных вариантов. Они не исключают друг друга.

Вариант 1. Набор бизнес-инструментов

Backend предоставляет AI ограниченный набор функций.

AI
 ↓
Tools
 ├── sales_summary
 ├── debt_summary
 ├── stock_summary
 ├── profitability
 └── orders_at_risk
 ↓
1С / PostgreSQL

Это хороший вариант для первого MVP: ограниченное число сценариев, понятные права и предсказуемые запросы.

Вариант 2. Semantic Layer

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

1С / DWH / PostgreSQL
        ↓
Semantic Layer
        ↓
Metrics
 ├── revenue
 ├── gross_profit
 ├── overdue_debt
 ├── stock_turnover
 └── plan_fact
        ↓
AI

В таком подходе определение метрики хранится в коде и конфигурации системы, а не в памяти LLM.

Вариант 3. Контролируемый Text-to-SQL

В некоторых аналитических системах Text-to-SQL действительно полезен. Но его лучше запускать не поверх всей production-базы 1С, а поверх специально подготовленного аналитического слоя.

1С
 ↓
ETL / CDC / Integration
 ↓
Analytics DB
 ↓
Curated schema
 ↓
Text-to-SQL
 ↓
SQL validation
 ↓
Read-only execution
 ↓
LLM explanation

Здесь модель может иметь больше свободы, потому что она работает с заранее подготовленной схемой и read-only доступом.

Почему PostgreSQL / DWH лучше подходит для AI-аналитики

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

Это даёт несколько преимуществ:

• можно подготовить понятную AI-схему данных;
• можно хранить исторические срезы;
• можно строить тяжёлые аналитические запросы отдельно от операционного контура;
• можно настроить read-only доступ;
• можно централизовать аудит AI-запросов;
• можно объединить данные 1С, CRM, WMS и других систем.

Архитектура начинает выглядеть так:

Это уже не «нейросеть подключили к базе». Это отдельный аналитический контур, где AI является интерфейсом к данным бизнеса.

Где здесь Symfony и Go

Для корпоративного проекта AI Gateway или Integration Layer можно реализовать как отдельный backend-сервис. Symfony хорошо подходит для API, авторизации, orchestration, бизнес-правил и административного интерфейса. Go может использоваться для высоконагруженных воркеров и отдельных интеграционных компонентов.

Как выглядит запрос руководителя в правильной архитектуре

Пусть руководитель спрашивает:

Почему прибыль в августе снизилась относительно июля?

Нельзя просто отправить весь массив данных в LLM. Сначала orchestration-слой разбивает задачу:

1. определить период сравнения;
2. получить выручку и себестоимость;
3. сравнить показатели;
4. найти направления с наибольшим отклонением;
5. проверить изменение объёмов, цен и скидок;
6. получить дополнительные данные при необходимости;
7. передать модели только проверенный результат;
8. сформировать объяснение человеческим языком.

В итоге получается:

Руководитель
     ↓
«Почему упала прибыль?»
     ↓
AI Orchestrator
     ↓
┌──────────────────────────────┐
│ get_revenue()                │
│ get_cost()                   │
│ get_margin_by_product()      │
│ get_sales_dynamics()         │
└──────────────────────────────┘
     ↓
Validated data
     ↓
LLM
     ↓
«Основное снижение связано с...»

LLM не является источником цифр. Она объясняет цифры, полученные от контролируемых инструментов.

А можно ли всё-таки использовать LLM + SQL?

Да. Вопрос не в том, чтобы полностью запретить Text-to-SQL.

Он может быть полезен для:

• исследовательской аналитики;
• внутренних прототипов;
• read-only аналитических баз;
• подготовленного DWH;
• сценариев, где данные не являются критичными;
• аналитиков и технических пользователей.

Но даже здесь полезны ограничения:

Что делать с большими объёмами данных

Ещё одна ошибка — отправлять в контекст LLM тысячи или миллионы строк из 1С.

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

Для аналитики сначала нужно агрегировать данные:

1 000 000 строк
      ↓
SQL / analytical query
      ↓
50 агрегатов
      ↓
LLM
      ↓
понятное объяснение

Модель должна получать ровно тот контекст, который нужен для ответа. Это дешевле, быстрее и проще контролировать.

LLM + SQL и RAG решают разные задачи

Часто AI-проект пытаются построить только вокруг RAG. Но RAG и SQL отвечают на разные вопросы.

Вопрос	Основной механизм
Сколько просроченной задолженности?	SQL / 1С API
Почему этот договор нельзя согласовать?	RAG + бизнес-данные
Какой склад хуже выполняет план?	SQL / analytics
Что написано в регламенте по отсрочке?	RAG
Почему клиенту нельзя дать такую отсрочку?	SQL + RAG + business rules

Настоящий корпоративный AI начинается там, где он умеет объединять несколько типов контекста, а не просто отвечает по одному источнику.

Какой MVP AI-аналитики поверх 1С имеет смысл делать первым

Не нужно сразу давать AI доступ ко всей информационной базе. Лучше выбрать несколько конкретных управленческих сценариев.

Например:

1. Продажи: динамика выручки и отклонения.
2. Дебиторка: просрочка и крупнейшие изменения.
3. Склад: остатки и оборачиваемость.
4. Маржа: товары и направления с ухудшением показателей.
5. Заказы: заказы с риском нарушения срока.

Под каждый сценарий создаётся отдельный инструмент. После этого можно добавлять новые источники и сценарии.

Типичные ошибки LLM + SQL в корпоративных проектах

• давать модели прямой доступ к production-базе 1С;
• разрешать произвольные INSERT, UPDATE и DELETE;
• решать права доступа только через system prompt;
• передавать LLM физическую схему базы без semantic layer;
• считать бизнес-метрики внутри промпта;
• передавать модели огромные объёмы исходных строк;
• не валидировать сгенерированный SQL;
• не ограничивать время и объём выполнения запросов;
• не вести audit AI-запросов;
• не иметь тестового набора эталонных вопросов и правильных ответов.

Правильный принцип: AI не должен знать, где лежат таблицы

Чем больше корпоративная система, тем важнее абстракция.

AI должен знать:

«У меня есть инструмент
для получения просроченной дебиторской задолженности».

А не:

«В таблице X есть поле Y,
соедини его с таблицей Z по ключу Q».

Второй вариант связывает интеллект с физической структурой хранения. Первый — с бизнес-возможностью.

Итог

LLM + SQL — полезная технология, но прямой доступ нейросети к базе 1С не должен становиться архитектурой корпоративного AI.

Для production-системы лучше разделить ответственность:

• 1С — источник учётных данных и бизнес-операций;
• Integration Layer — доступ к корпоративным системам;
• Semantic Layer — определения управленческих показателей;
• SQL / аналитическая БД — точные расчёты и агрегации;
• ACL — контроль того, какие данные доступны конкретному пользователю;
• RAG — поиск по корпоративным документам и знаниям;
• LLM — понимание вопроса, выбор инструмента и объяснение результата;
• Human approval — контроль критичных действий.

В результате получается не «ChatGPT подключили к 1С», а полноценный AI-слой над бизнесом:

Именно такая архитектура позволяет постепенно перейти от AI-аналитики к AI-ассистенту руководителя, а затем — к агентам, которые не только находят проблему, но и предлагают следующий шаг.