De meeste AI-integratieprojecten mislukken niet omdat het model verkeerd was. Ze mislukken omdat de organisatie niet klaar was voor het type AI-integratie dat ze koos, en niemand dit controleerde voordat de build begon.

Ik ben niet tot die les gekomen omdat iemand boven mij verordonneerde dat "we AI in het product nodig hebben." Als er al een mandaat was, liep dat de andere kant op. Mijn eigen team, mijn eigen managementteam, zag AI vooral als een bedreiging: iets dat de rollen die zij in de loop der jaren hadden opgebouwd, zou kunnen vervangen. Ik begreep de angst. Maar ik deelde de visie op waar AI daadwerkelijk voor bedoeld was niet.

Wat mij naar AI trok, was niet efficiëntie of headcount. Het was iets dat ik al heel lang goed wilde aanpakken en waarin ik nooit helemaal was geslaagd: echte compliance, niet de checkbox-versie. Het serieus najagen hiervan is wat mij naar AI leidde, en het bracht me veel meer dan ik had verwacht.

Wat Echte Compliance Daadwerkelijk Achterlaat

Compliance goed inrichten is onglamoureus werk. Het betekent het documenteren van processen, beslissingen, toegang en wijzigingen op een manier die gestructureerd en specifiek genoeg is om een audit te overleven, en niet pas achteraf opgeschreven om er snel aan te voldoen. De meeste agencies slaan dit over omdat het traag is en het niet voelt alsof je echt iets bouwt.

Wij deden het toch, en het liet ons achter met iets wat we niet volledig hadden voorzien: een grote, gestructureerde, oprecht contextuele body of documentation over hoe we daadwerkelijk werken. Geen wiki die niemand bijwerkt. Een live record van processen, beslissingen en rationale, actueel gehouden omdat het compliance-werk dat vereiste.

Dat is het deel van AI-integratie dat mensen verkeerd begrijpen wanneer ze zich voorstellen dat "AI onze code sneller schrijft." De programmeerassistentie is reëel, maar het is het minst interessante deel van wat er voor ons is veranderd. Het interessante deel is wat er gebeurde toen die documentatie eenmaal bestond in een vorm die een agent daadwerkelijk kon gebruiken.

Meer Output, Niet Minder Mensen

De instinctieve reactie in een kamer vol mensen die software bouwen voor de kost, wanneer iemand "AI" zegt, is om te horen: "we hebben minder mensen nodig." Ik denk dat dat het verkeerde tijdperk is om die angst vandaan te halen. Het ligt dichter bij de industriële revolutie. Machines maakten mensen niet overbodig. Een bedrijf bouwde meer machines en had mensen nodig om ze te bedienen, en produceerde meer met hetzelfde aantal mensen, en vervolgens nog meer naarmate er mensen werden toegevoegd om er nog meer te runnen.

Dat ligt dichter bij wat hier daadwerkelijk is gebeurd. Het doel was nooit om hetzelfde werk met minder mensen te doen. Het was het besef dat we veel meer werk konden verzetten met dezelfde mensen, en de compliance-grade documentatie die we al hadden opgebouwd – om heel andere redenen – bleek de grondstof te zijn die dit mogelijk maakte.

Een zichtbaar bijeffect van die verschuiving: mensen hoefden niet langer een meeting te plannen of een chat te starten met degene die toevallig de context nog wist. Ze pakken de documentatie erbij en vragen het direct aan een agent, en krijgen een contextueel antwoord dat afkomstig is uit hetzelfde gestructureerde record dat we om compliance-redenen hebben opgebouwd. Dat is een reële en nuttige verandering, maar het is een symptoom van de grotere verschuiving, niet de verschuiving zelf. De grotere verschuiving is capaciteit. Hetzelfde team kan nu meer scope, meer klanten en meer diepgang aan, zonder dat de compliance-rigor of de quality bar in het gedrang komt.

Voor een team dat alle reden had om op hun hoede te zijn voor AI omdat ze overal de "het vervangt banen"-versie van het verhaal hadden gehoord, veranderde het zien dat het zich daadwerkelijk vertaalde in meer werk dat door hen werd verzet, het interne gesprek meer dan alles waar ik direct voor had kunnen pleiten.

Dat is, denk ik, ook de meest ondergewaardeerde categorie van AI-integratie die een bedrijf kan nastreven, en het komt zelden op iemands roadmap terecht omdat het niet de meest flitsende is.

Niet Elke AI-integratie Is Dezelfde Gok

De interne, op documentatie gebaseerde variant die ik net beschreef, is bijna per definitie low-risk: een mens is nog steeds eigenaar van elke beslissing, de agent beantwoordt vragen en onderneemt geen acties, en de "failure mode" is een fout antwoord dat door iemand wordt opgemerkt, niet een foutieve actie die al is uitgevoerd.

Customer-facing AI-features, ingebed in een bestaand product, zijn een andere gok. Weliswaar afgekaderd, maar de output is nu zichtbaar voor mensen buiten het bedrijf, dus een slecht antwoord betekent een slechte ervaring, niet alleen een interne correctie.

Agentic workflow automation

is weer een heel andere gok: het systeem voert multi-step acties uit over andere systemen heen, met minimale menselijke controle bij elke stap. Dit is waar de belangen groot worden, omdat het systeem nu handelt en niet alleen informeert.

AI-native producten zijn een categorie apart: het model is geen feature die aan iets anders is toegevoegd, het is de reden dat het product bestaat, en de architectuur is er vanaf het begin omheen gebouwd.

Dit zijn geen fasen op een maturity ladder die elk bedrijf op volgorde moet beklimmen. Het zijn verschillende tools voor verschillende problemen, en de fout die ik het vaakst zie, is dat een bedrijf streeft naar de ambitie van de derde of vierde categorie, terwijl het alleen de readiness – en vaak ook alleen de behoefte – heeft voor de eerste.

Wat "Ready" Daadwerkelijk Betekent, Vóór de Eerste Regel Code

De vragen die ik nu stel voordat we AI-integratiewerk scopen, gaan allemaal terug naar wat ik heb geleerd bij het opbouwen van onze eigen compliance-documentatie, of de motivatie van de klant nu compliance is of niet.

-

Is het onderliggende proces daadwerkelijk gedocumenteerd, en niet alleen bekend bij één persoon?
Je kunt geen nuttig antwoord uit een agent krijgen, of een beslissing automatiseren, als het proces alleen bestaat als tribal knowledge in iemands hoofd.

• Is de data toegankelijk, gestructureerd en voorzien van de juiste permissies? Niet "bestaat het ergens," maar kan het betrouwbaar worden opgehaald zonder dat er eerst een data-cleaning project nodig is.
• Wie is er verantwoordelijk als het systeem iets fout doet, en wat wordt er gelogd? Voor alles wat verder gaat dan intern, door mensen gecontroleerd gebruik, moet dit vanaf dag één deel uitmaken van het ontwerp, en niet pas vlak voor de lancering worden toegevoegd.
• Is there a specific person who will own this day to day? Sponsorship is geen ownership. Projecten zonder een duidelijke owner lopen vast, ongeacht hoe goed de onderliggende technologie is.
• **Kunnen de bestaande systemen daadwerkelijk veilig onts