Governança de IA no SAP: conformidade, segurança, responsabilização

A governança de IA no SAP abrange todo recurso de IA que roda no S/4HANA, no SuccessFactors, no Ariba, no Concur ou no SAP BTP. Para cada um, você precisa saber quem é o dono das decisões dele, quais dados ele usa, como é registrado em log e quando é revisado. O relógio regulatório mudou em 2026: as obrigações do AI Act da UE para sistemas de alto risco independentes, como a IA usada em contratação, passam a valer em 2 de dezembro de 2027. Os deveres de transparência para conteúdo gerado por IA já valem. Este guia é para CIOs, líderes de conformidade e responsáveis por programas SAP. Ele cobre onde as lacunas de governança aparecem primeiro, o que mudou em 2026, as regras que se aplicam e um registro que você pode começar esta semana. Comece nomeando um dono por recurso de IA.

Comece com uma pergunta simples: quando um modelo entrega um resultado, quem responde por ele? Se a resposta não for clara, você tem uma lacuna de governança.

Os ambientes SAP são densos: S/4HANA no núcleo, CRM em nuvem, analytics complementar, sistemas legados em que ninguém quer mexer. Um engenheiro implanta um modelo em minutos. Rastrear o efeito dele na contratação, no crédito ou no planejamento de suprimentos pode levar semanas.

Os dados complicam ainda mais. Folha de pagamento, pedidos de compra, estoque e avaliações de fornecedores chegam em formatos diferentes, sob gestores diferentes. Uma equipe mascara os identificadores pessoais; outra os deixa expostos. Antes de qualquer modelo rodar, decida quais dados ele pode usar, quem aprova mudanças e por quanto tempo os registros são mantidos. Escreva, revise e faça valer.

Vi uma implantação em que a previsão de estoque funcionava quase bem demais. Os pedidos eram feitos antes da demanda, o que parecia eficiente no painel. Aí o financeiro ligou. O fluxo de caixa caiu, e ninguém sabia quem tinha a palavra final sobre o comportamento do modelo. A lógica estava enterrada. É nesse momento que a governança deixa de ser um slide de apresentação e vira coisa real.

Os padrões que continuo vendo:

Finanças. A IA no S/4HANA Finance ajuda no processamento de faturas, na previsão de caixa e na detecção de anomalias. É útil até deixar de ser: um pagamento legítimo bloqueado, um duvidoso aprovado, uma previsão construída sobre dados desatualizados. A solução é uma trilha de auditoria em cada decisão influenciada pela IA e uma pessoa nomeada que a confira.

Compras. A IA recomenda fornecedores, sinaliza riscos e revisa contratos. Se os dados históricos de compras carregam um viés, como fornecedores preferidos por motivos que ninguém enxerga, o modelo o repete. Alguém precisa revisar as pré-seleções em vez de aceitá-las.

RH. A IA no SuccessFactors pode ajudar a triar candidatos e analisar o engajamento. Treinada com dados de contratação que já tendiam a certos perfis, ela continua tendendo. Teste o viés antes da implantação e de novo após cada retreinamento.

Manufatura. Modelos de manutenção preditiva e de programação perdem qualidade quando uma planta é reconfigurada. Acompanhe a acurácia ao longo do tempo e agende o retreinamento. Não espere uma parada de linha para notar o desvio.

A IA nos aplicativos em nuvem da SAP costuma chegar sem alarde: conciliação de faturas no Ariba, aprovações no Concur, pontuação de leads no CRM. Ela trabalha em segundo plano, e esse é o atrativo. Também é o que dificulta a supervisão.

Lembro de um cliente que usava a inteligência embarcada no SAP Ariba. O sistema começou a sinalizar fornecedores duplicados automaticamente. Útil, mas ninguém percebeu que os alertas às vezes eram disparados por nomes inconsistentes nos dados mestre. Sem má-fé, apenas cadastros que não batiam. A área de compras não tinha um processo para validar os alertas, e isso causou atrasos e confusão. A solução é uma etapa de validação dos alertas e uma convenção de nomes consistente no cadastro mestre de fornecedores.

SAP BTP. O BTP permite que as equipes construam e implantem a sua própria IA em todo o ambiente SAP. Já vi um modelo aprovar fornecedores ruins porque foi treinado com dados de compras incompletos. O problema de dados veio antes do problema de IA, e limpar a entrada resolveu mais rápido do que ajustar o modelo.

SAP Concur. A IA de despesas detecta duplicidades e violações de política. Ela também gera falsos alertas de fraude em despesas legítimas, e quando os funcionários gastam tempo contestando rejeições o ganho de produtividade desaparece. Mantenha a revisão humana para casos limítrofes e atualize as regras sempre que a política de despesas mudar.

As datas de alto risco do AI Act da UE mudaram. O Digital Omnibus sobre IA, o Regulamento (UE) 2026/1744, entrou em vigor em 27 de julho de 2026. As obrigações para sistemas de alto risco independentes do Anexo III, que incluem a IA usada em recrutamento e gestão de trabalhadores e em avaliações de solvência de pessoas físicas, passam a valer em 2 de dezembro de 2027. A IA de alto risco embarcada em produtos regulados vem depois, em 2 de agosto de 2028. As práticas proibidas e a alfabetização em IA valem desde fevereiro de 2025, e os deveres de transparência do Artigo 50 para conteúdo gerado por IA, desde 2 de agosto de 2026. O adiamento é tempo de preparação, não alívio. A avaliação de conformidade e a documentação técnica são um trabalho lento.

1. 2025Práticas proibidas e alfabetização em IADesde fevereiro de 2025
2. 2026Digital Omnibus em vigor27 de julho, Regulamento (UE) 2026/1744
3. 2026Deveres de transparência para conteúdo gerado por IA2 de agosto, Artigo 50
4. 2027Sistemas de alto risco independentes (Anexo III)2 de dezembro. Contratação, gestão de trabalhadores, avaliação de solvência de pessoas físicas
5. 2028IA de alto risco embarcada em produtos regulados2 de agosto

Fonte: Regulamento (UE) 2026/1744, Digital Omnibus sobre IA

O registro em log do Joule depende de uma escolha que você talvez já tenha feito. Os logs de conversa do Joule registram o usuário, a data e hora, a conversa, os prompts e as respostas. Eles só existem se o armazenamento foi ativado no onboarding do Joule. A retenção padrão documentada pela SAP para esses logs é de 365 dias, e você pode solicitar outro período. Confira a configuração e se a retenção cobre o seu ciclo de auditoria.

A SAP restringiu agentes de IA em suas APIs. A política de API da SAP (versão 4.2026a) restringe o uso das APIs da SAP com sistemas de IA semiautônomos ou generativos que planejam, selecionam ou executam sequências de chamadas de API. Esse uso só é permitido por meio de arquiteturas e caminhos endossados pela SAP. Se um agente ou copiloto de terceiros chama o S/4HANA diretamente, isso agora é uma questão contratual além de uma questão de segurança. Faça o inventário dessas integrações.

Os controles do BTP existem, mas você precisa configurá-los. O generative AI hub da SAP oferece mascaramento de dados, filtragem de conteúdo de entrada e de saída, grounding, um registro de prompts e log de auditoria. São controles, não um programa de governança. Um log ativado sem política de retenção se apaga antes que uma revisão trimestral consiga lê-lo.

Se um fornecedor não consegue apresentar a documentação técnica de alto risco para um recurso de IA, esse recurso não pode permanecer em um uso de alto risco. O prazo mudou. A exigência de documentação, não.

Elas se aplicam às organizações que executam IA no SAP, onde quer que a SAP hospede o software.

Regulamentação	O que ela exige na prática
AI Act da UE	Deveres baseados em risco. Os usos de alto risco (recrutamento e gestão de trabalhadores, solvência de pessoas físicas e outros do Anexo III) exigem gestão de risco, documentação, registro em log, supervisão humana e avaliação de conformidade a partir de 2 de dezembro de 2027. Os deveres de transparência já se aplicam
GDPR	Base legal e minimização de dados. Para decisões baseadas exclusivamente em tratamento automatizado com efeitos jurídicos ou semelhantes, as salvaguardas do Artigo 22, incluindo intervenção humana e informação significativa sobre a lógica
ISO/IEC 42001:2023	Um sistema de gestão de IA auditável: papéis, processo de risco, controles e melhoria contínua
Frameworks nacionais	Os países do Golfo, Singapura e outros publicam princípios éticos e frameworks de governança de IA. Reveja todo ano os dos locais em que você opera

A classificação de alto risco importa especificamente para o SAP. A IA no SuccessFactors que influencia contratação, promoção ou desligamento está no escopo. As análises de crédito de clientes empresariais no S/4HANA, em geral, não estão, porque a categoria do Anexo III abrange a solvência de pessoas físicas. Classifique cada recurso em vez de presumir.

O ponto de partida prático é um registro. Uma linha por recurso de IA, preenchida.

Coluna	O que registrar
Recurso de IA	Por exemplo, a correspondência de candidatos do SuccessFactors ou a detecção de fornecedores duplicados do Ariba
Sistema e dono	O aplicativo e uma pessoa responsável nomeada
Categoria no AI Act	Proibida, alto risco (Anexo III), apenas transparência ou mínima
Dados usados	Fontes, dados pessoais, mascaramento aplicado
Revisão humana	Quem revisa quais resultados e quando pode anular a decisão
Log e retenção	Onde as decisões são registradas e por quanto tempo
Cadência de revisão	Trimestral para recursos de alto impacto, semestral para os demais
Última revisão	Data e resultado

1. Nomeie um dono por sistema de IA antes do go-live. Uma pessoa, não um comitê. Todos os demais têm um papel de apoio.
2. Mantenha uma trilha de auditoria das decisões influenciadas pela IA. Na aprovação de faturas, na seleção de fornecedores ou no ranqueamento de candidatos, registre os dados usados, o resultado e quando uma pessoa o revisou.
3. Agende revisões dos modelos. Os modelos se degradam conforme os dados mudam. Trimestral é um começo sensato para sistemas críticos. Não espere uma reclamação de usuário para descobrir três meses de respostas erradas.
4. Estabeleça primeiro a governança de dados e depois conecte a governança de IA a ela. Regras de acesso, padrões de qualidade e mascaramento precisam existir antes que a governança de IA possa funcionar. As equipes que constroem as duas ao mesmo tempo costumam ficar sem nenhuma.
5. Não confunda governança com documentação. Políticas no SharePoint não são governança. Governança muda a forma como as decisões são tomadas: quem revisa, quem escalona e quem pode pausar um modelo.

A regulamentação não para de mudar. As mudanças de 2026 no AI Act mostram com que rapidez as datas se movem. Designe uma pessoa para acompanhar as mudanças legais e traduzi-las, a cada ano, em requisitos específicos do SAP.

Privacidade entre módulos. O SAP guarda folha de pagamento, transações de clientes e registros de funcionários. A segurança baseada em roles do SAP não se aplica automaticamente às entradas dos modelos de IA. Verifique isso de forma explícita.

Viés nos dados de treinamento. Se um modelo do SuccessFactors aprendeu com cinco anos de dados de contratação enviesados, ele vai repetir o viés. Olhe os resultados por grupo antes da implantação, não só a acurácia.

Sistemas legados no pipeline. Quando a IA no BTP busca dados de um ERP legado ou de uma plataforma de terceiros, a qualidade de dados do sistema mais fraco passa a ser o seu limite. Mapeie as fontes antes de o modelo entrar em produção. Meu framework de gestão de riscos de IA cobre as etapas de avaliação, e meu guia do framework de governança de IA cobre o modelo operacional mais amplo.

O que é governança de IA em implementações SAP?

É o conjunto de donos, políticas e controles que fazem os recursos de IA no SAP operarem de forma responsável, transparente e legal. Abrange quais dados os modelos podem usar, como os recursos são aprovados e implantados, como as decisões são registradas e revisadas e quem pode pausar um modelo. Aplica-se ao S/4HANA, ao SuccessFactors, ao Ariba, ao Concur e a tudo o que você construir no SAP BTP.

Quando as regras de alto risco do AI Act da UE passam a valer para sistemas SAP?

Depois do Digital Omnibus (Regulamento (UE) 2026/1744), as obrigações para sistemas de alto risco independentes do Anexo III passam a valer em 2 de dezembro de 2027. A IA de alto risco embarcada em produtos regulados vem a partir de 2 de agosto de 2028. As práticas proibidas e a alfabetização em IA valem desde fevereiro de 2025, e os deveres de transparência para conteúdo gerado por IA, desde agosto de 2026. No SAP, a área de alto risco mais comum é a IA usada em recrutamento e em decisões sobre a força de trabalho.

Quem é responsável pela governança de IA em projetos SAP?

Um grupo multifuncional: a conformidade acompanha a regulamentação, TI e segurança cuidam de acessos e logs, as equipes de dados respondem pela qualidade dos dados de treinamento, os responsáveis pelos processos de negócio aprovam os resultados e o jurídico analisa a responsabilidade civil. A decisão mais importante é nomear um dono responsável por sistema de IA. Quando algo dá errado às 2 da manhã, você precisa saber quem recebe a ligação.

O Joule mantém uma trilha de auditoria?

Os logs de conversa do Joule podem registrar o usuário, a data e hora, a conversa e os prompts e respostas, mas só se o armazenamento de logs foi ativado durante o onboarding. A SAP documenta uma retenção padrão de 365 dias para os clientes que ativaram, e é possível solicitar outro período. As mudanças de configuração relevantes para a segurança no Joule Studio vão para o serviço SAP Audit Log no BTP. Confira a configuração do seu tenant em vez de presumir.

Como lidar com o viés em modelos de IA no SAP SuccessFactors?

Revise com o que o modelo foi treinado. Se os dados históricos de contratação prejudicaram certos grupos, o modelo também vai prejudicar. Teste os resultados entre grupos antes do go-live, monitore as taxas de seleção depois dele e retreine em um calendário conforme os dados da sua força de trabalho mudam. Se candidatos qualificados de um mesmo perfil de origem são filtrados de forma consistente, trate isso como um sinal, não como coincidência.

Com que frequência os modelos de IA no SAP devem ser revisados?

Trimestralmente para sistemas de alto impacto, como aprovações financeiras, decisões de RH ou seleção de fornecedores, e semestralmente para ferramentas de menor risco. Dispare uma revisão extra sempre que uma fonte de dados, uma integração ou um processo de negócio mudar, porque qualquer um deles pode alterar o comportamento do modelo sem mudança de código.