SQ1 — Механизмы доступа AI-агента к ERP/CRM

Part of: index.md · Method: web sweep · Status: done

Question

Какими техническими механизмами внешний AI-агент может получить доступ к ERP/CRM-системе? Построить таксономию способов подключения и для каждого определить тип доступа. Классы: (1) Native API — REST/GraphQL/SOAP/RPC; (2) Model Context Protocol (MCP); (3) iPaaS/коннекторы — Zapier, Make, n8n, Workato, Tray.ai; (4) RPA / computer-use / browser-агенты; (5) Webhooks / event streams / CDC; (6) прямой доступ к БД / DWH.

Каждый механизм классифицируется по трём осям (это ядро всего исследования):

Key findings

Сквозной вывод (крест всего SQ1): почти все «лёгкие» способы подключения (Data API, MCP, iPaaS, webhooks, DWH-синк) дают агенту доступ к ДАННЫМ (записям), но НЕ к конфигурации. Чтобы читать/менять workflows, автоматизации, права и схему (то есть проводить аудит настройки), нужен либо отдельный, более сложный Metadata/Config-API, либо RPA/computer-use, который водит по UI (включая admin-экраны). Это архитектурный, а не случайный разрыв: SaaS-вендоры намеренно разделяют «данные» и «метаданные».

1. Native API (REST / GraphQL / SOAP / RPC)

2. Model Context Protocol (MCP)

3. iPaaS / коннекторы (Zapier, Make, n8n, Workato, Tray.ai)

4. RPA / computer-use / browser-агенты (когда API нет)

5. Webhooks / event streams / CDC

6. Прямой доступ к БД / DWH (ODBC/JDBC, реплики, Fivetran-синк)

Сравнительная таблица (механизм × read/write × данные-vs-config × OOTB)

# Механизм Read / Write ДАННЫЕ (records) vs КОНФИГ/Metadata «Из коробки» (OOTB) / усилие Что реально даёт доступ
1a Native Data-API (REST/GraphQL/SOAP): SF REST, HubSpot CRM API, NetSuite REST, Odoo XML-RPC R + W ДАННЫЕ (CRUD по записям) Turnkey-ish (OAuth, доки), но интеграцию пишет разработчик Читать/менять записи; аудит workflow/настроек — нет
1b Native Metadata/Config-API: SF Metadata + Tooling API, SAP OData $metadata, NetSuite metadata R + W (Tooling чаще R — для аудита) КОНФИГУРАЦИЯ (objects, fields, profiles, permission sets, workflows, flows, Apex) Низкий OOTB — отдельный, более привилегированный и сложный API (SOAP, XML-пакеты, файловая модель) Читать/менять настройку org → база для само-аудита
2 MCP (HubSpot MCP, Zapier MCP, Make/n8n MCP, Agentforce как MCP-клиент) R + W (Resources=read, Tools=write) Наследует scope сервера; сегодня в осн. ДАННЫЕ + read-only конфиг Высокий, если есть готовый managed-сервер (минуты, OAuth); иначе сервер надо писать Данные read/write; переписать workflows через текущие CRM-MCP — нельзя
3 iPaaS / коннекторы (Zapier, Make, n8n, Workato) R + W (triggers=read/события, actions=write) Преимущественно ДАННЫЕ (CRUD через actions); config-операции редки Очень высокий (no-code, pre-built коннекторы; + MCP-обёртки) Оркестрация данных/действий; глубина = каталог действий коннектора
4 RPA / computer-use / browser (UiPath, Automation Anywhere, Anthropic computer use) R + W (всё, что может человек в UI) И ДАННЫЕ, И КОНФИГ (водит по UI, включая admin-экраны без API) Низкий OOTB, хрупко, кастом, медленно, governance-риски Единственный fallback к UI-only-настройкам → аудит того, у чего нет API
5 Webhooks / CDC / event streams (SF CDC, Platform Events, Streaming API) Read (push-уведомления; запись — отдельным API) Преимущественно ДАННЫЕ (изменения записей) Средний (admin-настройка + свой подписчик/endpoint) Near-real-time поток изменений записей; не конфиг-канал
6 Direct DB / DWH (ODBC/JDBC, read-реплики, Fivetran→Snowflake/BigQuery) В осн. Read (аналитическая копия); write в БД только on-prem (рискованно) ДАННЫЕ; при синке в DWH конфиг теряется; в self-hosted БД видны и config-таблицы SaaS: напрямую нельзя; Fivetran managed = turnkey read-copy. On-prem: кастом + рискованно Массовая аналитика/аудит данных; для реконфигурации бесполезно

Insights

Risks / caveats

Sources