IA em SAP TM: Automação de Processos e Mapeamento em 2026

A inteligência artificial deixou de ser experimento acadêmico e passou a operar dentro do stack SAP com consequências práticas para quem arquiteta e implementa processos. Em 2026, a pergunta não é mais se a IA vai entrar nos projetos SAP, mas onde ela já está rodando e como o consultor precisa posicionar suas entregas para extrair valor real — sem quebrar customizações existentes, sem perder rastreabilidade de GAPs e sem transformar o projeto num laboratório sem governança. Este guia cobre os pontos de integração concretos entre IA e os módulos SAP mais críticos.

O que mudou na arquitetura SAP com a chegada da IA

A SAP consolidou sua estratégia de IA em torno do SAP Business AI, que se manifesta tecnicamente em três camadas: modelos embarcados no standard (como o SAP Joule), extensões via BTP AI Core e pontos de extensão customizados por BAdI ou RAP Action. Para o arquiteto SAP, isso significa que o modelo de extensibilidade tradicional não foi descartado — ele foi reposicionado.

As principais mudanças arquiteturais em 2026 são:

• CDS Views com anotações de IA: tabelas analíticas passaram a suportar anotações @Analytics.dataExtract e @OData.publish orientadas a consumo por modelos ML embarcados no BTP
• RAP Actions com side effects: no ABAP RESTful Application Programming Model, Actions podem disparar chamadas assíncronas ao AI Core sem sair do framework transacional
• BAdI como ponto de injeção: BAdIs clássicos (ex: /SCMTMS/TOR_PROCESSING) e novos BAdIs RAP continuam sendo o mecanismo oficial para injetar lógica de IA sem modificar o standard
• Fiori Horizon com componentes ML: elementos visuais de predição (sugestões inline, classificação automática) já constam nas SAP Fiori Design Guidelines como padrão de UX para aplicações com IA

Quem projeta processos precisa mapear esses pontos antes de propor qualquer solução de automação inteligente.

IA no SAP TM: do VSR ao Freight Order

No SAP Transportation Management, os ganhos mais imediatos de IA estão na otimização de transporte. O VSR Optimizer (Vehicle Scheduling and Routing) já usa algoritmos heurísticos há anos, mas a integração com modelos de ML permite que padrões históricos de execução alimentem as restrições de roteamento em tempo quase real.

O fluxo típico numa implementação madura tem esta sequência:

1. Coleta de dados históricos: Freight Orders finalizadas são exportadas via CDS View I_FreightOrder para o BTP Data Intelligence
2. Treinamento do modelo: variáveis como lead time real, janela de entrega cumprida, custo por km e tipo de veículo alimentam um modelo de regressão ou classificação no AI Core
3. Scoring em tempo real: no momento da criação do Freight Order, um BAdI no enhancement spot /SCMTMS/TOR_PROCESSING chama o modelo e retorna uma pontuação de risco de atraso
4. Ação automática via Condition-Based Message Control: ordens com risco alto disparam alerta no Fiori Launchpad do planejador, que decide aprovar ou reroterizar

Este fluxo respeita o princípio de human-in-the-loop, que ainda é a abordagem recomendada pela SAP Community para processos logísticos com impacto fiscal (NF-e/CT-e).

IA no SAP SD/MM: proposta automática de condições e pedidos

Nos módulos SD e MM, a IA atua principalmente em dois pontos de alto volume: determinação automática de condições de preço e criação assistida de pedidos de compra.

SD — Determinação de condições: o standard usa tabelas de acesso (Zugriffsfolge) para varrer condições. Um modelo de ML pode pré-classificar o cliente + material + canal e sugerir a condição mais provável antes mesmo de a sequência de acesso ser executada, reduzindo o tempo de processamento em cenários de alto volume no VBAK/VBAP.

MM — Pedidos de compra inteligentes: o SAP Ariba e o S/4HANA Procurement já embarcam sugestões de fornecedor baseadas em histórico de EKKO/EKPO. Para quem está no ECC estendido ou S/4HANA sem Ariba, é possível replicar parte dessa inteligência via BAdI ME_PROCESS_PO_CUST chamando um endpoint REST do BTP AI Core.

| Cenário | Módulo | Ponto de Extensão | Modelo de IA || |---|---|---|---| | Classificação de risco de atraso | TM | BAdI /SCMTMS/TOR_PROCESSING | Regressão logística | | Sugestão de condição de preço | SD | BAdI PRICING_USEREXITS | Classificação multiclasse | | Recomendação de fornecedor | MM | BAdI ME_PROCESS_PO_CUST | Filtro colaborativo | | Detecção de duplicidade de NF | FI | BAdI BADI_ACC_DOCUMENT | Similaridade de embeddings | | Alocação de funcionário a tarefa | HCM | BAdI HRPAD00INFTY | Otimização por restrições |

Como documentar GAPs de IA no catálogo RICEFW

Um dos maiores problemas práticos em projetos que introduzem IA é a rastreabilidade. O catálogo RICEFW tradicional não tem campo nativo para referenciar modelos ML, versões de dataset ou SLAs de inferência. Isso cria débito técnico enorme no pós-go-live.

A abordagem recomendada é estender o template de Especificação Funcional com três blocos adicionais:

1. Bloco AI Model Card: nome do modelo, versão, plataforma (BTP AI Core, Vertex AI, Azure ML), data de treinamento e métricas de avaliação (F1, RMSE, etc.)
2. Bloco de Dependências de Dados: CDS Views ou tabelas SAP usadas como fonte, periodicidade de atualização, política de retenção
3. Bloco de Fallback: comportamento do processo quando o modelo estiver indisponível (timeout, circuit breaker, valor default)

Esses blocos precisam estar na Especificação Funcional para que o time de QA consiga criar casos de teste que cubram tanto o caminho feliz (modelo respondendo) quanto o caminho degradado (modelo fora do ar).

O post Automação de Processos com IA SAP: Guia Técnico 2026 aprofunda a estrutura de documentação para cenários de automação com IA.

Erros comuns de arquitetos SAP ao introduzir IA em projetos

Depois de acompanhar implementações em diferentes verticais, os erros recorrentes se agrupam em três categorias:

Erro 1 — Ignorar o modelo de extensibilidade SAP Desenvolver a lógica de IA fora dos pontos de extensão oficiais (BAdI, RAP Action, Enhancement Spot) cria modificações de objeto SAP que quebram em atualizações de Support Package. Toda lógica de IA deve ser isolada em objetos Z ou em implementações de BAdI registradas no Enhancement Framework.

Erro 2 — Não versionar o modelo junto ao transporte O modelo ML e o código ABAP que o chama evoluem juntos. Se o código ABAP que chama o endpoint do AI Core for transportado sem que o modelo correspondente esteja publicado no ambiente alvo, o processo quebra silenciosamente — pior do que um dump com ST22.

Erro 3 — Tratar a IA como substituta de regra de negócio documentada Sistemas de auditoria fiscal (SEFAZ, auditoria interna) exigem rastreabilidade de decisão. Um modelo que decide autonomamente sobre valores de CT-e sem log de decisão auditável é um passivo jurídico. Use sempre o padrão de explainability: registre o score, os atributos de entrada e a decisão tomada numa tabela Z com retenção definida.

Ferramentas SAP nativas vs extensões customizadas: quando usar cada uma

A SAP tem expandido o portfólio de IA embarcada no standard, especialmente no S/4HANA Cloud. Antes de desenvolver qualquer extensão customizada, o arquiteto deve verificar se a funcionalidade já existe no standard — isso poupa esforço de desenvolvimento e reduz o TCO.

Use o standard quando:

• O caso de uso é coberto pelo SAP Joule (geração de texto, sumarização, pesquisa semântica em documentos SAP)
• O módulo já tem BAdI publicado com documentação no SAP Help Portal para injeção de lógica de scoring
• A funcionalidade está no roadmap de entrega prevista para o próximo Support Package

Desenvolva extensão customizada quando:

• O modelo precisa ser treinado com dados proprietários da empresa (histórico de fornecedores, padrões de fraude internos)
• O tempo de resposta exigido é inferior ao SLA do AI Core padrão (< 200ms para processos online)
• O processo envolve dados sujeitos à LGPD que não podem sair do ambiente on-premise

Para apoiar esse processo de decisão, o Orquestração de Processos SAP: Guia Técnico 2026 traz um framework de avaliação make-or-buy aplicado a extensões de processo.

Como a documentação automatizada acelera projetos de IA SAP

Introduzir IA num projeto SAP aumenta a complexidade documental: além dos BPDs tradicionais, são necessários AI Model Cards, especificações de integração com BTP AI Core, scripts de teste para cenários com e sem resposta do modelo, e planos de rollback. Esse volume documental é tipicamente subestimado no planejamento de projetos.

Plataformas como o OrkestraFlow resolvem esse gargalo ao gerar automaticamente Especificações Funcionais estruturadas, catálogos RICEFW com campos estendidos para IA e fluxos de processo visuais que já contemplam os pontos de extensão SAP corretos. A IA da plataforma entende terminologia SAP real — tabelas como VBAK, /SCMTMS/D_TOR, EKKO — e não produz documentação genérica que precisa ser reescrita pelo consultor.

O ganho prático é que o arquiteto foca na decisão técnica (qual BAdI usar, qual modelo de IA é adequado, qual o SLA aceitável) e delega a geração do artefato documental para a ferramenta. Isso é especialmente relevante em projetos com múltiplos GAPs de IA, onde a consistência entre especificações é crítica para o time de QA.

Conclusão

A IA em processos empresariais SAP em 2026 não é uma camada separada — ela está embutida nos mesmos pontos de extensão que consultores SAP já conhecem: BAdIs, RAP Actions, CDS Views e Enhancement Spots. O diferencial do arquiteto que entrega bem nesse cenário é saber onde injetar inteligência sem violar o modelo de extensibilidade SAP, como documentar GAPs de IA no catálogo RICEFW de forma auditável e como criar casos de teste que cobrem os cenários de degradação graceful. Dominar esses três pontos é o que separa um projeto de IA SAP bem-executado de um piloto que nunca vai a produção.

---

Começar 5 dias grátis e gere suas especificações funcionais de IA, catálogos RICEFW e fluxos de processo SAP com uma plataforma que entende o stack técnico de verdade.