Jouw ene AI-expert verbergt een probleem dat jij niet ziet.

De meeste leiderschapsteams zijn dol op hun AI-persoon. Dingen worden snel opgeleverd, de demo's imponeren het bestuur, en elk automatiseringsverzoek wordt binnen een week afgehandeld. Wat ze niet zien, is het risico dat onder die snelheid schuilgaat. Hun ene AI-expert verbergt de scheuren in het systeem.

Dus als die persoon vertrekt, of zelfs maar twee weken vrij neemt, vertraagt het AI-werk niet gewoon. Het stopt. Dat is geen prestatieprobleem van een individu. Het is een structureel probleem, en het bedreigt stilletjes elk bedrijf dat één persoon de volledige AI-capaciteit liet worden.

Het verborgen risico van de AI-persoon

In de meeste teams eindigt het zo dat één persoon elke prompt, elke automatisering, elke integratie met de model-provider bezit. Het leiderschap prijst diegene, noemt hem of haar in bestuursupdates, en stopt stilletjes met vragen hoe alles eigenlijk werkt, omdat degene die het beheert nooit hulp lijkt nodig te hebben.

Die stilte is het risico. Elke prompt leeft in hun hoofd of hun persoonlijke notities. Elke workaround voor een eigenaardigheid van een provider is nooit vastgelegd, omdat het opschrijven trager voelde dan het gewoon opnieuw fixen de volgende keer. Elke architectuurbeslissing, waarom dit model en niet dat andere, waarom deze data hierheen stroomt en niet daarheen, bestaat alleen als iets wat zij zich herinneren, niet als iets wat de organisatie bezit.

Een systeem dat maar één persoon kan bedienen, is geen systeem. Het is een afhankelijkheid met een functietitel.

Waarom het onzichtbaar blijft tot het breekt

Key-person-risico duikt niet op in een dashboard. Alles ziet er prima uit, tot het moment dat dat niet meer zo is: de persoon is onbereikbaar, een provider wijzigt een API en alleen zij weten welke van de zes integraties afhankelijk is van het oude gedrag, of ze vertrekken gewoon, en de organisatie ontdekt dat "hoe AI hier werkt" nooit ergens is vastgelegd waar het te vinden was zonder hen.

Tegen de tijd dat het zichtbaar is, is het duur. Institutionele kennis vanaf nul herbouwen, onder druk, met een systeem dat al in productie draait, kost veel meer dan het documenteren onderweg zou hebben gekost. Het risico was er de hele tijd al. Het was alleen stil.

Wat het risico écht verkleint

Niet een tweede persoon aannemen om de eerste te schaduwen, en niet de expert vragen om te vertragen en alles één keer uit te leggen. Beide voelen als oplossingen en geen van beide overleeft het contact met een echte deadline. Wat het risico verkleint, is documentatie een bijproduct maken van het werk zelf, niet een aparte taak die om dezelfde uren concurreert.

Architectuurkeuzes, workarounds en de reden erachter worden vastgelegd op het moment dat ze gemaakt worden, niet achteraf uit het geheugen gereconstrueerd. Prompts en systeeminstructies leven in een repository met een geschiedenis, niet in een persoonlijke notitie-app. Elke niet-vanzelfsprekende beslissing draagt de datum en de reden, zodat iemand die het over zes maanden leest niet alleen begrijpt wat er gekozen werd, maar ook waarom, en het veilig kan aanpassen als de reden niet meer geldt.

Dat is trager op het moment zelf. Het is de enige vorm van snelheid die overleeft wanneer degene die het bouwde op vakantie gaat.

The ODB Way

Bij ODB Growth laat elk traject meer achter dan werkende software. Architectuurkeuzes, workarounds en de beslissingen die onderweg gemaakt worden, worden vastgelegd op het moment dat ze gemaakt worden, met de reden en de datum, zodat wie het over drie maanden overneemt kan lezen wat er gebeurd is en waarom, zonder dat de bouwer erbij hoeft te zijn.

Dat is geen rapport dat aan het einde wordt overhandigd. Het is de werkwijze gedurende het hele traject, want een systeem dat maar één persoon kan uitleggen, is niet af, hoe goed het vandaag ook werkt.