Betaal je voor verveelde GPU’s? Hoe AI-starvation je budget opeet
Je hebt een LLM aangesloten op je data. Binnen een paar weken beantwoordt hij binnen een paar minuten vragen waar een medewerker vroeger een dag voor nodig had. Mooi resultaat. Maar heb je ook gezien welke deur je daarmee hebt opengezet?
Edco Wallet, medeoprichter en eigenaar van OptimaData, legt uit waarom je de antwoorden op de vragen van de Cyberbeveiligingswet niet in je AI-tool vindt, maar in de database eronder.
In de meeste AI-projecten ligt de focus op het werkend krijgen van de koppeling. Een RAG-pipeline die documenten doorzoekt, een agent die query’s uitvoert, een chatbot die klantdata raadpleegt. Het datateam bouwt, het werkt, iedereen is blij.
Wat daarbij vaak niet wordt vastgelegd: welke data er precies doorheen stroomt, wie er via die AI-laag toegang krijgt tot je brondata, en waar die data allemaal naartoe gaat. Een vectordatabase, een externe LLM-provider, een embeddingservice. Elke schakel is een nieuw punt waar gevoelige data langskomt.
Je koppeling praat namelijk met je database via één account. In je AI-tool zie je daarom alleen dát de koppeling toegang heeft, niet welke gebruiker er via die koppeling welke gegevens heeft opgehaald, en ook niet bij hoeveel meer tabellen dat ene account kan. Dat staat een laag lager, in de rechten en de logging van je database.
Sinds 15 augustus is dat geen theoretische vraag meer. Toen trad de Cyberbeveiligingswet in werking, de Nederlandse uitwerking van NIS2. Ruim 8.000 organisaties vallen eronder, met verplichtingen rond registratie, zorgplicht en het melden van incidenten. Val je eronder, dan gelden die verplichtingen nu.
NIS2 draait om een paar kernthema’s: risicobeheer, toegangsbeheer, ketenveiligheid en het kunnen aantonen van continuïteit. Vertaal dat naar een AI-koppeling en je stuit al snel op vragen die je niet vanuit de AI-tool beantwoordt, maar vanuit de database eronder.
Wie of wat mag via de AI-laag bij welke data? Een agent die met een generieke service-account overal bij kan, is vanuit NIS2-oogpunt een risico.
Welke data mag embedded worden of naar een externe LLM, en welke niet? Dat bepaal je niet in de AI-tool, dat bepaal je in je databaseomgeving.
Kun je aantonen wie wat heeft opgevraagd via de AI-koppeling? Zonder inzicht in de onderliggende queries is een incident niet te herleiden.
Je vectordatabase en je LLM-provider zijn onderdeel van je keten. Vallen zij uit of lekken zij data, dan is het ook jouw verantwoordelijkheid om dat te melden en te beheersen. Datzelfde geldt voor ons, als partij die aan je database komt. Wij zijn daarom gecertificeerd volgens ISO/IEC 27001:2023 + A1:2024, zodat je die vraag over ons ook kunt beantwoorden.
Is er een back-up- en herstelstrategie voor de vectorstore, net zo goed als voor je productiedatabase? En heb je die weleens getest?
Vaak blijkt dat een AI-koppeling technisch prima werkt, maar dat niemand deze vragen eenduidig kan beantwoorden. Dat is geen AI-probleem. Het is een probleem in je datafundering, net als de dure GPU die staat te wachten op data. Je AI-laag is nooit veiliger of overzichtelijker dan de database waarop hij leunt.
Auditing en logging klinken als de makkelijkste knop om aan te zetten. In de praktijk is dat precies de plek waar het misgaat.
Wij kwamen bij een klant met een productiedatabase van 60GB die, met alle audit logging aan om aantoonbaar compliant te zijn, na een paar jaar was uitgegroeid naar 500TB aan opgeslagen logdata. Elke transactie werd vastgelegd, ook de transacties die voor compliance nergens toe deden. Los van de opslagkosten had dat direct effect op de performance van de database zelf.
Dat is de balans die vaak wordt gemist. Compliant zijn betekent niet alles loggen, het betekent doelgericht loggen. Welke acties op welke data zijn relevant voor NIS2, en welke logging zet je vooral aan omdat het kan? Die afweging maak je op het niveau van je database-architectuur, met retentiebeleid en gerichte auditing.
De verleiding is om compliance bij de AI-tool te zoeken. Een instelling hier, een policy daar. Maar de vragen die NIS2 stelt, beantwoord je pas goed als je weet hoe je data is ingericht, wie erbij kan en hoe dat wordt vastgelegd. Dat begint bij het in kaart brengen van je datastromen en je toegangsrechten, niet bij het aanpassen van een prompt.
Loop om te beginnen de vijf punten hierboven na voor één AI-koppeling die je in productie hebt staan. Kom je er bij twee of meer niet uit, dan weet je waar je werk ligt.
Wil je dat overzicht sneller hebben, dan brengen wij het voor je in beeld met de AI-Data Readiness QuickScan. Daarin zie je hoe je AI-koppelingen zich verhouden tot je database, waar de risico’s zitten rond toegang, dataclassificatie en logging, en welke stappen nodig zijn om aantoonbaar in control te zijn.
Liever eerst even sparren over je eigen situatie? Bel of mail gerust.