Le tue automazioni low-code non funzionano perché sono troppo intelligenti per il loro bene. Una rigida logica if-then è una condanna a morte quando ti trovi di fronte a incongruenze di dati del mondo reale che bloccano quotidianamente i tuoi sistemi. Il presupposto che i dati siano puliti è il peccato originale della progettazione low-code. Abbiamo costruito il nostro intero mondo sul modello if-then, ma tale modello richiede una certezza assoluta per funzionare. I dati del mondo reale non sono certi. Hanno le batti tu. Manca il contesto. È un flusso caotico di errori umani. Quando un sistema deterministico raggiunge una variazione del 1% non si piega e di certo non si adatta. Semplicemente zero. Ciò crea la trappola della fragilità in cui la tua automazione è forte solo quanto il tuo punto dati più pulito. In azienda questo è un obiettivo molto basso da raggiungere per i suoi. Ma il problema non sono i dati, è il modello che utilizziamo per elaborarli.

La morte dei deterministi. La logica deterministica dell'era dei dati strutturati funzionava quando tutto si trovava in una tabella SQL e quando costringevamo gli esseri umani a rientrare in caselle predefinite. Ma quel mondo è scomparso. Oggi l'80% dei dati aziendali non è strutturato, il che significa che si trova in email, il chat e registrazioni vocali. I flussi tradizionali di Power Automate trattano le mele 4 PPL3 common, due universi diversi. Per un sistema binario sono stringhe completamente indipendenti. Abbiamo raggiunto un punto di rottura in cui il costo della pulizia manuale dei dati supera il valore dell'automazione stessa. Se devi impiegare due ore per correggere un CSV solo per far funzionare un flusso per 5 secondi, in realtà non è automatizzato nulla. È solo spostato il lavoro. L'intelligenza artificiale non è solo una nuova funzionalità brillante che stiamo aggiungendo la Power Platform.

È un passaggio fondamentale dalla corrispondenza esatta alla somiglianza. Il vecchio modello chiedeva. E a? Il nuovo modello chiede. Quanto assomiglia ad a? Pensa come navighi nella tua casera di posta. Non esegui mentalmente un'espressione regolare per trovare una fattura. Cerchi degli schemi. Cerchi il contesto. Riconosci che INV202 e la fattura numero 202 sono la stessa cosa anche se i caratteri non corrispondono. I sistemi deterministici non possono farlo. Sono ciechi all'intento. Vedono solo la sintassi. E mentre ci avviciniamo al 2026, la sintassi sta diventando meno importante della semantica. Stiamo assistendo a un'enorme esplosione del volume di dati provenienti da sensori IoT, flussi in tempo reale e ripiloghi generati da LLM. Se provi a gestire tale volume con diramazioni IFDEN codificate, la tua logica diventerà un labirinto. Ti ritroverai con flussi con 50 condizioni modificate e si interromperanno comunque nel momento in cui un fornitore modifica la firma della propria mente.

Il modello IFDEN presuppone un mondo perfetto in cui l'input corrisponderà sempre allo schema. Ma in realtà è l'opposto. I dati sono la variabile. La logica dovrebbe essere la costante, ma la nostra logica è stata troppo rigida per sopravvivere al contatto con l'alba. Abbiamo costruito case di vetro in un mondo in cui grandinava di continuo e poi ci chiedevamo perché il pavimento fosse ricoperto di schegge. Il passaggio alla progettazione probabilistica riguarda la costruzione con la gomma anziché con il... Si tratta di creare sistemi in grado di assorbire l'impatto di un errore di battitura senza rompersi. Ci stiamo allontanando dall'idea che un sistema debba essere giusto al 100%, se ho sbagliato, al 100% perché nel mondo reale nulla è al 100%. Ci siamo mentiti sulla qualità dei nostri dati per decenni. Abbiamo creato stanze pulite per la nostra logica e poi ci siamo comportati in modo sorpreso quando i dati sporchi del team di vendita hanno causato un errore di sistema.

La morte del determinismo è la morte di quella menzogna. È una missione che non possiamo controllare l'input, quindi dobbiamo modernizzare l'elaborazione. Stiamo entrando nell'era dell'impresa approssimativa in cui accettiamo che abbastanza vicino sia in realtà meglio di esattamente sbagliato. Perché un sistema è in grado di elaborare una corrispondenza del 90% infinitamente più prezioso di un sistema che rifiuta tutto tranne una corrispondenza del 100%? Non si tratta solo di un cambiamento tecnico, ma anche psicologico. Bisogna abituarsi all'idea che il sistema potrebbe essere abbastanza sicuro di un dato. Bisogna imparare a progettare tenendo conto del dubbio, perché il dubbio è l'unico modo onesto di gestire informazioni in una struttura. Questo cambiamento ci impone di passare da trigger binario a qualcosa di molto più sfumato, il punteggio di confidenza, l'architettura dell'incertezza.

Se accettiamo che l'era della logica binaria è finita, dobbiamo sostituirla con un nuovo framework. Io lo chiamo modello dell'orchestra Sinfoni. In un'architettura IT tradizionale, tutti sono solisti che suonano sullo spartito rigido e se una persona sbaglia una sola nota, l'intera esibizione si interrompe. Ma in un'architettura probabilistica abbiamo direttori deterministici che gestiscono musicisti probabilistici. Il direttore ha il tuo flusso di automazione del potere. Fornisce la struttura, imposta il tempo e definisce i confini. I musicisti sono i modelli di intelligenza artificiale. Sono talentuosi, ma sono espressivi. E non sempre raggiungono la stessa identica frequenza ogni volta che suonano. Il compito del direttore d'orchestra non è quello di costringere i musicisti a essere ero. È quello di ascoltarli e decidere se il suono che producono è abbastanza buono per continuare. Questo ci porta al pilastro fondamentale del design moderno, il punteggio di affidabilità.

Un punteggio di affidabilità è un valore da 0 a 1 che quantifica il dubbio. È il modo in cui il modello dice, penso che questa sia una corrispondenza, ed ecco quanto sono disposto a scommetterci. Nel vecchio mondo avevamo percorsi codificati. Se l'oggetto dell'email contiene una fattura, allora salva l'allegato. Nel nuovo mondo utilizziamo il routing basato sull'affidabilità. Stiamo rendendo visibile al sistema il dubbio interno del modello. Non stiamo più trattando l'intelligenza artificiale come una scatola nera, ma la stiamo trattando come un testimone con un livello specifico di credibilità. Ecco come si crea effettivamente questo in Power Platform. Quando si utilizza AI Builder o Azure AI non si ottengono solo i dati estratti. Ottieni un livello di metadati che rivela la probabilità per ogni singolo campo. Se il modello estrae un import totale di 1.500 dollari ti dice anche che è sicuro al 95% in quel numero.

Come architetto, RAI tre distinte zone di azione. Innanzitutto la zona vera. L'affidabilità è pari o superiore a 90. Il rischio di errore è basso, il costo di un errore è gestibile e il risultato è che automatizzi. Il sistema procede senza intervento umano. In secondo luogo la zona è già. L'affidabilità è compresa tra 0,60 e 0,89. Il modello è abbastanza sicuro, ma non è certo. Forse il documento era leggermente sfocato o forse la grafia era disordinata. In questa zona, contrassegni. Il sistema indirizza i dati a un revisore umano per un rapido controllo. Dezzo nuovo la zona rosa. L'affidabilità è inferiore a 0,60. Modello sta indovinando. In questa zona rifiuti o esegui l'escalation. Non permetti che quei dati si avvicinino in alcun modo al tuo database blu. Questo è un livello trasparente di gestione del rischio. Consente di scalare l'automazione mantenendo una valvola di sicurezza. Pensa alle implicazioni per la governance.

In un sistema deterministico gli errori sono silenziosi. Un flusso viene seguito, sceglie il numero sbagliato. A causa di un errore di battitura scrive quel numero sbagliato nel tuo erpi. Non lo scopri fino alla fine del trimestre. In un sistema probabilistico l'errore è una firma. Il sistema sa di avere difficoltà e ti dice «Ehi, ho elaborato questo ma la mia affidabilità era solo del 62%.» Questo è un segnale incredibilmente potente. Ti consente di creare una dashboard di 2. Puoi vedere esattamente dove i tuoi modelli falliscono. Puoi vedere quali fornitori stanno inviando documenti che l'intelligenza artificiale non riesce a leggere e vedere quali fasi del processo raggiungono costantemente la zona giusta. Non stai solo creando un flusso, stai creando un ciclo di intelligenza. Ed è qui che Azure AI e AI Builder brillano davvero. Espongono questi punteggi a livello granulare in modo che tu possa vedere l'affidabilità per una tabella, una cella o un intento specifico.

Puoi persino usare PowerFX per creare sogli di nero. Forse per un'ota spesa da 50 dollari un livello di confidenza di 0,70 va bene. Ma per un ordine di acquisto da 50.000 dollari vuoi uno 0,98. È finalmente lineando la tua logica tecnica al rischio aziendale. Abbiamo trattato ogni punto dati come se avesse lo stesso peso ma non è così. La progettazione probabilistica ti consente di trattare una decisione ad alto rischio in modo diverso da un a basso rischio anche all'interno dello stesso flusso. Non stai più costruendo per un mondo perfetto? Stai costruendo per un mondo in cui sai esattamente quanta incertezza sei disposto a tollerare? Una volta padroneggiato il punteggio puoi iniziare a esaminare la logica che colma le lacune. Corrispondenza fazzi, logica semana. Ma come gestiamo effettivamente i dati che rientrano in quella via di mezzo di incertezza? Iniziamo ammettendo che la corrispondenza esatta non funziona.

Non funziona perché manca il contesto. Nel vecchio modello, se il nome di un fornitore era fuori posto di un solo punto, la ricerca non riuscì. La ricerca non tiene conto delle tue intenzioni ma solo dei valori ASCII. È qui che entra in gioco il fuzzy matching. È una tecnica che identifica e collega record non identici calcolando un punteggio di similarità e funge da ponte tra IBM e IBM. E l'impatto non è teorico. La ricerca mostra che l'implementazione del fuzzy matching può migliorare i tassi di corrispondenza fino al 24%. Si tratta del 24% dei dati che in precedenza sarebbero stati rifiutati o inviati a un essere umano per la correzione manuale. In un ambiente ad alto volume, ciò rappresenta migliaia di ore di tempo recuperato. Ma devi comprendere la meccanica. Ci sono due modi principali per pensare a questo. Innanzitutto, la logica è basata sui carattere. Questa è spesso chiamata distanza di Levinstein.

Conta il numero di modifiche necessarie per trasformare una stringa a un altro. È perfetta per le dibattiture. Se qualcuno scrive manage invece di management, il sistema vede la E e la A mancanti, calcola la distanza e vede che sono quasi identiche. In secondo luogo, abbiamo la logica semantica. È qui che le cose si fanno interessanti. La logica semantica non si preoccupa dell'ortografia. Si preoccupa del significato. Se un sistema dice cliente e un altro dice committente, la corrispondenza, basata sui caratteri, fallirà sempre. Ma un modello semantico sa che sono la stessa cosa. Questo è il passaggio dall'abbinamento dei caratteri all'abbinamento dei concetti. Quando si combinano punteggi di affidabilità con l'abbinamento fazzi, si crea un sistema in grado di stricarsi nella caotica realtà dei dati aziendali. Non si è più limitati da rigide regole che si interrompono nel momento in cui un essere umano commette un errore di battito.

Si sta creando un sistema che comprende le sfumature. E' così che si passa dalla semplice automazione alla vera intelligenza digitale, creando flussi di lavoro autocorrettivi. Anche con il miglior abbinamento fazzi al mondo dobbiamo affrontare la realtà che l'intelligenza artificiale continua ad avere allucinazione. E' semplicemente il modo in cui funziona la tecnologia in questo modo. I dati attuali mostrano che persino i modelli più avanzati hanno tassi di allucinazioni compresi tra il 15 e il 20%. Se si stanno creando sistemi per un'azienda non si può ignorare un tasso di fallimento di 1 su 5 e non si può sicuramente uscirne semplicemente con l'ingegnere immediata. Bisogna accettare che raggiungere un tasso di allucinazioni dello 0% ne ha un trucco magico. E' una scelta architettonica deliberata. E' qui che andiamo oltre la semplice automazione e iniziamo a creare flussi di lavoro resilienti autocorrettivi.

Lo facciamo utilizzando una struttura che chiamo modello di convalido del percorso dopo. Agisce come una salvaguardia che impedisce l'immaginazione creativa dell'intelligenza artificiale di rovinare i dati effettivi. C'è una regola fondamentale per l'architetto moderno. Non lasciare mai che un grande modello linguistico faccia i calcoli. Gli LLM sono motori per il ragionamento morbido il che li rende ottimi per comprendere l'intento o trovare un dettaglio specifico in una pila di testo disordinato. Tuttavia sono statisticamente inaffidabili quando si tratta di aritmetica di base. Se chiede all'intelligenza artificiale di estrarre tre goci da una fattura e di calcolarne il totale stai sostanzialmente chiedendo al sistema di fallire. In un progetto autocorrettivo usi l'LLM per la parte di ragionamento morbido come estrarre dati da un PDF disordinato. Una volta ottenuti quei numeri li passi a un sistema deterministico per gestire i vincoli rigidi.

Il flusso di Power Automate o motore di regole di base dovrebbero essere gli elementi che eseguono l'addizione. Dovrebbero essere loro a controllare le tasse o a verificare la conversione di valuti. Se l'LLM dichiara che il totale è di 500 dollari ma i calcoli indicano che dovrebbe essere di 480 da il sistema ha rilevato un'allucinazione in tempo reale. Invece di bloccarsi il sistema attiva un percorso di ripristi. Potrebbe provare un prompt diverso o potrebbe segnalare l'errore affinché una persona lo esamini. Questa è la differenza tra un flusso che si interrompe e un flusso che si autoripara. Stiamo assistendo allo stesso cambiamento nell'automazione dei processi robotici. L'ARPA tradizionale è molto fragile perché dipende dalle coordinate esatte su uno schermo. Se un pulsante si sposta di soli 3 pixel a sinistra l'intero bot non funziona. L'arpa autoriparante cambia questa situazione utilizzando la visione probabilistica.

Il bot non cerca più una coordinata pixel specifica cerca invece il pulsante che assomiglia a un'icona di salvataggio nella parte superiore della pagina. Quando l'interfaccia cambia il bot utilizza il contesto per adattarsi al volo riconosce il nuovo layout aggiorna la propria logica e termina l'attività. Ciò crea un ciclo resiliente in cui il sistema rileva un potenziale errore e crea un ponte verso la soluzione prima ancora che un utente si renda conto che c'era un problema. Questo spostamento sposta la nostra attenzione dai tassi di successo ai tassi di... Smettiamo di cercare di rendere l'intelligenza artificiale perfetta perché è comunque impossibile e iniziamo a rendere il sistema incrollabile. Si tratta di creare un livello di controllo e bilanciamento in ogni singola transazione. Dovresti trattare l'intelligenza artificiale come uno staggista ad alta velocità che si distrae facilmente.

Gli lasci fare il lavoro pesante di leggere migliaia di email ma non gli permetti mai di firmare gli assegni senza che un revisore senior verifichi la firma. In questo caso il tuo codice deterministico è quel revisore. Separando il pensiero dal calcolo crea un sistema che gestisce la confusione del linguaggio umano mantenendo la precisione di un orologio svizzero. Ecco come sposti l'intelligenza artificiale dalla fase di testa al fulcro della tua attività. Non ti fidi del modello ti fidi dell'architettura che costruiono adesso. Crea una rete di sicurezza così solida che l'occasionale inciampo del modello non conta nemmeno come errore. Diventa solo un'altra parte del ciclo di autocorrezione. Questo sembra fantastico in laboratorio ma in produzione il collo di bottiglia più grande non è l'intelligenza artificiale e l'essere umano nella realtà del ciclo. Questo sembra fantastico in laboratorio ma in produzione il collo di bottiglia più grande non è l'intelligenza artificiale e l'essere umano.

Di solito parliamo di automazione come se fosse una semplice scelta tra un essere umano o una macchina ma lo spostamento di probabilità ci costringe a una caotica via di mezzo. I parametri di riferimento del settore mostrano una verità piuttosto procura. Circa il 50% dei flussi di lavoro di intelligenza artificiale necessita ancora di un esperto per la revisione prima di essere completata. Questo è il motivo principale per cui assistiamo a una crisi tra progetti pilota e bruzz. Se guardi i numeri l'88% dei progetti pilota di intelligenza artificiale fallisce in drone. Non falliscono perché la tecnologia è rotta. Falliscono perché le persone che li progettano cercano di automatizzare il 100% delle attività troppo presto. Hanno creato un sistema che funziona su dati di test puliti ma la logica si interrompe nel momento in cui incontra l'attrito di un reparto reale. Quando si ignora l'elemento umano si crea un onere di verifica.

Se la tua intelligenza artificiale consente di risparmiare 10 minuti di emissione dati ma ne aggiunge 50 di controllo del lavoro perché il team non si fida hai effettivamente perso produttività. Hai creato una passività anziché una risorsa. Progetti di successo nel 2026 tratteranno il lavoro di verifica come una caratteristica primaria. Non vedono la revisione umana come un fallimento del sistema. Al contrario la vedono come una parte necessaria dell'architettura. Inseriscono il costo di tale revisione e ritorno sull'investimento sin dal primo giorno. Il segreto per far funzionare tutto questo è la logica di revisione a livello. È così che si scalano le cose senza perdere la testa. Le transazioni ad alta affidabilità avvengono silenziosamente. Se il modello è sicuro al 98% e i calcoli sono corretti il sistema va avanti e basta. Ma i casi di bassa affidabilità come quella zona gialla di cui abbiamo parlato attiveranno un escalation.

Ciò cambia completamente il ruolo umano. Stiamo passando dall'immissione dati all'audit dei dati. Nel vecchio modello l'uomo era il motore perché si occupava di digitare e cliccare. Nel nuovo modello l'uomo è il governatore. Gestisce le eccezioni e fornisce le sfumature che un modello probabilistico non è in grado di comprendere appieno. Pensa come si sente il team. Quando le persone sanno di dover esaminare solo il 5% dei casi effettivamente difficili rimangono molto più coinvolte. Non si annoiano più con la routine. Sono sfidate da complessità dei casi difficili. Ma devi creare l'interfaccia giusta affinché ciò funzioni. Non puoi semplicemente inviare un email dicendo che qualcosa è andato stop. Devi mostrare un confronto affiancato. Mostra alla persona il documento di origine. Mostra cosa è estratto l'intelligenza artificiale ed evidenzia il campo esatto in cui è sceso il punteggio di affidabilità.

Se vuoi scalare devi smetterla di comportarti come se la revisione umana significasse che la tua automazione è debba. In realtà è l'opposto. Un essere umano ben integrato è ciò che rende un sistema probabilistico abbastanza forte da sopravvivere nel mondo reale. È lo strato finale della tua architettura autocorrettiva. Il futuro agentico. Stiamo guardando verso un nuovo orizzonte chiamato imprese agenti. Questo è il punto di arrivo logico di tutto ciò di cui abbiamo parlato oggi. Stiamo entrando in un mondo in cui gli agenti non sono più solo semplici script flussi di base perché stanno diventando lavoratori digitali di prima classe. Power Platform sta cambiando proprio di fronte a noi. Sta passando da un generatore di app standard a un app di orchestrazione completo. Nel vecchio modello si creava un'app specifica per risolvere un problema specifico. Ma nel modello agentico si crea un ambiente in cui gli agenti risolvono quei problemi per te.

Questi agenti non seguono semplicemente un elenco statico di passaggi. Osservano il loro ambiente e valutano i propri livelli di confidenza e decidono quale strumento è effettivamente quello giusto da utilizzare. Entro il 2026 la governance non sarà più come quella di due anni fa. Strumenti come Purview e Sentinel si stanno muovendo verso il rilevamento probabilistico delle anomalie. Non cercano più solo una password trapelata. Al contrario cercano modelli comportamentali che semplicemente non sembrano corretti. Stanno applicando la stessa logica di similarità che utilizziamo per l'estrazione dei dati e la sicurezza dell'intero tenant. Questo cambiamento è permanente. Le persone che si attendono alla rigida logica del se allora si troveranno a gestire sistemi rotti e team frustati. Rimarranno bloccati in un ciclo di manutenzione costante mentre cercano di riparare una casa di vetro che non è mai stata costruita per questo tipo di condizioni meteorologiche.

L'impresa agentica inizia con una singola consapevolezza. Non abbiamo bisogno di controllare ogni singola variabile per ottenere un risultato affidabile. Dobbiamo solo controllare l'architettura. Il nostro compito è definire le soglie e impostare i guardra in modo che gli agenti possano lavorare entro quei limiti. In questo mondo la logica aziendale diventa elastica. Si estende per gestire un nuovo fornitore o un formato di documento diverso senza che uno sviluppatore debba riscrivere una singola riga di codice. Questa è la vera promessa del low code e la capacità di muoversi è la velocità del pensiero piuttosto che la velocità della sintassi. Ma per arrivarci devi iniziare oggi. Smetti di costruire per un mondo perfetto e inizia a costruire per quello caotico in cui viviamo. Devi abbracciare il dubbio. Sfida di implementazione Ecco i compiti per la settimana. Voglio che tu trovi il tuo flusso di errore più elevato.

Non scegliere quello più complesso ma trova quello che si blocca più spesso a causa di dati errati. L'obiettivo non è corriggere i dati. Non puoi controllare cosa decidono di inviarti i tuoi utenti o i tuoi fornitori. Invece di combattere questa realtà voglio che tu aggiunga una soglia di confidenza. Vai nel tuo e-builder o nella tua azione LLM ed esponi quel punteggio di probabilità. Crea una condizione semplice. Se il punteggio di confidenza è inferiore all'85% non lasciare che il flusso si blocchi. Inserisci quel caso specifico in una cartella di revisione o in un elenco di sharepoint per un controllo manuale. Guarda cosa succede al tuo tasso dei successi. Vedrai che lo stress abbandonerà il tuo sistema nel momento in cui smetterai di fingere che ogni input sarà perfetto. Se questo cambiamento di pensiero ha cambiato il tuo approccio seguimi Mirko Peter su LinkedIn. Condivido costantemente approfondimenti su questi modelli architetturali.

Condividi con il tuo team soprattutto se i tuoi flussi stanno interrompendo in questo momento. Dobbiamo smettere di costruire con il vetro e iniziare a costruire in tempo. Questa è la tecnica a riduce della metà i tempi di inattività una volta che inizi a praticarla.

Ammetti di combattere la realtà caotica dei tuoi dati e inizia a progettare in base ad essa. Quando utilizzi i punteggi di confidenza trasformi i flussi fragili in sistemi resilienti che funzionano davvero. Ma ecco il punto. Il modello funziona solo se lo costruisci correttamente. Se vuoi vedere esattamente come impostarlo in Copilot Studio guarda subito questo prossimo video. Se questo ha cambiato il tuo modo di pensare all'intelligenza artificiale seguimi su LinkedIn o iscriviti a Master The New Model.