Regie in een organisatie die AI inzet

De eerste is AI brede toegang geven. Een agent krijgt toegang tot je systemen en bedenkt zelf hoe hij zijn doel bereikt. Dat haalt de starheid van oude software weg, maar vervangt afhankelijkheid van software door afhankelijkheid van AI: niemand kan meer zeggen wat hij mocht, of waarom hij deed wat hij deed.

De tweede is overal een mens voor zetten. Elk resultaat wacht tot iemand op "akkoord" klikt. Dat voelt veilig, maar als een agent duizend routinestappen per dag doet, zit die mens alleen op papier in de lus. Niemand kan echt instaan voor duizend klikken.

Geen van beide geeft je regie. Regie komt van vooraf en uitdrukkelijk bepalen wat AI mag, en achteraf kunnen zien wat hij deed.

In CaseFlows wordt werk georganiseerd rond cases, en iedereen doet mee via een caserol: een omschreven verantwoordelijkheid met de informatie en handelingen die erbij horen in de fase waarin de case staat. Een AI-agent in een caseflow werkt op dezelfde manier. Hij krijgt geen toegang tot je organisatie; hij krijgt één rol, in één case, op één moment.

Dit gaat over agents die werk doen in je lopende cases. De code-assistent die je platform bouwt, werkt op de ontwikkelomgeving, onder andere regels; waar dat staat, lees je onderaan deze pagina.

Wat de agent buiten die rol vraagt, wordt geweigerd, en de weigering wordt vastgelegd. De grens is geen richtlijn die de agent gevraagd wordt te respecteren. Het platform waarop de agent draait dwingt hem af.

Harde grenzen blijven hard. Wat je als regel vastlegt, zoals een veld dat voor een rol verborgen blijft of een bedrag waarboven iemand anders moet goedkeuren, wordt afgedwongen, voor een mens en voor een agent. De wet, privacyregels en je eigen mandaten vertalen naar die regels blijft het werk van je organisatie; CaseFlows dwingt af wat je vastlegt. Binnen die grenzen is er ruimte om te handelen, en die ruimte is zichtbaar.

We beginnen daarom niet bij “een mens in de lus”, maar bij aanspreekbaarheid. Een agent mag zelfstandig handelen als drie dingen expliciet zijn: welke verantwoordelijkheid hij heeft gekregen, binnen welke grenzen, en wie in je organisatie instaat voor zijn inzet op die plek.

Soms moet een mens elk resultaat nakijken: een beslissing met grote gevolgen voor iemand, of een stap waar de agent vaak blijkt mis te zitten. Dan zet je die controle in de caseflow, als een eigen stap. Elders doet de agent zijn werk, en kijk je naar wat hij deed, niet naar elke klik.

Voor mensen geldt hetzelfde. Een professional die in een uitzonderlijke situatie van de gebruikelijke route afwijkt, kan dat beter zichtbaar doen, in het systeem, dan stil erbuiten. Ruimte voor oordeel en aanspreekbaarheid gaan samen.

Een log die zegt “gebruiker X wijzigde veld Y” vertelt maar een deel van het verhaal. Om een beslissing een jaar later te begrijpen, moet je weten vanuit welke verantwoordelijkheid hij werd genomen. Bij elke handeling legt CaseFlows vast:

• wie handelde, en vanuit welke caserol, een mens of een agent;
• in welke case, en in welke fase die op dat moment stond;
• wat er veranderde, niet alleen dát er iets veranderde;
• onder welke versie van de caseflow de case liep, zodat je hem beoordeelt naar de regels van toen, niet van nu;
• wat werd geweigerd: wat iemand probeerde dat zijn rol niet toestond.

Bij AI-aanroepen legt CaseFlows ook vast welk model antwoordde en op wiens sleutel het liep. Het spoor is alleen-toevoegen: de database weigert wijzigingen en verwijderingen, en elke regel is aan de vorige geketend, zodat geknoei zichtbaar zou worden. De uitvoering vertelt wat er gebeurde; de specificatie vertelt binnen welke afspraken dat gebeurde.

CaseFlows draait op de AI-sleutels van je eigen organisatie, niet op die van ons. Het modelgebruik loopt op jouw contract en onder jouw voorwaarden, en je ziet wat het kost.

Je kiest ook waar de intelligentie vandaan komt: een groot AI-platform, een aanbieder die modellen in Europa draait, of een model op je eigen infrastructuur. CaseFlows sluit op alle drie aan. Het model zit achter een koppeling van je platform, niet in je caseflows, dus je kunt werk naar een andere aanbieder verplaatsen zonder het werk opnieuw te ontwerpen.

Je kiest niet één keer voor AI. Je houdt het vermogen om te blijven kiezen.

AI is het sterkst waar proberen goedkoop is: een proces beschrijven, een eerste versie bouwen, die testen met testcases. Daar zet CaseFlows het zoveel mogelijk in. Een business expert beschrijft het werk aan een coach, en een code-assistent bouwt het.

Wat naar productie gaat, is geen AI die improviseert, maar een specificatie die je proceseigenaar goedkeurde, uitgevoerd zoals hij geschreven is. AI doet daar alleen een stap waar jij hem die gaf, in een rol, met grenzen. Maximaal AI in development. Minimaal AI in productie.

Dat betekent niet dat AI in productie weinig doet. Een agent kan daar een groot deel van het werk op zich nemen, zolang hij dat doet in een rol die jij hebt omschreven. Wat we minimaliseren is niet AI, maar AI die improviseert waar niemand heeft besloten dat dat mocht.

Het spoor is er niet alleen voor als er iets misgaat. Loopt een agent in een bepaalde fase vaak vast, of vraagt hij steeds om hulp, dan zie je dat. Misschien mist hij context, misschien is zijn rol te smal, of misschien is dit een beslissing die bij een mens hoort.

Mensen die met de agent werken kunnen dat melden vanuit de case, met de context erbij. Dat wordt een voorstel om de caseflow te veranderen, beproefd op de ontwikkelomgeving voordat er in productie iets verandert. Aanspreekbaarheid wordt dan een bron van verbetering, niet alleen van controle.

AI doet steeds vaker mee aan beslissingen met echte gevolgen voor mensen: een afgewezen aanvraag, een aanbod, een selectie. Uitleggen wat het systeem deed is dan niet altijd genoeg. Iemand moet de uitkomst kunnen aanvechten.

Daarvoor moet je weten wie verantwoordelijk is voor de beslissing, en kunnen reconstrueren onder welke omstandigheden hij tot stand kwam. “De AI besliste” is geen antwoord. Een model kan adviseren, een agent kan handelen, een service kan rekenen, maar in CaseFlows blijft zichtbaar welke rol, en dus welke organisatie, instaat voor het gebruik ervan.

Draait vandaag

• Agents en skills die een stap in een caseflow doen, op de eigen AI-sleutel van je organisatie.
• Caserollen waarvan de server de grenzen per fase afdwingt, met weigeringen vastgelegd, ook voor agents.
• Een spoor per handeling met de rol, de case, wat er veranderde en de caseflow-versie, alleen-toevoegen en geketend, zodat wijzigingen zichtbaar zouden worden.
• Bij AI-aanroepen: welk model antwoordde, en op wiens sleutel.
• Je eigen sleutels, en een keuze van aanbieder: een groot platform, een aanbieder die de gangbare API spreekt, of een model dat je zelf draait.

Waar we naartoe gaan

• Per caserol kiezen welk model gebruikt mag worden, bijvoorbeeld “alleen een model op onze eigen infrastructuur” voor de gevoeligste rol. Vandaag maak je die keuze per platform.
• De code-assistent die je platform bouwt onder dezelfde rolgrenzen als agents in je caseflows. Vandaag werkt hij nog met platformbrede rechten, op de ontwikkelomgeving.