O arquiteto Microsoft Dynamics 365 Finance & Operations (D365 F&O) não vai ser substituído por IA.

Mas o arquiteto que não entende IA pode ser substituído por outro que entende.

Essa frase parece dura, mas descreve bem o momento atual do mercado. Durante muitos anos, o papel do arquiteto ERP foi associado principalmente a desenho de solução, integrações, extensibilidade, performance, segurança, modelos de dados, localização fiscal e governança técnica. Tudo isso continua importante. Na verdade, ficou ainda mais importante.

O que mudou foi o centro de gravidade. Com Copilot, agentes, Microsoft Copilot Studio, Microsoft Foundry, Model Context Protocol (MCP), automações inteligentes e modelos de linguagem conectados ao ERP, o arquiteto deixa de desenhar apenas sistemas transacionais. Ele passa a desenhar sistemas de decisão, execução e supervisão assistidos por IA.

O futuro do arquiteto ERP será menos sobre customizar telas e mais sobre orquestrar processos inteligentes.

De arquiteto de sistema para arquiteto de operação inteligente

O D365 F&O sempre foi um ERP complexo. Ele concentra processos críticos: financeiro, fiscal, compras, estoque, manufatura, projetos, ativos, cadeia de suprimentos, faturamento e integrações com bancos, governos, clientes e fornecedores.

Antes da IA, a pergunta central do arquiteto era: como desenho uma solução robusta, escalável, segura e aderente ao processo de negócio?

Essa pergunta continua viva. Mas agora ela ganhou uma segunda camada: como desenho uma operação em que humanos, agentes de IA, regras de negócio e sistemas externos trabalhem juntos sem perder controle, rastreabilidade e confiança?

Não se trata apenas de colocar um chatbot ao lado do ERP. A própria Microsoft descreve o Copilot em finance and operations apps como uma arquitetura em que o Copilot Studio faz a orquestração central das capacidades, invocando ferramentas, dados, fluxos e plugins de acordo com a intenção do usuário. Em outras palavras, a IA passa a conversar com a camada operacional do ERP.

Para o arquiteto, isso muda o tipo de decisão que precisa ser tomada. Agora ele precisa definir quais processos podem ser assistidos por IA, quais podem ser parcialmente automatizados, quais nunca devem ser executados sem aprovação humana, quais dados podem ser expostos e quais ações um agente pode executar.

1. Arquitetura de agentes

A primeira competência nova do arquiteto D365 F&O é entender arquitetura de agentes.

Um agente não é apenas um prompt bonito. Um agente empresarial precisa ter objetivo, contexto, ferramentas, permissões, limites, memória operacional, mecanismo de fallback, supervisão e rastreabilidade.

No contexto do D365 F&O, um agente pode assumir várias formas: um Copilot lateral que responde perguntas sobre dados do ERP, uma experiência embutida em um workspace, um agente externo que consulta dados financeiros, um agente que executa ações via ferramentas, ou um fluxo orquestrado em Copilot Studio.

O erro comum é imaginar que todo agente deve resolver um processo inteiro de ponta a ponta. Na prática, o melhor desenho costuma ser modular. Um agente bom deve ser composto por capacidades pequenas, testáveis e governáveis: consultar saldo de cliente, resumir histórico de workflow, sugerir uma ação de cobrança, buscar divergências de pedido, classificar exceções de conciliação ou abrir uma tarefa para aprovação.

O papel do arquiteto é decompor o processo em capacidades seguras. Ele precisa responder perguntas como: o agente apenas informa ou também executa? A ação é reversível? Existe impacto contábil, fiscal ou financeiro? Quem aprova? Onde fica o log? Qual é o plano B se o modelo falhar?

2. Segurança e governança

No ERP, IA sem governança não é inovação. É risco operacional com interface bonita.

Um arquiteto D365 F&O precisa dominar segurança antes de liberar qualquer agente. Isso inclui segurança técnica, segurança funcional e segurança de dados.

Na prática, significa pensar em papéis e permissões do D365, segregação de funções, acesso a dados sensíveis, minimização de dados, trilha de auditoria, logs de prompts e respostas, limites de execução, ambientes de teste, política de uso de IA generativa e controles de aprovação humana.

O ponto crítico é simples: um agente não deveria conseguir fazer mais do que o usuário ou processo que ele representa tem permissão para fazer. Se um usuário não pode aprovar um pagamento, um agente operando em nome dele também não deveria poder.

Se uma regra exige aprovação de compliance, a IA não deve contornar essa etapa em nome da eficiência. E se um agente gerar uma recomendação fiscal, a empresa precisa conseguir explicar de onde veio a informação, quais dados foram usados e quem tomou a decisão final.

3. Integração com MCP

O Model Context Protocol (MCP) é uma das mudanças mais importantes para quem trabalha com agentes empresariais.

No D365 F&O, a Microsoft já posiciona o Dynamics 365 ERP MCP server como uma forma de permitir que agentes acessem dados e lógica de negócio das finance and operations apps sem depender sempre de conectores customizados, APIs específicas ou código novo para cada caso.

Antes, a pergunta era: qual API devo expor para essa integração? Agora, em muitos cenários, a pergunta passa a ser: quais capacidades do ERP devem estar disponíveis para agentes, em qual contexto, com quais permissões e com quais limites?

MCP torna o ERP mais preparado para agentes. Ele cria uma camada em que agentes conseguem interagir com dados, ferramentas e operações de maneira mais padronizada. Mas também aumenta a responsabilidade do desenho. O arquiteto precisa definir quais operações podem ser expostas, quais devem permanecer bloqueadas, como tratar identidade, autorização, validação de entrada e saída, e como lidar com riscos como prompt injection.

4. Desenho de processos assistidos por IA

Um dos erros mais comuns em projetos de IA é tentar automatizar o processo ruim exatamente como ele existe hoje.

IA não deve ser usada apenas para acelerar retrabalho, aprovações mal desenhadas ou exceções que nasceram de uma parametrização fraca. O primeiro trabalho continua sendo entender o processo.

Em contas a pagar, a IA pode ajudar a classificar divergências, mas o processo de matching precisa estar bem modelado. Em cobrança, a IA pode sugerir comunicações, mas a política de crédito precisa estar clara. Em estoque, a IA pode apontar anomalias, mas as dimensões, políticas de cobertura e regras de planejamento precisam estar corretas. Em fiscal, a IA pode resumir impacto regulatório, mas a determinação de impostos precisa ser governada por configuração, legislação e validação especializada.

O bom arquiteto não pergunta “onde colocamos IA?”. Ele pergunta: qual decisão neste processo pode ser melhorada com IA sem comprometer controle?

5. Revisão de prompts

Prompt não é detalhe operacional. Em sistemas empresariais, prompt é parte da especificação funcional.

Um prompt mal escrito pode fazer um agente responder com excesso de confiança, ignorar uma exceção importante, usar uma fonte errada, recomendar uma ação fora da política da empresa, revelar informação sensível ou executar um fluxo fora do contexto correto.

Por isso, o arquiteto D365 F&O precisa desenvolver uma competência nova: revisão de prompts e instruções de agentes.

Não significa virar “prompt engineer” no sentido superficial da palavra. Significa saber avaliar se a instrução do agente está alinhada ao processo de negócio, às regras do ERP, às permissões do usuário e à política da empresa.

Uma boa revisão de prompt em contexto D365 deve verificar se o agente sabe qual é seu papel, sabe o que não pode fazer, cita incerteza quando faltam dados, diferencia recomendação de execução, exige confirmação humana quando necessário e tem critérios claros para escalar para um humano.

6. Observabilidade

Se um processo tradicional falha, normalmente conseguimos rastrear: log de batch, infolog, histórico de workflow, transação, auditoria de tabela, mensagem de integração ou evento no Azure.

Com agentes, a observabilidade precisa ir além. O arquiteto precisa desenhar como a empresa vai enxergar qual prompt foi recebido, qual intenção foi detectada, quais ferramentas foram chamadas, quais dados foram consultados, qual resposta foi gerada, qual ação foi executada, qual usuário estava no contexto, quanto custou a execução, qual foi a latência e qual foi o resultado de negócio.

Sem observabilidade, a empresa não sabe se a IA está ajudando ou apenas parecendo inteligente. Essa será uma das maiores diferenças entre projetos maduros e demonstrações bonitas sem confiança operacional.

7. Ética e compliance

ERP não é laboratório isolado. ERP mexe com dinheiro, estoque, pessoas, impostos, contratos, clientes, fornecedores e obrigações legais.

Por isso, o arquiteto D365 F&O na era da IA precisa trazer ética e compliance para dentro do desenho técnico.

Algumas perguntas devem virar padrão: o usuário sabe quando está interagindo com IA? A resposta pode influenciar uma decisão financeira relevante? O agente pode tratar dados pessoais? Existe risco de viés na recomendação? Existe risco de exposição de informação confidencial? Existe política para revisão humana? A empresa consegue explicar a decisão depois?

No Brasil, isso se conecta diretamente com LGPD, governança corporativa, auditoria, compliance fiscal e responsabilidade sobre decisões automatizadas. O arquiteto não precisa ser advogado. Mas precisa saber quando chamar jurídico, segurança, compliance, fiscal e auditoria para a mesa.

8. Conhecimento profundo de dados e regras do ERP

A ironia da era da IA é que ela torna o conhecimento profundo do ERP ainda mais valioso.

Muita gente imagina que, se a IA consegue responder perguntas, o conhecimento funcional perde valor. O contrário é mais verdadeiro: quanto mais IA entra no processo, mais importante é saber se a resposta faz sentido.

Um agente pode resumir uma divergência, mas alguém precisa saber se ela é contabilmente relevante. Um agente pode sugerir um plano de suprimentos, mas alguém precisa entender cobertura, lead time, estoque de segurança, política de compra e capacidade produtiva. Um agente pode consultar dados fiscais, mas alguém precisa entender CFOP, CST, CBS, IBS, NF-e, NFS-e, SPED, retenções e particularidades brasileiras.

O novo arquiteto D365 F&O precisa combinar três camadas de conhecimento: técnico, funcional e IA. Quem domina apenas uma dessas camadas vira especialista pontual. Quem consegue conectar as três vira arquiteto de verdade para a nova fase do ERP.

O que muda na prática

No discovery, o arquiteto passa a identificar pontos de decisão repetitivos, processos com alto volume de exceções, atividades que consomem análise manual, áreas onde a IA pode resumir ou recomendar, riscos de automação indevida e dados sensíveis que não devem ser expostos.

No desenho da solução, entram novos artefatos: mapa de agentes, mapa de ferramentas, fronteiras entre recomendação e execução, níveis de autonomia, critérios de aprovação humana, logs, telemetria, estratégia de avaliação de respostas e plano de rollback.

Na implementação, surgem testes de prompts, cenários adversos, validação de permissões, avaliação de alucinação, testes de prompt injection, testes com dados anonimizados e medição de qualidade. No go-live, a pergunta deixa de ser apenas “o ERP está funcionando?” e passa a ser também “quem monitora os agentes e como medimos impacto real?”.

Conclusão

A IA não diminui o papel do arquiteto D365 F&O. Ela aumenta. Mas aumenta para quem aceita evoluir.

O arquiteto do passado era responsável por garantir que o ERP suportasse o processo. O arquiteto da nova fase será responsável por garantir que humanos, ERP, agentes, dados e automações trabalhem juntos com segurança, controle e valor real.

Menos tela. Mais fluxo. Menos customização por impulso. Mais orquestração. Menos automação cega. Mais inteligência governada.

O arquiteto D365 F&O não vai ser substituído por IA. Mas o arquiteto que entende IA vai redesenhar o mercado antes que os outros percebam.

O futuro do arquiteto ERP será menos sobre customizar telas e mais sobre orquestrar processos inteligentes.