Observability (AI) uitgelegd | EIGHTY8

Wat is observability bij AI? Loggen wat een model kreeg, deed en teruggaf, zodat je fouten kunt herleiden. Wat je minimaal vastlegt.

Observability bij AI is het vastleggen van wat een model kreeg, deed en teruggaf: de invoer, de instructie, de modelversie en het antwoord. Zonder die registratie is elke fout een raadsel; ermee is een foute uitkomst herleidbaar tot zijn oorzaak. EIGHTY8 legt elke aanroep vast. Met bewuste grenzen op wat er nooit in het logboek thuis hoort.

Als een AI-toepassing een fout maakt, begint het echte werk pas daarna: herleiden. Wat stond er in de aanvraag? Welke instructie had het model? Welke versie was actief, en wat gaf hij precies terug? Zonder antwoorden op die vragen blijft elk probleem een anekdote ('hij deed het gisteren raar') zonder mogelijkheid tot verbetering. Observability is de registratie die die vragen beantwoordt.

Minimaal hoort er per aanroep bij: de invoer die het model kreeg (inclusief de eigen documenten of context die mee gingen), de instructie waarmee hij werd gestuurd, de versie van het model, het tijdstip, de uitkomst en wat erna gebeurde. Is het antwoord geaccepteerd, verbeterd of verworpen? Die laatste is het waardevolst: het verschil tussen wat het model schreef en wat de mens ervan maakte, is de leerschool van je toepassing.

Er hoort een grens bij. Een logboek dat alles vastlegt, legt ook klantgegevens vast. En dan is je log zelf een privacy-risico geworden. Leg daarom vooraf vast welke velden in het log thuishoren en welke geschrapt of versleuteld worden, en hoe lang alles bewaard blijft. Observability zonder die afweging is een lek in de maak; met die afweging is het een gereedschap dat je elke dag opnieuw dankbaar gebruikt.

Observability is de moeite waard voor elke toepassing die het langer dan een dag uithoudt en een beslissing of uitkomst produceert die iemand kan vragen om. Kritieker: hoe meer de uitkomst de deur uit gaat richting klant of administratie, hoe meer je herleidbaarheid nodig hebt. Een log per aanroep is geen luxe maar een noodzaak zodra het model iets doet waar iemand op vertrouwt.

Voor een los experiment of een prototype is volledige registratie vaak niet nodig. Je verkent, je gooit weg. En er is een tegenkant: zichtbaarheid kost opslag, aandacht en een bewuste keuze over gevoelige velden. Volledig zicht op alles zonder doel leidt tot een log die niemand leest en die te veel vastlegt. Kies per werkstroom wat je wilt kunnen herleiden, en bouw de registratie daarop.

EIGHTY8 bouwt observability standaard in bij elke klantoplossing: per aanroep wordt vastgelegd wat erin ging, welke versie antwoordde en wat erna gebeurde, met een bewuste afweging over gevoelige velden. Die registratie voedt ook de toetsen tegen drift: zakken de uitkomsten, dan zie je dat in hetzelfde overzicht. Zo is een fout een vraag die je kunt beantwoorden, geen gerucht dat blijft rondgaan.

Welke gegevens leg je minimaal vast bij een AI-aanroep?

Vijf dingen: de invoer inclusief de context die meeging, de instructie waarmee het model werd gestuurd, de modelversie, het antwoord en wat de mens erna deed: geaccepteerd, verbeterd of geweigerd. Daarmee is elke uitkomst herleidbaar en leert de toepassing van de correcties. Alles verder (duur, verbruik, interne kenmerken) is handig maar secundair. Beter een klein log dat iedereen leest dan een enorm log dat niemand opent.

Mag je de inhoud van klantvragen loggen?

Alleen met een bewuste afweging vooraf. In de praktijk: bepaal welke velden voor herleidbaarheid écht nodig zijn, schraap of maskeer de rest op het moment van vastleggen, en zet een bewaartermijn neer. Log niet méér dan je bij een klantvraag kunt uitleggen. Wie alles vastlegt 'omdat het kan', bouwt een archief vol persoonsgegevens waar hij later verantwoording over moet afleggen. De registratie werkt tegen je in plaats van voor je.

Wat is het verschil tussen monitoring en observability?

Monitoring ziet dat er iets mis is: een drempel die overschreden wordt, een uitval, een piek in weigeringen. Observability gaat een stap verder: de registratie waarmee je kunt nazoeken wáárom het mis ging. Welke invoer, welke instructie, welke versie. Monitoring roept, observability legt het bewijs vast. Beide horen bij een volwassen AI-toepassing; met alleen monitoring weet je dat het kapot is, maar niet waarom.

Helpt observability ook bij het verklaren van een foute uitkomst?

Dat is juist zijn kernfunctie. Met een volledige registratie reconstrueer je de aanroep: wat stond erin, welke versie antwoordde, wat was de instructie. En op dat punt wordt een 'vreemde uitkomst' meestal een begrijpelijke oorzaak: een ambigu formulier, een ontbrekend document, een instructie die te ruim was. Zonder die registratie blijft het giswerk; ermee wordt elke klacht een gesprek over feiten in plaats van herinneringen.

EIGHTY8