Как сделать ИИ-агента для интеграции с 1С

Что получится в результате

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

Первая рабочая версия будет делать так:

1. 1С публикует ограниченный OData или HTTP endpoint;
2. n8n по расписанию читает справочники, документы или остатки;
3. агент получает только нужные поля, а не всю базу;
4. LLM готовит summary, проверку или рекомендацию;
5. результат попадает в Google Sheets со статусом `draft`;
6. ответственный человек ставит `approved`, `needs_fix` или `rejected`;
7. approved-действие создает задачу, комментарий или ограниченную запись через отдельный endpoint;
8. все чтения, ошибки и записи фиксируются в `integration_log`.

В первой версии агент не проводит документы, не меняет цены, не списывает товар, не удаляет данные и не выполняет массовые операции. Он читает, анализирует и готовит проверяемое действие.

Что понадобится

• Тестовая или копия базы 1С.
• Пользователь 1С для интеграции с минимальными правами.
• Опубликованный OData или HTTP-сервис 1С.
• n8n Cloud или self-hosted n8n.
• Google Sheets для approval и журналов.
• API-ключ LLM-провайдера.
• Специалист 1С, который настроит публикацию и права.
• 1-2 часа на первый read-only прототип.

Шаг 1. Выберите один сценарий

Не подключайте AI сразу ко всей 1С.

Для первого прототипа выберите один сценарий:

агент читает просроченные счета, остатки или документы и готовит список действий ответственному

Примеры безопасного старта:

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

Проверка: сценарий можно описать одной фразой и в нем нет автоматического проведения документов.

Шаг 2. Подготовьте тестовую базу 1С

Не начинайте с боевой базы.

Сделайте:

1. копию информационной базы;
2. отдельного пользователя `ai_integration`;
3. отдельную роль с минимальными правами;
4. доступ только к нужным объектам;
5. запрет на удаление и проведение документов;
6. журнал регистрации действий пользователя.

Проверка: пользователь `ai_integration` может читать нужные данные и не может проводить/удалять документы.

Шаг 3. Выберите способ интеграции

Для первой версии используйте один из вариантов:

1. OData, если нужно читать стандартные справочники и документы;
2. HTTP-сервис 1С, если нужен контролируемый endpoint с собственной логикой;
3. файловый обмен CSV/JSON, если API пока недоступен;
4. промежуточная база или витрина, если боевую 1С нельзя открывать.

Рекомендация:

read-only OData или HTTP endpoint для чтения + отдельный HTTP endpoint для approved-записи

Проверка: выбранный способ не требует давать агенту полные права администратора.

Шаг 4. Создайте таблицу проекта

Создайте Google Sheet:

1C AI integration agent

Добавьте листы:

integration_settings
objects_map
read_queue
draft_results
action_queue
integration_log
errors
test_cases

Проверка: у n8n есть доступ на чтение и запись.

Шаг 5. Заполните настройки интеграции

В листе `integration_settings` сделайте колонки:

key
value
comment

Заполните:

base_url | https://1c.example.com/demo/odata/standard.odata | адрес OData или HTTP API
auth_type | basic | тип авторизации первой версии
read_only_mode | yes | запрет записи в первой версии
max_items_per_run | 100 | ограничение объема
timeout_seconds | 30 | таймаут запросов
approval_required | yes | запись только после approval

Не храните пароль в Google Sheets. Пароль держите в credentials n8n или секретах сервера.

Проверка: таблица содержит настройки без секретов.

Шаг 6. Опишите объекты 1С

В листе `objects_map` сделайте колонки:

object_code
object_type
endpoint
key_field
allowed_fields
purpose
enabled

Пример:

counterparties
catalog
Catalog_Контрагенты
Ref_Key
Ref_Key,Description,ИНН,КПП
поиск дублей и проверка реквизитов
yes

customer_orders
document
Document_ЗаказКлиента
Ref_Key
Ref_Key,Number,Date,Контрагент,СуммаДокумента,Проведен
контроль заказов
yes

Проверка: агент получает только разрешенные поля, а не полный объект 1С.

Шаг 7. Проверьте доступ к OData вручную

Выполните тестовый запрос.

curl -u "ai_integration:PASSWORD" \
  "https://1c.example.com/demo/odata/standard.odata/"

Если endpoint доступен, вы увидите список опубликованных сущностей.

Потом проверьте конкретный объект:

curl -u "ai_integration:PASSWORD" \
  "https://1c.example.com/demo/odata/standard.odata/Catalog_Контрагенты?$top=5"

Проверка: запрос возвращает JSON или Atom/XML в зависимости от настроек, а не HTML-страницу ошибки.

Шаг 8. Создайте очередь чтения

В листе `read_queue` сделайте колонки:

read_id
object_code
filter_json
status
requested_by
created_at
processed_at
error

Пример:

READ-001
counterparties
{"top": 50, "filter": "ИНН ne null"}
new
Иван
2026-05-22

Проверка: чтение данных из 1С запускается через очередь, а не через ручное редактирование workflow.

Шаг 9. Создайте workflow чтения

Назовите workflow:

1C read and analyze

Добавьте узлы:

1. `Schedule Trigger`;
2. `Google Sheets` - чтение `integration_settings`;
3. `Google Sheets` - чтение `objects_map`;
4. `Google Sheets` - чтение `read_queue`;
5. `Filter` по `status = new`;
6. `HTTP Request` к 1С;
7. `Code` - нормализация ответа;
8. `Code` - ограничение полей;
9. `LLM` - анализ;
10. `Code` - проверка JSON;
11. `Google Sheets` - запись `draft_results`;
12. `Google Sheets` - запись `integration_log`;
13. `Google Sheets` - запись `errors`, если запрос упал.

Проверка: workflow создан и пока работает только в read-only режиме.

Шаг 10. Настройте HTTP Request к 1С

В n8n узле `HTTP Request`:

Method: GET
URL: {{$json.base_url}}/{{$json.endpoint}}
Authentication: Basic Auth
Timeout: {{$json.timeout_seconds}}

Query parameters:

$top={{max_items_per_run}}
$format=json

Если нужен фильтр:

$filter=...

Проверка: запрос возвращает не больше `max_items_per_run` строк.

Шаг 11. Нормализуйте ответ 1С

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

const body = $json;
const rows = body.value || body.d?.results || [];

return rows.map(row => ({
  json: {
    ref_key: row.Ref_Key || row.ref_key,
    number: row.Number || null,
    date: row.Date || null,
    description: row.Description || null,
    amount: row.СуммаДокумента || row.Amount || null,
    raw: row
  }
}));

Проверка: дальше workflow работает с одинаковой структурой, а не с разными форматами 1С.

Шаг 12. Ограничьте поля перед LLM

Перед отправкой в LLM удалите лишнее.

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

• пароли;
• токены;
• персональные данные, если они не нужны сценарию;
• внутренние GUID, если они не нужны для действия;
• полные документы, если достаточно summary;
• коммерческие условия вне задачи.

Пример компактного объекта:

{
  "object_code": "customer_orders",
  "items": [
    {
      "id": "Ref_Key",
      "number": "000001",
      "date": "2026-05-20",
      "customer": "ООО Север",
      "amount": 120000,
      "posted": false
    }
  ]
}

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

Шаг 13. Добавьте prompt анализа

System prompt:

Ты помощник по анализу данных 1С.
Работай только по переданным данным.
Не придумывай документы, суммы, контрагентов и статусы.
Не предлагай провести, удалить или изменить документ автоматически.
Верни только валидный JSON.

User prompt:

Сценарий:
{{purpose}}

Данные:
{{ JSON.stringify(items) }}

Верни JSON:
{
  "summary": "короткий вывод",
  "findings": [
    {
      "object_id": "id объекта",
      "problem": "что найдено",
      "risk_level": "low|medium|high|critical",
      "recommended_action": "что сделать человеку",
      "requires_write": false
    }
  ],
  "confidence": 0.0
}

Проверка: LLM возвращает JSON и не предлагает опасные автоматические действия.

Шаг 14. Проверьте JSON

Добавьте узел `Code`.

Правила:

• JSON парсится;
• `findings` не больше 50;
• `risk_level` входит в список;
• `requires_write` не может быть true в read-only режиме;
• нет слов “провести документ”, “удалить”, “списать”, “изменить цену”;
• каждый finding содержит `object_id`.

Если проверка не прошла:

status = error
step = llm_validation

Проверка: опасный или невалидный ответ не попадает в approval.

Шаг 15. Запишите draft_results

В листе `draft_results` сделайте колонки:

result_id
read_id
object_code
summary
findings_json
confidence
review_status
review_comment
approved_by
created_at
approved_at

После анализа добавьте строку:

review_status: draft

Проверка: человек видит результат анализа до любых действий.

Шаг 16. Добавьте журнал интеграции

В листе `integration_log` сделайте колонки:

log_id
run_id
step
object_code
endpoint
items_count
status
details
created_at

Логируйте:

• старт запроса;
• успешное чтение;
• количество строк;
• ошибку API;
• результат LLM;
• approval;
• запись обратно.

Проверка: можно восстановить, что агент сделал и когда.

Шаг 17. Проверьте результат человеком

Ответственный открывает `draft_results`.

Проверяет:

• действительно ли объект существует в 1С;
• верны ли суммы и даты;
• нет ли лишних данных;
• не предложил ли агент опасное действие;
• нужен ли комментарий, задача или запись обратно.

После проверки ставит:

review_status: approved
approved_by: имя
approved_at: дата

Или:

review_status: rejected
review_comment: причина

Проверка: без `approved` запись в 1С невозможна.

Шаг 18. Создайте action_queue

В листе `action_queue` сделайте колонки:

action_id
result_id
object_code
object_id
action_type
payload_json
review_status
approved_by
write_status
external_id
created_at
processed_at
error

Типы действий первой версии:

• `create_task`;
• `add_comment`;
• `mark_for_review`;
• `export_csv`;

Запрещенные действия:

• `post_document`;
• `delete_object`;
• `change_price`;
• `writeoff_stock`;
• `pay_invoice`.

Проверка: action_queue не содержит опасных типов действий.

Шаг 19. Создайте workflow записи approved-действий

Назовите workflow:

1C write approved action

Добавьте узлы:

1. `Schedule Trigger`;
2. `Google Sheets` - чтение `action_queue`;
3. `Filter` по `review_status = approved`;
4. `Code` - проверка allowlist действий;
5. `HTTP Request` к HTTP-сервису 1С или CRM;
6. `Google Sheets` - обновление `write_status`;
7. `Google Sheets` - запись `integration_log`.

Проверка: workflow не трогает `draft` и `rejected`.

Шаг 20. Сделайте allowlist записи

В узле `Code` перед записью:

const allowed = ['create_task', 'add_comment', 'mark_for_review', 'export_csv'];
const actionType = String($json.action_type || '');

if (!allowed.includes(actionType)) {
  throw new Error(`Blocked action type: ${actionType}`);
}

return [$json];

Проверка: даже если строка в таблице ошибочная, workflow не выполнит опасное действие.

Шаг 21. Используйте отдельный HTTP endpoint для записи

Не пишите напрямую в стандартные документы 1С из LLM-результата.

Сделайте отдельный HTTP-сервис в 1С, например:

POST /ai-integration/tasks
POST /ai-integration/comments

Payload:

{
  "external_id": "action_id",
  "object_code": "customer_orders",
  "object_id": "Ref_Key",
  "action_type": "mark_for_review",
  "comment": "Проверить заказ: сумма есть, документ не проведен."
}

Проверка: 1С сама валидирует action_type и права, а не доверяет n8n и LLM.

Шаг 22. Обновите статус записи

После успешной записи:

write_status: done
external_id: id созданной задачи или комментария
processed_at: дата
error: пусто

Если ошибка:

write_status: error
error: текст ошибки

Проверка: видно, какие approved-действия реально дошли до 1С.

Шаг 23. Обработайте ошибки API

В листе `errors` сделайте колонки:

error_id
run_id
step
object_code
endpoint
http_status
error_text
payload_fragment
created_at
resolved_at

Правила:

• 401/403 - остановить workflow и проверить права;
• timeout - повторить позже, но не бесконечно;
• 500 - записать ошибку и уведомить специалиста 1С;
• пустой ответ - не отправлять в LLM.

Проверка: ошибки интеграции не превращаются в молчаливые пропуски.

Шаг 24. Добавьте уведомления

Если за запуск есть ошибки или high/critical findings, отправьте уведомление.

Пример:

1С AI integration: найдено 5 high-risk пунктов и 1 ошибка API.
Откройте draft_results и errors.

Канал:

• Telegram;
• email;
• задача в Bitrix24;
• задача в самой 1С через approved endpoint.

Проверка: ответственный узнает о проблеме без ручного просмотра таблиц.

Шаг 25. Добавьте regression test

В листе `test_cases` сделайте колонки:

case_id
object_code
input_json
expected_findings_count
expected_risk_level
expected_requires_write
enabled

Добавьте тесты:

• пустой список объектов;
• документ без суммы;
• документ не проведен;
• контрагент без ИНН;
• дубль контрагента;
• запрос с запрещенным полем;
• опасное действие в LLM-ответе;
• ошибка авторизации;
• timeout;
• нормальный объект без проблем.

Создайте workflow:

1C integration regression test

Он прогоняет test_cases без обращения к боевой 1С и проверяет JSON-валидацию, allowlist и статусы.

Проверка: изменение prompt или правил не открывает опасную запись.

Шаг 26. Перенесите на боевой контур только после приемки

Перед подключением к боевой 1С проверьте:

• пользователь интеграции не администратор;
• права минимальны;
• read-only сценарий отработал на тестовой базе;
• все записи идут через allowlist;
• approval включен;
• журнал регистрации включен;
• есть ограничение количества объектов за запуск;
• есть timeout и обработка ошибок;
• regression test проходит.

Проверка: боевой запуск начинается с чтения и отчетов, а не с записи документов.

Минимальная проверка результата

Прототип работает, если выполняются все пункты:

• OData или HTTP endpoint 1С доступен тестовому пользователю;
• n8n читает ограниченный набор объектов;
• лишние поля отрезаются перед LLM;
• LLM возвращает валидный JSON;
• результат пишется в `draft_results`;
• человек ставит `approved` или `rejected`;
• approved-действия проходят allowlist;
• запись идет только через отдельный endpoint;
• все шаги пишутся в `integration_log`;
• ошибки попадают в `errors`.

Что нельзя автоматизировать в первой версии

• проведение документов;
• удаление объектов;
• изменение цен;
• списание товаров;
• оплату счетов;
• массовую запись в справочники;
• выдачу прав пользователям;
• работу с боевой базой без тестового прогона;
• запись в 1С без approval и allowlist.

Частые вопросы

Что лучше для старта: OData или HTTP-сервис?

Для read-only сценария часто проще OData. Для записи лучше отдельный HTTP-сервис 1С с собственной проверкой прав, типов действий и payload.

Можно ли дать агенту прямой доступ к базе 1С?

Нет. Агент должен работать через ограниченный API, отдельного пользователя, минимальные права, журнал и approval. Прямой доступ к базе опасен.

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

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

Как не отправлять лишние данные в LLM?

Сделайте allowlist полей в `objects_map` и отдельный Code node, который удаляет все поля вне списка. Не передавайте полные объекты 1С “на всякий случай”.

Какой минимум нужен для запуска?

Тестовая база 1С, пользователь `ai_integration`, OData или HTTP endpoint, n8n, таблицы `objects_map`, `read_queue`, `draft_results`, `action_queue`, `integration_log`, LLM prompt, approval и allowlist действий.