Hoe ik mijn AI-architectuur ontwierp zonder technische achtergrond, en wat 42001 me erover leerde
Ik programmeer niet. Toch heb ik een werkende AI-architectuur ontworpen en draai ik die. De twee feiten zijn minder tegenstrijdig dan ze klinken, en de reden waarom bleek de nuttigste les over 42001 die ik buiten een klantopdracht heb geleerd.
Dit is geen handleiding. Het is een reflectie op ontwerpbeslissingen en de governance-redenering erachter, geschreven door iemand die voor zijn werk AI-managementsystemen auditeert en besloot dezelfde blik op zijn eigen opzet te richten. Een AI-architectuur is in deze context de samenhangende opzet van tools, kennisstromen en controlepunten waarmee iemand AI verantwoord laat werken.
Wat de architectuur eigenlijk is
De opzet is een verbonden set tools, geen stapel losse apps. Claude als redeneerlaag. Confluence als persistente kennislaag, waar strategie, paginadocumentatie en besluithistorie leven en over sessies heen beschikbaar blijven. Jira voor gestructureerde taken. Ahrefs voor data waarvan het werk afhankelijk is. Deze zijn verbonden via het Model Context Protocol, zodat de redeneerlaag rechtstreeks uit de kennislaag kan lezen en ernaar kan schrijven, in plaats van dat ik tekst tussen vensters kopieer.
Het punt zijn niet de specifieke tools. Het is dat de architectuur een vorm heeft. Kennis blijft op één plek bestaan. Werk loopt via gedefinieerde paden. De redeneerlaag begint niet elke keer vanaf nul, omdat de kennislaag onthoudt.
De ontwerpprincipes, en waar ze vandaan kwamen
Ik begon niet met een tool-lijst. Ik begon met principes, en merkte pas daarna dat ze vrijwel exact aansloten op een norm die ik voor anderen implementeer.
Het eerste principe was persistente kennis. Alles wat het systeem nodig heeft om goed te redeneren, hoort ergens duurzaam te leven, niet in de vluchtige context van één gesprek. Daarom staat Confluence in het midden. Het tweede was reproduceerbare workflows. Dezelfde taak hoort op dezelfde manier te lopen, wat betekent dat de stappen in documentatie leven, niet in mijn geheugen. Het derde was menselijke controle op gedefinieerde controlepunten. Het systeem stelt op en stelt voor. Ik beoordeel en beslis. De grens tussen die twee is expliciet, niet geïmproviseerd. Het vierde waren kwaliteitspoorten. Werk wordt tegen een rubric gescoord voordat het als klaar geldt, en de drempel staat opgeschreven.
Die vier principes zijn een governance-ontwerp. Ik herkende dat pas achteraf, wat de eerlijke versie van het verhaal is.
Wat 42001 zegt over de keuzes die ik maakte
42001:2023 opent met context, cl. 4.1. Begrijp, vóór al het andere, de omgeving waarin de AI opereert en wat hij moet bereiken. Dat had ik gedaan zonder het te benoemen: de architectuur was gebouwd rond wat mijn praktijk werkelijk nodig heeft, niet rond wat de tools konden.
cl. 6.1 vereist risicobeoordeling van AI-gebruik. Mijn eigen opzet ontwerpen dwong me te vragen waar het mis kon gaan, wat er gebeurt wanneer de redeneerlaag met overtuiging incorrect is, en welke stappen een mens in de lus nodig hebben juist omdat de kosten van een onbeoordeelde fout hoog zijn. Dat is een risicobeoordeling van mijn eigen AI-gebruik, uitgevoerd omdat het bouwen van het ding de risico’s concreet maakte.
cl. 8.4 gaat over menselijk toezicht. De gedefinieerde controlepunten, waar het systeem voorstelt en ik beschik, zijn precies dat. Geen toezicht als beleidsuitspraak, maar toezicht ingebouwd in de workflow als een stap die niet kan worden overgeslagen.
Wat een beperkte technische achtergrond eigenlijk deed
Ik verwachtte dat mijn gebrek aan programmeren een beperking zou zijn. Het werkte meer als een ontwerpfilter. Omdat ik niet naar een slimme technische oplossing kon grijpen, moest elke beslissing in gewone termen uit te leggen zijn en achteraf auditeerbaar. Kon ik niet beschrijven waarom een stap werkte en hoe ik zou weten dat hij faalde, dan kon ik hem niet bouwen. Die discipline maakte de architectuur robuuster, niet minder. Er zit niets in dat ik niet kan verantwoorden, precies de eigenschap waar ik naar zoek wanneer ik andermans AI-governance auditeer.
De volgende laag is moeilijker. Meerdere agents die samenwerken, supervisorpatronen die ze coördineren, de vragen die komen met het overdragen van meer autonomie aan het systeem. Dat zijn de vragen waar ik nu naartoe werk, en het zijn governancevragen voordat het technische vragen zijn. Wie is verantwoordelijk wanneer de ene agent handelt op de output van een andere. Waar zit het menselijke controlepunt wanneer de workflow meer bewegende delen heeft. De norm zal daar ook iets over te zeggen hebben.
De reden om dit op te schrijven is niet de opzet zelf. Het is dat de vragen die ik moest beantwoorden om het verantwoord te bouwen dezelfde vragen zijn die elke organisatie die AI inzet moet beantwoorden, of iemand het zo heeft geformuleerd of niet. Waar leeft kennis. Hoe worden workflows gereproduceerd. Waar zit het menselijke controlepunt. Wat is de kwaliteitspoort. Hoe zou je weten dat het systeem faalde. Dit zijn precies de vragen die AI-governance hoort op te lossen, en het is dezelfde blik die iQomply toepast bij het beoordelen van hoe een organisatie haar eigen AI heeft opgezet. Maakte dit je duidelijk dat je die vragen voor je eigen AI-opzet niet volledig kunt beantwoorden, dan is die herkenning het nuttige deel. Een AI-architectuurreview legt dezelfde governanceblik op de AI van jouw organisatie, en dat is werk waar iQomply steeds vaker om wordt gevraagd. De makkelijkste eerste stap is een gesprek.
Veelgestelde vragen
Nee. Een werkende architectuur vereist ontwerpdenken, helderheid over hoe kennis stroomt, en een governance-mindset meer dan dat het programmeren vereist. Een beperkte technische achtergrond kan zelfs als nuttig filter werken, omdat het elke beslissing dwingt verklaarbaar en auditeerbaar te zijn in plaats van afhankelijk van een slimme technische oplossing.
Op dezelfde manier als voor dat van een klant. cl. 4.1 vraagt je de context te begrijpen waarin je AI opereert. cl. 6.1 vereist een risicobeoordeling van je AI-gebruik. cl. 8.4 vereist menselijk toezicht. Een architectuur bouwen rond persistente kennis, reproduceerbare workflows en gedefinieerde menselijke controlepunten voldoet in de praktijk aan die clausules, niet alleen op papier.
Het systeem stelt op en stelt voor. De mens beoordeelt en beslist. De grens tussen die twee is in de workflow ingebouwd als een controlepunt dat niet kan worden overgeslagen, wat cl. 8.4 met menselijk toezicht bedoelt. Het is een ontworpen stap, geen beleidsuitspraak.
Het legt een governanceblik op hoe een organisatie haar AI heeft opgezet: waar kennis leeft, hoe workflows worden gereproduceerd, waar menselijke controlepunten zitten, en hoe falen zou worden gedetecteerd. Dezelfde vragen die in het bouwen van een verantwoorde architectuur gaan, zijn de vragen die worden gebruikt om een bestaande te beoordelen.
