O chat virou peça intercambiável. A disputa real da IA enterprise é sobre quem autoriza a transação

Uma funcionária escreve no Microsoft Teams que precisa passar dois dias de férias para o mês que vem. Um modelo de um fornecedor entende o que isso significa. Um motor de orquestração de outro decide qual agente deve cuidar do pedido. Um terceiro sistema confere o saldo, a aprovação do gestor e as regras trabalhistas do país, e só então altera o registro.

Quatro fornecedores podem tocar nesse pedido. Só um deles pode dizer sim.

Os anúncios desta semana deixam essa divisão visível como poucas vezes, e, na nossa leitura, é aí que se decidem os próximos anos da arquitetura de IA enterprise. Não em qual assistente os funcionários preferem, nem em qual modelo lidera um benchmark, mas em qual camada tem a autoridade para efetivar uma transação de negócio.

A mesma linha, traçada três vezes

Primeiro, os fatos.

Em 13 de outubro, a Workday tornou sua plataforma de agentes headless: agentes externos podem chamar suas ferramentas MCP e consultar dados vivos, e a orquestração da Sana está indo para dentro do Claude, do Copilot, do Gemini Enterprise, do Teams e do Slack. A posição dela sobre a fronteira é explícita: “Ferramentas e plataformas de IA de terceiros nunca têm acesso bruto aos dados da Workday”, e “as verificações de política e as aprovações continuam ancoradas na Workday”. Analisamos o anúncio em a Workday virou headless para agentes de IA.

Em 12 de outubro, a Microsoft publicou uma arquitetura de referência em que um agente do Foundry faz a inferência com a própria identidade, mas busca documentos no SharePoint como o usuário logado, para que o SharePoint, e não o agente, decida o que cada pessoa pode ver. Tratamos disso em a busca como o usuário.

Em 13 de outubro, um engenheiro do Azure Networking descreveu um agente de plantão em que “o modelo nunca toma a decisão e nunca segura a credencial de execução”. Escritas em produção param para aprovação humana, aplicada no motor de execução. Veja como esse agente transforma raciocínio em playbooks.

E, no começo do mês, a SAP fez a mesma aposta pelo lado oposto ao manter os agentes do Joule dentro do sistema de transação, onde limites de aprovação e segregação de funções já funcionam.

Empresas diferentes, produtos diferentes, uma só arquitetura: o raciocínio é portátil, a autoridade não.

Quatro camadas, duas móveis

Todo pedido de IA enterprise hoje atravessa quatro camadas: a interface onde começa, o raciocínio que interpreta e planeja, a autorização que decide se esta pessoa pode fazer isto agora e a execução com registro que efetiva a operação. As duas primeiras estão virando peças intercambiáveis. A Workday suporta meia dúzia de famílias de modelos e cinco assistentes; os agentes da Microsoft trocam de modelo por configuração; os funcionários vão usar a janela de chat que a empresa licenciou neste ano.

As duas últimas não são intercambiáveis, e não deveriam ser. A autorização depende de fatos que só o sistema de registro tem: linhas de reporte, saldos, limites, aprovações pendentes, regras regulatórias de cada país. A execução precisa ser atômica, auditável e reversível nos termos do próprio sistema. Um assistente que tentasse cuidar disso teria de duplicar o registro, e aí haveria dois.

Aqui passamos do fato para a opinião. Nossa expectativa é que a disputa comercial siga essa divisão. Fornecedores de interface vão buscar orquestrar mais do trabalho e guardar mais do contexto. Sistemas de registro vão buscar ser donos da autorização de todo agente que toque seus dados, seja quem for que o construiu. Os fornecedores que vão ganhar a empresa serão os que tornarem a autorização fácil de chamar por terceiros, não os que deixarem sua janela de chat mais grudenta.

Em setores regulados, isso já está decidido

Bancos e ciências da vida não esperaram os agentes para decidir onde mora a autoridade. As regras de dupla checagem e de segregação de funções de um banco são aplicadas nos sistemas centrais e auditadas ali. Num ambiente GxP, o sistema validado é o registro, e um front-end não vira registro por ser conveniente. Para essas organizações, a arquitetura acima não é preferência de desenho. É a única versão que um supervisor ou um inspetor vai aceitar. A questão é se os programas de IA nascem desenhados assim ou são remendados depois do primeiro apontamento de auditoria.

O que fazer com essa visão

Se a camada de transação é a estratégica, seguem quatro consequências práticas:

• Decida onde cada classe de transação é autorizada, e use o sistema de registro como padrão. Uma lista de “quais assistentes podem iniciar quais transações, autorizadas onde” é um documento curto que evita discussões longas.
• Mantenha as credenciais de execução fora da camada de raciocínio. Nenhum modelo, e nenhum motor de orquestração que você não controla, deveria ter uma credencial capaz de efetivar uma transação sozinho. É a separação que descrevemos em seis autoridades independentes.
• Desenhe a ligação entre as trilhas de auditoria. O assistente registra a conversa; o sistema de registro registra a transação. Uma análise de incidente precisa das duas, ligadas por um identificador que os dois lados gravem. Peça isso no desenho da integração, não depois do incidente.
• Pergunte aos fornecedores qual camada eles reivindicam. Em compras, “o seu agente autoriza, ou pergunta ao sistema de registro?” é uma pergunta melhor do que “quais modelos vocês suportam?”.

O que provaria que estamos errados

Se os assistentes passarem a manter registros oficiais por conta própria, ou se auditores começarem a aceitar o log de conversa de um assistente como registro de uma decisão de negócio, a autoridade estaria subindo na pilha, e esta visão precisaria ser revista. Vamos acompanhar as duas coisas. Por ora, a evidência aponta para o outro lado: a janela de chat está virando uma porta de entrada, e o negócio continua decidindo quem passa por ela.