No diagrama do Gartner sobre o IT de 2030, cada camada do stack ganha uma versão pronta para IA. Mas tem uma camada tratada como implícita, e ela é a que separa um stack que pensa bem de um stack que consegue prestar contas: onde a decisão de negócio é executada. Um guia técnico sobre por que a camada de decisão precisa estar no diagrama antes de virar incidente em produção.
Tecnologia
No diagrama do Gartner sobre o IT de 2030, a coluna "AI-first IT" reorganiza o stack inteiro. "AI-ready data and BI" substitui o velho "Data and BI". "AI-enabled software and platforms" substitui o "Enterprise software". "Agent-ready software" aparece no topo. A mensagem é clara: cada camada do stack tradicional ganha uma versão preparada para a IA.
Tem uma camada que o diagrama trata como implícita, e que merece ser explícita: a camada onde as decisões de negócio são executadas.
Porque "AI-ready" não significa só dado limpo e modelo treinado. Significa que, quando o modelo termina seu trabalho probabilístico, existe um lugar determinístico, governável e auditável para a decisão final acontecer. Sem isso, você tem um stack que pensa muito bem e não consegue prestar contas de nada.
Todo arquiteto que já fez manutenção em sistema legado conhece o sintoma: a regra de negócio espalhada.
Um if no controller. Uma constante no serviço. Uma validação no front. Uma stored procedure que ninguém quer tocar. A política de negócio existe, mas não mora em lugar nenhum específico. Ela é a soma de pedaços espalhados que, juntos, ninguém consegue ler de uma vez.
Isso sempre foi um problema de manutenção. O que o estudo do Gartner deixa evidente é que, na arquitetura AI-first, isso vira um problema estrutural.
Quando você adiciona modelos e agentes a um sistema com a lógica de decisão espalhada, você não está organizando a casa. Está adicionando inquilinos novos numa casa sem planta. O agente vai chamar o serviço que tem o if. O modelo vai pontuar e passar o resultado para uma função que tem outra regra embutida. E a decisão final emerge de uma cadeia que nenhum diagrama de arquitetura representa fielmente, porque a lógica está implícita no código.
O Gartner aponta que organizações de sucesso investem até quatro vezes mais em fundação. Em termos de arquitetura, a camada de decisão explícita é fundação. Não é feature.
Há uma distinção que todo arquiteto precisa internalizar para a era da IA, e que o BRMS materializa na prática.
Sistemas de IA são, por natureza, probabilísticos. Eles estimam, classificam, pontuam, geram. São excelentes em capturar padrões que um humano não conseguiria codificar em regras. Mas seu output é uma probabilidade, não uma certeza, e não vem com uma explicação auditável de "por quê" no formato que um regulador aceita.
A camada de decisão é determinística por construção. Dada uma entrada, sempre produz a mesma saída, segundo regras explícitas, versionadas, testáveis. E registra cada execução.
A arquitetura robusta para a era da IA combina as duas naturezas em vez de confundi-las. O modelo processa o que é difícil de regrar (analisa um documento, estima um risco, detecta um padrão de fraude, lê linguagem natural). A camada de decisão pega o output do modelo, combina com as regras de negócio explícitas, e produz a decisão final, determinística e auditável.
Em pseudo-arquitetura, em vez de "requisição, modelo de IA, decisão (opaca, não auditável)", você desenha "requisição, modelo de IA (score, classificação, extração), camada de decisão / BRMS (regras explícitas + output do modelo), decisão final (determinística, versionada, com log)".
O segundo desenho é o que o Gartner chama de "embed controls directly into workflows". O controle não é uma política num documento que ninguém lê. É uma camada arquitetural que executa.
A objeção honesta de muitos times é: "a gente já tem isso, são nossas regras no código, com testes". Três razões pelas quais o código da aplicação é o lugar errado para a camada de decisão na era da IA.
Cadência de mudança diferente. Regras de negócio mudam por motivos de negócio (uma nova política, uma mudança regulatória, um ajuste de pricing). Código de aplicação muda por motivos de engenharia. Acoplar os dois significa que toda mudança de política vira um ciclo de desenvolvimento, deploy e risco de regressão. Na velocidade que a IA impõe ao negócio, isso é gargalo garantido.
Auditabilidade. Uma regra no código tem o histórico que o Git oferece, que é histórico de quem mudou o arquivo, não histórico de qual decisão foi tomada para qual caso, segundo qual versão da regra. Auditoria de decisão e versionamento de código são coisas diferentes. A camada de decisão registra a decisão, não só a alteração do arquivo.
Quem mantém. Regra no código só o desenvolvedor toca. Regra numa camada low-code dedicada pode ser lida, revisada e, em muitos casos, ajustada por quem entende o negócio, com o desenvolvedor saindo do caminho crítico de cada mudança de política. O Gartner fala em "democratization-ready technology stack". A camada de decisão low-code é exatamente isso aplicado à lógica de negócio.
Se você é arquiteto e está recebendo a missão de "deixar o stack AI-ready", a recomendação concreta é: antes de escolher onde os modelos vão rodar, defina onde as decisões vão acontecer.
Mapeie as decisões de negócio críticas do seu domínio. Para cada uma, pergunte: essa decisão está explícita e versionada em algum lugar, ou está implícita na soma de pedaços de código? Se está implícita, ela é dívida técnica que a IA vai cobrar com juros.
A camada de decisão não é a parte glamourosa do diagrama. Não tem demo bonita. Mas é a diferença entre um stack que toma decisões defensáveis e um stack que toma decisões que ninguém consegue explicar depois.
A Abaccus é uma plataforma low-code de regras de negócio pensada para ser exatamente essa camada. Decisões explícitas, versionadas, testáveis e com log de execução, separadas do código da aplicação e prontas para receber o output dos modelos de IA. O modelo de cobrança é por motor de decisão, não por transação, o que importa de verdade quando o volume de decisões cresce na escala que a era da IA traz.
Se você está desenhando o AI-ready stack, vale colocar a camada de decisão no diagrama antes de ela aparecer como incidente em produção.
Para aprofundar na arquitetura, a Abaccus tem uma página sobre arquitetura de IA determinística (confira aqui): como a camada de decisão separa o que o modelo faz bem do que precisa ser determinístico e auditável. E para a base conceitual completa, o nosso e-book sobre regras de negócio vai do que é uma regra de negócio até como funcionam os fluxos determinísticos, exatamente a distinção entre probabilístico e determinístico que este artigo desenvolve.
