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

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

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

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

Проще говоря: техническая возможность подключиться к SAP API больше не означает, что поверх них можно свободно построить любого ИИ-агента.

Главная граница: ИИ советует или ИИ действует

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

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

Если инструмент работает с уже выгруженными данными — например, делает сводку, прогноз или подсказку для пользователя, — риск обычно ниже. Особенно если финальное действие все равно выполняет человек внутри SAP.

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

Четыре практические границы новой политики

1. Стороннему ИИ-агенту нужен признанный SAP маршрут

The Register пишет, что SAP запрещает использование своих API для интеграции с ИИ-системами вне одобренных архитектур, что вызвало опасения: сторонние ИИ-инструменты могут оказаться отрезаны от клиентских SAP-данных и процессов.

Fivetran также отмечает, что политика прямо выделяет полуавтономные и генеративные ИИ-системы, которые сами планируют, выбирают или выполняют последовательности вызовов API.

Это меняет логику проектирования. Вопрос теперь не только в том, может ли коннектор технически достучаться до SAP API. Вопрос в том, относится ли конкретный сценарий к SAP-endorsed architecture, data service или service-specific pathway — то есть к маршруту, который SAP прямо допускает для такого типа использования.

2. Опубликованные и документированные API становятся базовым требованием

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

В SAP API Policy опубликованные API определяются как API, размещенные в SAP Business Accelerator Hub, также известном как API Hub, или иным образом указанные в продуктовой документации.

Для компаний с большим наследием кастомных интеграций это важный сигнал. Даже если старый коннектор сегодня работает, его устойчивость при обновлениях, аудитах и изменении поддержки может стать слабым местом.

3. Массовое извлечение и копирование данных тоже под ограничениями

Новая оговорка касается не только ИИ-агентов, которые вызывают API по цепочке. Fivetran и The Register указывают, что политика также затрагивает scraping, harvesting, систематическое или крупномасштабное извлечение и репликацию данных — если это не проходит через контролируемые или одобренные SAP архитектуры и маршруты.

Поэтому проект, в котором SAP-данные массово копируются во внешний data lake, warehouse или не-SAP ИИ-платформу, нужно оценивать не только по стоимости, скорости и пропускной способности. Придется проверять API Policy, договорные права, лимиты API, требования аудита и допустимый маршрут доступа.

4. Экосистема SAP становится более естественным вариантом

SAP в собственной документации описывает возможность строить ИИ-агентов на SAP BTP — Business Technology Platform — и интегрировать их с Joule, центральным ИИ-копилотом SAP, а также с базовой ИИ-инфраструктурой SAP BTP. SAP Cloud SDK for AI также может подключаться к популярным агентным фреймворкам через LangChain и другие адаптеры.

Кроме того, SAP позиционирует SAP Knowledge Graph как механизм, который помогает Joule и другим ИИ-системам, включая ИИ-агентов, отвечать точнее и релевантнее за счет бизнес-контекста из SAP-приложений.

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

Какие ИИ-проекты затронуты сильнее всего

Сценарий	Уровень риска	Почему
BI, отчеты или офлайн-анализ на основе уже разрешенной выгрузки	Низкий или средний	Если ИИ не оркестрирует SAP API напрямую, он меньше похож на agentic AI-сценарий. Но крупное извлечение или репликация данных все равно требуют проверки.
Чат-бот дает рекомендацию, а человек выполняет действие в SAP	Низкий	В центре политики — ИИ-системы, которые планируют, выбирают или выполняют последовательности API calls. Рекомендательный сценарий отличается от прямого управления SAP.
ИИ автоматически читает и изменяет SAP: остатки, заказы, закупки, согласования, мастер-данные	Высокий	Обычно это многошаговые вызовы API, запись обратно в систему и изменение бизнес-состояния — именно та зона, на которую обращает внимание новая оговорка.
SAP-данные массово копируются во внешнюю ИИ-платформу	Высокий	Политика отдельно упоминает scraping, harvesting, систематическое или крупномасштабное извлечение и репликацию данных.
Старые коннекторы и кастомные интеграции используют недокументированные API	Средний или высокий	SAPInsider указывает, что недокументированные API находятся за пределами поддержки; SAP Policy привязывает Published APIs к API Hub или продуктовой документации.

Что меняется для инноваций: пилот начинается с governance

С точки зрения платформенного управления у SAP есть понятная мотивация ограничивать неограниченные внешние вызовы к ядру ERP, особенно там, где есть запись, транзакции и влияние на производительность. В SAP API Policy прямо говорится о защите solution health и security, справедливом доступе и предотвращении злоупотреблений API.

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

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

Контроль над данными: доступ не равен праву на прямое действие

Обновленная политика в первую очередь регулирует доступность API, лимиты и контрольные механизмы. Это не полноценное заявление о владении данными.

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

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

Важно и другое: в том же анализе приводится разъяснение CEO SAP Christian Klein о том, что цель политики — защитить доменную экспертизу SAP и избежать деградации производительности, а не лишить клиентов доступа к их собственным данным. Для предприятий практический вывод остается прежним: такую позицию нужно переводить в договоры, архитектурные решения, список одобренных маршрутов и явные разрешения для каждого use case.

Vendor lock-in может сместиться в слой процессов

Зависимость от поставщика не всегда выглядит как запрет на экспорт данных. В мире ИИ-агентов она может возникать в слое оркестрации процессов.

Если самый безопасный, понятный для аудиторов и наименее спорный путь автоматизации — размещать агентов внутри SAP BTP, Joule, SAP AI Core или Knowledge Graph, долгосрочная ИИ-архитектура компании естественным образом будет сильнее опираться на экосистему SAP.

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

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

1. Разобрать ИИ-сценарии на типы действий. Отделите read-only, write-back, сценарии с ручным подтверждением и сценарии, где ИИ сам выполняет многошаговый процесс. Риск резко растет в последних двух категориях.
2. Запросить у SAP или системного интегратора подтверждение допустимого маршрута. Для каждого сценария нужно понять, можно ли реализовать его через SAP-endorsed architecture, data service, service-specific pathway или через архитектуры вокруг SAP BTP и Joule.
3. Проверить, являются ли используемые API опубликованными и документированными. Если интеграция держится на недокументированных API, закладывайте риск рефакторинга, поддержки и обновлений.
4. Закрепить права на данные и ответственность в документах. Особенно важно описать использование стороннего ИИ, извлечение и репликацию данных, лимиты API, аудит, ответственность за инциденты и границу ответственности при записи обратно в SAP.
5. Следить за FAQ и обновлениями SAP API Policy. SAP указывает, что FAQ по API Policy содержит ответы на распространенные вопросы и может обновляться время от времени.

Вывод

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

Если компания уже строит ИИ-стратегию вокруг SAP BTP, Joule и SAP AI Core, официальный маршрут выглядит более понятным. Если же цель — открытый слой ИИ-агентов поверх разных корпоративных систем, перед разработкой нужно подтвердить одобренные SAP архитектуры, права использования API и границы извлечения данных. Иначе есть риск построить инновационный проект на интеграции, которую потом нельзя будет безопасно и легально эксплуатировать.