Управление ИИ в SAP: соответствие требованиям, безопасность, ответственность

Управление ИИ в SAP охватывает каждую функцию ИИ, работающую в S/4HANA, SuccessFactors, Ariba, Concur или на SAP BTP. По каждой нужно знать, кто отвечает за её решения, какие данные она использует, как она журналируется и когда её пересматривают. Регуляторные сроки в 2026 году сдвинулись: обязанности по Закону ЕС об ИИ (EU AI Act) для автономных систем высокого риска, например ИИ при найме, теперь применяются с 2 декабря 2027 года. Требования прозрачности для контента, созданного ИИ, действуют уже сейчас. Это руководство для CIO, руководителей по соответствию требованиям и владельцев программ SAP. Оно показывает, где пробелы в управлении проявляются первыми, что изменилось в 2026 году, какие правила применяются, и даёт реестр, с которого можно начать на этой неделе. Начните с того, чтобы назначить одного владельца на каждую функцию ИИ.

Начните с простого вопроса: когда модель выдаёт результат, чьё имя стоит на кону? Если ответ неясен, у вас пробел в управлении.

Ландшафты SAP перенаселены: S/4HANA в ядре, облачная CRM, подключаемая аналитика, унаследованные системы, которые никто не хочет трогать. Инженер может развернуть модель за минуты. Проследить её влияние на найм, кредитование или планирование поставок может занять недели.

Данные всё усложняют. Расчёт заработной платы, заказы на закупку, запасы и рейтинги поставщиков приходят в разных форматах и находятся в ведении разных руководителей. Одна команда маскирует персональные идентификаторы, другая оставляет их открытыми. Прежде чем запускать любую модель, решите, какие данные она вправе использовать, кто утверждает изменения и как долго хранятся записи. Зафиксируйте это письменно, пересматривайте и добивайтесь исполнения.

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

Закономерности, которые я вижу снова и снова:

Финансы. ИИ в S/4HANA Finance помогает с обработкой счетов, прогнозом денежных средств и выявлением аномалий. Он полезен, пока не перестаёт быть таким: законный платёж заблокирован, сомнительный одобрен, прогноз построен на устаревших данных. Решение: журнал аудита по каждому решению, на которое повлиял ИИ, и назначенный человек, который его проверяет.

Закупки. ИИ рекомендует поставщиков, отмечает риски и проверяет договоры. Если исторические данные о закупках содержат смещение, например поставщиков, которым отдавали предпочтение по причинам, которых никто не видит, модель его повторит. Кто-то должен проверять шорт-листы, а не принимать их как есть.

HR. ИИ в SuccessFactors может помогать в первичном отборе кандидатов и анализе вовлечённости. Если его обучили на данных о найме, которые уже были смещены в пользу определённых профилей, он продолжит смещать. Проверяйте на предвзятость перед внедрением и снова после каждого переобучения.

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

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

Помню клиента, который использовал встроенный интеллект в SAP Ariba. Система начала автоматически помечать дубли поставщиков. Полезно, но никто не заметил, что пометки иногда срабатывали из-за несогласованных названий в основных данных. Дурных намерений не было, просто записи не совпадали. В закупках не было процесса проверки этих сигналов, и это вызвало задержки и путаницу. Решение: шаг проверки сигналов и единое правило именования в основных данных поставщиков.

SAP BTP. BTP позволяет командам создавать и развёртывать собственный ИИ по всему ландшафту SAP. Я видел, как модель одобряла плохих поставщиков, потому что её обучили на неполных данных о закупках. Проблема с данными возникла раньше проблемы с ИИ, и очистка входных данных исправила дело быстрее, чем настройка модели.

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

Сроки EU AI Act для высокого риска сдвинулись. Digital Omnibus по ИИ, Регламент (ЕС) 2026/1744, вступил в силу 27 июля 2026 года. Обязанности для автономных систем высокого риска по Приложению III, к которым относится ИИ в подборе и управлении работниками и в проверках кредитоспособности физических лиц, теперь применяются с 2 декабря 2027 года. Высокорисковый ИИ, встроенный в регулируемые продукты, следует за ними 2 августа 2028 года. Запрещённые практики и ИИ-грамотность действуют с февраля 2025 года, а требования прозрачности по статье 50 для контента, созданного ИИ, с 2 августа 2026 года. Перенос даёт время на подготовку, а не послабление. Оценка соответствия и техническая документация готовятся медленно.

1. 2025Запрещённые практики и ИИ-грамотностьС февраля 2025 года
2. 2026Digital Omnibus вступает в силу27 июля, Регламент (ЕС) 2026/1744
3. 2026Требования прозрачности для контента, созданного ИИ2 августа, статья 50
4. 2027Автономные системы высокого риска (Приложение III)2 декабря. Найм, управление работниками, проверка кредитоспособности физических лиц
5. 2028Высокорисковый ИИ в регулируемых продуктах2 августа

Источник: Регламент (ЕС) 2026/1744, Digital Omnibus по ИИ

Журналирование Joule зависит от выбора, который вы, возможно, уже сделали. Журналы диалогов Joule фиксируют пользователя, время, диалог, запросы и ответы. Они существуют только если хранение было включено при подключении Joule. По документации SAP срок хранения этих журналов по умолчанию составляет 365 дней, и можно запросить другой срок. Проверьте настройку и то, покрывает ли срок хранения ваш аудиторский цикл.

SAP ограничила ИИ-агентов в своих API. Политика API SAP (версия 4.2026a) ограничивает использование API SAP с полуавтономными или генеративными системами ИИ, которые планируют, выбирают или выполняют последовательности вызовов API. Такое использование разрешено только через одобренные SAP архитектуры и пути. Если сторонний агент или копилот вызывает S/4HANA напрямую, это теперь не только вопрос безопасности, но и договорный вопрос. Проведите инвентаризацию таких интеграций.

Средства контроля BTP существуют, но их нужно настроить. Generative AI hub от SAP предлагает маскирование данных, фильтрацию входящего и исходящего контента, grounding, реестр промптов и журналирование аудита. Это средства контроля, а не программа управления. Журналирование, включённое без политики хранения, стирается раньше, чем его сможет прочитать квартальная проверка.

Если вендор не может предоставить техническую документацию для высокорисковой функции ИИ, эта функция не может оставаться в высокорисковом применении. Срок сдвинулся. Требование к документации нет.

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

Регулирование	Что оно требует на практике
EU AI Act	Обязанности, зависящие от уровня риска. Применения высокого риска (подбор и управление работниками, кредитоспособность физических лиц и другие в Приложении III) требуют управления рисками, документации, журналирования, надзора человека и оценки соответствия с 2 декабря 2027 года. Требования прозрачности уже действуют
GDPR	Законное основание и минимизация данных. Для решений, основанных исключительно на автоматизированной обработке и имеющих юридические или схожие последствия, гарантии статьи 22, включая вмешательство человека и содержательную информацию о логике
ISO/IEC 42001:2023	Аудируемая система управления ИИ: роли, процесс управления рисками, средства контроля и постоянное улучшение
Национальные рамки	Страны Персидского залива, Сингапур и другие публикуют принципы этики ИИ и рамки управления. Пересматривайте те, что действуют там, где вы работаете, каждый год

Классификация по высокому риску для SAP имеет особое значение. ИИ в SuccessFactors, влияющий на найм, повышение или увольнение, подпадает под регулирование. Проверки кредитоспособности корпоративных клиентов в S/4HANA, как правило, не подпадают, потому что категория Приложения III охватывает кредитоспособность физических лиц. Классифицируйте каждую функцию, а не делайте допущений.

Практическая отправная точка: реестр. Одна строка на каждую функцию ИИ, заполненная до конца.

Столбец	Что записывать
Функция ИИ	Например, подбор кандидатов в SuccessFactors или поиск дублей поставщиков в Ariba
Система и владелец	Приложение и один назначенный ответственный человек
Категория по Закону об ИИ	Запрещённая, высокого риска (Приложение III), только прозрачность или минимальная
Используемые данные	Источники, персональные данные, применяемое маскирование
Проверка человеком	Кто проверяет какие результаты и когда может их отменить
Журналирование и хранение	Где журналируются решения и как долго
Периодичность пересмотра	Ежеквартально для функций с высоким влиянием, раз в полгода для остальных
Последний пересмотр	Дата и результат

1. Назначьте одного владельца на каждую систему ИИ до go-live. Человека, а не комитет. Все остальные играют вспомогательную роль.
2. Ведите журнал аудита по решениям, на которые повлиял ИИ. Для согласования счетов, выбора поставщика или ранжирования кандидатов фиксируйте использованные данные, результат и момент, когда человек его проверил.
3. Назначайте пересмотры моделей. Модели деградируют по мере изменения данных. Для критичных систем разумное начало: раз в квартал. Не ждите жалобы пользователя, чтобы обнаружить три месяца неверных ответов.
4. Сначала внедрите управление данными, затем подключите к нему управление ИИ. Правила доступа, стандарты качества и маскирование должны существовать до того, как управление ИИ сможет работать. Команды, которые строят то и другое одновременно, часто в итоге не получают ни того, ни другого.
5. Не путайте управление с документацией. Политики в SharePoint не являются управлением. Управление меняет то, как принимаются решения: кто проверяет, кто эскалирует и кто может приостановить модель.

Регулирование постоянно меняется. Изменения Закона об ИИ в 2026 году показывают, как быстро сдвигаются сроки. Назначьте одного человека, который будет отслеживать правовые изменения и каждый год переводить их в требования, специфичные для SAP.

Конфиденциальность между модулями. В SAP хранятся расчёт заработной платы, клиентские транзакции и кадровые записи. Ролевая модель безопасности SAP автоматически не распространяется на входные данные моделей ИИ. Проверяйте это явно.

Смещение в обучающих данных. Если модель SuccessFactors училась на пяти годах смещённых данных о найме, она повторит это смещение. Перед внедрением смотрите на результаты по группам, а не только на точность.

Унаследованные системы в конвейере. Когда ИИ на BTP берёт данные из унаследованной ERP или сторонней платформы, пределом для вас становится качество данных самой слабой системы. Опишите источники до запуска модели. Мой фреймворк управления рисками ИИ описывает шаги оценки, а мой гайд по фреймворку управления ИИ охватывает более широкую операционную модель.

Что такое управление ИИ при внедрении SAP?

Это набор владельцев, политик и средств контроля, благодаря которым функции ИИ в SAP работают ответственно, прозрачно и законно. Он охватывает то, какие данные могут использовать модели, как функции утверждаются и внедряются, как решения журналируются и пересматриваются и кто может приостановить модель. Он действует в S/4HANA, SuccessFactors, Ariba, Concur и во всём, что вы создаёте на SAP BTP.

Когда правила EU AI Act для высокого риска начинают применяться к системам SAP?

После Digital Omnibus (Регламент (ЕС) 2026/1744) обязанности для автономных систем высокого риска из Приложения III применяются с 2 декабря 2027 года. Высокорисковый ИИ, встроенный в регулируемые продукты, следует с 2 августа 2028 года. Запрещённые практики и ИИ-грамотность действуют с февраля 2025 года, а требования прозрачности для контента, созданного ИИ, с августа 2026 года. Для SAP самая частая область высокого риска: ИИ в подборе персонала и решениях по работникам.

Кто отвечает за управление ИИ в проектах SAP?

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

Ведёт ли Joule журнал аудита?

Журналы диалогов Joule могут фиксировать пользователя, время, диалог, а также запросы и ответы, но только если хранение журналов было включено при подключении. SAP документирует срок хранения по умолчанию 365 дней для клиентов, включивших эту опцию, а другой срок можно запросить. Изменения конфигурации в Joule Studio, существенные для безопасности, попадают в сервис SAP Audit Log на BTP. Проверьте настройку в вашем тенанте, а не полагайтесь на предположения.

Как работать со смещением в моделях ИИ в SAP SuccessFactors?

Проверьте, на чём модель обучалась. Если исторические данные о найме ставили в невыгодное положение определённые группы, то же сделает и модель. Проверьте результаты по группам до go-live, отслеживайте долю отобранных после него и переобучайте по графику по мере изменения данных о персонале. Если квалифицированных кандидатов из одной среды систематически отсеивают, считайте это сигналом, а не совпадением.

Как часто нужно пересматривать модели ИИ в SAP?

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