De verborgen dataflow achter een simpele AI-vraag

Iemand typt een vraag in een AI-chat: "Kun je deze offerte herschrijven voor een nieuwe klant?" en plakt de hele offerte erbij. Drie seconden later staat er een keurig antwoord. Voor de gebruiker is dat het hele verhaal. Vraag erin, antwoord eruit.

Voor de organisatie is dat pas het begin. Tussen het indrukken van enter en het verschijnen van het antwoord zit een complete dataflow, verspreid over systemen, partijen en vaak meerdere landen. De gebruiker ziet alleen het antwoord. De organisatie moet de hele dataflow begrijpen.

Dat is geen theoretisch punt. Overal worden nu AI-beleid en leverancierscontracten geschreven, mede door de AI Act en de AVG. Maar je kunt geen goed beleid maken over iets dat je niet kunt zien. Daarom loop ik de route van zo'n simpele vraag een keer helemaal af.

Stap 1: de prompt is groter dan je vraag

Wat naar het model gaat, is niet alleen jouw zin. De prompt die het systeem opbouwt, bestaat meestal uit een systeemprompt (instructies van de leverancier of je eigen organisatie), de eerdere berichten in het gesprek, soms een gebruikersprofiel of "memory" met dingen die de tool over je heeft onthouden, en pas dan jouw vraag. Plak je een offerte mee, dan gaan ook de klantnaam, prijzen en voorwaarden mee.

Dat pakket wordt omgezet naar tokens, kleine stukjes tekst waarin het model rekent. Een onschuldige vraag van tien woorden kan zo een verzoek van duizenden tokens worden, vol context die de gebruiker zich niet bewust meestuurt. Wie wil weten welke data een AI-tool verwerkt, moet dus niet naar het invoerveld kijken, maar naar wat er werkelijk in het verzoek zit.

Stap 2: documenten worden geknipt en omgerekend

Upload je een document, dan gebeurt er nog iets extra's. Het bestand wordt geparsed (tekst eruit gehaald), in stukken geknipt (chunks) en vaak omgezet naar embeddings. Een embedding is geen samenvatting. Het is een rij getallen die de betekenis van een stuk tekst een plek geeft op een soort betekeniskaart. Twee zinnen met andere woorden kunnen daar toch dicht bij elkaar liggen. Dat is precies wat zoeken in bedrijfsdocumenten mogelijk maakt: de techniek achter RAG.

Maar die embeddings staan ergens. Meestal in een vector database, en dat is een ander systeem dan waar het originele document staat. Soms zelfs bij een andere partij. En hier komt een vraag die bijna niemand stelt: als je het document verwijdert, verdwijnen de chunks en embeddings dan ook? In slordig gebouwde systemen niet. Dan is het document weg, maar leeft de inhoud door in een database die niemand meer op het netvlies heeft.

Stap 3: onderweg naar het model

Daarna vertrekt het verzoek naar de modelprovider. Soms direct, soms via een gateway of LLM-router die bepaalt welk model het verzoek krijgt. Handig voor kosten en betrouwbaarheid, maar het is wel een extra partij die je prompts ziet en mogelijk logt.

Het transport zelf is versleuteld via TLS. Dat beschermt de data onderweg, maar zegt niets over wat er op de bestemming gebeurt. De bestemming is een datacenter, en de regio daarvan staat in je contract of instellingen. Let op het verschil: data residency betekent dat de data fysiek in een bepaalde regio staat. Het betekent niet automatisch dat alleen mensen in die regio erbij kunnen. Wie toegang heeft, hangt af van de leverancier, de moedermaatschappij en de wetgeving waar die onder valt. Dit is geen juridisch advies, maar wel een technische realiteit.

Stap 4: GPU's, batching en caches

In dat datacenter komt je prompt terecht op GPU's. Het model staat geladen in VRAM, het werkgeheugen van zo'n kaart, en rekent token voor token een antwoord uit. Om dat betaalbaar te houden, gebruiken providers batching: meerdere verzoeken van verschillende klanten worden tegelijk door dezelfde hardware verwerkt. Jouw offerte deelt op dat moment dus rekencapaciteit met de prompts van vreemden. Bij een serieuze provider is dat netjes gescheiden, maar het is goed om te beseffen dat "de cloud" hier heel concreet wordt: gedeelde machines in een hal.

Daarnaast bestaat er caching. Tijdens het genereren houdt het model tussenresultaten bij (de KV-cache), en veel providers bieden prompt caching aan: terugkerende delen van een prompt, zoals een lange systeemprompt of een vast document, worden tijdelijk warm gehouden zodat het volgende verzoek sneller en goedkoper is. Technisch slim. Maar het betekent ook dat delen van jouw invoer even ergens blijven hangen, buiten je eigen zicht. Niet per se onveilig, wel een plek in de dataflow die je moet kennen.

Stap 5: het antwoord, en wat er achterblijft

Het antwoord stroomt terug naar je scherm en daarmee lijkt het klaar. Alleen: onderweg zijn er kopieën en sporen ontstaan. De provider logt verzoeken, vaak tijdelijk, bijvoorbeeld voor misbruikdetectie. De gateway logt. Je eigen applicatie logt, voor debugging en monitoring. De chatgeschiedenis wordt opgeslagen zodat je het gesprek later kunt teruglezen. En soms kijkt er nog een analytics-tool mee in de frontend.

Hier zit ook een misvatting die ik vaak tegenkom: "ze trainen niet op onze data, dus het zit goed." Trainen en loggen zijn twee verschillende dingen. Een leverancier kan oprecht beloven dat je data niet in een volgend model belandt, terwijl je prompts wel dertig dagen in logs staan. Voor een privacy- of securitybeoordeling telt allebei.

Een voorbeeld: het advocatenkantoor

Stel, een medewerker van een advocatenkantoor uploadt een conceptdagvaarding naar een gratis AI-chatdienst en vraagt om een samenvatting. Tel even mee waar die inhoud nu staat of heeft gestaan: in de browser van de medewerker, in de frontend van de tool, in de bestandsopslag van de dienst, als chunks en embeddings in een vector database, in de prompt richting de modelprovider, in de logs van die provider, in de opgeslagen chatgeschiedenis en mogelijk in een cache. Dat zijn zomaar acht plekken, na een handeling van tien seconden.

En omdat het een gratis account is, gelden waarschijnlijk de consumentenvoorwaarden, niet de zakelijke. Dat is het echte risico van Shadow AI: niet dat medewerkers AI gebruiken, maar dat de dataflow buiten elk contract en elke beoordeling om loopt.

Waar het technisch misgaat

De problemen zitten zelden in het model zelf. Ze zitten in de randen van de dataflow:

Verwijderen dat niet doorwerkt: het document is weg, de embeddings en logs niet.
Logs in een andere regio dan de inference, terwijl het contract alleen over de inference ging.
Subverwerkers die niemand heeft opgemerkt: de gateway, de vector database, de monitoring-tool.
Rechten die niet meereizen: een document dat intern afgeschermd was, is via de AI-zoeklaag ineens voor iedereen vindbaar.
Een demo-opzet die productie wordt, inclusief de tijdelijke keuzes die nooit zijn herzien.

Dit klinkt simpel, maar in productie wordt het interessant. Een demo hoeft alleen een goed antwoord te geven. Een productiesysteem moet ook kunnen uitleggen waar elke byte is geweest.

Een denkmodel: volg de data in vijf stappen

Wie dit voor de eigen organisatie wil snappen, kan elke AI-toepassing langs vijf vragen leggen:

Invoer: wat gaat er werkelijk mee in de prompt, naast de zichtbare vraag?
Verrijking: worden documenten geknipt en omgezet naar embeddings, en waar staan die?
Transport en verwerking: welke partijen zitten er tussen gebruiker en GPU, en in welke regio's?
Opslag: wat wordt er gelogd, gecachet en bewaard, hoe lang, en door wie?
Restanten: wat gebeurt er bij verwijderen, en werkt dat door in alle kopieën?

Vijf vragen, een middag werk per toepassing. En je hebt direct het materiaal dat je nodig hebt voor verwerkersovereenkomsten, een DPIA of de gesprekken die de AI Act van organisaties gaat vragen.

Tot slot

Niets hiervan is een reden om AI niet te gebruiken. Het is een reden om AI te behandelen als wat het is: een keten van systemen die jouw data verwerken, niet een magisch tekstvak. Bij Klai en HostYourAI is dit precies waarom ik begin met het tekenen van de dataflow voordat er ook maar een model wordt gekozen. Welke route je data aflegt, bepaalt welke leverancier, regio en architectuur passen, niet andersom.

Als je AI veilig wilt inzetten, begin dan met de dataflow. Het antwoord op het scherm is het kleinste deel van wat er gebeurt.

↘︎ ALLE ARTIKELEN

Waarom Europa eigen AI-modellen moet ontwikkelen 13 juni 2026. Anthropic moest Fable 5 en Mythos 5 op overheidsbevel wereldwijd uitzetten. Wat dat zegt over waarom Europa zelf modellen moet kunnen maken.
De verborgen dataflow achter een simpele AI-vraag 10 juni 2026. Wat er technisch gebeurt tussen je vraag aan een AI-chat en het antwoord, en waar je data overal terechtkomt.
RAG begrijpelijk uitgelegd 10 juni 2026. RAG in gewone taal: chunking, embeddings, vector databases, retrieval en de valkuilen in productie.
Het verschil tussen data residency en echte data-soevereiniteit 10 juni 2026. Data in een Europees datacenter is nog geen soevereine data. Over software, recht en encryptiesleutels.
Shadow AI: het datalek dat al gebeurd is 10 juni 2026. Medewerkers gebruiken allang AI-tools, met of zonder beleid. Wat er met die data gebeurt en wat wel werkt.
Van AI-demo naar productie 10 juni 2026. Waarom AI-pilots stranden en wat de stap van prototype naar live systeem echt vraagt.
Embeddings en vector databases: de kopie van je bedrijfskennis waar niemand het over heeft 10 juni 2026. Wat een embedding technisch is, hoe similarity search werkt en waarom je embeddings moet behandelen als een kopie van je bedrijfskennis.
AI-geletterdheid: waarom tooling zonder begrip een risico is 10 juni 2026. Licenties uitdelen is geen AI-strategie. Wat AI-geletterdheid concreet inhoudt, hoe het raakt aan de AI Act en hoe je het aanpakt zonder saaie e-learning.
Hoe je een open-source model host 10 juni 2026. Wat je nodig hebt om een open model zoals Llama of Mistral zelf te draaien: gewichten, VRAM, een inference server, kwantisatie en alles eromheen.
Agents, tool permissions en prompt injection: als AI niet alleen praat maar ook doet 10 juni 2026. Een AI-agent kan mailen, bestanden wijzigen en systemen aanroepen. Waarom tool permissions en prompt injection dan het echte veiligheidsvraagstuk zijn.
Waarom data in Europa houden belangrijk kan zijn 10 juni 2026. Vijf praktische redenen om data in Europa te houden, van AVG en aanbestedingen tot continuïteit. En wanneer het eerlijk gezegd weinig uitmaakt.
Model gateways en LLM-routers, de verkeerstoren van je AI-landschap 10 juni 2026. Waarom je applicaties niet rechtstreeks met modelproviders wilt laten praten. Wat een model gateway en een LLM router doen, en waar het risico zit.
De AI Act is geen beleidsstuk, het is een technisch project 10 juni 2026. De AI Act vraagt om inventarisatie, logging en toegangsbeheer. Waarom een beleidsdocument alleen niet genoeg is en wat je technisch moet kunnen leveren.
Bedrijfskennis veilig aan AI koppelen: wie wat mag zien geldt ook voor de assistent 10 juni 2026. Rechten, document permissions, verwijderde documenten en logging bepalen of een AI-assistent op bedrijfskennis veilig is. Zo pak je de governancekant aan.
GPU-infra zonder mist: VRAM, batching, latency en wat AI echt kost 10 juni 2026. Waarom AI op GPU's draait, wat VRAM bepaalt, waarom een wachtende GPU geld verbrandt en hoe je nuchter rekent aan huren, kopen en spot instances.
Observability, logs en audit trails voor AI, kun je terugzien wat er gebeurde? 10 juni 2026. Als niemand kan terugzien wat de AI deed, heb je een probleem. Wat je logt, hoe je privacy bewaakt en hoe je van logs naar echte evaluatie komt.
OpenAI-compatible APIs, de stekker die overal in past 10 juni 2026. Hoe het API formaat van OpenAI de standaard werd voor bijna elk AI model, waarom dat wisselen makkelijk maakt en waar de compatibiliteit ophoudt.
Self-hosting, Europese cloud en vendor lock-in, waar zit je nou echt vast? 10 juni 2026. Lock-in bij AI zit niet in het model maar in prompts, embeddings, logs en processen. Een gelaagd denkmodel voor self-hosting en Europese cloud.
Use-case: host je eigen model in Europa 10 juni 2026. Hoe een zorginstelling stap voor stap een open model in Europa ging hosten. Van modelkeuze en GPU tot de eerste echte productieproblemen.
One man company, hoe ik in mijn eentje bouw wat eerder een team vroeg 10 juni 2026. Hoe een persoon met AI tooling een productportfolio kan bouwen en draaien. Wat AI overneemt, wat niet, en waar het schuurt als alles jouw probleem is.
Reverse engineering, bouw een compleet softwarepakket na in een dag 10 juni 2026. Met AI tooling bouw je de functionaliteit van bestaande software in een dag na. Wat dat zegt over waar softwarewaarde nu echt zit, en waar niet.
Use-case: je complete boekhouding laten doen door een agent 10 juni 2026. Een AI agent die bonnetjes uit je mail vist en aan transacties koppelt. Wat er technisch voor nodig is, waar het eng wordt en welke vangrails je wilt.
Een supervisor-agent voor al mijn projecten, een kopie van mezelf 10 juni 2026. Hoe een supervisor-agent al je projecten kan bewaken, kleine fixes zelf doet en wekelijks rapporteert. Wat al werkt, wat wensdenken is.
DeepGov, waarom honderden gemeenten niet elk hun eigen AI hoeven te bouwen 10 juni 2026. Een voorstel voor een open source AI platform voor overheden. Gedeelde bouwblokken, Europese hosting en controleerbare code in plaats van losse pilots.
The age of open source: de standaardkeuze voor AI kantelt 10 juni 2026. Open modellen en open AI tooling zijn volwassen. Wat je nog koopt verschuift naar gemak en garanties, en waarom dat voor Europa interessant is.
Je moet het kunnen bedenken, AI werkt vooral als je het grotere plaatje ziet 10 juni 2026. De bottleneck bij AI zit niet meer in de techniek maar in het bedenken. Waarom de beste toepassingen komen van mensen die het hele proces overzien.
Gebruiken we over twee jaar nog wel een scherm? 10 juni 2026. Agents kunnen taken steeds vaker zelf afronden. Wat betekent dat voor het scherm, en moet je nog interfaces bouwen of vooral taken en API's?