Wanneer je AI rechtstreeks aan websites en servers koppelt, lijkt één brede toegang in eerste instantie aantrekkelijk. Geef het systeem een beheeraccount of een terminal en vrijwel iedere opdracht wordt technisch mogelijk. Je hoeft niet voor iedere nieuwe toepassing een aparte functie te bouwen.
Precies daar ontstaat voor mij het grootste risico. Een systeem dat alles kan, kan ook op veel meer manieren de verkeerde actie uitvoeren. De invoer is minder goed te begrenzen, de mogelijke gevolgen zijn groter en achteraf is moeilijker vast te stellen wat precies is toegestaan.
Daarom geef ik INDY liever twintig kleine tools dan één onbeperkte toegang. Iedere tool heeft één duidelijk doel, een beperkt invoerformaat en een controleerbaar resultaat. Dat kost aan de voorkant meer ontwerpwerk, maar maakt automatisering uiteindelijk veiliger, begrijpelijker en eenvoudiger uit te breiden.
Een terminal is geen nette automatiseringsinterface
Met vrije terminaltoegang kun je bijna iedere technische taak uitvoeren. Je kunt bestanden wijzigen, services herstarten, databases benaderen en scripts starten. Voor een menselijke beheerder is die vrijheid soms noodzakelijk. Voor een geautomatiseerd systeem betekent ze vooral dat de grens tussen een bedoelde en onbedoelde handeling erg dun wordt.
Een opdracht als “los het probleem op” bevat namelijk geen exacte scope. Moet er alleen een cache worden geleegd? Is een PHP-service herladen voldoende? Mag een configuratiebestand worden aangepast? Zonder afgebakende functie moet het systeem al die beslissingen zelf invullen.
Een kleine tool maakt die ruimte bewust kleiner. “Controleer de publieke status van dit beheerde domein” accepteert bijvoorbeeld alleen een domein en eventueel een pad. De functie kan geen bestanden verwijderen, geen service herstarten en geen willekeurig commando uitvoeren. Dat is geen beperking die ik later hoop weg te werken. Het is een belangrijk onderdeel van het ontwerp.
Iedere tool is een expliciete bevoegdheid
Ik zie een tool niet alleen als technische functionaliteit, maar ook als een bevoegdheid. De naam beschrijft wat mag gebeuren. Het invoerschema bepaalt waarop dat mag gebeuren. De bevestigingsvelden leggen vast wanneer menselijke toestemming nodig is.
Een functie voor het publiceren van een WordPress-bericht krijgt daarom een bestaand bericht-ID, een exact domein en een expliciete publicatiebevestiging. Een functie voor een serverherstart vereist de actuele server-ID én de exacte servernaam. Een media-upload accepteert alleen ondersteunde afbeeldingsformaten, een lokaal bestand binnen de maximale grootte en een beheerd WordPress-domein.
Door deze regels in de tool zelf te plaatsen, zijn ze niet afhankelijk van een zorgvuldig geformuleerde prompt. De beveiligingsgrens zit in de uitvoering, niet alleen in de instructie aan het model.
Een ontbrekende functie is waardevolle informatie
Tijdens het bouwen van INDY wilde ik een gegenereerde afbeelding als uitgelichte afbeelding aan een bestaand blogartikel koppelen. De koppeling kon op dat moment wel berichten aanmaken en publiceren, maar nog geen mediabestand uploaden of een bestaand bericht van een uitgelichte afbeelding voorzien.
De makkelijke route was een omweg zoeken. Misschien kon een algemene WordPress-aanroep worden misbruikt of kon de afbeelding via de server worden geplaatst. Dat zou de opdracht mogelijk hebben voltooid, maar de veiligheidsgrens onduidelijk hebben gemaakt.
De juiste conclusie was eenvoudiger: de benodigde bevoegdheid bestond nog niet. Dat is geen reden om een ongeveer passende actie te gebruiken. Het is een capability gap: een concrete ontbrekende functie die als zodanig moet worden vastgelegd en gebouwd.
Waarom één actie vaak twee tools nodig heeft
Zelfs de opdracht “plaats deze uitgelichte afbeelding” heb ik bewust opgesplitst. Eerst uploadt een tool het bestand naar de WordPress-mediabibliotheek. Die geeft een media-ID terug. Daarna koppelt een tweede tool precies dat media-ID aan precies één bericht.
Die splitsing maakt de tussenstap zichtbaar en controleerbaar. Na het uploaden kan worden vastgesteld of WordPress het juiste bestand heeft ontvangen en welke metadata eraan hangt. Na het koppelen kan het bericht opnieuw worden uitgelezen om te bevestigen dat het veld voor de uitgelichte afbeelding werkelijk is aangepast.
Wanneer beide handelingen in één algemene functie verdwijnen, is bij een fout minder duidelijk waar het misging. Kleine tools leveren dus niet alleen een betere veiligheidsgrens op, maar ook een beter diagnosepad.
Een capability gap is niet hetzelfde als een storing
Het onderscheid tussen ontbrekende functionaliteit en een technisch defect is belangrijk. Als een functie niet bestaat, moet ze worden ontworpen en toegevoegd. Als een bestaande functie tijdelijk een API-fout geeft, moet de koppeling worden onderzocht. Als verplichte invoer ontbreekt, moet die informatie eerst worden opgehaald of gevraagd.
Door al die situaties “de tool werkt niet” te noemen, ontstaat een onduidelijke backlog. INDY registreert daarom alleen een capability gap wanneer een geldige gebruikersopdracht niet exact door de actuele functiecatalogus wordt ondersteund.
Dat bouwvoorstel beschrijft de echte ontbrekende functie. Het wordt niet gekoppeld aan een actie die toevallig ongeveer in de buurt komt. Zo blijft de uitbreiding van het systeem doelgericht en voorkom ik dat tijdelijke workarounds stilletjes permanente architectuur worden.
Bevestiging hoort bij de impact van de tool
Niet iedere functie heeft dezelfde impact. Inventarisaties, statuscontroles en publieke healthchecks kunnen meestal direct read-only worden uitgevoerd. Publiceren, caches legen, services herladen en instellingen wijzigen vragen om een expliciete uitvoeropdracht.
De bevestiging moet bovendien aan het juiste object zijn gekoppeld. Een algemeen “ja” is minder sterk dan een bevestiging met het exacte taak-ID, domein, bericht-ID of de actuele servernaam. Daarmee wordt duidelijk waarop het akkoord betrekking heeft en kan een verouderde bevestiging niet zomaar voor een andere actie worden hergebruikt.
Kleine tools maken die relatie praktisch uitvoerbaar. Iedere functie kan een bevestigingsmechanisme krijgen dat past bij haar eigen risico.
Een auditspoor wordt vanzelf begrijpelijker
Wanneer een systeem slechts één algemene actie kent, ziet een logboek er al snel uit als “voer opdracht uit”. Om te begrijpen wat er gebeurde, moet je de volledige invoer reconstrueren en interpreteren.
Met kleine tools vertelt de actienaam al een groot deel van het verhaal. Het systeem heeft een website gecontroleerd, een concept aangemaakt, een specifiek bericht gepubliceerd, media geüpload of een service herladen. Per stap kunnen de invoer, goedkeuring, uitvoeringsstatus, verificatie en eventuele rollbackmogelijkheid worden bewaard.
Dat maakt foutonderzoek sneller. Je ziet niet alleen dát een workflow mislukte, maar ook bij welke beperkte handeling en met welk controleerbaar resultaat.
Kleine tools maken onafhankelijke verificatie mogelijk
Iedere uitvoerende tool heeft idealiter een aparte read-only controle. Na publicatie wordt het bericht opnieuw uitgelezen en de publieke permalink bezocht. Na het koppelen van een afbeelding wordt het bericht gecontroleerd op het nieuwe media-ID. Na een serviceactie volgt een actuele status- of applicatiecontrole.
De uitvoerende functie mag dus niet zelf het enige bewijs leveren dat alles goed is gegaan. Dat zou hetzelfde zijn als je eigen werk nakijken met alleen de melding dat je klaar bent.
Door acties klein te houden, kan ook het verificatiecontract klein en specifiek blijven. Dat levert duidelijker bewijs op dan één algemene controle na een reeks onzichtbare wijzigingen.
Uitbreiden zonder de veiligheidsgrens te verliezen
Twintig tools klinkt misschien als meer onderhoud dan één algemene toegang. In de praktijk groeit het systeem juist overzichtelijker. Een nieuwe mogelijkheid wordt alleen toegevoegd wanneer het doel, de toegestane invoer, de bevestiging en de verificatie helder zijn.
- Beschrijf de concrete gebruikersopdracht.
- Bepaal de kleinst mogelijke uitvoerende handeling.
- Beperk de invoer tot bekende objecten en toegestane waarden.
- Koppel de juiste bevestiging aan de impact.
- Ontwerp een onafhankelijke read-only verificatie.
- Leg resultaat en fouten vast in het centrale auditspoor.
Als deze onderdelen niet duidelijk zijn, is de functie nog niet klaar om zelfstandig beschikbaar te worden gemaakt.
Beperking is hier een kwaliteit
Bij AI wordt veel gesproken over wat een systeem allemaal kan. Voor operationele automatisering vind ik minstens zo belangrijk wat het aantoonbaar niet kan.
INDY hoeft geen onbeperkte beheerder te zijn. Het moet een verzameling betrouwbare bevoegdheden hebben die precies aansluiten op echte werkzaamheden. Wanneer een nieuwe bevoegdheid nodig is, voeg ik die bewust en controleerbaar toe.
Twintig kleine tools zijn daardoor niet twintig losse trucs. Samen vormen ze een veiligheidsmodel: iedere actie is begrensd, iedere toestemming is specifiek en ieder resultaat kan onafhankelijk worden gecontroleerd.
Dat is voor mij de basis van bruikbare AI-automatisering. Niet maximale toegang, maar maximale duidelijkheid.