Het eerlijke uitgangspunt: fouten gebeuren, punt

Software van enige omvang bevat fouten. Dat gold voor met de hand geschreven code al decennialang, en het geldt evengoed voor code die met AI geschreven is. De vraag is dus niet of er ooit een fout doorglipt, die vraag is al beantwoord. De vraag die er echt toe doet, is wat er gebeurt op het moment dat het gebeurt.

Voor de bredere vraag of AI-geschreven software wel veilig genoeg is om op te vertrouwen, staat een uitgebreider antwoord in is software die met AI gebouwd is wel veilig? Dit artikel gaat over wat er concreet gebeurt op het moment dat er toch iets misloopt.

Hoe een fout opgemerkt wordt

Software die stil faalt, is erger dan software die luid faalt. Bij stil falen weet niemand dat er iets moet opgelost worden, tot een klant of collega het toevallig ontdekt, soms pas weken later. Daarom hoort een fout een zichtbaar signaal te sturen naar een vaste, met naam gekende persoon, niet te verdwijnen in een logbestand dat nooit iemand opent. Dat geldt voor een technische fout, zoals een koppeling die vastloopt, en evengoed voor een fout in de logica zelf, zoals een verkeerd berekend bedrag.

Hoe de schade beperkt blijft

Twee dingen bepalen hoe groot de impact van een fout wordt, los van waar de fout vandaan kwam.

Zo min mogelijk rechten, overal. Elke toegang tot een systeem krijgt enkel wat nodig is voor die ene taak. Gaat er iets mis in één onderdeel, dan blijft de schade beperkt tot dat onderdeel, in plaats van dat het hele systeem meegetrokken wordt.

Wijzigingen die terug te draaien zijn. Een aanpassing die live gaat, kan ook weer teruggedraaid worden naar de vorige, werkende versie, zonder dat daar paniek of improvisatie bij komt kijken. Dat is een bewuste keuze in hoe er gebouwd wordt, geen toeval.

Hoe een fout in de logica zelf vooraf al opgevangen wordt

Naast wat er gebeurt ná een fout, is er wat vooraf al gebeurt om er een te vermijden. Voor iets live gaat, wordt het getest tegen echte gegevens, niet enkel tegen voorbeelddata die toevallig netjes uitkomt. Dat is ook waarom er bij Niklu al tijdens de eerste dagen op uw eigen data gewerkt wordt in plaats van op een mockup: een fout die pas opduikt bij echte, rommelige gegevens, komt dan aan het licht voor de oplevering, niet erna. Zie wat levert de eerste twee dagen concreet op?

Wie mag welke gegevens zien of aanpassen, wordt daarnaast apart getest, niet enkel verondersteld te werken omdat de functie zelf werkt. Dat is een ander soort fout dan een verkeerde berekening, en verdient een aparte controle.

Wie de fout uiteindelijk oplost

Achter dit alles staat iemand die begrijpt wat de software doet, hoe ze draait en wat ze aanraakt. Bij Niklu is dat dezelfde persoon die het gebouwd heeft en die na de overdracht bereikbaar blijft via Losse dagen. Een fout wordt dan niet uitgezocht door iemand die de opbouw voor het eerst ziet, wat zelf al tijd bespaart bij het oplossen. Wat er gebeurt als die persoon niet meer beschikbaar is, staat in wat als de ontwikkelaar er niet meer is?

Wat dit niet belooft

Er bestaat geen manier om te garanderen dat er nooit een fout optreedt, met AI gebouwd of niet. Wat wel te beloven valt: een fout blijft niet onopgemerkt, de schade blijft beperkt tot waar ze ontstond, en er is iemand die weet hoe ze op te lossen. Dat is een eerlijkere belofte dan “dat gebeurt bij ons niet”.

Wilt u weten hoe dat voor uw eigen situatie concreet ingericht wordt? Een gratis kennismaking van een half uur bespreekt dat graag mee.