# Arquitetura de IA empresarial: a camada que falta na maioria das implementações em 2026

A maioria das implementações tem duas camadas. Faltam três.

A camada de linguagem está lá: o modelo grande que interpreta texto, voz, imagem, conversa. A camada de orquestração também: o framework que conecta ferramentas, gerencia memória de sessão, roteia intenção do usuário para a ação correta. O que falta, consistentemente, é a camada de decisão. A ausência dela passa despercebida no demo. Aparece seis meses depois, quando a auditoria bate ou quando o produto toma uma decisão que ninguém consegue explicar, muito menos reverter.

Este artigo é sobre essa lacuna. Por que ela existe, o que ela custa e como a arquitetura precisa mudar para que IA empresarial funcione de verdade em ambiente regulado.

Quando uma equipe implementa IA num processo de negócio, o caminho natural é: escolher o modelo, conectar ao sistema via API, instrumentar algum tipo de orquestração para gerenciar o fluxo. Isso resolve 80% do problema técnico de fazer a IA "funcionar". O modelo interpreta, a orquestração conecta, o sistema executa.

O que esse stack deixa sem resposta é: quem decide, com base em qual critério, e essa decisão pode ser auditada?

Modelos de linguagem aprendem padrões de dados históricos e produzem inferências. Essa é exatamente a capacidade que os torna úteis para interpretar um laudo de sinistro em texto livre, classificar uma reclamação de cliente, sumarizar um contrato de 40 páginas em 30 segundos. Inferência, por definição, é probabilística. O modelo que aprovou uma cobertura ontem pode recusar a mesma solicitação amanhã se o contexto de sessão for diferente. Isso é comportamento esperado de um sistema probabilístico, não um bug.

O problema aparece quando esse comportamento probabilístico é tratado como suficiente para decisões que precisam ser determinísticas: elegibilidade de cobertura, critérios de subscrição, regras de precificação, franquias aplicáveis por tipo de sinistro. Essas decisões têm que ser iguais para todos os casos com as mesmas variáveis, auditáveis com data e autor da versão da regra aplicada, e modificáveis pelo negócio sem re-deploy do modelo. A camada de decisão é o componente arquitetural que cumpre esses requisitos, e ela está ausente na maioria dos stacks implantados nos últimos 18 meses.

Vale ser preciso sobre o que cada camada faz, porque a confusão entre elas é a origem do problema arquitetural.

A camada de linguagem processa input não-estruturado e produz output interpretado. O modelo recebe texto, voz ou imagem e devolve classificação, extração, sumarização ou geração. É o ponto de entrada para tudo que vem de humanos ou de documentos sem estrutura rígida. Interpreta uma descrição de sinistro em linguagem natural, extrai campos relevantes de um contrato digitalizado, classifica intenção de um cliente em chat. Garantir que a mesma decisão seja tomada da mesma forma em toda instância, versionar critérios com data e autor, responder à SUSEP qual regra específica foi aplicada em qual caso: isso está fora do escopo dessa camada.

A camada de orquestração gerencia o fluxo entre ferramentas, sistemas e modelos. Decide quando chamar o modelo de linguagem, quando consultar uma base de dados, quando acionar um serviço externo. Responsável por memória de contexto, retry em falha, roteamento de intenção. É a cola que faz o stack funcionar como pipeline, mas seu papel é rotear chamadas, não tomar decisões de negócio. A distinção importa porque equipes frequentemente colocam lógica de elegibilidade dentro do orquestrador, na forma de condicionais hardcoded no prompt ou no código do agente, acreditando que isso resolve o problema de governança. O que acontece na prática é que o problema migra de lugar sem ser resolvido.

A camada de decisão executa regras determinísticas, auditáveis e versionadas. Recebe um conjunto de fatos estruturados, os dados extraídos pela camada de linguagem, e aplica as regras de negócio para produzir uma decisão. Cada regra tem versão, data de vigência, autor e histórico de alteração. A execução é idêntica para todo input com as mesmas variáveis. A decisão pode ser explicada linha a linha. Essa é a camada que o BRMS ocupa.

O padrão correto de integração é simples de descrever. A complexidade está em respeitar os limites de cada camada e não deixar lógica de decisão escapar para as outras.

``` [INPUT NÃO-ESTRUTURADO] ↓ [CAMADA DE LINGUAGEM] Modelo LLM / NLP → extrai, classifica, estrutura o input → output: fatos estruturados (JSON, campos normalizados) ↓ [CAMADA DE ORQUESTRAÇÃO] Framework de agente / workflow engine → roteia fatos estruturados para o serviço correto → chama o motor de decisão via API REST → gerencia contexto, retry, log de chamadas ↓ [CAMADA DE DECISÃO] Motor de regras (BRMS) → receb

e fatos estruturados como payload → aplica regra de negócio versionada → retorna decisão + justificativa + versão da regra aplicada ↓ [OUTPUT AUDITÁVEL] → ação no sistema → registro de decisão com rastreabilidade completa ```

A integração entre a camada de orquestração e a camada de decisão acontece via chamada REST padrão. O motor de regras expõe um endpoint que recebe o payload com os fatos estruturados e retorna a decisão com os metadados de auditoria: qual versão da regra foi aplicada, quais critérios foram avaliados, qual foi o resultado de cada condição.

Esse padrão tem uma propriedade crítica: o negócio pode alterar as regras na camada de decisão sem tocar na camada de linguagem ou de orquestração. O atuário que precisa ajustar um fator de risco regional abre o motor, faz a alteração, e ela entra em vigor na próxima chamada, com versão registrada, sem ticket para TI.

Uma variação comum é embutir as regras de negócio diretamente no prompt do modelo: "se o valor do bem for acima de R$ 500 mil, aplicar fator 1.3". Parece resolver o problema no curto prazo. O modelo, porém, não garante que vai executar a instrução da mesma forma em toda chamada. Temperatura, contexto de sessão, variações no input influenciam o output. A regra que está no prompt não tem versão formal, não tem data de vigência auditável, não tem registro de quem autorizou a alteração. Quando a fiscalização perguntar qual critério foi aplicado numa decisão específica de três meses atrás, o histórico de commits do repositório de prompts não serve como audit trail.

A Resolução CNSP 395/2020 e a Circular SUSEP 667 colocaram exigências claras sobre explicabilidade de decisões automatizadas. O que a maioria das seguradoras ainda não mapeou é que essas exigências se aplicam ao processo decisório completo, não apenas ao modelo de IA em si.

Quando um sinistro é negado por um sistema automatizado, a fiscalização pode perguntar: qual critério foi aplicado, qual era a versão vigente desse critério na data da decisão, quem autorizou a última alteração, e o critério foi aplicado de forma consistente em casos com perfil equivalente. Um stack sem camada de decisão explícita não tem resposta estruturada para nenhuma dessas perguntas.

O ponto que costuma pegar por surpresa: a exigência de explicabilidade recai sobre a decisão, não sobre o modelo. Uma seguradora pode usar um modelo de linguagem sofisticado para extrair dados de um laudo e ainda ter a decisão de cobertura completamente auditável, desde que essa decisão seja tomada por um motor de regras com versioning e rastreabilidade. O modelo de linguagem extrai os fatos; o motor de regras produz a decisão; a auditoria consegue ver os dois passos separadamente. Usar o modelo tanto para extração quanto para decisão, e depois tentar reconstruir o raciocínio post-hoc a partir dos logs de chamada, não produz o resultado que o regulador espera.

Além do risco regulatório, a ausência da camada de decisão tem custo operacional direto.

Quando as regras de negócio vivem no código do sistema ou embutidas nos prompts, qualquer alteração de critério passa pelo ciclo completo de engenharia: especificação, desenvolvimento, QA, aprovação, deploy. Em projetos que acompanhei em duas seguradoras brasileiras entre 2023 e 2024, esse ciclo consumiu entre quatro e quinze dias úteis para mudanças de regra que, numa arquitetura com motor externalizado, um analista de negócio qualificado resolveria em menos de uma hora, sem abrir ticket.

Uma parcela expressiva do backlog de engenharia em seguradoras com regras acopladas ao código é, na prática, mudanças de critério disfarçadas de desenvolvimento. O ticket chega para TI como "ajuste no cálculo de prêmio", mas o que o negócio quer é mudar o fator de severidade para um determinado ramo. Isso não deveria gerar um ticket de engenharia. Gera porque a arquitetura não tem a camada certa.

O custo de cada um desses tickets é concreto: dois engenheiros por dois dias são 48 horas de desenvolvimento, mais a interrupção do sprint, mais a feature que ficou para trás. Multiplique pelo volume mensal e o número é o argumento para a revisão arquitetural que o CTO já sabe que precisa fazer.

Para quem está revisando a arquitetura atual, o padrão de mudança tem três etapas práticas.

Primeiro, mapear as decisões de negócio no fluxo de IA: identificar onde, no pipeline atual, o sistema toma decisões que deveriam ser determinísticas e auditáveis, como elegibilidade, precificação, subscrição, critérios de sinistro. Essas decisões são os candidatos para migração para a camada de motor.

Segundo, externalizar as regras: extrair a lógica que está no código ou nos prompts e modelá-la como regras explícitas no motor. Cada regra recebe versão, data de vigência e responsável pelo cadastro. O motor expõe os endpoints que a camada de orquestração vai consumir.

Terceiro, validar o audit trail: antes de colocar em produção, confirmar que cada chamada ao motor retorna os metadados completos, ou seja, qual versão da regra foi executada, quais condições foram avaliadas, qual foi a decisão. Esses metadados precisam ser armazenados junto ao registro da transação, não apenas nos logs de sistema.

O ciclo de migração varia dependendo do volume de regras e da qualidade da documentação existente. O maior risco não é técnico, é de descoberta: boa parte das regras de negócio que estão no código ou nos prompts nunca foram documentadas de forma explícita em lugar nenhum. O processo de externalização frequentemente é o primeiro momento em que a organização vê todas as suas regras de decisão num único lugar. Nos projetos que acompanhei, isso foi ao mesmo tempo o momento mais trabalhoso e o mais revelador de todo o processo.

O movimento de adoção de IA em seguradoras e instituições financeiras acelerou nos últimos dois anos. A maioria dos projetos priorizou velocidade de implementação, o que é compreensível dado o contexto competitivo. O problema é que velocidade de implementação muitas vezes significou atalhar a camada de decisão.

Dois vetores vão pressionar essa escolha de forma simultânea. O regulatório: a SUSEP vai aprofundar as exigências de explicabilidade, e seguradoras sem audit trail estruturado vão precisar reconstruir isso sob pressão, que é o pior momento para fazer arquitetura. O operacional: à medida que os produtos de IA amadurecem, a frequência de ajustes de critério aumenta, e o custo de cada ajuste numa arquitetura sem camada de decisão externalizada vira um freio visível no time-to-market.

A arquitetura com as três camadas desacopladas resolve os dois problemas ao mesmo tempo. A camada de linguagem interpreta, extrai e classifica em escala. A camada de decisão produz determinismo, versiona com rastreabilidade e responde ao regulador com precisão.

Pegue os fluxos de decisão automatizada que estão em produção hoje. Para cada um, faça a pergunta: se a SUSEP pedir o audit trail desta decisão de 90 dias atrás, qual versão da regra estava vigente e quem autorizou a última alteração? Se a resposta for "preciso verificar no código", a terceira camada ainda está faltando.

O padrão de integração entre motor de regras e modelos de IA, incluindo estrutura de payload e metadados de auditoria, está detalhado no guia de arquitetura BRMS disponível nos comentários.