Suas automações low-code estão falhando porque tentam ser espertas demais. Lógica rígida de C, então, é uma sentença de morte ao lidar com dados reais e bagunçados que travam seus sistemas diariamente. Assumir que os dados são limpos é o pecado original do design low-code. Construímos nosso mundo no modelo C, então, mas ele exige certeza absoluta para funcionar. Dados do mundo real não são certos. Eles contêm erros de digitação. Eles contêm falta de contexto. São um fluxo caótico de erros humanos. Quando um sistema determinístico encontra 1% de variação, ele não cede e certamente não se adapta. Ele é em cima de quebra. Isso cria a armadilha da fragilidade, onde sua automação é tão forte quanto seu dado mais limpo. Nas empresas, é um nível muito baixo para definir sucesso. Mas o problema não são os dados, é o modelo que usamos para processá-lo. A morte do determinismo. Lógica determinística é uma relíquia da era dos dados estruturados.

Funcionava quando tudo vivia em tabelas SQL, quando forçávamos humanos a caberem caixas predefinidas. Mas esse mundo acabou. Hoje, 80% dos dados corporativos não são estruturados, ou seja, vivem em e-mails, chats e gravações de voz. De voz. Fluxos tradicionais do Power Automate tratam uma SANs e 4 PPL3 como dois universos diferentes. Para um sistema binário, são sequências de caracteres totalmente desconexas. Chegamos a um ponto crítico onde o custo da limpeza manual de dados supera o valor da automação em si. Se você gasta duas horas corrigindo um CSV para que um fluxo rode por 5 segundos, você não automatizou nada. É apenas transferir o trabalho humano. E A não é apenas um novo recurso brilhante que estamos adicionando à Power Platform. É uma mudança fundamental da correspondência exata para a similaridade. O modelo antigo pergunta. Isto é A? O novo modelo pergunta. O quanto isso se parece com A?

Pense em como você navega para a sua caixa de entrada. Eu não executo uma expressão regular na cabeça para achar uma nota fiscal. Você busca por padrão. Você busca por contexto. Você reconhece que NV202 e nota fiscal número 202 são a mesma coisa, mesmo que os caracteres não batam. Sistemas determinísticos não conseguem fazer isso. Eles são cegos em intenção. Eles só enxergam a sintaxe. E à medida que avançamos para 2026, a sintaxe se torna menos importante que a semântica. Estamos vendo uma explosão massiva no volume de dados de sensores IoT, fluxos em tempo real e resumos gerados por LLMs. Se tentar gerenciar esse volume com ramificações 100 tão rígidas, sua lógica virará um labirinto. Você terminará com um fluxo de 50 condições alinhadas, que ainda assim quebrarão no momento em que um fornecedor mudar sua assinatura de e-mail. O modelo 100 então assume um mundo perfeito, onde a entrada sempre corresponderá ao esquema.

Mas na realidade é o oposto. Os dados são a variável. A lógica deveria ser a constante, mas a nossa lógica tem sido rígida demais para sobreviver ao contato com a realidade. Temos construído casas de vidro em um mundo onde graniza constantemente, e depois nos perguntamos por que o chão está coberto de cacos. A mudança para o design probabilístico trata de construir com borracha em vez de vidro. Trata-se de criar sistemas que possam absorver o impacto de um erro de digitação sem se despedaçar. Estamos afastando da ideia de que um sistema deve estar 100% ou 100% errado, porque no mundo real, nada é 100%. Temos mentido para nós mesmos sobre a qualidade dos nossos dados adeptos. Construímos salas limpas para a nossa lógica, e depois agimos com surpresa quando os dados imprecisos da equipe de vendas causavam uma falha geral no sistema. A morte do determinismo é a morte dessa mentira. É a admissão de que não podemos controlar a entrada.

Então precisamos modernizar o processamento. Estamos entrando na era da empresa aproximativa, onde aceitamos que perto o suficiente é, na verdade, melhor do que exatamente errado. Porque um sistema que consegue processar uma correspondência de 90% é infinitamente mais valioso do que um sistema que rejeita tudo, exceto uma correspondência de 100%. Esta não é apenas uma mudança técnica, é uma mudança psicóloga. Você precisa se sentir confortável com a ideia de que seu sistema pode estar apenas bastante seguro sobre um dado. Você precisa aprender a projetar para dúvida, pois a dúvida é a única maneira honesta de lidar com informações não estruturadas. Essa mudança exige que passemos de gatilhos binários para algo muito mais sutil, a pontuação de confiança. A arquitetura vem certeza. Se aceitarmos que a era da lógica binária acabou, temos que substituí-la por uma nova estrutura. Eu chamo isso de modelo de orquestra sinfônica.

Em uma arquitetura de TI tradicional, todos são solistas tocando uma partitura rígida. E se alguém erra uma nota, a apresentação inteira para. Mas em uma arquitetura probabilística, temos maestros determinísticos gerenciando músicos probabilísticos, maestro ao seu fluxo no paro também. Ele fornece estrutura, define o ritmo e estabelece os limites. Os músicos são os modelos de A. Eles são talentosos, mas expressivos. E nem sempre atingem a mesma frequência exata todas as vezes que tocam. O trabalho do maestro não é forçar os músicos a serem robôs. É ouvi-los e decidir se o som que estão produzindo é bom o suficiente para continuar. Isso nos leva ao pilar central do design moderno, a pontuação de confiança. Uma pontuação de confiança é um valor de 0 a 1 que quantifica a dúvida. É a maneira do modelo dizer, eu acho que isso é uma correspondência. E aqui está o quanto estou disposto a apostar nisso.

No mundo antigo, tínhamos caminhos codificados. Se o assunto do e-mail, quando tiver fatura, salve o anexo. No novo mundo, usamos roteamento baseado em confiança. Estamos tornando a dúvida interna do modelo visível para o sistema. Não tratamos mais a IA como uma caixa preta, mas a tratamos como uma testemunha com nível específico de credibilidade. Veja como você realmente constrói isso na Power Platform. Ao usar o AI Builder ou o Azure AI, você não obtém apenas os dados extraídos. Você obtém uma camada de metadados que revela a probabilidade de cada campo. Se o modelo extrai um valor total de US$ 1.500, ele também informa que tem 95% de certeza sobre esse número. Como arquiteto, você agora tem três zonas distintas de ação. Primeiro, a zona verde. A confiança é 0,90 ou superior. O risco de erro é baixo, o custo de um erro é administrável, e o resultado é que você automatiza. O sistema prossegue sem intervenção humana.

Segundo, a zona amarela. A confiança está entre 0,60 e 0,89. O modelo está bem seguro, mas não tem certeza. Talvez o documento estivesse um pouco desfocado, talvez a caligrafia estivesse confusa. Nesta zona, você sinaliza. O sistema encaminha os dados para um revisor humano para uma verificação rápida. Terceira zona vermelha. A confiança está abaixo de 0,60. O modelo está tendo a adivinhar. Nesta zona, você rejeita ou escala. Você não deixa esses dados chegarem perto do seu banco de dados de produção. Esta é uma camada transparente de gerenciamento de risco. Ela permite que você dimensione sua automação enquanto mantém uma válvula de segurança. Pense nas implicações para governança. Em um sistema determinístico, os erros são silenciosos. Um fluxo é executado, escolhe o número errado por causa de um erro de digitação e escreve esse número errado no seu RP. Você só descobre no final do trimestre.

Em um sistema probabilístico, o erro tem uma assinatura. O sistema sabe que está com dificuldades e lhe diz Ei, processei isso, mas minha confiança foi de apenas 62%. Esse é um sinal incrivelmente poderoso. Ele permite que você crie um painel de dúvida. Você pode ver exatamente onde seus modelos estão falhando. Você pode ver quais fornecedores estão enviando documentos que a EA não consegue ler e ver quais etapas do processo estão atingindo constantemente a zona amarela. Você não está apenas construindo um fluxo, você está construindo um ciclo de inteligência. E é aqui que o Azure AI e o AI Builder realmente se destacam. Eles expõem essas pontuações em um nível granular para que você possa ver a confiança de uma tabela, célula ou intenção específica. Pode até usar o PowerFix para criar limites dinâmicos. Talvez para um relatório de despesas de US$ 50 e uma confiança de 0,70 seja aceitável.

Mas para um pedido de compra de US$ 50 mil, você quer 0,98. Você está finalmente alinhando sua lógica técnica ao seu risco de negócio. Temos tratado cada ponto de dados como se tivesse o mesmo peso, mas não. O design probabilístico permite tratar uma decisão de alto risco de forma diferente de uma de baixo risco mesmo, dentro do mesmo fluxo. Você não está mais construindo para um mundo perfeito, você constrói para um mundo onde sabe exatamente quanto a incerteza está disposto a tolerar. E uma vez que você domina a pontuação, pode começar a olhar para a lógica que preenche as lacunas. Correspondência difusa, frase médica. Mas como lidamos de fato com os dados que caem nesse meio termo de incerteza? Começamos admitindo que a correspondência exata está falhando. Ela falha porque lhe falta contexto. No modelo antigo, se o nome de um fornecedor estivesse com um ponto a menos, a busca falhava.

A busca não se importa com sua intenção, ela só se importa com os valores A a C. É aqui que entra a correspondência difusa. É uma técnica que identifica e vincula registros não idênticos, calculando uma pontuação de similaridade, servindo como ponte entre IBM e IE e IBM. E o impacto não é teórico. Pesquisas mostram que implementar a correspondência difusa pode melhorar suas taxas de acerto em até 24%. São 24% dos seus dados que antes seriam rejeitados ou enviados a um humano para a correção manual. Em um ambiente de alto volume, isso representa milhares de horas de tempo recuperado. Mas é preciso entender a mecânica. Existem duas formas principais de pensar sobre isso. Primeiro, a lógica baseada em caracteres. Isso é frequentemente chamado de distância de Leverstein. Ela conta o número de edições necessárias para transformar uma stream em outro. É perfeito para erros de digitação. Se alguém escreve manage management em vez de management, o sistema vê a falta do m-e-nit.

Ele calcula a distância e vê que são quase idênticos. Segundo, temos a lógica semântica. É aqui que as coisas ficam interessantes. Lógica semântica não se importa com a grafia. Ela se importa com o significado. Se um sistema diz customer e outro diz client, uma correspondência baseada em caracteres falhará sempre. Mas o modelo semântico sabe que são a mesma coisa. Essa é a mudança de combinar caracteres para combinar conceitos. Ao combinar pontuações de confiança com correspondência difusa, você cria um sistema capaz de navegar pela realidade complexa dos dados comerciais. Você não fica mais limitado a regras rígidas que quebram no momento em que um humano comete um erro de digitação. Você está construindo um sistema que compreende nuances. E é assim que você passa da simples automação para a verdadeira inteligência digital, criando fluxos de trabalho que se autocorrigem. Mesmo com a melhor correspondência difusa do mundo, precisamos encarar a realidade de que a EA ainda alucina.

É apenas assim que a tecnologia funciona no mundo. Dados atuais mostram que até os modelos mais avançados têm taxa de alucinação entre 15% e 20%. Se você está construindo sistemas para uma empresa, não pode ignorar uma taxa de falha de 1 em cada 5 e definitivamente não pode resolver isso apenas com engenharia de prompt. Você precisa aceitar que atingir uma taxa de 0% de alucinação não é um truque de mágica. É uma escolha arquitetônica deliberada. É aqui que superamos a automação simples e começamos a construir fluxos de trabalho resiliente e de autocorreção. Fazemos isso usando uma estrutura que chamo de padrão de validação de Camindu. Ele atua como uma proteção que impede que a imaginação criativa da EA estrague seus dados reais. Existe uma regra fundamental para o arquiteto moderno. Nunca deixe um grande modelo de linguagem fazer matemática. LLMs são motores de raciocínio flexível que os torna ótimos para entender a intenção ou encontrar um detalhe específico em um monte de texto confuso.

No entanto, eles são estatisticamente pouco confiáveis quando se trata de aritmética básica. Se você pedir a uma EA para extrair 3 itens de uma fatura e calcular o total, você está basicamente pedindo para o sistema falhar. Em um design de autocorreção, você usa o LLM para a parte de raciocínio flexível como extrair dados de um PDF confuso. Depois de obter esses números, você os passa para um sistema determinístico para lidar com as restrições rígidas. Seu fluxo no Power Automate ou um motor de regras básico deve ser o responsável por fazer a soma. Deve ser ele quem verifica o imposto ou valida a conversão de moeda. Se o LLM afirma que o total é US$ 500, mas seu cálculo mostra que deveria ser US$ 480, o sistema detectou uma alucinação em tempo real. Em vez de travar, o sistema aciona um caminho de recuperação. Ele pode tentar um prompt diferente ou marcar o erro para que uma pessoa analise.

Essa é a diferença entre um fluxo que quebra e um fluxo que realmente se autocura. Estamos vendo a mesma mudança acontecer na automação de processos robóticos. O RPA tradicional é muito frágil porque depende de coordenadas exatas na tela. Se um botão se move apenas 3 pixels para a esquerda, todo o bot falha. O RPA de autocura muda isso ou usar visão probabilística. O bot não procura mais por uma coordenada de pixel específica. Em vez disso, ele procura o botão que parece um ícone de salvar perto do topo da página. Quando a interface muda, o bot usa o contexto para se adaptar na hora. Ele reconhece o novo layout, atualiza a sua própria lógica e termina a tarefa. Isso cria um ciclo resiliente onde o sistema vê uma falha potencial e constrói uma ponte para a solução antes mesmo do usuário perceber que havia um problema. Essa mudança desloca nosso foco das taxas de sucesso para as taxas de recuperação.

Paramos de tentar tornar a IA perfeita, o que é impossível de qualquer forma, e começamos a tornar o sistema inabalável. Trata-se de construir uma camada de verificação e equilíbrio em cada transação. Você deve tratar a IA como estagiário de alta velocidade que se distrai facilmente. Você deixa que eles façam um trabalho pesado de ler milhares de e-mails, mas nunca os deixa assinar o cheque sem um auditor sênior verificando a assinatura. Nesse caso, seu código determinístico é esse auditor. Ao separar o pensamento do cálculo, você constrói um sistema que lida com a desordem da linguagem humana enquanto mantém a precisão de um relógio suíço. É assim que você move a IA da fase de testes para o núcleo do seu negócio. Você não confia no modelo, você confia na arquitetura que construiu ao redor dele. Você cria uma rede de segurança tão forte que o tropeço ocasional do modelo nem sequer conta como um erro.

Isso se torna apenas mais uma parte do ciclo de autocorreção. Isso soa ótimo no laboratório, mas na produção o maior gargalo não é a IA. É a realidade do humano no circuito. Isso soa ótimo no laboratório, mas na produção o maior gargalo não é a IA, é o humano. Costumamos falar sobre a automação como se fosse uma escolha simples entre um humano ou uma máquina. Mas a mudança de probabilidade nos força a um meio termo complicado. As referências da indústria mostram a verdade bastante sóbria. Cerca de 50% dos fluxos de trabalho de IA ainda precisam de um especialista para revisá-los antes de serem finalizados. Essa é a principal razão pela qual vemos uma crise da transição do piloto para a produção. Se você olhar para os números, 88% dos projetos pilotos de IA falham dentro de um ano. Eles não falham porque a tecnologia está quebrada. Eles falham porque as pessoas que os projetam tentam automatizar 100% a tarefa cedo demais.

Eles construíram um sistema que funciona com dados de teste limpos, mas a lógica quebra no momento em que atinge o atrito de um departamento real. Quando você ignora o elemento humano, você cria uma carga de verificação. Se sua IA economiza 10 minutos de entrada de dados, mas adiciona 50 minutos para verificar o trabalho porque a equipe não confia nela, você na verdade perdeu produtividade. Você construiu um passivo em vez de um ativo. Projetos bem-sucedidos em 2026 tratarão o trabalho de verificação como um recurso principal. Eles não veem a revisão humana como uma falha do sistema. Em vez disso, veem isso como a parte necessária da arquitetura. Eles incluem o custo dessa revisão, um retorno sobre investimento desde o primeiro dia. O segredo para fazer isso funcionar é a lógica de revisão. É assim que você escala as coisas sem perder a cabeça. Transações de alta confiança acontecem silenciosamente.

Se o modelo tem 98% de certeza e o cálculo está correto, o sistema simplesmente segue em frente. Mas casos de baixa confiança, como aquela zona amarela de que falamos, acionaram uma escalada. Isso muda o papel humano por completo. Estamos nos afastando da entrada de dados e indo em direção à auditoria de dados. No modelo antigo, o humano era o motor porque fazia toda a agitação e os cliques. No novo modelo, o humano é o governador. Eles lidam com as exceções e fornecem a nuance que o modelo probabilístico não consegue entender bem. Pensem como isso é sentido pela equipe. Quando as pessoas sabem que só precisam analisar os 5% dos casos que são realmente difíceis, elas ficam muito mais engajadas. Elas não se sentem mais entediadas pela rotina. Elas são desafiadas pela complexidade dos casos difíceis. Mas você precisa construir a interface certa para que isso funcione. Você não pode simplesmente enviar um e-mail dizendo que algo deu errado.

Você precisa mostrar uma comparação lá da lado. Mostre à pessoa o documento de origem. Mostre o que a IA extraiu e destaque o campo exato onde a pontuação de confiança caiu. Se você quer escalar, tem que parar de agir como se a revisão humana significasse que sua automação é fraca. Na verdade, é o oposto. Um humano bem integrado é o que torna um sistema probabilístico forte o suficiente para sobreviver no mundo real. É a camada final da sua arquitetura de autocorreção. O futuro agente. Estamos olhando para um novo horizonte chamado empresa agente. Este é o ponto final lógico para tudo o que discutimos hoje. Estamos caminhando para um mundo onde agentes não são mais apenas scripts simples ou fluxos básicos porque estão se tornando trabalhadores digitais de primeira classe. A Power Platform está mudando bem diante de nós. Ela está mudando de um construtor de aplicativos padrão para um hub de orquestração completo.

No modelo antigo, você construiu um aplicativo específico para resolver um problema específico. Mas, no modelo agente, você constrói um ambiente onde agentes resolvem esses problemas para você. Esses agentes não seguem apenas uma lista estática de passos. Eles observam o ambiente, avaliam seus próprios níveis de confiança e decidem qual ferramenta é realmente a correta para usar em seguida. Até 2026, a governança não se parecerá em nada com o que era há dois anos. Ferramentas como o Purview e o Sentinel estão caminhando para a detecção probabilística de anomalias. Eles não estão mais apenas procurando por uma senha vazada. Em vez disso, buscam padrões comportamentais que simplesmente não parecem corretos. Eles estão aplicando a mesma lógica de similaridade que usamos para a extração de dados à segurança de todo o seu tenant. Essa mudança é permanente. Pessoas que se prendem a uma lógica rígida de se então ficarão gerenciando sistemas quebrados e equipes frustradas.

Ficarão presas em um ciclo de manutenção constante, tentando remendar uma casa de vidro que nunca foi feita para este clima, a empresa agêntica começa com uma única percepção. Não precisamos controlar cada variável para obter um resultado confiável. Precisamos apenas controlar a arquitetura. Nosso trabalho é definir os limites e estabelecer as diretrizes para que os agentes possam operar dentro dessas fronteiras. Nesse mundo, sua lógica de negócio se torna elástica. Ela se expande para lidar com um novo fornecedor num formato de documento diferente sem que um desenvolvedor precise reescrever uma única linha de código. Essa é a verdadeira promessa, louco. É a capacidade de se mover na velocidade do pensamento em vez da velocidade da sintaxe. Mas para chegar lá, você precisa começar hoje. Pare de construir para o mundo perfeito e comece a construir para o mundo caótico em que realmente vivemos.

Você precisa aceitar dúvida. Desafio de implementação. Que é a sua lição de casa para cima? Quero que você encontre seu fluxo com a maior taxa de falhas. Não escolha o mais complexo, mas encontre aquele que trava com mais frequência devido a dados ruins. O objetivo não é corrigir os dados. Você não pode controlar o que seus usuários ou fornecedores decidem enviar para você. Em vez de lutar contra essa realidade, quero que adicione um limite de confiança. Vá ao seu AI Builder a sua ação de LLM e expõe-se a pontuação de probabilidade. Crie uma condição simples. Se a pontuação de confiança for inferior a 85%, não deixe o fluxo travar. Encaminhe esse caso específico para uma pasta de revisão ou uma lista do SharePoint para uma verificação manual. Observe o que acontece com sua taxa de sucesso. Você verá o estresse sair do seu sistema no momento em que parar de fingir que cada entrada será perfeita.

Se essa mudança de pensamento alterou sua abordagem, siga-me, Mirko Peters, no LinkedIn. Estou constantemente compartilhando análises profundas sobre esses padrões arquiteturais. Compartilhe isso com sua equipe, especialmente se seus fluxos estiverem quebrando a mão. Precisamos parar de construir com vidro e começar a construir com propósito. Essa é a técnica e ela reduz seu tempo de inatividade pela metade assim que você começa a praticá-la. Se você quer a versão avançada que os profissionais usam, confira este próximo vídeo e inscreva-se para mais tutoriais. Pare de lutar contra a realidade confusa dos seus dados e comece a projetar pensando neles. Ao usar pontuações de confiança, você transforma fluxos frágeis em sistemas resilientes que realmente funcionam. Mas aqui está o ponto principal. O modelo só funciona se você o construir corretamente. Se você quer ver exatamente como configurar isso no Copilot Studio, assista a este próximo vídeo agora mesmo.

E se isso mudou sua forma de pensar sobre a siga-me no LinkedIn ou inscreva-se no Master the New Model.