Главный вопрос для компаний, которые подключают ИИ-агентов к SAP, звучит не так: «теперь сторонним системам вообще нельзя работать с SAP?». Граница тоньше. Обновление политики API в апреле 2026 года сужает поддерживаемое использование API вокруг ERP-данных и бизнес-процессов до опубликованных интерфейсов, документации продуктов, одобренных SAP архитектур, сервисов данных или явно указанных сервисных путей.^[1][7][10]

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

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

SAP формализует границу между «можно вызвать» и «поддерживается и разрешено использовать долгосрочно». По данным CIO, SAP считает опубликованными API только те интерфейсы, которые перечислены в SAP Business Accelerator Hub или в документации соответствующего продукта.^[7] The Register также сообщает, что новая политика разрешает использовать API только в пределах

SAP-endorsed architectures, data services, or service-specific pathways

[2]

[10]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вывод

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

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