Door Devolvio · Cloud, software en AI-engineering
1. Beschrijf de dataflow voordat je iets bouwt
De belangrijkste vraag is niet welk model je gebruikt, maar welke gegevens waarheen gaan. Teken de volledige route: van de vraag van de gebruiker, via de bronnen die worden geraadpleegd, naar het model, en terug.
Leg per stap vast welke gegevens meegaan, welke buiten de eigen omgeving komen, wat er gelogd wordt en hoe lang dat bewaard blijft. Prompts en tussenresultaten bevatten in de praktijk vaak gevoeliger informatie dan de eindantwoorden.
Deze beschrijving is ook het document waarmee je het gesprek met privacy- en securityfunctionarissen kunt voeren. Zonder dat blijft dat gesprek hangen in aannames.
2. Kies hosting en model op basis van consequenties
Er is een wezenlijk verschil tussen een model dat je zelf host op Europese infrastructuur en een externe model-API. Bij het eerste blijft verwerking binnen de omgeving die je beheert; bij het tweede verlaat data die omgeving, hoe de voorwaarden ook luiden.
Dat maakt de externe route niet verkeerd. Voor veel toepassingen weegt kwaliteit of snelheid zwaarder dan volledige controle over verwerking. Maar het is wel een expliciete keuze die je moet kunnen uitleggen, en het is geen soevereine opstelling.
Een gemengde opzet komt vaak voor: een zelf gehost model voor gevoelige bronnen en een extern model voor taken waarbij geen bedrijfsgegevens meegaan. Zorg dan wel dat in de code onmogelijk is dat de verkeerde route wordt gekozen.
3. Pas autorisatie toe bij het ophalen
Bij retrieval-toepassingen is dit de kern. Rechten moeten worden toegepast op het moment dat documenten worden opgehaald, niet nadat het model een antwoord heeft geformuleerd. Filteren achteraf is onbetrouwbaar: het antwoord is dan al gebaseerd op materiaal dat de gebruiker niet mag zien.
Praktisch betekent dat: rechten meenemen in de index, de identiteit van de gebruiker doorgeven tot in de zoekopdracht, en bij twijfel niets teruggeven. Verwijzingen naar bronnen in het antwoord helpen daarbij, omdat een gebruiker dan kan controleren waar iets vandaan komt — en jij kunt zien of er iets is meegekomen dat er niet hoorde.
Houd er rekening mee dat rechten veranderen. Een index die eenmalig is opgebouwd, loopt achter op de werkelijkheid zodra iemand van rol wisselt of een document wordt afgeschermd.
4. Evalueer met een vaste set, niet met een gevoel
AI-applicaties zijn niet deterministisch. Een wijziging in een prompt, een model of een retrieval-instelling kan de uitkomst op onvoorspelbare plekken verbeteren én verslechteren. Zonder meetmethode merk je alleen het eerste.
Een bruikbare evaluatieset bestaat uit representatieve vragen met een verwachte uitkomst of beoordelingscriteria, samengesteld met de mensen die het vakinhoudelijk kunnen beoordelen. Neem er expliciet vragen in op die het systeem niet hoort te beantwoorden.
- Juistheid: klopt het antwoord, en is het te herleiden naar de gebruikte bron?
- Volledigheid: ontbreekt er informatie die wel beschikbaar was?
- Weigering: geeft het systeem netjes aan wanneer het iets niet weet of niet mag tonen?
- Latency en kosten: wat is de responstijd en het verbruik per vraag bij realistisch gebruik?
5. Behandel het als productiesoftware
Zodra een AI-applicatie iets wijzigt, verstuurt of vastlegt, gelden dezelfde eisen als bij elke andere applicatie: wie heeft het geïnitieerd, wat is er gebeurd, hoe draai je het terug. Bij acties met impact hoort een menselijke bevestiging, en die bevestiging hoort in de logging.
Monitor in productie op kwaliteit, latency, kosten en foutpatronen. Voer wijzigingen aan prompts, modellen en instellingen door via dezelfde route als code: versiebeheer, review, evaluatie en een uitrol die je kunt terugdraaien.
Reken op onderhoud. Modellen worden vervangen, bronnen veranderen en gebruikers stellen na een half jaar andere vragen dan bij de start. Een AI-applicatie is geen project met een einddatum, maar een product dat beheerd wordt.