Пять архитектур для остатков, заказов, сделок и маркировки. Сравним трудозатраты и выберем схему под конкретный контур.
Пять схем интеграции ИИ
Для пилота за 4–8 недель важно не усложнять архитектуру. Ниже пять схем, к которым дальше привязаны отдельные разделы статьи: 1) Прямой HTTP-вызов ИИ из 1С — 1С напрямую ходит к внешнему API ИИ. 2) Сервис-прослойка между 1С и ИИ — отдельный REST‑сервис на Python/Node.js, к которому обращается 1С. 3) ИИ-агент для AmoCRM и Битрикс24 — CRM запускает webhooks, оркестратор (n8n или сервис) вызывает ИИ и пишет результат обратно. 4) Связка чат-бота ИИ и 1С для склада — клиент пишет боту, ИИ общается с сервисом и 1С, формирует ответ. 5) True API Честного знака и ИИ — учетная система работает через True API, ИИ помогает разбирать статусы и ошибки.
Если задача — пилот за 4–8 недель, выбирайте самую простую схему под ваш контур: есть интернет на сервере 1С — прямой HTTP; нет интернета — сервис-прослойка; центр продаж в CRM — ИИ-агент; основная боль по складу — чат-бот; упор на маркировку — связка True API и ИИ. Критичные действия с УПД и суммами сделок лучше запускать в формате черновика с ручным подтверждением. Что можно сделать сейчас: выписать свои ключевые потоки (остатки, статусы, переписка, маркировка) и сопоставить их с одной из этих пяти схем.
Сценарии для 1С и склада
ИИ полезен там, где запросы повторяются и опираются на структуру базы 1С: «дай статус заказа по номеру», «собери сводку по остаткам и резервам», «предупреди про возможный недостачу по отгрузке». 1С остается источником цифр, остатков и статусов, ИИ только формулирует понятные ответы и подсказки.
- •Если в запросах фигурируют номер заказа, артикул, склад или дата, их удобно обрабатывать ИИ.
- •Если ответ не меняет проводки и статусы УПД, его можно записывать автоматически в комментарий.
- •Если ответ влияет на отгрузку, обещания по срокам или કિંчку клиента, нужна проверка человеком.
Для пилота по складу достаточно нескольких таблиц и документов 1С:
- •справочник номенклатуры (коды, названия, единицы измерения);
- •регистры остатков и резервов по складам;
- •документы заказов клиентов и отгрузок;
- •при необходимости — регистр движений по складу для сводных ответов.
Простой поток на пилот: клиентский вопрос → ИИ формирует запрос к 1С → 1С возвращает факты → ИИ собирает текст ответа → человек получает краткую сводку. Записывать ответы удобнее в отдельное поле или комментарий, не трогая проводки.
Сценарии для CRM и переписок
В CRM ИИ снимает перегрузку по переписке и звонкам: резюмирует диалоги, квалифицирует лиды, заполняет поля по тексту общения и ставит задачи. Типовая цепочка: CRM шлет webhook, оркестратор (например, n8n) принимает JSON, формирует запрос к LLM и обновляет CRM через REST‑API.
Если ИИ влияет на стадию сделки или обещания клиенту, включайте эскалацию: сначала предложение от агента, затем подтверждение менеджером. Для пилота достаточно одной тестовой воронки, одного webhook и права агента писать только в комментарий и ставить задачи, без прямой смены статусов и сумм.
Сценарии для маркировки и True API
В задачах маркировки True API отвечает кодами и статусами, а ИИ помогает пользователям разобраться: объясняет статус УПД, формирует комментарий к ошибочному документу и пишет понятные инструкции «что делать дальше».
- •проверка статуса задачи или УПД по идентификатору;
- •пояснение кода ошибки и ее причин на обычном языке;
- •подсказка по действиям: переподписание, корректировка данных, повторный запрос.
Пример: True API вернул ответ с ошибкой "errorCode": "INVALID_PARTICIPANT" и техническим описанием. ИИ превращает это в текст вида «в документе указан участник, который не зарегистрирован в системе маркировки; проверьте ИНН/КПП и используйте актуальные реквизиты контрагента», а также добавляет короткий чек‑лист действий. Это снижает нагрузку на специалистов, но сами операции (подпись, ввод в оборот, передача) остаются под контролем учетной системы и ответственных сотрудников.
Если команда регулярно сталкивается с непонятными статусами и протоколами True API, ИИ-слой логично использовать как подсказку и переводчик, а не как исполнитель критичных операций маркировки.
Прямой HTTP-вызов ИИ из 1С
1С может напрямую отправлять запросы в REST‑API ИИ через HTTPСоединение и HTTPЗапрос: событие в базе формирует JSON, модель возвращает текст, а 1С записывает его в объект. При исходящем HTTPS‑доступе это проще и дешевле сервис‑прослоек. URL, ключ и параметры модели храните в константах или справочнике настроек.
Учитывайте лимиты, таймауты и формат JSON. Заголовки X-RateLimit-Limit, X-RateLimit-Remaining и X-RateLimit-Reset помогают настроить паузы или очереди; ошибки 4xx указывают на запрос или авторизацию, 5xx — на сбой ИИ. Для пилота достаточно одного сценария, например автогенерации ответа клиенту. Операции, меняющие суммы или статусы УПД, сразу подключать не стоит.
Поток данных между 1С и ИИ
После проведения документа, нажатия кнопки или запуска обработки код собирает данные и отправляет текстовый либо JSON‑запрос к API модели. Ответ парсят и сохраняют в реквизите, комментарии или регистре сведений вместе с идентификатором документа, датой и пользователем.
Если результат не влияет на проводки, суммы или статусы УПД, его можно записать и логировать. При влиянии на отгрузку или оплату ответ отправляют в черновик для проверки и только затем переносят в рабочие реквизиты.
Пример кода с HTTPСоединение и HTTPЗапрос
Минимальная реализация создает HTTPСоединение, формирует заголовки Authorization и Content-Type и выполняет POST‑запрос. JSON может содержать prompt, context, настройки модели и идентификатор пользователя. Ответ разбирают стандартными средствами 1С, выделяя текст и ошибку.
Проверяйте HTTP‑статус и поля ошибки, учитывайте X-RateLimit-Limit, X-RateLimit-Remaining и X-RateLimit-Reset. Не храните ключи в коде, не игнорируйте 4xx/5xx и не выполняйте медленные запросы в интерфейсном потоке.
Запись ответа ИИ в документы 1С
Ответ сохраняют в комментарии к заказу, поле «Ответ ИИ» или регистре сведений для аудита. Для бизнес‑решений используйте статусы: «черновик», «подтверждено», «отклонено»; в документ попадают только подтвержденные ответы.
Для старта достаточно одного поля в тестовой конфигурации. Модель сначала должна быть советчиком, а не автономно менять статусы заказов или УПД.
Сервис-прослойка между 1С и ИИ
Эта схема нужна, когда 1С не может напрямую выходить в интернет или когда доступ к внешним API нужно жестко контролировать. В отличие от раздела про «Схемы для 1С без доступа к интернету», здесь речь о постоянном онлайн‑сервисе, который стоит между 1С и ИИ и отвечает за безопасный обмен. Шлюз из раздела про работу без интернета — частный случай такой прослойки с более строгими фильтрами.
1С обращается к сервису по локальному HTTP или через файловый/очередной обмен, сервис принимает запрос, ходит к ИИ API, обрабатывает ошибки и возвращает очищенный ответ. В прослойке удобно концентрировать авторизацию, лимиты, очереди, ретраи, логи и метрики, не усложняя конфигурацию 1С. Ключи и токены лежат в сервисе, а не в базе 1С.
Если выход 1С в интернет запрещен или нужно унифицировать доступ к нескольким моделям ИИ и другим API, сервис-прослойка — базовая архитектура. Что сделать сейчас: выбрать стек (например, FastAPI или Express), описать 2–3 эндпоинта и формат JSON, затем согласовать место и режим работы сервиса с ИБ.
REST-сервис на Python или Node.js
Базовый эндпоинт /ai принимает JSON, например с полями context (описание задачи), payload (данные из 1С) и userId (кто инициировал запрос). В ответ сервис возвращает объект с text (готовый ответ ИИ), errorCode (если что-то пошло не так) и, при необходимости, диагностикой.
На FastAPI это POST‑метод с pydantic‑моделью. Псевдоструктура:
class AiRequest(BaseModel):
context: str
payload: dict
userId: str
@app.post("/ai")
async def ai_handler(req: AiRequest):
resp = await httpx.post(
LLM_URL,
json={"prompt": build_prompt(req.context, req.payload), "user": req.userId},
timeout=10,
)
if resp.status_code != 200:
return {"text": "", "errorCode": resp.status_code}
data = resp.json()
return {"text": data.get("answer", ""), "errorCode": ""}
На Express структура похожая:
app.post("/ai", async (req, res) => {
const { context, payload, userId } = req.body;
try {
const resp = await axios.post(
LLM_URL,
{ prompt: buildPrompt(context, payload), user: userId },
{ timeout: 10000 }
);
res.json({ text: resp.data.answer, errorCode: "" });
} catch (e) {
res.json({ text: "", errorCode: "LLM_ERROR" });
}
});
Если нагрузка растет, сервис масштабируется независимо от 1С: можно добавить несколько инстансов за балансировщиком, изменять логику работы с моделями или очередями, не трогая конфигурацию учетной системы.
Важно не оставлять вызовы без таймаутов и логирования и не передавать в ИИ «сырые» данные без фильтрации: сервис должен явно знать, какие поля допустимо выводить наружу и какие сценарии ему разрешено выполнять.
Очереди, ретраи и логирование
Сервис-прослойка помогает переживать временные сбои ИИ, CRM и сетевые проблемы. Запросы от 1С можно сначала положить в очередь (таблица в БД или брокер сообщений), а отдельный обработчик по мере возможности вызывать ИИ и возвращать результат.
При ошибках 5xx, таймауте или недоступности модели сервис повторяет запрос по правилам (через заданный интервал, с ограничением по числу попыток), не блокируя работу 1С. Для операций, чувствительных к потере (статусы УПД, коды маркировки), очередь обязательна.
Логи должны фиксировать минимум: время, тип операции, ID документа или объекта в 1С, статус ответа ИИ, код ошибки и основные параметры запроса. Это помогает отслеживать проблемы и не слепо полагаться на внешнюю модель.
На пилоте достаточно простой таблицы или файла‑журнала с записями «запрос → ответ → результат обработки». По этим данным видно, где нужны ретраи, какие лимиты выставить и как часто сервис сталкивается с отказами по каждой из пяти схем.
ИИ-агент для AmoCRM и Битрикс24
Когда CRM — центр продаж, пилот проще запускать именно там. Базовая архитектура из начала статьи такая: CRM отправляет событие по webhook → оркестратор (например, n8n или ваш сервис) принимает JSON → вызывает ИИ → пишет результат обратно в CRM через REST‑API. Здесь фокус не на повторном описании цепочки, а на том, как агент используется в живых сценариях.
Триггеры — новая сделка, изменение стадии, создание контакта, входящее сообщение или звонок. Важно, чтобы вебхуки и токены были настроены один раз и контролировались централизованно, а не описывались заново в каждом сценарии. Следите за лимитами API и сроком жизни токенов, чтобы массовая обработка событий не упиралась в ограничения.
Если CRM уже структурирована, а менеджеры тонут в переписке и звонках, ИИ-агент дает быстрый эффект. Начните с одного webhook на тестовую воронку и сценария, который записывает результат ИИ только в комментарий, без прямой смены стадий и сумм.
Запуск по webhook и маршрут данных
Маршрут данных выглядит так: CRM отправляет webhook с JSON‑payload → оркестратор читает сделку, контакт и переписку → формирует промпт для ИИ с нужными полями → вызывает модель → получает ответ и через REST‑API обновляет CRM. Эта логика описана один раз и дальше переиспользуется во всех сценариях.
Сами вебхуки и токены не стоит дублировать в описании каждого блока: достаточно один раз задать правила их обновления и мониторинга. Если событие критично (смена статуса оплаты, УПД подписан), лучше добавить ручную проверку перед применением предложений ИИ и оставить агенту роль советника.
На тестовой воронке полезно промерить задержки: от события до webhook, от webhook до ответа ИИ и от ответа до обновления CRM. Это покажет, насколько процесс подходит для автоматизации без дискомфорта для клиентов и без перегруза менеджеров.
Обновление полей сделки и ответы клиентам
Основные действия агента: резюме переписки в поле «Комментарий», классификация лида, автозаполнение атрибутов сделки, постановка задач менеджеру и подсказки по следующему шагу, черновики ответов клиентам. При нестандартных запросах, сильном негативе или попытке выбить крупную скидку агент не принимает решение сам, а эскалирует на человека.
Полезно явно разделить поля:
- •что можно отдавать ИИ: текст переписки, общие параметры сделки, публичные реквизиты;
- •что лучше не отдавать: детальные цены, скидки, внутренние пометки, конфиденциальные данные;
- •что ИИ может менять сам: комментарии, задачи, вспомогательные поля и метки;
- •что требует подтверждения: суммы, стадии, обещания клиенту и любые юридически значимые условия.
Если ИИ меняет статус сделки или влияет на деньги, используйте пороги и правила: например, автоматическая смена стадии только при явном согласии клиента и без изменения суммы, а все остальное — через подтверждение менеджером.
Ошибки CRM и повторные запросы
Ошибки CRM имеет смысл обрабатывать один раз в оркестраторе, а не расписывать под каждый сценарий. При кодах 401 он обновляет токен, при 429 — замедляет поток запросов или ставит их в очередь, при 5xx — отправляет в отложенную обработку с повторной попыткой.
Если CRM часто недоступна в пиковые часы, нужен fallback: ИИ продолжает общение с клиентом, помечает диалог как «ожидает записи», а сервис позже создает или обновляет сделку. Логирование вебхуков и искусственный прогон ошибок помогают проверить, что повторные запросы работают предсказуемо и данные не теряются.
Чат-бот ИИ и 1С для склада
Клиент пишет боту, ИИ извлекает суть, сервис запрашивает в 1С остатки, цены или статус заказа, а бот отправляет понятный ответ. Это снижает нагрузку менеджеров. Заранее определяют самостоятельные операции (статус, наличие) и случаи для человека (споры, крупные суммы, претензии).
- •ИИ не работает с 1С без настройки: нужен HTTP‑сервис или REST с определенными данными.
- •Полная база опасна: клиенту могут раскрыться внутренние цены, скидки и пометки.
- •Чтение данных, включая УПД и персональные данные, требует безопасности и аудита.
- •Нужны отдельные роли, пользователь и сервисы 1С.
Для пилота выберите Telegram или WhatsApp, опишите 3–5 вопросов и проверьте, сводится ли каждый к параметрам и 1–2 обращениям к 1С.
Схема диалога и запросов к 1С
В запросе «где мой заказ 12345» ИИ извлекает номер, уточняет город или пункт выдачи, сервис получает статус из 1С, а модель переводит его в понятный ответ. Параметры (номер заказа, дата, ФИО, телефон) подставляются в подготовленный вызов: ИИ не обращается к базе напрямую.
- •распознать тип запроса;
- •извлечь параметры;
- •выполнить один вызов к 1С;
- •перевести статус и числа без внутренней терминологии.
При неполных данных (нет номера, перепутан город, устарел заказ) бот просит уточнение или передает диалог менеджеру.
Остатки, цены и статусы заказов
Используются справочник номенклатуры, регистры остатков и резервов, документы заказов покупателей и реализаций. Следует учитывать кеш, репликацию и обновление регистров, не обещая точность до минуты.
- •остатки: код товара, склад, единица измерения, свободный остаток без резервов;
- •цены: тип, валюта, дата действия;
- •статусы: номер, дата, статус, сумма, способ доставки.
Из ответов исключают внутренние артикулы, пометки, наценки и скидки.
Ограничение данных и уровни доступа
Боту назначают отдельного пользователя 1С с минимальными правами: просмотр нужных справочников и регистров, доступ к определенным документам, запрет изменения проводок. Для персональных данных, УПД и кодов маркировки нужны журналирование и маскирование ФИО, телефонов и адресов.
- •ограниченная роль и аудит чтения и изменений;
- •фильтры по статусам и типам документов;
- •сценарии, требующие подтверждения человеком.
Создайте технического пользователя, привяжите минимальную роль и проверьте тестовые диалоги по логам: это покажет лишние поля и необходимость ручной проверки.
True API Честного знака и ИИ
True API связывает 1С, WMS и ЭДО с системой маркировки: через него заказывают коды, вводят их в оборот, передают, выводят и проверяют статусы УПД. ИИ добавляет поверх этого слой понятных пояснений: переводит технические ответы и ошибки в человеческий язык, помогает пользователям понять, что произошло и что делать дальше.
Если оборот маркированных товаров большой, операции лучше вести через True API, а личный кабинет оставлять запасным каналом. Нужны два контура — sandbox для тестов и промышленный для боевой работы, плюс настроенные УКЭП и СКЗИ на сервере. Асинхронность запросов и контроль статусов УПД напрямую влияют на отгрузку и оплату, поэтому архитектура должна учитывать задержки.
Если инфраструктура подписи уже готова, следующий шаг — связать ответы True API с ИИ: собирать статусы и ошибки, а затем давать пользователям краткие пояснения и чек‑листы действий, не вмешиваясь напрямую в юридически значимые данные.
Авторизация и токены True API
Авторизация строится на запросе случайных данных, их подписи УКЭП и получении JWT‑токена. Сервер запрашивает случайную строку, подписывает ее ГОСТ‑ключом через СКЗИ (например, КриптоПро), отправляет подпись и получает токен для последующих вызовов.
- •типичные проблемы: неверный сертификат, просроченная УКЭП, ошибка формата CMS‑подписи;
- •подготовка: установка и проверка СКЗИ, корректная цепочка доверия, тесты авторизации в sandbox;
- •роль ИИ: объяснить пользователю, почему авторизация не прошла, и какие шаги нужны (обновить сертификат, проверить настройки подписи).
Если подпись на сервере не настроена, интеграция с True API не стартует. ИИ здесь помогает быстрее найти причину, но сама настройка криптоинфраструктуры остается задачей администраторов.
Методы для кодов и документов
Основные операции True API: заказ кодов маркировки, ввод в оборот, передача, вывод из оборота, а также работа с УПД. Каждый запрос требует набора полей: GTIN, серийный номер, код товара, данные участников, параметры партии.
Мини‑пример: запрос на ввод в оборот может вернуть ответ вида {"status": "ERROR", "errorCode": "WRONG_PRODUCT_DATA"}. ИИ объясняет это как «данные товара в запросе не совпадают с зарегистрированными в системе маркировки» и предлагает проверить коды, наименование, GTIN и контрагента.
Если часть операций по маркировке все еще делается вручную через личный кабинет, они кандидаты на перенос в True API. Версии API нужно отслеживать: устаревшие методы отключаются, и ИИ может помогать пользователям понимать, почему запрос больше не работает и какой метод использовать вместо него.
Асинхронные операции и статусы УПД
Многие операции True API асинхронны: сначала система возвращает ID задачи, затем по этому ID нужно регулярно проверять статус. Для УПД возможны состояния «отправлен», «получен», «подписан», «отклонен», «в обработке» — создание задачи не гарантирует успешное завершение.
- •«подписан» — можно продолжать обычный процесс отгрузки и оплаты;
- •«отклонен» — требуется найти причину и скорректировать документ;
- •«в обработке» — стоит повторить проверку через заданный интервал.
Упрощенный сценарий: сервис отправляет запрос, получает {"taskId": "123"}, периодически делает GET /tasks/123 и получает, например, {"status": "REJECTED", "errorCode": "INVALID_UPD_DATA"}. ИИ превращает это в понятное сообщение: «УПД отклонен: некорректные реквизиты документа или участника. Проверьте реквизиты продавца и покупателя, номер и дату УПД, соответствие данных договору», и добавляет список шагов, не меняя сам документ.
Если бизнес зависит от статуса УПД (фулфилмент, работа с маркетплейсами), нужен отдельный процесс или сервис для мониторинга статусов, а ИИ — для объяснения этих статусов и подсказок по дальнейшим действиям.
Права, ключи и работа без интернета
Интеграция ИИ с 1С, CRM и True API всегда связана с боевыми данными: деньгами, остатками, УПД и реквизитами клиентов. Поэтому важно заранее разделить права, настроить хранение ключей и продумать работу в средах без прямого выхода в интернет. Риски при этом зависят от выбранной схемы: прямой вызов из 1С, сервис-прослойка, CRM‑агент, чат‑бот со складом или контур True API.
Критерий простой: если ИИ-агент имеет доступ к реальным данным учетки или CRM, без аккуратного разграничения прав и инвентаризации токенов пилот рискован. Настройки для 1С, CRM и сервис-прослоек должны быть согласованы между собой и увязаны с выбранной архитектурой: где лежат ключи, от чьего имени действует агент, какие данные уходят наружу.
Базовый чек‑лист инвентаризации ключей и прав сосредоточен на главном:
- •перечислить все API‑ключи, токены и сертификаты, которые используются для ИИ, CRM и True API;
- •определить, где они хранятся (файлы, справочники, переменные окружения, секрет‑хранилища);
- •проверить, кто имеет к ним доступ и под какими ролями;
- •описать, какие действия может выполнять ИИ-агент в каждой из пяти схем;
- •установить правила смены ключей и токенов и порядок их отзыва;
- •для схем без интернета — отдельно описать, какие данные выходят на шлюз, а какие остаются внутри.
Если такого списка нет, начните пилот именно с его заполнения: это покажет, где тонко, и какие ограничения стоит ввести до запуска.
Хранение API-ключей и токенов
Ключи и токены нужно хранить отдельно от прикладного кода и пользовательских данных. В 1С — в конфигурационных файлах или специальных справочниках с ограниченным доступом, в сервис-прослойках — в переменных окружения, секрет‑хранилищах или зашифрованных конфигурациях.
Критерий: если ключ лежит в открытом модуле 1С или в обычной таблице, это уязвимость. Простые правила:
- •использовать отдельные технические учетные записи для интеграций;
- •ограничивать чтение ключей и токенов только сервису, который их реально применяет;
- •шифровать или маскировать ключи в логах и интерфейсах;
- •менять токены регулярно и при каждом подозрении на утечку;
- •не пересылать ключи по почте и мессенджерам.
Если ключ попал в открытый канал, лучше считать его скомпрометированным и перевыпустить, а не надеяться на случай.
Роли и права ИИ-агента
Для ИИ-агента в 1С и CRM полезно создать отдельные роли и учетные записи. Им дают минимальный набор прав, достаточный для чтения необходимых данных и записи черновиков.
- •в 1С — чтение заказов, остатков, базовых реквизитов, ограниченные права на комментарии и служебные поля;
- •в CRM — доступ к сделкам, перепискам и задачам без прав на изменение финансовых полей и закрытие сделок;
- •для True API — права на чтение статусов и ошибок, без возможности запускать критичные операции без участия человека.
Критерий: если действие ИИ влияет на деньги или юридические документы, нужна двухступенчатая схема «черновик → подтверждение человеком». Это касается изменений сумм, стадий сделок, статусов УПД и любых операций, которые могут вызвать споры с контрагентами.
Схемы для 1С без доступа к интернету
Когда политика ИБ не допускает прямой выход 1С в интернет, есть несколько вариантов. Первый — локальный ИИ на сервере рядом с 1С: модель или агент работают внутри периметра и не отправляют данные наружу. Второй — сервис‑шлюз в отдельной зоне, который по строго заданным правилам обменивается минимальным набором данных с внешним ИИ и по сути является специализированной сервис-прослойкой.
- •выделить отдельный сервер или виртуальную машину под шлюз;
- •ограничить типы запросов и поля, которые могут выходить за периметр;
- •передавать только технические идентификаторы и агрегированные данные, без персональных и финансовых деталей;
- •использовать существующие механизмы обмена (например, MPC‑подобные решения), если они уже встроены в вашу инфраструктуру.
Критерий: если прямой выход 1С в интернет невозможен, архитектура должна минимизировать объем передаваемых данных и четко разделять контуры. Сначала проектируется шлюз и права, а уже потом подключается внешняя модель ИИ.
Точки отказа и оценка затрат
Любая из пяти схем интеграции ИИ опирается на несколько звеньев: 1С или CRM, сервис-прослойку, ИИ API, True API, подпись, сеть. Чем больше звеньев, тем больше потенциальных точек отказа и затрат на поддержку. Для пилота выгодно выбирать архитектуру с минимальным числом элементов, которые вы реально контролируете.
Надежность повышают очереди, логи, ретраи и fallback‑сценарии, но их стоит описывать один раз для всей архитектуры, а не повторять в каждом разделе. Критичные операции — маркировка, УПД, изменения финансовых статусов — лучше проводить через черновики и ручное подтверждение, чтобы сбой ИИ не превращался в ошибку учетки.
Точки отказа и способы их обойти
Основные точки отказа одинаковы для разных схем:
- •недоступность ИИ или превышение лимитов API;
- •сбои CRM или 1С (падение базы, недоступность REST‑интерфейса);
- •истекшие или некорректные токены для CRM, ИИ и True API;
- •ошибки подписи и криптоинфраструктуры для True API;
- •сетевые проблемы между сервис-прослойкой и внешними API.
Базовый обход для всех: запросы ставятся в очередь, при отказе выполняются ретраи по правилам, пользователю отдается безопасный шаблонный ответ, а критичные операции переводятся в ручной режим. Для маркировки и УПД обязательно предусмотреть запасной путь через личный кабинет или ручную корректировку документов.
Что проверить на пилоте: отказ ИИ, недоступность CRM/1С, проблемы True API, истекшие токены. Эти сценарии лучше прогнать заранее и убедиться, что очередь и fallback работают, а данные не теряются.
Таблица затрат по пяти схемам
Эта таблица напрямую соответствует пяти схемам из начала статьи и помогает сравнить их по трудозатратам и рискам. Если инфраструктура минимальная (один сервер 1С с интернетом, без отдельного сервера и УКЭП), логичен прямой HTTP‑вызов ИИ из 1С или агент для CRM. Если есть команда под Python/Node.js и требования ИБ высокие, разумен вариант с сервис-прослойкой. Если нет УКЭП и СКЗИ, схемы с True API лучше отложить.
Отметьте в таблице те строки, для которых у вас уже есть инфраструктура и компетенции: пилот стоит запускать с этих опций, а более тяжелые схемы планировать на вторую очередь.
Шаги для запуска пилота
Для старта пилота полезно зажать сценарий и схему в узкие рамки. Сначала выберите один процесс: остатки и статусы в 1С, одну воронку в CRM или небольшой набор операций маркировки. Затем сопоставьте его с подходящей из пяти схем, опираясь на таблицу затрат.
- •описать поток данных от триггера (документ, сделка, операция) до записи результата на одной диаграмме;
- •запустить тестовый контур с логами, очередями и ограниченными правами ИИ-агента;
- •обкатать один процесс (типовой заказ или одну воронку), посмотреть на логи и точки отказа;
- •после стабильной работы расширять сценарий постепенно, не убирая fallback и ретраи.
Критерий: если пилот нельзя описать на одной странице схемы, он перегружен. Лучше сузить объем, чем пытаться автоматизировать все сразу.
Источники
