Je low-code automatiseringen lopen vast omdat ze TE-accent slim voor hun eigen best wil zijn. Starre asdant logica is een doodvolnis wanneer je te maken krijgt met slordige data uit de echte wereld die je systemen dagelijks laat crashen. De aanname dat data schoon is, is de erfzonde van low-code ontwerp. We hebben onze hele wereld gebouwd op het asdant model, maar dat model vereist absolute zekerheid om te functioneren. Data uit de echte wereld is niet zeker. Er staan typfouten in. Er ontbreekt context. Het is een chaotische stroom van menselijke fouten. Wanneer een deterministisch systeem een afwijking van 1% tegenkomt, buigt het niet mee en past het zich zeker niet aan. Het breekt simpelweg. Dit creëert de valstrik van kwetsbaarheid, waarbij je automatisering slecht zo sterk is als je schoonste datapunt. In het bedrijfsleven is dat een erg lage lat voor succes. Maar het probleem is niet de data, het is het model dat we gebruiken om deze te verwerken.

De dood van het determinisme. Deterministische logica is een reliquie uit het tijdperk van gestructureerde data. Het werkte toen alles in een SQL-tabel stond en het werkte toen we mensen dwongen in vooraf gedefinieerde hokjes te passen. Maar die wereld is voorbij. Vandaag de dag is 80% van bedrijfsdata ongestructureerd, wat betekent dat het in e-mails, chats en spraakopnames leeft. Traditionele Power Automate flows behandelen appels en 4PPL3S als twee verschillende universums. Voor een binair systeem zijn dit totaal niet gerelateerde reeksen. We hebben een breekpunt bereikt waarop de kosten van handmatige datacorrectie nu de waarde van de automatisering zelf overstijgen. Als je twee uur moet besteden aan het repareren van een CSV-bestand zodat een flow vijf seconden kan draaien, heb je niets echt geautomatiseerd. Je hebt het werk alleen maar verplaatst. AII is niet zomaar een glimmende nieuwe functie die we aan de zijkant van het Power Platform plakken.

Het is een fundamentele verschuiving van exacte overeenkomst naar gelijkenis. Het oude model vraagt, is dit A? Het nieuwe model vraagt, hoeveel lijkt dit op A? Denk eens aan hoe jij door je inbox navigeert. Je draait geen regex in je hoofd om een factuur te vinden. Je zoekt naar patronen. Je zoekt naar context. Je herkent dat INV202 en factuurnummer 202 hetzelfde zijn, zelfs als de tekens niet overeenkomen. Deterministische systemen kunnen dat niet. Ze zijn blind voor intentie. Ze zien alleen de syntax. En terwijl we naar 2026 toewerken, wordt syntax minder belangrijk dan semantiek. We zien een enorme explosie in data-volumen door IoT-sensoren, real-time streams en door LLM-gegenereerde samenvattingen. Als je dat volume probeert te beheren met hardcoded, als dan vertakkingen, wordt je logica een labyrinth. Je eindigt met flows met 50 geneste voorwaarden en ze zullen alsnog stuk lopen zodra een leverancier hun e-mailhandtekening wijzigt.

Het als dan model gaat uit van een perfecte wereld waarin de input altijd overeenkomt met het schema. Maar in werkelijkheid is het tegenovergestelde waar. De data is de variabele. De logica zou de constante moeten zijn, maar onze logica is de rigide gebleken om de confrontatie met de werkelijkheid te overleven. We hebben glazen huizen gebouwd in een wereld waar het constant hagelt. En we vragen ons vervolgens af waarom de vloer vol scherven ligt. De verschuiving naar probabilistisch ontwerp draait om bouwen met rubber in plaats van glas. Het gaat om het creëren van systemen die de impact van een typfout kunnen opvangen zonder te verbreizelen. We stappen af van het idee dat een systeem 100% goed of 100% fout moet zijn, want in de echte wereld is niets 100%. We liegen onszelf al tientallen jaren voor over de kwaliteit van onze data. We bouwden cleanrooms voor onze logica en waren vervolgens verbaasd toen de vervuilde data van het sales team leidde tot een systeemfout.

De dood van het determinisme is de dood van die leugen. Het is de erkenning dat we de input niet kunnen beheersen, dus moeten we de verwerking moderniseren. We treden het tijdperk van de benaderende onderneming binnen, waarin we accepteren dat, bijna goed, eigenlijk beter is dan, precies fout. Want een systeem dat een match van 90% kan verwerken is oneindig veel waardevoller dan een systeem dat alles behalve een match van 100% verwerpt. Dit is niet alleen een technische verandering, het is een psychologische. Je moet wennen aan het idee dat je systeem redelijk zeker kan zijn over een stuk data. Je moet leren ontwerpen voor twijfel, want twijfel is de enige eerlijke manier om ongestructureerde informatie te verwerken. Deze verschuiving vereist dat we van binaire triggers overstappen op iets veel genuanceerder, de betrouwbaarheid scoren, de architectuur van onzekerheid. Als we accepteren dat het tijdperk van binaire logica voorbij is, moeten we dat vervangen door een nieuw kader.

Ik noem dit het symfonieorkestmodel. In een traditionele IT-architectuur is iedereen een solist die speelt vanaf een rigide bladmuziek. Als één persoon een noot mist, stopt de hele uitvoering. Maar in een probabilistische architectuur hebben we deterministische dirigenten die probabilistische muzici aansturen. De dirigent is jouw power automate flow. Deze biedt de structuur, bepaalt het tempo en definieert de grenzen. De muzici zijn de AI-modellen. Ze zijn getalenteerd, maar expressief, en ze raken niet altijd precies dezelfde frequentie elke keer dat ze spelen. Het is niet de taak van de dirigent om de muzici te dwingen robots te zijn. Het is om naar hen te luisteren en te beslissen of het geluid dat ze maken goed genoeg is om door te gaan. Dit brengt ons bij de kernpijler van modern ontwerp, de betrouwbaarheidsscoren. Een betrouwbaarheidsscoren is een waarde van 0 tot 1 die twijfel KW antificeert.

Het is de manier van het model om te zeggen, ik denk dat dit een match is, en dit is hoeveel ik erop durf in te zetten. In de oude wereld werkten we met harde codering. Als het email-onderwerp factuur bevat, sla dan de bijlage op. In de nieuwe wereld gebruiken we routering op basis van betrouwbaarheid. We maken de interne twijfel van het model zichtbaar voor het systeem. We behandelen de AI niet langer als een zwarte doos, maar als een getuige met een bepaald geloofwaardigheidsniveau. Hier is hoe je dit daadwerkelijk bouwt in het Power Platform. Wanneer je AI Builder of Azure AI gebruikt, krijg je niet alleen de geëxtraheerde gegevens. Je krijgt een metadata laag die de waarschijnlijkheid voor elk veld onthult. Als het model een totaalbedrag van 1500 dollar extraheert, vertelt het je ook dat het voor 95% zeker is van dat getal. Als architect heb je nu drie duidelijke actiezones. Ten eerste, de groene zone.

De betrouwbaarheid is 0,90 of hoger. Het risico op fouten is laag, de kosten van een vergissing zijn beheersbaar en het resultaat is dat je automatiseert. Het systeem gaat door zonder menselijke tussenkomst. Ten tweede, de gele zone. De betrouwbaarheid ligt tussen 0,60 en 0,89. Het model is redelijk zeker, maar niet volledig overtuigd. Misschien was het document een beetje wazig of was het handschrift slordig. In deze zone zet je een vlaggetje. Het systeem stuurt de gegevens naar een menselijke controleur voor een snelle check. Ten derde, de rode zone. De betrouwbaarheid is lager dan 0,60. Het model is aan het gokken. In deze zone wijs je af of escaleer je. Je laat die gegevens absoluut niet in de buurt van je productiedatabase komen. Dit is een transparante laag voor risicobeheer. Hiermee kun je je automatisering opschalen terwijl je een veiligheidsklep behoudt. Denk aan de implicaties voor governance.

In een deterministisch systeem zijn fouten onzichtbaar. Een flow draait, pakt het verkeerde getal door een typfout en schrijft dat foute getal naar je erp. Je ontdekt het pas aan het einde van het kwartaal. In een probabilistisch systeem heeft de fout een kenmerk. Het systeem weet dat het moeite heeft en zegt, hé, ik heb dit verwerkt, maar mijn betrouwbaarheid was slechts 62%. Dat is een ongelooflijk krachtig signaal. Hiermee kun je een twijfel-dashboard bouwen. Je kunt precies zien waar je modellen falen. Je kunt zien welke leveranciers documenten sturen die de AI niet kan lezen en welke processtappen consistent in de gele zone belanden. Je bouwt niet zomaar een flow, je bouwt een intelligentielis. En dit is waar Azure AI en AI Builder echt uitblinken. Ze stellen deze scores op granulair niveau beschikbaar, zodat je de betrouwbaarheid voor een specifieke tabel, cel of intentie kunt zien.

Je kunt zelfs PowerFX gebruiken om dynamische drempelwaarden te creëren. Misschien is voor een onkostendeclaratie van 50 dollar een betrouwbaarheid van 0,70 prima. Maar voor een inkooporder van 50.000 dollar wil je een score van 0,98. Je brengt je technische logica eindelijk in lijn met je bedrijfsrisico. We hebben elk gegevenspunt behandeld alsof het even zwaar weegt, maar dat is niet zo. Dankzij probabilistisch ontwerp kun je beslissingen met een hoog risico anders behandelen dan die met een laag risico, zelfs binnen dezelfde stroom. Je bouwt niet langer voor een perfecte wereld, maar voor een wereld waarin je precies weet hoeveel onzekerheid je bereid bent te tolereren. En zodra je de score beheerst, kun je gaan kijken naar de logica die de hiëten opvult. Fuzzy matching en semantische logica. Maar hoe gaan we daadwerkelijk om met de gegevens die in dat grijze gebied van onzekerheid vallen?

We beginnen door toe te geven dat exacte matching tekort schiet. Het schiet tekort omdat het de context mist. In het oude model mislukte het opzoeken al als een leveranciersnaam slechts één puntje afweek. Bij het opzoeken gaat het niet om je intentie, maar alleen om de ASCII-waarde. Dit is waar Fuzzy matching om de hoek komt kijken. Het is een techniek die niet identieke records identificeert en koppelt door een gelijkenisscore te berekenen, en het fungeert als de brug tussen IBM en IBM. En de impact is niet louter theoretisch. Onderzoek toont aan dat het implementeren van Fuzzy matching je matchpercentages met wel 24% kan verbeteren. Dat is 24% van je data die voorheen zou zijn afgewezen of naar een mens zou zijn gestuurd voor handmatige correctie. In een omgeving met grote volumes vertegenwoordigt dat duizenden uren aan teruggewonnen tijd. Maar je moet de werking ervan wel begrijpen. Er zijn twee manieren om hierover na te denken.

Ten eerste, karaktergebaseerde logica. Dit wordt vaak levenstijn afstand genoemd. Het telt het aantal bewerkingen dat nodig is om de ene reekstekens in de andere te veranderen. Het is perfect voor typfouten. Als iemand manage schrijft in plaats van management, ziet het systeem de ontbrekende E en A. Het berekent de afstand en ziet dat ze bijna identiek zijn. Ten tweede hebben we semantische logica. Dit is waar het interessant wordt. Semantische logica geeft niets om de spelling. Het kijkt naar de betekenis. Als het ene systeem customer zegt en het andere client zal een karaktergebaseerde match altijd falen. Maar een semantisch model weet dat ze hetzelfde betekenen. Dit is de verschuiving van het matchen van tekens naar het matchen van concepten. Wanneer je betrouwbaarheidsscores combineert met fasi-matching, creëer je een systeem dat de rommelige realiteit van bedrijfsdata aan kan. Je bent niet langer beperkt door starre regels die breken zodra een mens een typfout maakt.

Je bouwt een systeem dat nuances begrijpt. En zo stap je over van eenvoudige automatisering naar echte digitale intelligentie door zelfcorrigerende workflows te bouwen. Zelfs met de beste fasi-matching ter wereld moeten we de realiteit onder ogen zien dat AI nog steeds hallucineert. Dat is nu eenmaal hoe de technologie op dit moment werkt. Huidige data toont aan dat zelfs de meest geavanceerde modellen hallucinatiepercentages tussen de 15 en 20 procent hebben. Als je systemen bouwt voor een bedrijf kun je een foutmarge van 1 op de 5 niet negeren en je kunt het probleem zeker niet oplossen door enkel aan prompt engineering te doen. Je moet accepteren dat het bereiken van een hallucinatiepercentage van 0 procent geen trucje is. Het is een bewuste architecturale keuze. Dit is het punt waar we voorbij eenvoudige automatisering gaan en veerkrachtige, zelfcorrigerende workflows bouwen. We doen dit door een structuur te gebruiken die ik het dual-pad validation patroon noem.

Het fungeert als een vangnet dat voorkomt dat de creatieve verbeeldingskracht van de AI werkelijke data verpest. Er is één fundamentele regel voor de moderne architect. Laat een large-language model nooit het rekenwerk doen. LLMs zijn motoren voor zachte logica, wat ze uitstekend maakt in het begrijpen van intentie of het vinden van een specifiek detail in een bergrommelige tekst. Ze zijn echter statistisch onbetrouwbaar als het aankomt op basisrekenkunde. Als je een AI vraagt om drie items uit een factuur te halen en het totaal te berekenen, vraag je in feite om systeemfalen. In een zelfcorrigerend ontwerp gebruik je het LLM voor het zachte redeneerwerk, zoals het halen van data uit een rommelige pdf. Zodra je die getallen hebt, voer je ze in een deterministisch systeem in om de harde beperkingen af te handelen. Je Power Automate Flow of een eenvoudige Rules Engine zou de optelsel moeten maken.

Die zou de belasting moeten controleren of de valutaomzetting moeten verifiëren. Als het LLM beweert dat het totaal 500 dollar is, maar jouw berekening laat zien dat het 480 dollar moet zijn, dan heeft het systeem een hallucinatie in realtime onderschept. In plaats van vast te lopen, activeert het systeem een herstelpad. Het kan een andere prompt proberen of de fout markeren voor menselijke beoordeling. Dit is het verschil tussen een flow die breekt en een flow die zichzelf daadwerkelijk herstelt. We zien dezelfde verschuiving plaatsvinden bij Robotic Process Automation. Traditionele RPA is erg kwetsbaar omdat het afhankelijk is van exacte coördinaten op een scherm. Als een knop slechts drie pixels naar links verschuift, faalt de hele bot. Self Healing RPA verandert dat door gebruik te maken van probabilistisch zicht. De bot zoekt niet langer naar een specifiek pixelcoördinaat. In plaats daarvan zoekt hij naar de knop die er uitziet als een opslagicoon bovenaan de pagina.

Wanneer de interface verandert, gebruikt de bot context om zich direct aan te passen. Hij herkent een nieuwe layout, werkt zijn eigen logica bij en voltooit de taak. Dit creëert een veerkrachtige lus waarin het systeem een potentiële fout ziet en een oplossing bouwt nog voordat de gebruiker doorheeft dat er een probleem was. Deze verschuiving verlegt onze focus van succespercentages naar herstelpercentages. We stoppen met proberen de AI perfect te maken, wat toch onmogelijk is, en beginnen het systeem onwankelbaar te maken. Het gaat erom een controlemechanisme in te bouwen in elke transactie. Je moet de AI behandelen als een razendsnelle stagiair die snel afgeleid is. Je laat in het zware werk doen van duizenden e-mails lezen, maar je laat ze nooit check ondertekenen zonder dat een senior auditor de handtekening verifieert. In dit geval is jouw deterministische code die auditor. Door het denken te scheiden van het rekenen, bouw je een systeem dat de rommeligheid van menselijke taal aan kan en toch de precisie van een Zwitsers horloge behoudt.

Dit is hoe je AI uit de testfase haalt en naar de kern van je bedrijf brengt. Je vertrouwt niet op het model, je vertrouwt op de architectuur die je eromheen hebt gebouwd. Je creëert een vangde dat zo sterk is dat de incidentele struikeling van het model niet is als een fout telt. Het wordt gewoon een onderdeel van de zelfcorrectiecyclus. Dit klinkt geweldig in het lab, maar in productie is de grootste bottleneck niet de AI, maar de realiteit van de mens in de lus. Dit klinkt geweldig in het lab, maar in productie is de grootste bottleneck niet de AI, maar de mens. We praten meestal over automatisering alsof het een simpele keuze is tussen mens of machine, maar de waarschijnlijkheidsverschuiving dwingt ons naar een rommelig middengebied. Industrie benchmarks laten een behoorlijk ontnuchterende waarheid zien. Ongeveer 50% van de AI workflows heeft nog steeds een expert nodig om ze te beoordelen voordat ze klaar zijn.

Dit is de belangrijkste reden voor de crisis bij de overgang van pilot naar productie. Als je naar de cijfers kijkt, mislukt 88% van de AI pilots binnen een jaar. Ze falen niet omdat de technologie kapot is. Ze falen omdat de ontwerpers ervan veel te snel 100% van de taak proberen te automatiseren. Ze bouwen een systeem dat werkt op schone testdata, maar de logica breekt zodra het de weerstand van een echte afdeling tegenkomt. Wanneer je het menselijke element negeert, creëer je een verificatielast. Als je AI 10 minuten aan gegevensinvoer bespaart, maar 50 minuten aan controlewerk toevoegt omdat het team het niet vertrouwt, ben je in feite productiviteit verloren. Je hebt een blok aan het been gebouwd in plaats van een aanwinst. Succesvolle ontwerpen in 2026 behandelen verificatiewerk als een primaire functie. Zij zien menselijke beoordeling niet als een falen van het systeem. In plaats daarvan zien ze het als een noodzakelijk onderdeel van de architectuur.

Ze verwerken de kosten van die beoordeling vanaf de eerste dag in het rendement op investering. Het geheim om dit te laten werken is gelaagde beoordelingslogica. Dit is hoe je dingen opschalt zonder je verstand te verliezen. Transacties met een hoog vertrouwen gebeuren geruisloos. Als het model 98% zeker is en de berekening klopt, gaat het systeem gewoon door. Maar gevallen met een laag vertrouwen, zoals die gele zonne waar we het over hadden, zullen een escalatie triggeren. Dit verandert de rol van de mens volledig. We bewegen ons weg van gegevensinvoer en richting gegevenscontrole. In het oude model was de mens de motor omdat zij al het type- en klikwerk deden. In het nieuwe model is de mens de regisseur. Zij behandelen de uitzonderingen en bieden de nuance die een probabilistisch model niet helemaal begrijpt. Denk eens na over hoe dit voelt voor het team. Wanneer mensen weten dat ze alleen naar de 5% van de gevallen hoeven te kijken die echt moeilijk zijn, blijven ze veel meer betrokken.

Ze vervelen zich niet langer door de routine. Ze worden uitgedaagd door de complexiteit van de lastige gevallen. Maar je moet de juiste interface bouwen om dit te laten werken. Je kunt niet zomaar een e-mail sturen waarin staat dat er iets misging. Je moet een zij-aan-zijvergelijking laten zien. Laat de persoon het brondocument zien. Laat zien wat de AI heeft geëxtraheerd en markeer het exacte veld waar de betrouwbaarheidsscoren daalden. Als je wilt opschalen, moet je stoppen met doen alsof menselijke beoordeling betekent dat je automatiseringszwak is. Het is eigenlijk het tegenovergestelde. Een goed geïntegreerd mens is wat een probabilistisch systeem sterk genoeg maakt om in de echte wereld te overleven. Het is de laatste laag van je zelfcorrigerende architectuur. De agetische toekomst. We kijken naar een nieuwe horizon genaamd de agetische onderneming. Dit is het logische eindpunt voor alles wat we vandaag hebben besproken.

We bewegen ons naar een wereld waarin agents niet langer slecht simpele scripts of basisstromen zijn, omdat ze volwaardige digitale werknemers worden. Het Power Platform verandert recht voor onze ogen. Het verschuift van een standaard app bouwer naar een volledig orkestratieplatform. In het oude model bouw je een specifieke app om een specifiek probleem op te lossen. Maar in het agetische model bouw je een omgeving waarin agents die problemen voor je oplossen. Deze agents volgen niet alleen een statische lijst met stappen. Ze observeren hun omgeving, evalueren hun eigen betrouwbaarheidsniveau en bepalen welke tool daadwerkelijk de juiste is om te gebruiken. Tegen 2026 zou Governance er heel anders uitzien dan twee jaar geleden. Tools zoals Purview en Sentinel bewegen zich richting probabilistische anomaliedetectie. Ze zoeken niet langer alleen naar een gelekt wachtwoord. In plaats daarvan zoeken ze naar gedragspatronen die er simpelweg niet kloppen.

Ze passen dezelfde gelijkenislogica die we voor data extractie gebruiken nu toe op de beveiliging van je hele tenant. Deze verschuiving is blijvend. Mensen die vasthouden aan rigide als dan logica, blijven achter met kapotte systemen en gefrustreerde teams. Ze zitten vast in een cyclus van constant onderhoud terwijl ze een glazen huis proberen te lappen dat nooit gebouwd is voor dit weer. De agentische onderneming begint met één besef. We hoeven niet elke variabele te controleren om een betrouwbaar resultaat te krijgen. We hoeven alleen de architectuur te beheersen. Het is onze taak om de drempelwaarden en vangrails te bepalen, zodat de agents binnen die kaders kunnen werken. In deze wereld wordt je bedrijfslogica elastisch. Het rekt mee om een nieuwe leverancier of een ander documentformaat aan te kunnen, zonder dat een developer een regelcode hoeft te herschrijven. Dit is de echte belofte van low-code.

Het is het vermogen om te bewegen op de snelheid van gedachten in plaats van de snelheid van syntax. Maar om daar te komen, moet je vandaag beginnen. Stop met bouwen voor een perfecte wereld en begin met bouwen voor de rommelige wereld waarin we echt leven. Je moet de twijfel omarmen. Implementatie, uitdaging. Dit is je huiswerk voor deze week. Ik wil dat je je flow met het hoogste fout percentage opzoekt. Kies niet de meest complexe, maar zoek degene die het vaakst crasht door slechte data. Het doel is niet om de data te repareren. Je kunt niet controleren wat je gebruikers of leveranciers besluiten naar je te sturen. In plaats van die realiteit te bevechten, wil ik dat je een betrouwbaarheidsstempel toevoegt. Ga naar je AI-builder of je LLM-actie en stel die waarschijnlijkheidsscoren beschikbaar. Maak een eenvoudige voorwaarde. Als de betrouwbaarheidsscoren lager is dan 85%, laat de flow dan niet crashen.

Stuur dat specifieke geval naar een beoordelingsmap of een SharePoint-lijst voor handmatige controle. Kijk wat er met je succespercentage gebeurt. Je zult zien dat de druk van je systeem afneemt zodra je stopt met doen alsof elke invoer perfect zal zijn. Als deze verandering in denken je aanpak heeft veranderd, volg mij, meer copeters, dan op LinkedIn. Ik deel constant diepgaande analyses over deze architecturale patronen. Deel dit met je team, vooral als je flows nu constant stuklopen. We moeten stoppen met bouwen van glas en beginnen met bouwen vanuit visie. Dat is de techniek en het halverdje downtime zodra je het begint toe te passen. Wil je de geavanceerde versie die de professionals gebruiken? Bekijk dan deze video. Abonneer je voor meer tutorials. Stop met het bevechten van de rommelige realiteit van je data en begin eromheen te ontwerpen. Wanneer je betrouwbaarheidsscores gebruikt, verander je fragiele stromen in robuuste systemen die echt werken.

Maar dit is het punt. Het model werkt alleen als je het correct opbouwt. Als je precies wilt zien hoe je dit instelt in Copilot Studio, bekijk dan nu deze volgende video. En als dit je kijk op AI heeft veranderd, volg me dan op LinkedIn of abonneer je op Master Finu model.