Новая политика SAP API: как она ограничивает сторонних ИИ-агентов в ERP

Для ИТ-директоров, архитекторов и команд автоматизации это не юридическая мелочь, а практический вопрос проектирования. Новые правила могут затронуть PoC с ИИ-агентами, data lakehouse, RPA, iPaaS, ETL-конвейеры и собственные сценарии автоматизации, если они напрямую читают или меняют данные в SAP.

Что именно меняется

SAP формализует границу между «можно вызвать» и «поддерживается и разрешено использовать долгосрочно». По данным CIO, SAP считает опубликованными API только те интерфейсы, которые перечислены в SAP Business Accelerator Hub или в документации соответствующего продукта. The Register также сообщает, что новая политика разрешает использовать API только в пределах SAP-endorsed architectures, data services, or service-specific pathways — то есть архитектур, сервисов данных или специальных маршрутов, одобренных SAP.

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

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

Иными словами, это не только «пункт про ИИ». Это более широкий вопрос управления ERP-интеграциями: какие API считаются опубликованными, какие сценарии поддерживаются, где есть лимиты на выгрузку и репликацию, а какие автоматизации должны идти только через одобренный SAP маршрут.

Почему ИИ-агенты попали в центр внимания

Самый спорный блок — правила для автономных и генеративных систем. В публикациях, ссылающихся на текст политики, говорится, что SAP запрещает использовать API для взаимодействия или интеграции с полуавтономными либо генеративными ИИ-системами, которые планируют, выбирают или выполняют последовательности API-вызовов, если это не происходит через одобренные SAP архитектуры, сервисы данных или специально указанные пути.

Здесь важно отличие агентного ИИ от классической интеграции. Обычная интеграция чаще работает по заранее заданному сценарию: система вызывает конкретный API и выполняет одну понятную операцию. ИИ-агент может действовать иначе: сначала проверить поставщика, затем складские остатки, затем историю закупок, затем сформировать рекомендацию и, возможно, запустить согласование или обновить запись.

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

Та же группа ограничений затрагивает scraping, harvesting, а также систематическое или крупномасштабное извлечение и репликацию данных. Поэтому риск касается не только агентов, которые что-то записывают в SAP. Массовое чтение SAP-данных для внешней ИИ-платформы, lakehouse или слоя orchestration тоже требует повторной проверки.

Инновации не останавливаются, но PoC становятся «взрослее»

Для внутренних инновационных команд, системных интеграторов и ISV главный сдвиг — появление дополнительного этапа управления до эксперимента. Раньше команда могла быстрее подключить сторонний ИИ-агент к ERP и проверить автоматическую сверку, закупочные рекомендации, анализ запасов или автоматизацию клиентского сервиса. Теперь до такого PoC нужно выяснить, есть ли API в SAP Business Accelerator Hub или документации продукта, относится ли архитектура к одобренным SAP путям, не затрагивает ли сценарий квоты и ограничения на массовую выгрузку, и будет ли агент самостоятельно строить цепочки API-вызовов.

Это не означает, что ИИ-пилоты вокруг SAP невозможны. Скорее, они начинают напоминать полноценный интеграционный проект: нужен реестр API, модель прав доступа, оценка нагрузки, схема потоков данных и подтверждение соответствия политике.

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

Неопределённость сама по себе способна замедлить инновации. The Register сообщает, что немецкоязычная группа пользователей SAP DSAG раскритиковала политику за неопределённость; в той же публикации критики указывают, что список одобренных интерфейсов может быть недостаточно хорошо управляемым и не всегда своевременно обновляться.

Контроль данных: вопрос не только в том, кому они принадлежат

Спор вокруг политики — это не только вопрос формального владения клиентскими данными. Для бизнеса важнее другое: может ли компания использовать выбранную ею ИИ-платформу, стек данных и инструменты автоматизации для прямого, регулярного и почти реального доступа к SAP-данным и ERP-процессам.

The Register описывает проблему как риск исключения сторонних ИИ-инструментов из доступа к клиентским данным SAP; ERP Today рассматривает её на уровне архитектуры ERP-интеграций, репликации данных и ИИ-доступа.

Если компания хочет синхронизировать SAP-данные во внешний lakehouse, ИИ-платформу, agent orchestration layer или стороннюю систему автоматизации, ей нужно отдельно проверить квоты data ingress/egress, условия массового извлечения и репликации, область опубликованных API и необходимость идти через одобренный SAP маршрут.

Такой подход может усилить контроль производительности, безопасности, аудита и governance. Цена — меньшая свобода в кроссплатформенной ИИ-архитектуре, особенно там, где сценарий требует активного чтения и записи транзакционных SAP-данных.

Vendor lock-in: риск выше, но исход не предрешён

Риск привязки к поставщику возникает из практической логики. Если сторонний ИИ-агент не может свободно взаимодействовать с SAP API, заказчик с большей вероятностью будет опираться на одобренные SAP архитектуры, официальные сервисы данных или явно разрешённые способы интеграции. The Register уже описал ИИ-пункт политики как источник опасений по поводу lock-in, поскольку он может ограничить доступ некоторых сторонних ИИ-инструментов к данным клиентов SAP.

Реакция DSAG показывает, что пользовательское сообщество видит проблему шире, чем набор технических ограничений. E3 Magazine сообщает, что DSAG считает неприемлемыми жёсткие ограничения SAP на недокументированные сценарии, систематическое массовое извлечение данных и взаимодействие со сторонними автономными генеративными ИИ-системами.

При этом lock-in не является неизбежным результатом. Многое будет зависеть от того, насколько ясно SAP определит одобренные пути, насколько полно и быстро будет обновляться список опубликованных API, появятся ли проверяемые процедуры исключений или согласований, и смогут ли сторонние поставщики продолжать инновации по понятным правилам. Критики уже указывают на возможные проблемы с управлением и актуальностью списка одобренных интерфейсов — это именно та область, которую заказчикам стоит проверять до закупки или архитектурного решения.

Что делать компаниям сейчас

1. Составить реестр всех SAP-интеграций. Для каждого подключения стоит отметить: опубликованный API, API из документации продукта, недокументированный интерфейс, массовая выгрузка, чтение/запись в реальном времени, RPA, iPaaS или вызов из внешнего workflow либо ИИ-агента.

2. Отдельно проверить ИИ-сценарии. Все процессы, где модель или агент сам планирует, выбирает или выполняет несколько SAP API calls, должны пройти оценку риска по новой политике.

3. Пересмотреть извлечение и репликацию данных. Массовая extraction, replication, scraping и harvesting прямо попали в ограничиваемую область. Действующие data lake, lakehouse, BI, ИИ-обучение и синхронизация данных требуют проверки квот, условий и допустимых маршрутов.

4. Запрашивать письменное подтверждение у SAP или внедренческого партнёра. Для агентного ИИ, автоматических транзакционных обновлений, кросс-системной orchestration и массового экспорта данных лучше не полагаться на устные трактовки. Критика DSAG по поводу неопределённости показывает, насколько важны письменно зафиксированные границы.

5. Сохранять архитектурный выбор. Даже если компания использует одобренный SAP путь, стоит проектировать ИИ-оркестрацию, управление данными, права доступа, журналы аудита и бизнес-правила как заменяемые модули. Это снижает риск того, что вся логика инноваций окажется привязанной к одному маршруту.

Вывод

Новая политика SAP API 2026 года не означает, что ИИ больше нельзя использовать с SAP. Но она означает, что сторонние ИИ-агенты не должны рассчитывать на свободную оркестрацию SAP API, особенно если они сами планируют и выполняют цепочки вызовов. Для компаний это повышает требования к безопасности, производительности и управлению, но также увеличивает стоимость соответствия, усложняет быстрые эксперименты и усиливает опасения по поводу привязки к поставщику.

Самая прагматичная стратегия на ближайшее время — инвентаризировать интеграции, выделить рискованные ИИ-агенты, подтвердить одобренные SAP маршруты и заранее оставить в архитектуре пространство для кроссплатформенного выбора.