WEBVTT

00:00:00.000 --> 00:00:03.280
Suas automações low-code estão falhando porque tentam ser espertas demais.

00:00:03.840 --> 00:00:07.840
Lógica rígida de C, então, é uma sentença de morte ao lidar com dados reais e bagunçados

00:00:07.840 --> 00:00:09.460
que travam seus sistemas diariamente.

00:00:10.200 --> 00:00:13.100
Assumir que os dados são limpos é o pecado original do design low-code.

00:00:13.480 --> 00:00:17.880
Construímos nosso mundo no modelo C, então, mas ele exige certeza absoluta para funcionar.

00:00:18.300 --> 00:00:19.480
Dados do mundo real não são certos.

00:00:19.840 --> 00:00:20.680
Eles contêm erros de digitação.

00:00:21.040 --> 00:00:21.960
Eles contêm falta de contexto.

00:00:22.400 --> 00:00:23.780
São um fluxo caótico de erros humanos.

00:00:24.480 --> 00:00:27.080
Quando um sistema determinístico encontra 1% de variação,

00:00:27.340 --> 00:00:29.140
ele não cede e certamente não se adapta.

00:00:29.140 --> 00:00:30.100
Ele é em cima de quebra.

00:00:31.620 --> 00:00:35.360
Isso cria a armadilha da fragilidade, onde sua automação é tão forte quanto seu dado mais limpo.

00:00:35.800 --> 00:00:37.980
Nas empresas, é um nível muito baixo para definir sucesso.

00:00:38.360 --> 00:00:41.220
Mas o problema não são os dados, é o modelo que usamos para processá-lo.

00:00:41.940 --> 00:00:42.860
A morte do determinismo.

00:00:43.500 --> 00:00:46.120
Lógica determinística é uma relíquia da era dos dados estruturados.

00:00:47.120 --> 00:00:49.140
Funcionava quando tudo vivia em tabelas SQL,

00:00:49.540 --> 00:00:52.660
quando forçávamos humanos a caberem caixas predefinidas.

00:00:53.380 --> 00:00:54.040
Mas esse mundo acabou.

00:00:54.460 --> 00:00:56.840
Hoje, 80% dos dados corporativos não são estruturados,

00:00:56.840 --> 00:00:59.020
ou seja, vivem em e-mails, chats e gravações de voz.

00:00:59.140 --> 00:00:59.860
De voz.

00:01:00.420 --> 00:01:05.440
Fluxos tradicionais do Power Automate tratam uma SANs e 4 PPL3 como dois universos diferentes.

00:01:06.260 --> 00:01:09.480
Para um sistema binário, são sequências de caracteres totalmente desconexas.

00:01:10.140 --> 00:01:14.720
Chegamos a um ponto crítico onde o custo da limpeza manual de dados supera o valor da automação em si.

00:01:14.720 --> 00:01:20.420
Se você gasta duas horas corrigindo um CSV para que um fluxo rode por 5 segundos, você não automatizou nada.

00:01:21.100 --> 00:01:22.220
É apenas transferir o trabalho humano.

00:01:22.620 --> 00:01:25.680
E A não é apenas um novo recurso brilhante que estamos adicionando à Power Platform.

00:01:26.480 --> 00:01:28.720
É uma mudança fundamental da correspondência exata para a similaridade.

00:01:30.500 --> 00:01:31.440
O modelo antigo pergunta.

00:01:31.620 --> 00:01:32.000
Isto é A?

00:01:32.440 --> 00:01:33.500
O novo modelo pergunta.

00:01:33.600 --> 00:01:34.640
O quanto isso se parece com A?

00:01:34.640 --> 00:01:36.980
Pense em como você navega para a sua caixa de entrada.

00:01:37.420 --> 00:01:39.320
Eu não executo uma expressão regular na cabeça para achar uma nota fiscal.

00:01:39.720 --> 00:01:40.600
Você busca por padrão.

00:01:40.900 --> 00:01:41.640
Você busca por contexto.

00:01:42.260 --> 00:01:47.560
Você reconhece que NV202 e nota fiscal número 202 são a mesma coisa, mesmo que os caracteres não batam.

00:01:48.080 --> 00:01:49.600
Sistemas determinísticos não conseguem fazer isso.

00:01:49.880 --> 00:01:50.780
Eles são cegos em intenção.

00:01:51.120 --> 00:01:52.040
Eles só enxergam a sintaxe.

00:01:52.040 --> 00:01:56.280
E à medida que avançamos para 2026, a sintaxe se torna menos importante que a semântica.

00:01:56.800 --> 00:02:02.400
Estamos vendo uma explosão massiva no volume de dados de sensores IoT, fluxos em tempo real e resumos gerados por LLMs.

00:02:03.240 --> 00:02:07.700
Se tentar gerenciar esse volume com ramificações 100 tão rígidas, sua lógica virará um labirinto.

00:02:08.320 --> 00:02:13.600
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.

00:02:14.180 --> 00:02:17.700
O modelo 100 então assume um mundo perfeito, onde a entrada sempre corresponderá ao esquema.

00:02:18.900 --> 00:02:20.480
Mas na realidade é o oposto.

00:02:21.040 --> 00:02:21.980
Os dados são a variável.

00:02:22.480 --> 00:02:26.520
A lógica deveria ser a constante, mas a nossa lógica tem sido rígida demais para sobreviver ao contato com a realidade.

00:02:27.020 --> 00:02:32.340
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.

00:02:32.920 --> 00:02:36.240
A mudança para o design probabilístico trata de construir com borracha em vez de vidro.

00:02:36.860 --> 00:02:41.100
Trata-se de criar sistemas que possam absorver o impacto de um erro de digitação sem se despedaçar.

00:02:41.840 --> 00:02:48.480
Estamos afastando da ideia de que um sistema deve estar 100% ou 100% errado, porque no mundo real, nada é 100%.

00:02:48.480 --> 00:02:51.040
Temos mentido para nós mesmos sobre a qualidade dos nossos dados adeptos.

00:02:51.040 --> 00:02:57.900
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.

00:02:58.420 --> 00:03:00.260
A morte do determinismo é a morte dessa mentira.

00:03:00.900 --> 00:03:02.680
É a admissão de que não podemos controlar a entrada.

00:03:02.840 --> 00:03:04.220
Então precisamos modernizar o processamento.

00:03:04.220 --> 00:03:10.840
Estamos entrando na era da empresa aproximativa, onde aceitamos que perto o suficiente é, na verdade, melhor do que exatamente errado.

00:03:11.540 --> 00:03:18.800
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%.

00:03:18.800 --> 00:03:21.820
Esta não é apenas uma mudança técnica, é uma mudança psicóloga.

00:03:21.820 --> 00:03:26.540
Você precisa se sentir confortável com a ideia de que seu sistema pode estar apenas bastante seguro sobre um dado.

00:03:27.500 --> 00:03:31.980
Você precisa aprender a projetar para dúvida, pois a dúvida é a única maneira honesta de lidar com informações não estruturadas.

00:03:32.880 --> 00:03:37.460
Essa mudança exige que passemos de gatilhos binários para algo muito mais sutil, a pontuação de confiança.

00:03:37.680 --> 00:03:38.780
A arquitetura vem certeza.

00:03:38.780 --> 00:03:43.600
Se aceitarmos que a era da lógica binária acabou, temos que substituí-la por uma nova estrutura.

00:03:44.180 --> 00:03:45.860
Eu chamo isso de modelo de orquestra sinfônica.

00:03:46.300 --> 00:03:50.120
Em uma arquitetura de TI tradicional, todos são solistas tocando uma partitura rígida.

00:03:50.340 --> 00:03:52.600
E se alguém erra uma nota, a apresentação inteira para.

00:03:53.680 --> 00:03:57.760
Mas em uma arquitetura probabilística, temos maestros determinísticos gerenciando músicos probabilísticos,

00:03:58.320 --> 00:03:59.580
maestro ao seu fluxo no paro também.

00:04:00.160 --> 00:04:02.660
Ele fornece estrutura, define o ritmo e estabelece os limites.

00:04:03.160 --> 00:04:04.280
Os músicos são os modelos de A.

00:04:04.280 --> 00:04:06.820
Eles são talentosos, mas expressivos.

00:04:07.220 --> 00:04:10.340
E nem sempre atingem a mesma frequência exata todas as vezes que tocam.

00:04:11.120 --> 00:04:13.460
O trabalho do maestro não é forçar os músicos a serem robôs.

00:04:14.180 --> 00:04:17.480
É ouvi-los e decidir se o som que estão produzindo é bom o suficiente para continuar.

00:04:18.440 --> 00:04:21.440
Isso nos leva ao pilar central do design moderno, a pontuação de confiança.

00:04:22.300 --> 00:04:25.140
Uma pontuação de confiança é um valor de 0 a 1 que quantifica a dúvida.

00:04:25.960 --> 00:04:28.380
É a maneira do modelo dizer, eu acho que isso é uma correspondência.

00:04:28.420 --> 00:04:29.980
E aqui está o quanto estou disposto a apostar nisso.

00:04:30.940 --> 00:04:32.800
No mundo antigo, tínhamos caminhos codificados.

00:04:32.800 --> 00:04:35.980
Se o assunto do e-mail, quando tiver fatura, salve o anexo.

00:04:36.680 --> 00:04:38.680
No novo mundo, usamos roteamento baseado em confiança.

00:04:38.920 --> 00:04:41.540
Estamos tornando a dúvida interna do modelo visível para o sistema.

00:04:42.220 --> 00:04:44.100
Não tratamos mais a IA como uma caixa preta,

00:04:44.160 --> 00:04:47.040
mas a tratamos como uma testemunha com nível específico de credibilidade.

00:04:47.980 --> 00:04:49.920
Veja como você realmente constrói isso na Power Platform.

00:04:50.460 --> 00:04:53.840
Ao usar o AI Builder ou o Azure AI, você não obtém apenas os dados extraídos.

00:04:54.340 --> 00:04:57.540
Você obtém uma camada de metadados que revela a probabilidade de cada campo.

00:04:57.540 --> 00:05:00.340
Se o modelo extrai um valor total de US$ 1.500,

00:05:00.660 --> 00:05:03.360
ele também informa que tem 95% de certeza sobre esse número.

00:05:04.160 --> 00:05:06.400
Como arquiteto, você agora tem três zonas distintas de ação.

00:05:06.920 --> 00:05:07.720
Primeiro, a zona verde.

00:05:08.420 --> 00:05:09.780
A confiança é 0,90 ou superior.

00:05:10.860 --> 00:05:13.120
O risco de erro é baixo, o custo de um erro é administrável,

00:05:13.200 --> 00:05:14.760
e o resultado é que você automatiza.

00:05:15.440 --> 00:05:17.160
O sistema prossegue sem intervenção humana.

00:05:17.820 --> 00:05:18.680
Segundo, a zona amarela.

00:05:19.040 --> 00:05:21.660
A confiança está entre 0,60 e 0,89.

00:05:21.660 --> 00:05:24.300
O modelo está bem seguro, mas não tem certeza.

00:05:24.700 --> 00:05:26.240
Talvez o documento estivesse um pouco desfocado,

00:05:26.340 --> 00:05:27.560
talvez a caligrafia estivesse confusa.

00:05:27.980 --> 00:05:29.120
Nesta zona, você sinaliza.

00:05:29.680 --> 00:05:32.180
O sistema encaminha os dados para um revisor humano para uma verificação rápida.

00:05:33.060 --> 00:05:33.840
Terceira zona vermelha.

00:05:34.120 --> 00:05:35.680
A confiança está abaixo de 0,60.

00:05:36.100 --> 00:05:36.960
O modelo está tendo a adivinhar.

00:05:37.240 --> 00:05:38.980
Nesta zona, você rejeita ou escala.

00:05:39.500 --> 00:05:41.760
Você não deixa esses dados chegarem perto do seu banco de dados de produção.

00:05:42.260 --> 00:05:44.160
Esta é uma camada transparente de gerenciamento de risco.

00:05:44.640 --> 00:05:47.560
Ela permite que você dimensione sua automação enquanto mantém uma válvula de segurança.

00:05:47.960 --> 00:05:49.420
Pense nas implicações para governança.

00:05:49.580 --> 00:05:51.880
Em um sistema determinístico, os erros são silenciosos.

00:05:51.880 --> 00:05:55.120
Um fluxo é executado, escolhe o número errado por causa de um erro de digitação

00:05:55.120 --> 00:05:56.580
e escreve esse número errado no seu RP.

00:05:57.080 --> 00:05:58.560
Você só descobre no final do trimestre.

00:05:59.020 --> 00:06:00.780
Em um sistema probabilístico, o erro tem uma assinatura.

00:06:01.280 --> 00:06:03.060
O sistema sabe que está com dificuldades e lhe diz

00:06:03.060 --> 00:06:05.980
Ei, processei isso, mas minha confiança foi de apenas 62%.

00:06:05.980 --> 00:06:07.780
Esse é um sinal incrivelmente poderoso.

00:06:08.220 --> 00:06:09.620
Ele permite que você crie um painel de dúvida.

00:06:09.840 --> 00:06:11.460
Você pode ver exatamente onde seus modelos estão falhando.

00:06:11.840 --> 00:06:14.800
Você pode ver quais fornecedores estão enviando documentos que a EA não consegue ler

00:06:14.800 --> 00:06:17.780
e ver quais etapas do processo estão atingindo constantemente a zona amarela.

00:06:18.280 --> 00:06:20.880
Você não está apenas construindo um fluxo, você está construindo um ciclo de inteligência.

00:06:20.880 --> 00:06:23.560
E é aqui que o Azure AI e o AI Builder realmente se destacam.

00:06:24.060 --> 00:06:26.060
Eles expõem essas pontuações em um nível granular

00:06:26.060 --> 00:06:29.740
para que você possa ver a confiança de uma tabela, célula ou intenção específica.

00:06:30.260 --> 00:06:32.360
Pode até usar o PowerFix para criar limites dinâmicos.

00:06:33.180 --> 00:06:36.700
Talvez para um relatório de despesas de US$ 50 e uma confiança de 0,70 seja aceitável.

00:06:37.240 --> 00:06:40.180
Mas para um pedido de compra de US$ 50 mil, você quer 0,98.

00:06:41.180 --> 00:06:44.060
Você está finalmente alinhando sua lógica técnica ao seu risco de negócio.

00:06:44.620 --> 00:06:47.420
Temos tratado cada ponto de dados como se tivesse o mesmo peso, mas não.

00:06:47.420 --> 00:06:51.180
O design probabilístico permite tratar uma decisão de alto risco de forma diferente

00:06:51.180 --> 00:06:53.720
de uma de baixo risco mesmo, dentro do mesmo fluxo.

00:06:54.680 --> 00:06:56.540
Você não está mais construindo para um mundo perfeito,

00:06:56.640 --> 00:07:00.240
você constrói para um mundo onde sabe exatamente quanto a incerteza está disposto a tolerar.

00:07:01.500 --> 00:07:04.740
E uma vez que você domina a pontuação, pode começar a olhar para a lógica que preenche as lacunas.

00:07:05.600 --> 00:07:06.760
Correspondência difusa, frase médica.

00:07:07.320 --> 00:07:10.840
Mas como lidamos de fato com os dados que caem nesse meio termo de incerteza?

00:07:11.900 --> 00:07:13.940
Começamos admitindo que a correspondência exata está falhando.

00:07:13.940 --> 00:07:15.800
Ela falha porque lhe falta contexto.

00:07:16.320 --> 00:07:19.560
No modelo antigo, se o nome de um fornecedor estivesse com um ponto a menos, a busca falhava.

00:07:20.120 --> 00:07:23.140
A busca não se importa com sua intenção, ela só se importa com os valores A a C.

00:07:23.700 --> 00:07:25.060
É aqui que entra a correspondência difusa.

00:07:25.520 --> 00:07:28.180
É uma técnica que identifica e vincula registros não idênticos,

00:07:28.280 --> 00:07:29.940
calculando uma pontuação de similaridade,

00:07:30.280 --> 00:07:32.820
servindo como ponte entre IBM e IE e IBM.

00:07:33.280 --> 00:07:34.380
E o impacto não é teórico.

00:07:34.900 --> 00:07:36.980
Pesquisas mostram que implementar a correspondência difusa

00:07:36.980 --> 00:07:39.120
pode melhorar suas taxas de acerto em até 24%.

00:07:39.120 --> 00:07:43.600
São 24% dos seus dados que antes seriam rejeitados ou enviados a um humano para a correção manual.

00:07:44.120 --> 00:07:47.160
Em um ambiente de alto volume, isso representa milhares de horas de tempo recuperado.

00:07:47.560 --> 00:07:48.720
Mas é preciso entender a mecânica.

00:07:49.200 --> 00:07:50.800
Existem duas formas principais de pensar sobre isso.

00:07:51.040 --> 00:07:52.200
Primeiro, a lógica baseada em caracteres.

00:07:52.640 --> 00:07:54.300
Isso é frequentemente chamado de distância de Leverstein.

00:07:54.660 --> 00:07:57.340
Ela conta o número de edições necessárias para transformar uma stream em outro.

00:07:57.660 --> 00:07:58.880
É perfeito para erros de digitação.

00:07:59.200 --> 00:08:01.900
Se alguém escreve manage management em vez de management,

00:08:02.160 --> 00:08:03.900
o sistema vê a falta do m-e-nit.

00:08:04.240 --> 00:08:06.400
Ele calcula a distância e vê que são quase idênticos.

00:08:06.400 --> 00:08:09.140
Segundo, temos a lógica semântica.

00:08:09.740 --> 00:08:10.920
É aqui que as coisas ficam interessantes.

00:08:11.180 --> 00:08:12.720
Lógica semântica não se importa com a grafia.

00:08:13.060 --> 00:08:14.020
Ela se importa com o significado.

00:08:14.400 --> 00:08:16.460
Se um sistema diz customer e outro diz client,

00:08:16.680 --> 00:08:19.440
uma correspondência baseada em caracteres falhará sempre.

00:08:19.780 --> 00:08:21.440
Mas o modelo semântico sabe que são a mesma coisa.

00:08:22.060 --> 00:08:24.480
Essa é a mudança de combinar caracteres para combinar conceitos.

00:08:25.020 --> 00:08:27.500
Ao combinar pontuações de confiança com correspondência difusa,

00:08:27.580 --> 00:08:30.520
você cria um sistema capaz de navegar pela realidade complexa dos dados comerciais.

00:08:31.160 --> 00:08:32.740
Você não fica mais limitado a regras rígidas

00:08:32.740 --> 00:08:34.720
que quebram no momento em que um humano comete um erro de digitação.

00:08:34.720 --> 00:08:36.800
Você está construindo um sistema que compreende nuances.

00:08:37.620 --> 00:08:41.020
E é assim que você passa da simples automação para a verdadeira inteligência digital,

00:08:41.480 --> 00:08:43.040
criando fluxos de trabalho que se autocorrigem.

00:08:43.700 --> 00:08:45.540
Mesmo com a melhor correspondência difusa do mundo,

00:08:45.680 --> 00:08:47.720
precisamos encarar a realidade de que a EA ainda alucina.

00:08:48.140 --> 00:08:49.760
É apenas assim que a tecnologia funciona no mundo.

00:08:50.540 --> 00:08:52.920
Dados atuais mostram que até os modelos mais avançados

00:08:52.920 --> 00:08:55.140
têm taxa de alucinação entre 15% e 20%.

00:08:55.140 --> 00:08:57.480
Se você está construindo sistemas para uma empresa,

00:08:57.600 --> 00:08:59.620
não pode ignorar uma taxa de falha de 1 em cada 5

00:08:59.620 --> 00:09:02.100
e definitivamente não pode resolver isso apenas com engenharia de prompt.

00:09:02.100 --> 00:09:05.300
Você precisa aceitar que atingir uma taxa de 0% de alucinação

00:09:05.300 --> 00:09:06.560
não é um truque de mágica.

00:09:06.960 --> 00:09:08.460
É uma escolha arquitetônica deliberada.

00:09:08.860 --> 00:09:10.300
É aqui que superamos a automação simples

00:09:10.300 --> 00:09:12.860
e começamos a construir fluxos de trabalho resiliente e de autocorreção.

00:09:13.540 --> 00:09:16.260
Fazemos isso usando uma estrutura que chamo de padrão de validação de Camindu.

00:09:16.900 --> 00:09:19.600
Ele atua como uma proteção que impede que a imaginação criativa

00:09:19.600 --> 00:09:20.940
da EA estrague seus dados reais.

00:09:20.940 --> 00:09:24.100
Existe uma regra fundamental para o arquiteto moderno.

00:09:24.180 --> 00:09:25.960
Nunca deixe um grande modelo de linguagem fazer matemática.

00:09:26.720 --> 00:09:28.760
LLMs são motores de raciocínio flexível

00:09:28.760 --> 00:09:30.740
que os torna ótimos para entender a intenção

00:09:30.740 --> 00:09:33.600
ou encontrar um detalhe específico em um monte de texto confuso.

00:09:34.440 --> 00:09:36.300
No entanto, eles são estatisticamente pouco confiáveis

00:09:36.300 --> 00:09:37.580
quando se trata de aritmética básica.

00:09:38.060 --> 00:09:40.440
Se você pedir a uma EA para extrair 3 itens de uma fatura

00:09:40.440 --> 00:09:43.080
e calcular o total, você está basicamente pedindo para o sistema falhar.

00:09:43.880 --> 00:09:45.020
Em um design de autocorreção,

00:09:45.320 --> 00:09:47.540
você usa o LLM para a parte de raciocínio flexível

00:09:47.540 --> 00:09:49.340
como extrair dados de um PDF confuso.

00:09:49.980 --> 00:09:51.080
Depois de obter esses números,

00:09:51.180 --> 00:09:52.840
você os passa para um sistema determinístico

00:09:52.840 --> 00:09:54.180
para lidar com as restrições rígidas.

00:09:54.840 --> 00:09:57.280
Seu fluxo no Power Automate ou um motor de regras básico

00:09:57.280 --> 00:09:58.960
deve ser o responsável por fazer a soma.

00:09:59.480 --> 00:10:00.780
Deve ser ele quem verifica o imposto

00:10:00.780 --> 00:10:01.900
ou valida a conversão de moeda.

00:10:02.680 --> 00:10:04.520
Se o LLM afirma que o total é US$ 500,

00:10:04.920 --> 00:10:07.040
mas seu cálculo mostra que deveria ser US$ 480,

00:10:07.320 --> 00:10:09.100
o sistema detectou uma alucinação em tempo real.

00:10:09.900 --> 00:10:12.020
Em vez de travar, o sistema aciona um caminho de recuperação.

00:10:12.520 --> 00:10:13.920
Ele pode tentar um prompt diferente

00:10:13.920 --> 00:10:15.600
ou marcar o erro para que uma pessoa analise.

00:10:15.600 --> 00:10:18.620
Essa é a diferença entre um fluxo que quebra

00:10:18.620 --> 00:10:20.260
e um fluxo que realmente se autocura.

00:10:21.000 --> 00:10:22.280
Estamos vendo a mesma mudança acontecer

00:10:22.280 --> 00:10:23.620
na automação de processos robóticos.

00:10:24.120 --> 00:10:25.440
O RPA tradicional é muito frágil

00:10:25.440 --> 00:10:27.260
porque depende de coordenadas exatas na tela.

00:10:27.980 --> 00:10:30.080
Se um botão se move apenas 3 pixels para a esquerda,

00:10:30.160 --> 00:10:30.980
todo o bot falha.

00:10:31.740 --> 00:10:32.900
O RPA de autocura muda isso

00:10:32.900 --> 00:10:34.120
ou usar visão probabilística.

00:10:34.840 --> 00:10:35.760
O bot não procura mais

00:10:35.760 --> 00:10:37.460
por uma coordenada de pixel específica.

00:10:37.860 --> 00:10:39.080
Em vez disso, ele procura o botão

00:10:39.080 --> 00:10:41.040
que parece um ícone de salvar perto do topo da página.

00:10:41.620 --> 00:10:42.560
Quando a interface muda,

00:10:42.640 --> 00:10:44.520
o bot usa o contexto para se adaptar na hora.

00:10:44.520 --> 00:10:46.600
Ele reconhece o novo layout,

00:10:46.780 --> 00:10:48.680
atualiza a sua própria lógica e termina a tarefa.

00:10:49.540 --> 00:10:50.860
Isso cria um ciclo resiliente

00:10:50.860 --> 00:10:52.540
onde o sistema vê uma falha potencial

00:10:52.540 --> 00:10:54.040
e constrói uma ponte para a solução

00:10:54.040 --> 00:10:56.020
antes mesmo do usuário perceber que havia um problema.

00:10:57.040 --> 00:10:59.200
Essa mudança desloca nosso foco das taxas de sucesso

00:10:59.200 --> 00:10:59.980
para as taxas de recuperação.

00:11:00.540 --> 00:11:02.220
Paramos de tentar tornar a IA perfeita,

00:11:02.260 --> 00:11:03.500
o que é impossível de qualquer forma,

00:11:03.580 --> 00:11:05.260
e começamos a tornar o sistema inabalável.

00:11:05.800 --> 00:11:07.740
Trata-se de construir uma camada de verificação

00:11:07.740 --> 00:11:08.820
e equilíbrio em cada transação.

00:11:09.040 --> 00:11:11.300
Você deve tratar a IA como estagiário de alta velocidade

00:11:11.300 --> 00:11:12.340
que se distrai facilmente.

00:11:12.340 --> 00:11:14.860
Você deixa que eles façam um trabalho pesado

00:11:14.860 --> 00:11:15.760
de ler milhares de e-mails,

00:11:15.900 --> 00:11:17.000
mas nunca os deixa assinar o cheque

00:11:17.000 --> 00:11:18.780
sem um auditor sênior verificando a assinatura.

00:11:19.900 --> 00:11:20.400
Nesse caso,

00:11:20.480 --> 00:11:21.900
seu código determinístico é esse auditor.

00:11:22.640 --> 00:11:24.140
Ao separar o pensamento do cálculo,

00:11:24.260 --> 00:11:25.640
você constrói um sistema

00:11:25.640 --> 00:11:27.320
que lida com a desordem da linguagem humana

00:11:27.320 --> 00:11:29.360
enquanto mantém a precisão de um relógio suíço.

00:11:30.280 --> 00:11:32.080
É assim que você move a IA da fase de testes

00:11:32.080 --> 00:11:33.200
para o núcleo do seu negócio.

00:11:34.320 --> 00:11:35.180
Você não confia no modelo,

00:11:35.180 --> 00:11:37.140
você confia na arquitetura que construiu ao redor dele.

00:11:37.720 --> 00:11:39.560
Você cria uma rede de segurança tão forte

00:11:39.560 --> 00:11:42.020
que o tropeço ocasional do modelo nem sequer conta como um erro.

00:11:42.520 --> 00:11:44.660
Isso se torna apenas mais uma parte do ciclo de autocorreção.

00:11:46.080 --> 00:11:47.620
Isso soa ótimo no laboratório,

00:11:47.700 --> 00:11:50.100
mas na produção o maior gargalo não é a IA.

00:11:50.700 --> 00:11:52.880
É a realidade do humano no circuito.

00:11:53.620 --> 00:11:55.020
Isso soa ótimo no laboratório,

00:11:55.120 --> 00:11:57.240
mas na produção o maior gargalo não é a IA,

00:11:57.380 --> 00:11:57.780
é o humano.

00:11:59.100 --> 00:12:00.500
Costumamos falar sobre a automação

00:12:00.500 --> 00:12:01.920
como se fosse uma escolha simples

00:12:01.920 --> 00:12:03.220
entre um humano ou uma máquina.

00:12:03.560 --> 00:12:04.840
Mas a mudança de probabilidade

00:12:04.840 --> 00:12:06.380
nos força a um meio termo complicado.

00:12:06.380 --> 00:12:09.300
As referências da indústria mostram a verdade bastante sóbria.

00:12:10.020 --> 00:12:11.940
Cerca de 50% dos fluxos de trabalho de IA

00:12:11.940 --> 00:12:13.060
ainda precisam de um especialista

00:12:13.060 --> 00:12:14.420
para revisá-los antes de serem finalizados.

00:12:14.640 --> 00:12:15.700
Essa é a principal razão pela qual

00:12:15.700 --> 00:12:17.360
vemos uma crise da transição do piloto para a produção.

00:12:17.680 --> 00:12:18.280
Se você olhar para os números,

00:12:18.380 --> 00:12:20.820
88% dos projetos pilotos de IA falham dentro de um ano.

00:12:21.180 --> 00:12:22.700
Eles não falham porque a tecnologia está quebrada.

00:12:23.320 --> 00:12:25.020
Eles falham porque as pessoas que os projetam

00:12:25.020 --> 00:12:27.320
tentam automatizar 100% a tarefa cedo demais.

00:12:28.220 --> 00:12:29.220
Eles construíram um sistema

00:12:29.220 --> 00:12:30.680
que funciona com dados de teste limpos,

00:12:30.760 --> 00:12:31.700
mas a lógica quebra no momento

00:12:31.700 --> 00:12:33.360
em que atinge o atrito de um departamento real.

00:12:33.920 --> 00:12:35.160
Quando você ignora o elemento humano,

00:12:35.160 --> 00:12:36.620
você cria uma carga de verificação.

00:12:37.200 --> 00:12:39.420
Se sua IA economiza 10 minutos de entrada de dados,

00:12:39.500 --> 00:12:41.260
mas adiciona 50 minutos para verificar o trabalho

00:12:41.260 --> 00:12:42.280
porque a equipe não confia nela,

00:12:42.700 --> 00:12:43.900
você na verdade perdeu produtividade.

00:12:44.820 --> 00:12:46.840
Você construiu um passivo em vez de um ativo.

00:12:47.380 --> 00:12:49.020
Projetos bem-sucedidos em 2026

00:12:49.020 --> 00:12:51.060
tratarão o trabalho de verificação como um recurso principal.

00:12:51.820 --> 00:12:53.840
Eles não veem a revisão humana como uma falha do sistema.

00:12:54.560 --> 00:12:56.660
Em vez disso, veem isso como a parte necessária da arquitetura.

00:12:57.340 --> 00:12:58.780
Eles incluem o custo dessa revisão,

00:12:59.120 --> 00:13:00.760
um retorno sobre investimento desde o primeiro dia.

00:13:01.340 --> 00:13:02.480
O segredo para fazer isso funcionar

00:13:02.480 --> 00:13:03.680
é a lógica de revisão.

00:13:04.400 --> 00:13:06.260
É assim que você escala as coisas sem perder a cabeça.

00:13:07.040 --> 00:13:09.040
Transações de alta confiança acontecem silenciosamente.

00:13:09.580 --> 00:13:12.160
Se o modelo tem 98% de certeza e o cálculo está correto,

00:13:12.240 --> 00:13:13.460
o sistema simplesmente segue em frente.

00:13:14.160 --> 00:13:15.320
Mas casos de baixa confiança,

00:13:15.400 --> 00:13:16.680
como aquela zona amarela de que falamos,

00:13:16.780 --> 00:13:17.600
acionaram uma escalada.

00:13:18.220 --> 00:13:19.580
Isso muda o papel humano por completo.

00:13:20.020 --> 00:13:21.380
Estamos nos afastando da entrada de dados

00:13:21.380 --> 00:13:22.580
e indo em direção à auditoria de dados.

00:13:23.060 --> 00:13:24.380
No modelo antigo, o humano era o motor

00:13:24.380 --> 00:13:26.100
porque fazia toda a agitação e os cliques.

00:13:26.860 --> 00:13:28.340
No novo modelo, o humano é o governador.

00:13:28.340 --> 00:13:29.900
Eles lidam com as exceções

00:13:29.900 --> 00:13:31.920
e fornecem a nuance que o modelo probabilístico

00:13:31.920 --> 00:13:32.960
não consegue entender bem.

00:13:33.600 --> 00:13:34.840
Pensem como isso é sentido pela equipe.

00:13:35.180 --> 00:13:36.640
Quando as pessoas sabem que só precisam analisar

00:13:36.640 --> 00:13:38.580
os 5% dos casos que são realmente difíceis,

00:13:38.640 --> 00:13:39.880
elas ficam muito mais engajadas.

00:13:40.280 --> 00:13:41.780
Elas não se sentem mais entediadas pela rotina.

00:13:42.260 --> 00:13:44.180
Elas são desafiadas pela complexidade dos casos difíceis.

00:13:44.660 --> 00:13:46.280
Mas você precisa construir a interface certa

00:13:46.280 --> 00:13:47.020
para que isso funcione.

00:13:47.500 --> 00:13:48.740
Você não pode simplesmente enviar um e-mail

00:13:48.740 --> 00:13:49.680
dizendo que algo deu errado.

00:13:50.220 --> 00:13:51.780
Você precisa mostrar uma comparação lá da lado.

00:13:52.440 --> 00:13:53.820
Mostre à pessoa o documento de origem.

00:13:54.280 --> 00:13:55.460
Mostre o que a IA extraiu

00:13:55.460 --> 00:13:58.460
e destaque o campo exato onde a pontuação de confiança caiu.

00:13:59.020 --> 00:14:00.420
Se você quer escalar, tem que parar de agir

00:14:00.420 --> 00:14:01.780
como se a revisão humana significasse

00:14:01.780 --> 00:14:02.740
que sua automação é fraca.

00:14:03.160 --> 00:14:03.920
Na verdade, é o oposto.

00:14:04.460 --> 00:14:05.400
Um humano bem integrado

00:14:05.400 --> 00:14:07.220
é o que torna um sistema probabilístico forte

00:14:07.220 --> 00:14:09.540
o suficiente para sobreviver no mundo real.

00:14:10.340 --> 00:14:12.480
É a camada final da sua arquitetura de autocorreção.

00:14:13.840 --> 00:14:14.540
O futuro agente.

00:14:15.160 --> 00:14:16.360
Estamos olhando para um novo horizonte

00:14:16.360 --> 00:14:17.520
chamado empresa agente.

00:14:18.260 --> 00:14:19.460
Este é o ponto final lógico

00:14:19.460 --> 00:14:20.760
para tudo o que discutimos hoje.

00:14:21.440 --> 00:14:22.340
Estamos caminhando para um mundo

00:14:22.340 --> 00:14:23.600
onde agentes não são mais apenas

00:14:23.600 --> 00:14:25.200
scripts simples ou fluxos básicos

00:14:25.200 --> 00:14:25.880
porque estão se tornando

00:14:25.880 --> 00:14:27.340
trabalhadores digitais de primeira classe.

00:14:28.160 --> 00:14:29.340
A Power Platform está mudando

00:14:29.340 --> 00:14:30.200
bem diante de nós.

00:14:30.860 --> 00:14:31.860
Ela está mudando de um construtor

00:14:31.860 --> 00:14:32.760
de aplicativos padrão

00:14:32.760 --> 00:14:34.280
para um hub de orquestração completo.

00:14:34.740 --> 00:14:35.360
No modelo antigo,

00:14:35.440 --> 00:14:36.780
você construiu um aplicativo específico

00:14:36.780 --> 00:14:37.860
para resolver um problema específico.

00:14:38.380 --> 00:14:39.340
Mas, no modelo agente,

00:14:39.420 --> 00:14:40.320
você constrói um ambiente

00:14:40.320 --> 00:14:41.220
onde agentes resolvem

00:14:41.220 --> 00:14:42.160
esses problemas para você.

00:14:42.740 --> 00:14:43.580
Esses agentes não seguem

00:14:43.580 --> 00:14:44.940
apenas uma lista estática de passos.

00:14:45.480 --> 00:14:46.480
Eles observam o ambiente,

00:14:46.640 --> 00:14:48.220
avaliam seus próprios níveis de confiança

00:14:48.220 --> 00:14:49.220
e decidem qual ferramenta

00:14:49.220 --> 00:14:50.640
é realmente a correta para usar em seguida.

00:14:51.160 --> 00:14:51.920
Até 2026,

00:14:52.260 --> 00:14:53.520
a governança não se parecerá em nada

00:14:53.520 --> 00:14:54.280
com o que era há dois anos.

00:14:54.960 --> 00:14:55.900
Ferramentas como o Purview

00:14:55.900 --> 00:14:57.020
e o Sentinel estão caminhando

00:14:57.020 --> 00:14:58.020
para a detecção probabilística

00:14:58.020 --> 00:14:58.580
de anomalias.

00:14:59.260 --> 00:15:00.120
Eles não estão mais apenas

00:15:00.120 --> 00:15:01.340
procurando por uma senha vazada.

00:15:01.880 --> 00:15:02.380
Em vez disso,

00:15:02.500 --> 00:15:03.740
buscam padrões comportamentais

00:15:03.740 --> 00:15:05.200
que simplesmente não parecem corretos.

00:15:06.100 --> 00:15:06.780
Eles estão aplicando

00:15:06.780 --> 00:15:07.940
a mesma lógica de similaridade

00:15:07.940 --> 00:15:09.080
que usamos para a extração de dados

00:15:09.080 --> 00:15:10.400
à segurança de todo o seu tenant.

00:15:11.040 --> 00:15:11.920
Essa mudança é permanente.

00:15:12.420 --> 00:15:13.180
Pessoas que se prendem

00:15:13.180 --> 00:15:13.900
a uma lógica rígida

00:15:13.900 --> 00:15:15.140
de se então ficarão gerenciando

00:15:15.140 --> 00:15:15.820
sistemas quebrados

00:15:15.820 --> 00:15:16.580
e equipes frustradas.

00:15:17.260 --> 00:15:17.960
Ficarão presas

00:15:17.960 --> 00:15:19.500
em um ciclo de manutenção constante,

00:15:19.620 --> 00:15:20.980
tentando remendar uma casa de vidro

00:15:20.980 --> 00:15:22.420
que nunca foi feita para este clima,

00:15:22.420 --> 00:15:23.780
a empresa agêntica começa

00:15:23.780 --> 00:15:24.880
com uma única percepção.

00:15:25.800 --> 00:15:26.680
Não precisamos controlar

00:15:26.680 --> 00:15:27.420
cada variável

00:15:27.420 --> 00:15:28.700
para obter um resultado confiável.

00:15:29.060 --> 00:15:29.620
Precisamos apenas

00:15:29.620 --> 00:15:30.380
controlar a arquitetura.

00:15:30.900 --> 00:15:32.240
Nosso trabalho é definir os limites

00:15:32.240 --> 00:15:33.340
e estabelecer as diretrizes

00:15:33.340 --> 00:15:33.960
para que os agentes

00:15:33.960 --> 00:15:35.520
possam operar dentro dessas fronteiras.

00:15:36.180 --> 00:15:36.580
Nesse mundo,

00:15:36.660 --> 00:15:37.440
sua lógica de negócio

00:15:37.440 --> 00:15:38.220
se torna elástica.

00:15:38.700 --> 00:15:39.240
Ela se expande

00:15:39.240 --> 00:15:40.400
para lidar com um novo fornecedor

00:15:40.400 --> 00:15:41.660
num formato de documento diferente

00:15:41.660 --> 00:15:42.380
sem que um desenvolvedor

00:15:42.380 --> 00:15:43.040
precise reescrever

00:15:43.040 --> 00:15:43.920
uma única linha de código.

00:15:44.460 --> 00:15:45.740
Essa é a verdadeira promessa, louco.

00:15:46.100 --> 00:15:47.080
É a capacidade de se mover

00:15:47.080 --> 00:15:48.060
na velocidade do pensamento

00:15:48.060 --> 00:15:49.280
em vez da velocidade da sintaxe.

00:15:49.280 --> 00:15:50.340
Mas para chegar lá,

00:15:50.420 --> 00:15:51.220
você precisa começar hoje.

00:15:51.600 --> 00:15:52.860
Pare de construir para o mundo perfeito

00:15:52.860 --> 00:15:54.080
e comece a construir para o mundo caótico

00:15:54.080 --> 00:15:54.940
em que realmente vivemos.

00:15:55.640 --> 00:15:56.520
Você precisa aceitar dúvida.

00:15:57.640 --> 00:15:58.500
Desafio de implementação.

00:15:58.980 --> 00:16:00.000
Que é a sua lição de casa para cima?

00:16:00.420 --> 00:16:01.160
Quero que você encontre

00:16:01.160 --> 00:16:02.420
seu fluxo com a maior taxa de falhas.

00:16:02.780 --> 00:16:03.900
Não escolha o mais complexo,

00:16:03.940 --> 00:16:04.900
mas encontre aquele que trava

00:16:04.900 --> 00:16:05.640
com mais frequência

00:16:05.640 --> 00:16:06.500
devido a dados ruins.

00:16:06.960 --> 00:16:08.040
O objetivo não é corrigir os dados.

00:16:08.360 --> 00:16:09.160
Você não pode controlar

00:16:09.160 --> 00:16:09.920
o que seus usuários

00:16:09.920 --> 00:16:10.780
ou fornecedores

00:16:10.780 --> 00:16:11.620
decidem enviar para você.

00:16:11.940 --> 00:16:13.320
Em vez de lutar contra essa realidade,

00:16:13.500 --> 00:16:14.040
quero que adicione

00:16:14.040 --> 00:16:14.920
um limite de confiança.

00:16:15.480 --> 00:16:16.320
Vá ao seu AI Builder

00:16:16.320 --> 00:16:17.200
a sua ação de LLM

00:16:17.200 --> 00:16:18.920
e expõe-se a pontuação de probabilidade.

00:16:19.360 --> 00:16:20.200
Crie uma condição simples.

00:16:20.580 --> 00:16:21.720
Se a pontuação de confiança

00:16:21.720 --> 00:16:23.000
for inferior a 85%,

00:16:23.000 --> 00:16:24.060
não deixe o fluxo travar.

00:16:24.600 --> 00:16:25.700
Encaminhe esse caso específico

00:16:25.700 --> 00:16:26.600
para uma pasta de revisão

00:16:26.600 --> 00:16:27.500
ou uma lista do SharePoint

00:16:27.500 --> 00:16:28.340
para uma verificação manual.

00:16:28.720 --> 00:16:29.460
Observe o que acontece

00:16:29.460 --> 00:16:30.320
com sua taxa de sucesso.

00:16:30.660 --> 00:16:31.460
Você verá o estresse

00:16:31.460 --> 00:16:32.260
sair do seu sistema

00:16:32.260 --> 00:16:33.080
no momento em que parar

00:16:33.080 --> 00:16:34.200
de fingir que cada entrada

00:16:34.200 --> 00:16:34.940
será perfeita.

00:16:35.380 --> 00:16:36.460
Se essa mudança de pensamento

00:16:36.460 --> 00:16:37.300
alterou sua abordagem,

00:16:37.440 --> 00:16:38.540
siga-me, Mirko Peters, no LinkedIn.

00:16:39.080 --> 00:16:40.140
Estou constantemente compartilhando

00:16:40.140 --> 00:16:40.900
análises profundas

00:16:40.900 --> 00:16:41.920
sobre esses padrões arquiteturais.

00:16:42.320 --> 00:16:43.260
Compartilhe isso com sua equipe,

00:16:43.340 --> 00:16:44.180
especialmente se seus fluxos

00:16:44.180 --> 00:16:44.940
estiverem quebrando a mão.

00:16:45.400 --> 00:16:46.260
Precisamos parar de construir

00:16:46.260 --> 00:16:46.960
com vidro e começar

00:16:46.960 --> 00:16:47.860
a construir com propósito.

00:16:48.100 --> 00:16:48.760
Essa é a técnica

00:16:48.760 --> 00:16:49.540
e ela reduz seu tempo

00:16:49.540 --> 00:16:50.560
de inatividade pela metade

00:16:50.560 --> 00:16:51.640
assim que você começa a praticá-la.

00:16:52.040 --> 00:16:53.200
Se você quer a versão avançada

00:16:53.200 --> 00:16:54.100
que os profissionais usam,

00:16:54.220 --> 00:16:55.360
confira este próximo vídeo

00:16:55.360 --> 00:16:57.160
e inscreva-se para mais tutoriais.

00:16:57.680 --> 00:16:58.160
Pare de lutar

00:16:58.160 --> 00:16:59.220
contra a realidade confusa

00:16:59.220 --> 00:16:59.720
dos seus dados

00:16:59.720 --> 00:17:00.520
e comece a projetar

00:17:00.520 --> 00:17:01.200
pensando neles.

00:17:01.780 --> 00:17:03.160
Ao usar pontuações de confiança,

00:17:03.240 --> 00:17:04.540
você transforma fluxos frágeis

00:17:04.540 --> 00:17:05.500
em sistemas resilientes

00:17:05.500 --> 00:17:06.460
que realmente funcionam.

00:17:06.660 --> 00:17:07.540
Mas aqui está o ponto principal.

00:17:07.940 --> 00:17:08.740
O modelo só funciona

00:17:08.740 --> 00:17:09.720
se você o construir corretamente.

00:17:10.120 --> 00:17:10.920
Se você quer ver exatamente

00:17:10.920 --> 00:17:11.820
como configurar isso

00:17:11.820 --> 00:17:12.560
no Copilot Studio,

00:17:12.560 --> 00:17:13.900
assista a este próximo vídeo

00:17:13.900 --> 00:17:14.600
agora mesmo.

00:17:15.280 --> 00:17:15.940
E se isso mudou

00:17:15.940 --> 00:17:17.100
sua forma de pensar sobre a

00:17:17.100 --> 00:17:17.880
siga-me no LinkedIn

00:17:17.880 --> 00:17:18.720
ou inscreva-se no

00:17:18.720 --> 00:17:19.640
Master the New Model.