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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вывод

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

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