WEBVTT 00:00:00.000 --> 00:00:03.920 Je low-code automatiseringen lopen vast omdat ze TE-accent slim voor hun eigen best wil zijn. 00:00:04.120 --> 00:00:09.860 Starre asdant logica is een doodvolnis wanneer je te maken krijgt met slordige data uit de echte wereld die je systemen dagelijks laat crashen. 00:00:10.020 --> 00:00:13.260 De aanname dat data schoon is, is de erfzonde van low-code ontwerp. 00:00:13.340 --> 00:00:17.800 We hebben onze hele wereld gebouwd op het asdant model, maar dat model vereist absolute zekerheid om te functioneren. 00:00:18.040 --> 00:00:22.140 Data uit de echte wereld is niet zeker. Er staan typfouten in. Er ontbreekt context. 00:00:22.380 --> 00:00:24.540 Het is een chaotische stroom van menselijke fouten. 00:00:24.720 --> 00:00:29.460 Wanneer een deterministisch systeem een afwijking van 1% tegenkomt, buigt het niet mee en past het zich zeker niet aan. 00:00:29.460 --> 00:00:35.540 Het breekt simpelweg. Dit creëert de valstrik van kwetsbaarheid, waarbij je automatisering slecht zo sterk is als je schoonste datapunt. 00:00:35.700 --> 00:00:38.140 In het bedrijfsleven is dat een erg lage lat voor succes. 00:00:38.360 --> 00:00:41.720 Maar het probleem is niet de data, het is het model dat we gebruiken om deze te verwerken. 00:00:41.880 --> 00:00:43.180 De dood van het determinisme. 00:00:43.760 --> 00:00:47.040 Deterministische logica is een reliquie uit het tijdperk van gestructureerde data. 00:00:47.260 --> 00:00:52.960 Het werkte toen alles in een SQL-tabel stond en het werkte toen we mensen dwongen in vooraf gedefinieerde hokjes te passen. 00:00:53.120 --> 00:00:54.260 Maar die wereld is voorbij. 00:00:54.260 --> 00:01:00.240 Vandaag de dag is 80% van bedrijfsdata ongestructureerd, wat betekent dat het in e-mails, chats en spraakopnames leeft. 00:01:00.600 --> 00:01:06.340 Traditionele Power Automate flows behandelen appels en 4PPL3S als twee verschillende universums. 00:01:06.580 --> 00:01:09.540 Voor een binair systeem zijn dit totaal niet gerelateerde reeksen. 00:01:09.720 --> 00:01:15.100 We hebben een breekpunt bereikt waarop de kosten van handmatige datacorrectie nu de waarde van de automatisering zelf overstijgen. 00:01:15.100 --> 00:01:20.800 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. 00:01:20.940 --> 00:01:22.500 Je hebt het werk alleen maar verplaatst. 00:01:22.680 --> 00:01:26.380 AII is niet zomaar een glimmende nieuwe functie die we aan de zijkant van het Power Platform plakken. 00:01:26.540 --> 00:01:30.240 Het is een fundamentele verschuiving van exacte overeenkomst naar gelijkenis. 00:01:30.420 --> 00:01:32.280 Het oude model vraagt, is dit A? 00:01:32.440 --> 00:01:34.700 Het nieuwe model vraagt, hoeveel lijkt dit op A? 00:01:34.880 --> 00:01:36.980 Denk eens aan hoe jij door je inbox navigeert. 00:01:37.160 --> 00:01:39.540 Je draait geen regex in je hoofd om een factuur te vinden. 00:01:39.760 --> 00:01:40.780 Je zoekt naar patronen. 00:01:40.940 --> 00:01:41.880 Je zoekt naar context. 00:01:41.880 --> 00:01:47.660 Je herkent dat INV202 en factuurnummer 202 hetzelfde zijn, zelfs als de tekens niet overeenkomen. 00:01:48.180 --> 00:01:49.640 Deterministische systemen kunnen dat niet. 00:01:49.840 --> 00:01:51.020 Ze zijn blind voor intentie. 00:01:51.220 --> 00:01:52.340 Ze zien alleen de syntax. 00:01:52.580 --> 00:01:56.680 En terwijl we naar 2026 toewerken, wordt syntax minder belangrijk dan semantiek. 00:01:56.840 --> 00:02:03.060 We zien een enorme explosie in data-volumen door IoT-sensoren, real-time streams en door LLM-gegenereerde samenvattingen. 00:02:03.200 --> 00:02:08.060 Als je dat volume probeert te beheren met hardcoded, als dan vertakkingen, wordt je logica een labyrinth. 00:02:08.060 --> 00:02:13.940 Je eindigt met flows met 50 geneste voorwaarden en ze zullen alsnog stuk lopen zodra een leverancier hun e-mailhandtekening wijzigt. 00:02:14.120 --> 00:02:18.240 Het als dan model gaat uit van een perfecte wereld waarin de input altijd overeenkomt met het schema. 00:02:18.500 --> 00:02:20.780 Maar in werkelijkheid is het tegenovergestelde waar. 00:02:20.980 --> 00:02:22.300 De data is de variabele. 00:02:22.460 --> 00:02:27.100 De logica zou de constante moeten zijn, maar onze logica is de rigide gebleken om de confrontatie met de werkelijkheid te overleven. 00:02:27.260 --> 00:02:29.940 We hebben glazen huizen gebouwd in een wereld waar het constant hagelt. 00:02:30.160 --> 00:02:32.640 En we vragen ons vervolgens af waarom de vloer vol scherven ligt. 00:02:32.840 --> 00:02:36.720 De verschuiving naar probabilistisch ontwerp draait om bouwen met rubber in plaats van glas. 00:02:36.720 --> 00:02:41.700 Het gaat om het creëren van systemen die de impact van een typfout kunnen opvangen zonder te verbreizelen. 00:02:41.880 --> 00:02:48.440 We stappen af van het idee dat een systeem 100% goed of 100% fout moet zijn, want in de echte wereld is niets 100%. 00:02:48.440 --> 00:02:51.800 We liegen onszelf al tientallen jaren voor over de kwaliteit van onze data. 00:02:52.060 --> 00:02:58.020 We bouwden cleanrooms voor onze logica en waren vervolgens verbaasd toen de vervuilde data van het sales team leidde tot een systeemfout. 00:02:58.220 --> 00:03:00.660 De dood van het determinisme is de dood van die leugen. 00:03:00.860 --> 00:03:04.720 Het is de erkenning dat we de input niet kunnen beheersen, dus moeten we de verwerking moderniseren. 00:03:04.720 --> 00:03:11.380 We treden het tijdperk van de benaderende onderneming binnen, waarin we accepteren dat, bijna goed, eigenlijk beter is dan, precies fout. 00:03:11.600 --> 00:03:19.100 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. 00:03:19.300 --> 00:03:22.540 Dit is niet alleen een technische verandering, het is een psychologische. 00:03:22.720 --> 00:03:26.680 Je moet wennen aan het idee dat je systeem redelijk zeker kan zijn over een stuk data. 00:03:27.040 --> 00:03:32.420 Je moet leren ontwerpen voor twijfel, want twijfel is de enige eerlijke manier om ongestructureerde informatie te verwerken. 00:03:32.420 --> 00:03:39.320 Deze verschuiving vereist dat we van binaire triggers overstappen op iets veel genuanceerder, de betrouwbaarheid scoren, de architectuur van onzekerheid. 00:03:39.460 --> 00:03:44.140 Als we accepteren dat het tijdperk van binaire logica voorbij is, moeten we dat vervangen door een nieuw kader. 00:03:44.300 --> 00:03:46.080 Ik noem dit het symfonieorkestmodel. 00:03:46.260 --> 00:03:50.660 In een traditionele IT-architectuur is iedereen een solist die speelt vanaf een rigide bladmuziek. 00:03:50.760 --> 00:03:53.200 Als één persoon een noot mist, stopt de hele uitvoering. 00:03:53.200 --> 00:03:57.960 Maar in een probabilistische architectuur hebben we deterministische dirigenten die probabilistische muzici aansturen. 00:03:58.120 --> 00:04:00.060 De dirigent is jouw power automate flow. 00:04:00.320 --> 00:04:03.220 Deze biedt de structuur, bepaalt het tempo en definieert de grenzen. 00:04:03.400 --> 00:04:04.820 De muzici zijn de AI-modellen. 00:04:05.060 --> 00:04:10.620 Ze zijn getalenteerd, maar expressief, en ze raken niet altijd precies dezelfde frequentie elke keer dat ze spelen. 00:04:10.800 --> 00:04:13.980 Het is niet de taak van de dirigent om de muzici te dwingen robots te zijn. 00:04:14.140 --> 00:04:18.060 Het is om naar hen te luisteren en te beslissen of het geluid dat ze maken goed genoeg is om door te gaan. 00:04:18.300 --> 00:04:21.860 Dit brengt ons bij de kernpijler van modern ontwerp, de betrouwbaarheidsscoren. 00:04:21.860 --> 00:04:25.860 Een betrouwbaarheidsscoren is een waarde van 0 tot 1 die twijfel KW antificeert. 00:04:26.000 --> 00:04:30.580 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. 00:04:30.760 --> 00:04:32.860 In de oude wereld werkten we met harde codering. 00:04:33.100 --> 00:04:36.300 Als het email-onderwerp factuur bevat, sla dan de bijlage op. 00:04:36.400 --> 00:04:39.160 In de nieuwe wereld gebruiken we routering op basis van betrouwbaarheid. 00:04:39.300 --> 00:04:42.220 We maken de interne twijfel van het model zichtbaar voor het systeem. 00:04:42.380 --> 00:04:46.860 We behandelen de AI niet langer als een zwarte doos, maar als een getuige met een bepaald geloofwaardigheidsniveau. 00:04:47.620 --> 00:04:50.100 Hier is hoe je dit daadwerkelijk bouwt in het Power Platform. 00:04:50.100 --> 00:04:54.320 Wanneer je AI Builder of Azure AI gebruikt, krijg je niet alleen de geëxtraheerde gegevens. 00:04:54.540 --> 00:04:57.800 Je krijgt een metadata laag die de waarschijnlijkheid voor elk veld onthult. 00:04:58.000 --> 00:05:03.880 Als het model een totaalbedrag van 1500 dollar extraheert, vertelt het je ook dat het voor 95% zeker is van dat getal. 00:05:04.020 --> 00:05:06.340 Als architect heb je nu drie duidelijke actiezones. 00:05:06.620 --> 00:05:08.040 Ten eerste, de groene zone. 00:05:08.300 --> 00:05:10.600 De betrouwbaarheid is 0,90 of hoger. 00:05:10.760 --> 00:05:15.100 Het risico op fouten is laag, de kosten van een vergissing zijn beheersbaar en het resultaat is dat je automatiseert. 00:05:15.260 --> 00:05:17.420 Het systeem gaat door zonder menselijke tussenkomst. 00:05:17.420 --> 00:05:18.940 Ten tweede, de gele zone. 00:05:19.160 --> 00:05:22.060 De betrouwbaarheid ligt tussen 0,60 en 0,89. 00:05:22.360 --> 00:05:24.820 Het model is redelijk zeker, maar niet volledig overtuigd. 00:05:24.960 --> 00:05:27.780 Misschien was het document een beetje wazig of was het handschrift slordig. 00:05:27.920 --> 00:05:29.360 In deze zone zet je een vlaggetje. 00:05:29.540 --> 00:05:32.480 Het systeem stuurt de gegevens naar een menselijke controleur voor een snelle check. 00:05:32.640 --> 00:05:33.840 Ten derde, de rode zone. 00:05:34.080 --> 00:05:35.940 De betrouwbaarheid is lager dan 0,60. 00:05:36.160 --> 00:05:37.320 Het model is aan het gokken. 00:05:37.520 --> 00:05:39.340 In deze zone wijs je af of escaleer je. 00:05:39.500 --> 00:05:42.200 Je laat die gegevens absoluut niet in de buurt van je productiedatabase komen. 00:05:42.440 --> 00:05:44.440 Dit is een transparante laag voor risicobeheer. 00:05:44.440 --> 00:05:47.900 Hiermee kun je je automatisering opschalen terwijl je een veiligheidsklep behoudt. 00:05:47.960 --> 00:05:49.660 Denk aan de implicaties voor governance. 00:05:49.940 --> 00:05:52.420 In een deterministisch systeem zijn fouten onzichtbaar. 00:05:52.580 --> 00:05:56.780 Een flow draait, pakt het verkeerde getal door een typfout en schrijft dat foute getal naar je erp. 00:05:56.840 --> 00:05:58.720 Je ontdekt het pas aan het einde van het kwartaal. 00:05:58.860 --> 00:06:01.340 In een probabilistisch systeem heeft de fout een kenmerk. 00:06:01.400 --> 00:06:02.820 Het systeem weet dat het moeite heeft en zegt, 00:06:02.980 --> 00:06:06.120 hé, ik heb dit verwerkt, maar mijn betrouwbaarheid was slechts 62%. 00:06:06.120 --> 00:06:08.040 Dat is een ongelooflijk krachtig signaal. 00:06:08.180 --> 00:06:09.960 Hiermee kun je een twijfel-dashboard bouwen. 00:06:10.120 --> 00:06:11.860 Je kunt precies zien waar je modellen falen. 00:06:11.860 --> 00:06:15.200 Je kunt zien welke leveranciers documenten sturen die de AI niet kan lezen 00:06:15.200 --> 00:06:17.980 en welke processtappen consistent in de gele zone belanden. 00:06:18.180 --> 00:06:20.920 Je bouwt niet zomaar een flow, je bouwt een intelligentielis. 00:06:21.080 --> 00:06:23.900 En dit is waar Azure AI en AI Builder echt uitblinken. 00:06:24.140 --> 00:06:26.360 Ze stellen deze scores op granulair niveau beschikbaar, 00:06:26.600 --> 00:06:29.740 zodat je de betrouwbaarheid voor een specifieke tabel, cel of intentie kunt zien. 00:06:29.920 --> 00:06:32.940 Je kunt zelfs PowerFX gebruiken om dynamische drempelwaarden te creëren. 00:06:33.160 --> 00:06:36.940 Misschien is voor een onkostendeclaratie van 50 dollar een betrouwbaarheid van 0,70 prima. 00:06:37.160 --> 00:06:40.860 Maar voor een inkooporder van 50.000 dollar wil je een score van 0,98. 00:06:40.860 --> 00:06:44.320 Je brengt je technische logica eindelijk in lijn met je bedrijfsrisico. 00:06:44.520 --> 00:06:48.020 We hebben elk gegevenspunt behandeld alsof het even zwaar weegt, maar dat is niet zo. 00:06:48.260 --> 00:06:53.100 Dankzij probabilistisch ontwerp kun je beslissingen met een hoog risico anders behandelen dan die met een laag risico, 00:06:53.340 --> 00:06:54.500 zelfs binnen dezelfde stroom. 00:06:54.680 --> 00:06:56.720 Je bouwt niet langer voor een perfecte wereld, 00:06:56.860 --> 00:07:00.720 maar voor een wereld waarin je precies weet hoeveel onzekerheid je bereid bent te tolereren. 00:07:00.900 --> 00:07:05.080 En zodra je de score beheerst, kun je gaan kijken naar de logica die de hiëten opvult. 00:07:05.080 --> 00:07:07.100 Fuzzy matching en semantische logica. 00:07:07.300 --> 00:07:11.380 Maar hoe gaan we daadwerkelijk om met de gegevens die in dat grijze gebied van onzekerheid vallen? 00:07:11.540 --> 00:07:14.200 We beginnen door toe te geven dat exacte matching tekort schiet. 00:07:14.360 --> 00:07:16.160 Het schiet tekort omdat het de context mist. 00:07:16.380 --> 00:07:20.080 In het oude model mislukte het opzoeken al als een leveranciersnaam slechts één puntje afweek. 00:07:20.280 --> 00:07:23.340 Bij het opzoeken gaat het niet om je intentie, maar alleen om de ASCII-waarde. 00:07:23.560 --> 00:07:25.560 Dit is waar Fuzzy matching om de hoek komt kijken. 00:07:25.800 --> 00:07:29.880 Het is een techniek die niet identieke records identificeert en koppelt door een gelijkenisscore te berekenen, 00:07:29.880 --> 00:07:32.240 en het fungeert als de brug tussen IBM en IBM. 00:07:32.880 --> 00:07:34.520 En de impact is niet louter theoretisch. 00:07:34.680 --> 00:07:39.220 Onderzoek toont aan dat het implementeren van Fuzzy matching je matchpercentages met wel 24% kan verbeteren. 00:07:39.400 --> 00:07:43.780 Dat is 24% van je data die voorheen zou zijn afgewezen of naar een mens zou zijn gestuurd voor handmatige correctie. 00:07:43.940 --> 00:07:47.200 In een omgeving met grote volumes vertegenwoordigt dat duizenden uren aan teruggewonnen tijd. 00:07:47.380 --> 00:07:48.940 Maar je moet de werking ervan wel begrijpen. 00:07:49.120 --> 00:07:50.820 Er zijn twee manieren om hierover na te denken. 00:07:51.020 --> 00:07:52.700 Ten eerste, karaktergebaseerde logica. 00:07:52.900 --> 00:07:54.600 Dit wordt vaak levenstijn afstand genoemd. 00:07:54.720 --> 00:07:57.840 Het telt het aantal bewerkingen dat nodig is om de ene reekstekens in de andere te veranderen. 00:07:57.840 --> 00:07:59.340 Het is perfect voor typfouten. 00:07:59.500 --> 00:08:04.200 Als iemand manage schrijft in plaats van management, ziet het systeem de ontbrekende E en A. 00:08:04.360 --> 00:08:07.280 Het berekent de afstand en ziet dat ze bijna identiek zijn. 00:08:07.460 --> 00:08:09.320 Ten tweede hebben we semantische logica. 00:08:09.540 --> 00:08:10.840 Dit is waar het interessant wordt. 00:08:11.120 --> 00:08:12.900 Semantische logica geeft niets om de spelling. 00:08:13.120 --> 00:08:14.440 Het kijkt naar de betekenis. 00:08:14.660 --> 00:08:19.440 Als het ene systeem customer zegt en het andere client zal een karaktergebaseerde match altijd falen. 00:08:19.560 --> 00:08:21.920 Maar een semantisch model weet dat ze hetzelfde betekenen. 00:08:22.120 --> 00:08:25.060 Dit is de verschuiving van het matchen van tekens naar het matchen van concepten. 00:08:25.060 --> 00:08:30.960 Wanneer je betrouwbaarheidsscores combineert met fasi-matching, creëer je een systeem dat de rommelige realiteit van bedrijfsdata aan kan. 00:08:31.120 --> 00:08:35.000 Je bent niet langer beperkt door starre regels die breken zodra een mens een typfout maakt. 00:08:35.160 --> 00:08:37.140 Je bouwt een systeem dat nuances begrijpt. 00:08:37.340 --> 00:08:43.300 En zo stap je over van eenvoudige automatisering naar echte digitale intelligentie door zelfcorrigerende workflows te bouwen. 00:08:43.540 --> 00:08:47.860 Zelfs met de beste fasi-matching ter wereld moeten we de realiteit onder ogen zien dat AI nog steeds hallucineert. 00:08:48.080 --> 00:08:50.280 Dat is nu eenmaal hoe de technologie op dit moment werkt. 00:08:50.280 --> 00:08:55.680 Huidige data toont aan dat zelfs de meest geavanceerde modellen hallucinatiepercentages tussen de 15 en 20 procent hebben. 00:08:55.820 --> 00:09:02.400 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. 00:09:02.600 --> 00:09:06.660 Je moet accepteren dat het bereiken van een hallucinatiepercentage van 0 procent geen trucje is. 00:09:06.840 --> 00:09:08.720 Het is een bewuste architecturale keuze. 00:09:08.960 --> 00:09:13.240 Dit is het punt waar we voorbij eenvoudige automatisering gaan en veerkrachtige, zelfcorrigerende workflows bouwen. 00:09:13.240 --> 00:09:16.740 We doen dit door een structuur te gebruiken die ik het dual-pad validation patroon noem. 00:09:16.900 --> 00:09:21.340 Het fungeert als een vangnet dat voorkomt dat de creatieve verbeeldingskracht van de AI werkelijke data verpest. 00:09:21.500 --> 00:09:24.000 Er is één fundamentele regel voor de moderne architect. 00:09:24.260 --> 00:09:26.580 Laat een large-language model nooit het rekenwerk doen. 00:09:26.880 --> 00:09:34.120 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. 00:09:34.300 --> 00:09:37.780 Ze zijn echter statistisch onbetrouwbaar als het aankomt op basisrekenkunde. 00:09:37.780 --> 00:09:43.560 Als je een AI vraagt om drie items uit een factuur te halen en het totaal te berekenen, vraag je in feite om systeemfalen. 00:09:43.760 --> 00:09:49.760 In een zelfcorrigerend ontwerp gebruik je het LLM voor het zachte redeneerwerk, zoals het halen van data uit een rommelige pdf. 00:09:50.000 --> 00:09:54.620 Zodra je die getallen hebt, voer je ze in een deterministisch systeem in om de harde beperkingen af te handelen. 00:09:54.820 --> 00:09:58.900 Je Power Automate Flow of een eenvoudige Rules Engine zou de optelsel moeten maken. 00:09:59.100 --> 00:10:02.380 Die zou de belasting moeten controleren of de valutaomzetting moeten verifiëren. 00:10:02.380 --> 00:10:09.460 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. 00:10:09.620 --> 00:10:12.460 In plaats van vast te lopen, activeert het systeem een herstelpad. 00:10:12.620 --> 00:10:16.480 Het kan een andere prompt proberen of de fout markeren voor menselijke beoordeling. 00:10:16.740 --> 00:10:20.420 Dit is het verschil tussen een flow die breekt en een flow die zichzelf daadwerkelijk herstelt. 00:10:20.620 --> 00:10:23.780 We zien dezelfde verschuiving plaatsvinden bij Robotic Process Automation. 00:10:24.160 --> 00:10:27.900 Traditionele RPA is erg kwetsbaar omdat het afhankelijk is van exacte coördinaten op een scherm. 00:10:28.080 --> 00:10:31.220 Als een knop slechts drie pixels naar links verschuift, faalt de hele bot. 00:10:31.220 --> 00:10:34.760 Self Healing RPA verandert dat door gebruik te maken van probabilistisch zicht. 00:10:34.920 --> 00:10:37.680 De bot zoekt niet langer naar een specifiek pixelcoördinaat. 00:10:37.800 --> 00:10:41.420 In plaats daarvan zoekt hij naar de knop die er uitziet als een opslagicoon bovenaan de pagina. 00:10:41.640 --> 00:10:45.280 Wanneer de interface verandert, gebruikt de bot context om zich direct aan te passen. 00:10:45.420 --> 00:10:49.480 Hij herkent een nieuwe layout, werkt zijn eigen logica bij en voltooit de taak. 00:10:49.600 --> 00:10:56.260 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. 00:10:56.500 --> 00:11:00.400 Deze verschuiving verlegt onze focus van succespercentages naar herstelpercentages. 00:11:00.400 --> 00:11:05.620 We stoppen met proberen de AI perfect te maken, wat toch onmogelijk is, en beginnen het systeem onwankelbaar te maken. 00:11:05.820 --> 00:11:09.140 Het gaat erom een controlemechanisme in te bouwen in elke transactie. 00:11:09.280 --> 00:11:12.800 Je moet de AI behandelen als een razendsnelle stagiair die snel afgeleid is. 00:11:12.980 --> 00:11:19.560 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. 00:11:19.720 --> 00:11:22.380 In dit geval is jouw deterministische code die auditor. 00:11:22.380 --> 00:11:30.040 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. 00:11:30.120 --> 00:11:33.740 Dit is hoe je AI uit de testfase haalt en naar de kern van je bedrijf brengt. 00:11:33.880 --> 00:11:37.620 Je vertrouwt niet op het model, je vertrouwt op de architectuur die je eromheen hebt gebouwd. 00:11:37.800 --> 00:11:42.400 Je creëert een vangde dat zo sterk is dat de incidentele struikeling van het model niet is als een fout telt. 00:11:42.600 --> 00:11:45.280 Het wordt gewoon een onderdeel van de zelfcorrectiecyclus. 00:11:45.280 --> 00:11:52.900 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. 00:11:53.420 --> 00:11:58.320 Dit klinkt geweldig in het lab, maar in productie is de grootste bottleneck niet de AI, maar de mens. 00:11:58.840 --> 00:12:06.560 We praten meestal over automatisering alsof het een simpele keuze is tussen mens of machine, maar de waarschijnlijkheidsverschuiving dwingt ons naar een rommelig middengebied. 00:12:06.760 --> 00:12:09.620 Industrie benchmarks laten een behoorlijk ontnuchterende waarheid zien. 00:12:09.840 --> 00:12:14.300 Ongeveer 50% van de AI workflows heeft nog steeds een expert nodig om ze te beoordelen voordat ze klaar zijn. 00:12:14.300 --> 00:12:17.520 Dit is de belangrijkste reden voor de crisis bij de overgang van pilot naar productie. 00:12:17.660 --> 00:12:21.140 Als je naar de cijfers kijkt, mislukt 88% van de AI pilots binnen een jaar. 00:12:21.360 --> 00:12:23.280 Ze falen niet omdat de technologie kapot is. 00:12:23.500 --> 00:12:27.940 Ze falen omdat de ontwerpers ervan veel te snel 100% van de taak proberen te automatiseren. 00:12:28.160 --> 00:12:33.660 Ze bouwen een systeem dat werkt op schone testdata, maar de logica breekt zodra het de weerstand van een echte afdeling tegenkomt. 00:12:33.840 --> 00:12:37.120 Wanneer je het menselijke element negeert, creëer je een verificatielast. 00:12:37.120 --> 00:12:44.360 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. 00:12:44.560 --> 00:12:47.060 Je hebt een blok aan het been gebouwd in plaats van een aanwinst. 00:12:47.400 --> 00:12:51.460 Succesvolle ontwerpen in 2026 behandelen verificatiewerk als een primaire functie. 00:12:51.640 --> 00:12:54.240 Zij zien menselijke beoordeling niet als een falen van het systeem. 00:12:54.380 --> 00:12:57.220 In plaats daarvan zien ze het als een noodzakelijk onderdeel van de architectuur. 00:12:57.440 --> 00:13:01.020 Ze verwerken de kosten van die beoordeling vanaf de eerste dag in het rendement op investering. 00:13:01.200 --> 00:13:04.120 Het geheim om dit te laten werken is gelaagde beoordelingslogica. 00:13:04.120 --> 00:13:06.720 Dit is hoe je dingen opschalt zonder je verstand te verliezen. 00:13:07.060 --> 00:13:09.420 Transacties met een hoog vertrouwen gebeuren geruisloos. 00:13:09.600 --> 00:13:13.780 Als het model 98% zeker is en de berekening klopt, gaat het systeem gewoon door. 00:13:13.960 --> 00:13:18.020 Maar gevallen met een laag vertrouwen, zoals die gele zonne waar we het over hadden, zullen een escalatie triggeren. 00:13:18.180 --> 00:13:19.920 Dit verandert de rol van de mens volledig. 00:13:20.060 --> 00:13:23.020 We bewegen ons weg van gegevensinvoer en richting gegevenscontrole. 00:13:23.220 --> 00:13:26.560 In het oude model was de mens de motor omdat zij al het type- en klikwerk deden. 00:13:26.720 --> 00:13:28.620 In het nieuwe model is de mens de regisseur. 00:13:28.860 --> 00:13:33.160 Zij behandelen de uitzonderingen en bieden de nuance die een probabilistisch model niet helemaal begrijpt. 00:13:33.160 --> 00:13:35.100 Denk eens na over hoe dit voelt voor het team. 00:13:35.300 --> 00:13:40.060 Wanneer mensen weten dat ze alleen naar de 5% van de gevallen hoeven te kijken die echt moeilijk zijn, blijven ze veel meer betrokken. 00:13:40.240 --> 00:13:41.800 Ze vervelen zich niet langer door de routine. 00:13:42.100 --> 00:13:44.620 Ze worden uitgedaagd door de complexiteit van de lastige gevallen. 00:13:44.800 --> 00:13:47.260 Maar je moet de juiste interface bouwen om dit te laten werken. 00:13:47.440 --> 00:13:50.060 Je kunt niet zomaar een e-mail sturen waarin staat dat er iets misging. 00:13:50.260 --> 00:13:52.240 Je moet een zij-aan-zijvergelijking laten zien. 00:13:52.480 --> 00:13:54.080 Laat de persoon het brondocument zien. 00:13:54.300 --> 00:13:58.500 Laat zien wat de AI heeft geëxtraheerd en markeer het exacte veld waar de betrouwbaarheidsscoren daalden. 00:13:58.500 --> 00:14:02.880 Als je wilt opschalen, moet je stoppen met doen alsof menselijke beoordeling betekent dat je automatiseringszwak is. 00:14:03.040 --> 00:14:04.800 Het is eigenlijk het tegenovergestelde. 00:14:04.980 --> 00:14:10.160 Een goed geïntegreerd mens is wat een probabilistisch systeem sterk genoeg maakt om in de echte wereld te overleven. 00:14:10.360 --> 00:14:13.260 Het is de laatste laag van je zelfcorrigerende architectuur. 00:14:13.500 --> 00:14:14.800 De agetische toekomst. 00:14:14.980 --> 00:14:17.960 We kijken naar een nieuwe horizon genaamd de agetische onderneming. 00:14:18.200 --> 00:14:21.240 Dit is het logische eindpunt voor alles wat we vandaag hebben besproken. 00:14:21.460 --> 00:14:25.800 We bewegen ons naar een wereld waarin agents niet langer slecht simpele scripts of basisstromen zijn, 00:14:25.800 --> 00:14:27.820 omdat ze volwaardige digitale werknemers worden. 00:14:27.980 --> 00:14:30.560 Het Power Platform verandert recht voor onze ogen. 00:14:30.760 --> 00:14:34.420 Het verschuift van een standaard app bouwer naar een volledig orkestratieplatform. 00:14:34.620 --> 00:14:38.240 In het oude model bouw je een specifieke app om een specifiek probleem op te lossen. 00:14:38.400 --> 00:14:42.420 Maar in het agetische model bouw je een omgeving waarin agents die problemen voor je oplossen. 00:14:42.700 --> 00:14:45.300 Deze agents volgen niet alleen een statische lijst met stappen. 00:14:45.460 --> 00:14:50.880 Ze observeren hun omgeving, evalueren hun eigen betrouwbaarheidsniveau en bepalen welke tool daadwerkelijk de juiste is om te gebruiken. 00:14:51.080 --> 00:14:54.680 Tegen 2026 zou Governance er heel anders uitzien dan twee jaar geleden. 00:14:54.680 --> 00:14:59.160 Tools zoals Purview en Sentinel bewegen zich richting probabilistische anomaliedetectie. 00:14:59.300 --> 00:15:01.660 Ze zoeken niet langer alleen naar een gelekt wachtwoord. 00:15:01.820 --> 00:15:05.500 In plaats daarvan zoeken ze naar gedragspatronen die er simpelweg niet kloppen. 00:15:05.680 --> 00:15:10.660 Ze passen dezelfde gelijkenislogica die we voor data extractie gebruiken nu toe op de beveiliging van je hele tenant. 00:15:10.940 --> 00:15:12.400 Deze verschuiving is blijvend. 00:15:12.620 --> 00:15:17.180 Mensen die vasthouden aan rigide als dan logica, blijven achter met kapotte systemen en gefrustreerde teams. 00:15:17.440 --> 00:15:22.920 Ze zitten vast in een cyclus van constant onderhoud terwijl ze een glazen huis proberen te lappen dat nooit gebouwd is voor dit weer. 00:15:22.920 --> 00:15:25.160 De agentische onderneming begint met één besef. 00:15:25.280 --> 00:15:28.780 We hoeven niet elke variabele te controleren om een betrouwbaar resultaat te krijgen. 00:15:29.000 --> 00:15:30.900 We hoeven alleen de architectuur te beheersen. 00:15:31.080 --> 00:15:35.860 Het is onze taak om de drempelwaarden en vangrails te bepalen, zodat de agents binnen die kaders kunnen werken. 00:15:36.060 --> 00:15:38.440 In deze wereld wordt je bedrijfslogica elastisch. 00:15:38.640 --> 00:15:44.080 Het rekt mee om een nieuwe leverancier of een ander documentformaat aan te kunnen, zonder dat een developer een regelcode hoeft te herschrijven. 00:15:44.280 --> 00:15:45.820 Dit is de echte belofte van low-code. 00:15:46.020 --> 00:15:49.500 Het is het vermogen om te bewegen op de snelheid van gedachten in plaats van de snelheid van syntax. 00:15:49.700 --> 00:15:51.500 Maar om daar te komen, moet je vandaag beginnen. 00:15:51.500 --> 00:15:55.520 Stop met bouwen voor een perfecte wereld en begin met bouwen voor de rommelige wereld waarin we echt leven. 00:15:55.700 --> 00:15:56.920 Je moet de twijfel omarmen. 00:15:57.600 --> 00:15:58.560 Implementatie, uitdaging. 00:15:58.820 --> 00:16:00.200 Dit is je huiswerk voor deze week. 00:16:00.360 --> 00:16:02.860 Ik wil dat je je flow met het hoogste fout percentage opzoekt. 00:16:03.040 --> 00:16:06.480 Kies niet de meest complexe, maar zoek degene die het vaakst crasht door slechte data. 00:16:06.700 --> 00:16:08.420 Het doel is niet om de data te repareren. 00:16:08.600 --> 00:16:11.800 Je kunt niet controleren wat je gebruikers of leveranciers besluiten naar je te sturen. 00:16:11.980 --> 00:16:15.280 In plaats van die realiteit te bevechten, wil ik dat je een betrouwbaarheidsstempel toevoegt. 00:16:15.500 --> 00:16:18.960 Ga naar je AI-builder of je LLM-actie en stel die waarschijnlijkheidsscoren beschikbaar. 00:16:18.960 --> 00:16:24.480 Maak een eenvoudige voorwaarde. Als de betrouwbaarheidsscoren lager is dan 85%, laat de flow dan niet crashen. 00:16:24.660 --> 00:16:28.440 Stuur dat specifieke geval naar een beoordelingsmap of een SharePoint-lijst voor handmatige controle. 00:16:28.640 --> 00:16:30.660 Kijk wat er met je succespercentage gebeurt. 00:16:30.840 --> 00:16:34.960 Je zult zien dat de druk van je systeem afneemt zodra je stopt met doen alsof elke invoer perfect zal zijn. 00:16:35.140 --> 00:16:38.900 Als deze verandering in denken je aanpak heeft veranderd, volg mij, meer copeters, dan op LinkedIn. 00:16:39.100 --> 00:16:42.260 Ik deel constant diepgaande analyses over deze architecturale patronen. 00:16:42.440 --> 00:16:45.100 Deel dit met je team, vooral als je flows nu constant stuklopen. 00:16:45.100 --> 00:16:48.280 We moeten stoppen met bouwen van glas en beginnen met bouwen vanuit visie. 00:16:48.440 --> 00:16:51.660 Dat is de techniek en het halverdje downtime zodra je het begint toe te passen. 00:16:51.860 --> 00:16:55.580 Wil je de geavanceerde versie die de professionals gebruiken? Bekijk dan deze video. 00:16:55.880 --> 00:16:57.300 Abonneer je voor meer tutorials. 00:16:57.720 --> 00:17:01.640 Stop met het bevechten van de rommelige realiteit van je data en begin eromheen te ontwerpen. 00:17:01.880 --> 00:17:06.600 Wanneer je betrouwbaarheidsscores gebruikt, verander je fragiele stromen in robuuste systemen die echt werken. 00:17:06.780 --> 00:17:10.140 Maar dit is het punt. Het model werkt alleen als je het correct opbouwt. 00:17:10.140 --> 00:17:14.960 Als je precies wilt zien hoe je dit instelt in Copilot Studio, bekijk dan nu deze volgende video. 00:17:15.220 --> 00:17:20.040 En als dit je kijk op AI heeft veranderd, volg me dan op LinkedIn of abonneer je op Master Finu model.