Drie dagen Power Platform Community Conference in Las Vegas leveren vooral een lange lijst aankondigingen op. Copilot Studio kreeg een nieuwe harness, Power Pages bouwt een site vanuit een prompt en Microsoft liet Autopilot zien, een agent die doorwerkt als jij je laptop dichtklapt. Na afloop hebben we de slides van onze sessies nog eens naast elkaar gelegd, met de vraag die klanten ons straks ook gaan stellen: wat betekent dit voor een organisatie die op Power Platform bouwt?

Kort gezegd maakt bijna alles wat we zagen het bouwen sneller. Het lastige deel van een project zit daar alleen steeds minder.

Bouwen kost steeds minder, eigenaarschap steeds meer

Het Power Pages-team opende met een plaatje dat veel organisaties zullen herkennen: zes digitale voordeuren naar dezelfde bedrijfsdata. Een partnerportaal in .NET, een aanvraagformulier op PHP, een leveranciersportaal in Java, elk met een eigen manier van inloggen. Zes securitymodellen om gelijk te trekken, zes stacks om te patchen en geen enkele plek om ze centraal te beheren. Zij noemen dat de maintenance tax. Een site bouwen is makkelijk, onderhouden doe je voor altijd.

Duke DeVan van RSM kwam in zijn sessie Is Low-Code still Low-Code? via een andere route op hetzelfde uit. Code schrijven gaat sneller dan ooit, voor makers en developers. Maar iemand moet het daarna nog steeds ondersteunen, beveiligen en bijwerken. Zijn advies aan leidinggevenden was: begroot het eigenaarschap voor jaar twee, niet alleen de bouw.

Dat herkennen we. Een project heeft een budget voor de bouw en een opleverdatum. Wat daarna komt, is vaak niemands budget. Zolang bouwen duur was, viel dat minder op. Nu AI een eerste versie veel sneller neerzet, draait die verhouding om. Microsoft bouwt in Power Pages zelfs een aparte functie om de eigenaar van een site over te zetten, zodat een portaal niet verweesd raakt als iemand vertrekt. Blijkbaar gaat dat vaak genoeg mis.

Het platform bepaalt wat low-code is

De vraag in de titel van DeVans sessie is terecht. Als een developer met Claude Code of GitHub Copilot een React-app bouwt, is dat dan nog low-code? DeVan liet het menu zien: canvas apps, model-driven apps, code apps, Copilot Studio-agents en Azure-services. Geen van die opties zegt iets over hoeveel code erbij komt kijken.

Volgens hem maakt het platform iets low-code. Hij toetst vier dingen.

Hosting: draait het in een omgeving die een beheerder al beheert? Governance: gelden datapolicies, securityrollen en audit? Data: staat de data in Dataverse of achter connectoren, en niet in een losse database? Lifecycle: gaat het via solutions en pipelines naar productie?

Vier keer ja, dan noemt hij het low-code, hoeveel code er ook in zit. Dat geldt dus ook voor een React code app, al moet iemand die code dan wel kunnen onderhouden. In zijn live demo bouwde hij dezelfde app twee keer, als canvas app en als code app, op dezelfde Dataverse-tabel. Zelfde app, alleen meer code om zelf te onderhouden.

Voor de keuze gebruikt hij een ladder. Begin met een model-driven of canvas app op Dataverse. Voeg een PCF-control of code app toe waar het platform ophoudt. Zet een agent in waar een mens anders zijn ervaring zou gebruiken. Wijk pas uit naar Azure als het werk echt van het platform af moet. En klim alleen een trede hoger als de trede eronder niet meer volstaat.

Die ladder past bij hoe wij werken. We pakken zelf steeds meer pro-code op. Low-code blijft de basis. Code gebruiken we waar het platform tekortschiet, en om goed te kunnen beoordelen wat AI voor ons schrijft. De keuze tussen een canvas app en een code app wordt zo vooral een vraag over eigenaarschap: kan een maker het volgende maand nog aanpassen, of ligt het onderhoud bij een developer met een repo?

AI alleen waar oordeel nodig is

Het Copilot Acceleration Team van Microsoft liet zien hoe automatisering in Copilot Studio verschuift: van cloud flows in Power Automate, via agent flows, naar workflows waarin een agent of AI-stap een gewone bouwsteen is, naast een conditie of een goedkeuring.

De demo ging over Zava, een fictieve verzekeraar na een bosbrand. Na zo'n ramp komen de claims tegelijk binnen en ziet elke inventarislijst er anders uit. Het team knipte het proces in stappen en gaf elke stap een label: volgt regels, vraagt oordeel, of de schadebehandelaar beslist. Dekking controleren en afschrijving berekenen volgen vaste regels. Een rommelige lijst lezen met regels als "TV LG 47" en een vergelijkbaar vervangend product zoeken, vragen oordeel. Dat deden agents. Items met lage zekerheid, specialistische spullen of een waarde vanaf 2.500 dollar gingen naar de schadebehandelaar, die goedkeurde, afkeurde of aanhield. Alles kwam met audittrail in Dataverse terecht.

Hun samenvatting: versnel het bewijs, behoud het oordeel. Agents en workflows zijn volgens hen ook geen keuze tussen het een of het ander. De vraag is welk deel van het proces vast moet liggen en welk deel mag meebewegen.

Dat is een bruikbare werkwijze, ook buiten Copilot Studio. Loop het proces stap voor stap door en stel per stap één vraag: moet dit elke keer precies hetzelfde gaan? Zo ja, dan hoort het in een vaste flow, testbaar en voorspelbaar. Alleen waar het antwoord nee is, heb je een model nodig. En bij elke stap waar geld, aansprakelijkheid of een klant aan hangt, hoort een mens die beslist.

Vertrouwen en kosten bepalen of AI blijft

In de sessie over Autopilot, de nieuwe persoonlijke agent in Copilot, stond een voorspelling van Gartner op de slide: ruim 40% van de agentic AI-projecten wordt voor eind 2027 stopgezet. Gartner noemt oplopende kosten, onduidelijke businesswaarde en onvoldoende risicobeheersing als oorzaken. Het Autopilot-team trok de conclusie dat vertrouwen bepaalt wie slaagt.

Autopilot werk je in als een collega, met een eigen mailbox, agenda en geheugen, en het blijft werken als jij er niet bent. Juist daarom ging een groot deel van de sessie over governance. Elke Autopilot is een eigen Entra Agent User, eigendom van één persoon in één tenant. Acties krijgen een risiconiveau, een goedkeuring geldt alleen voor het exacte verzoek en elke actie wordt gelogd. Beheerders leggen met beleid vast hoeveel Copilot Credits er verbruikt mogen worden.

Ook in Copilot Studio tikt de meter door. Agents op de nieuwe GitHub Copilot harness verbruiken Copilot Credits tijdens het bouwen én tijdens het draaien. Het Autopilot-team organiseerde zelfs een aparte roundtable over hoe je de waarde van een altijd actieve agent weegt tegen kosten en governance, als tijdwinst maar een deel van het verhaal is. Dat is geen vraag die je pas na de livegang wilt beantwoorden.

Het Power Pages-team keek er vanuit security naar. In oktober ging PHP2Shell rond: een lek dat ruim tien jaar in PHP zat, tot onderzoekers het met AI vonden en er een werkende exploit van maakten. Ook in Nederland gingen publieke sites tijdelijk offline. "AI doesn't get tired. Every stack you run is in the queue", stond op hun slide. Als AI oude lekken goedkoper uitbuitbaar maakt, wordt elke losse webstack die je zelf onderhoudt een groter risico. Eén beheerd platform met één securitymodel, waar elke fix elke site beschermt, is daarmee ook een businessargument geworden.

Wat we anders doen in projecten

Veel hiervan is niet nieuw. Governance, ALM en beheer maakten altijd al het verschil tussen een app die blijft en een app die langzaam verwatert. Wat verandert is de verhouding. Als de bouw bijna niets meer kost, is de rest ineens het grootste deel van de business case.

Voor onze eigen projecten nemen we er een paar vuistregels uit mee:

Bij de start vragen we wie de oplossing in jaar twee beheert, en dat nemen we mee in de begroting. We beginnen op het platform en voegen pas code toe waar het platform ophoudt. Voordat er een agent wordt gebouwd, bepalen we per processtap of die vast moet liggen of oordeel vraagt. We maken het verbruik van Copilot Credits vooraf inzichtelijk, ook voor de runtime.

Microsoft maakt bouwen elk jaar sneller. Wie het daarna draaiende houdt, beslist geen enkele tool voor je.