LLM-productiegereedheid voor EU-enterprise-teams.
Wat US-checklists missen voor EU-teams
De standaard productiegereedheids-checklist voor LLM-features dekt: latentie p99 onder load, modelevauatieset met regressiegate, fallback voor modelfouten, kostenraming per query, promptinjectieverdediging, rate limiting. Dit alles is correct en noodzakelijk.
Voor EU-enterprise-teams die opereren onder de AVG, NIS2 of gereguleerde sectoren bedienen, gelden drie extra dimensies. Ten eerste: vindt inferentie plaats binnen EU-dataresidentiegrenzen, en dekt de gegevensverwerkingsovereenkomst van de modelleverancier de gegevenstypes die jouw prompts bevatten? Ten tweede: valt jouw use case onder de hoog-risicoclassificatie van de AI Act, en wat vereist dat dan dat je bouwt? Ten derde: hoe gedraagt GPU-compute-kosten zich bij jouw verwachte query-volume, en wie bezit die kosten als ze onverwacht stijgen?
Dit zijn geen compliance-toevoegingen aan een technische checklist. Het zijn architectuurbeslissingen die bepalen welke leveranciers je kunt gebruiken, welke logging je moet bewaren, en of jouw huidige FinOps-model GPU-kostengedrag überhaupt kan opvangen.
Dataresidentie bij inferentie
De AVG is van toepassing op persoonsgegevens. De meeste LLM-prompts in enterprise-contexten bevatten persoonsgegevens: namen van medewerkers, klantidentificatoren, contractreferenties, vrije-tekstvelden uit CRM-systemen. Als de prompt de EU verlaat om een inferentie-eindpunt van een modelleverancier te bereiken, heb je een juridisch mechanisme nodig onder AVG Hoofdstuk V: een adequaatheidsbesluit (het EU-VS Data Privacy Framework of DPF, van kracht sinds juli 2023 maar onder lopende juridische uitdaging van noyb, het Europese Centrum voor Digitale Rechten geleid door Max Schrems, en met grote kans op een gang naar het Hof van Justitie van de Europese Unie (HvJ-EU) als Schrems III), standaard contractbepalingen met aanvullende maatregelen conform Schrems II, of bindende bedrijfsregels. Het Framework is voorlopig het eenvoudigste pad. Plan alsof het niet stand zal houden.
De praktische implicatie heeft twee lagen. Eerste laag: je keuze van modelleverancier wordt beperkt door wat de prompts bevatten. De grote leveranciers bieden allemaal EU-dataresidentietiers. De controle is doorgaans een regionale API-eindpuntselectie en een addendum op de gegevensverwerkingsovereenkomst. Geen van beide is moeilijk. Geen van beide is de standaard. Je moet er expliciet om vragen. Tweede laag: een EU-regio is geen soevereine immuniteit. De Amerikaanse CLOUD Act (Clarifying Lawful Overseas Use of Data Act) kan elke in de VS gevestigde leverancier, inclusief de EU-dochters en de EU-regio- of 'sovereign cloud'-aanbiedingen, dwingen om klantgegevens te produceren op een geldig Amerikaans juridisch verzoek ongeacht waar de gegevens staan. Voor gewone persoonsgegevens volstaat een EU-regio plus een Hoofdstuk V-mechanisme. Voor handelsgeheimen, gereguleerde workloads, of gegevens die je klanten expliciet buiten Amerikaans bereik hebben geplaatst, is regiokeuze de verkeerde laag om die beslissing te nemen.
Voor gevoeliger gegevens (gezondheidsgegevens, financiële gegevens, HR-gegevens, defensie-gerelateerde gegevens) is het risicoprofiel van het versturen van prompts naar een in de VS gevestigde leverancier mogelijk niet acceptabel op welk tier dan ook, zelfs met een EU-regio. In die gevallen verschuift de architectuur naar een leverancier die niet onder Amerikaanse jurisdictie valt, open-weight-modellen lokaal gehost binnen je eigen tenant, of prompt-engineering die persoonsgegevens verwijdert voor inferentie. De afweging is kwaliteit en kosten tegen jurisdictiecontrole. De keuze ligt stroomopwaarts van leverancierskeuze, niet erbinnen.
AI Act: hoog-risicoclassificatie en wat het operationeel betekent
De EU AI Act (Verordening 2024/1689) is op 1 augustus 2024 in werking getreden en wordt gefaseerd toegepast. Verboden praktijken sinds februari 2025. Verplichtingen voor general-purpose AI-modellen sinds augustus 2025. Het hoog-risico-regime onder Bijlage III is van toepassing vanaf augustus 2026. Bijlage III omvat AI-systemen die worden gebruikt bij arbeidsbesluiten, kredietscores en toegang tot essentiële diensten, biometrische identificatie, kritieke infrastructuur, onderwijs, rechtshandhaving en de rechtsbedeling. Als jouw LLM-feature in deze categorieën valt, bouw je een gereguleerd AI-systeem.
De platform-engineering-implicaties van hoog-risicoclassificatie zijn specifiek: conformiteitsbeoordeling voor inzet, documentatie van modelkeuzerationale, een technisch afgedwongen menselijk toezichtmechanisme, nauwkeurigheids- en robuustheidsevaluatie tegen een representatieve testset, en een post-marktmonitoringplan dat modeluitvoer logt en driftsignalen terug in je evaluatieproces voedt.
Voor de meeste enterprise-LLM-features, zoals interne kenniszoek, codeassistentie en documentsamenvatting, is hoog-risicoclassificatie niet van toepassing. Het checklistitem is niet 'ben je compliant met de AI Act.' Het is 'heb je bepaald of jouw use case in scope valt en heb je die bepaling gedocumenteerd.' De bepaling kost een middag. De afwezigheid ervan is een compliance-gat dat bij een audit aan het licht komt, niet in productie.
"Dataresidentie bij inferentie, AI Act-classificatie en GPU-kostengedrag zijn geen compliance-toevoegingen. Het zijn de dimensies die als eerste breken bij EU-enterprise-deployments."
Sebastiaan van Parijs / Founder
Kostenbeheersing voor GPU-workloads
GPU-compute heeft drie eigenschappen die het onderscheiden van de CPU-compute waarvoor jouw FinOps-model gekalibreerd is. Ten eerste: per-token-prijsstelling produceert niet-lineaire kostenschaling. Een prompt die een uitvoerig antwoord retourneert, kost 3 tot 10 keer zoveel als een prompt die een beknopt antwoord retourneert op hetzelfde querytype. Gebruikspatronen die er soepel uitzien op query-count-metrics, zien er piekerig uit op kostenmetrics.
Ten tweede: latentie-kostafwegingen zijn expliciet en moeten voor de lancering worden gemaakt. Kleinere modellen zijn sneller en goedkoper. Grotere modellen zijn nauwkeuriger en duurder. Het optimale model wordt bepaald door je evaluatieset en je kostendrempel samen. Teams die modellen selecteren op kwaliteit alleen en de kosten daarna ontdekken, hebben de afweging achterstevoren.
Ten derde: GPU-workloads op zelf-gehoste infrastructuur draaien niet schoon stationair. Een GPU-node op 30 procent bezetting kost nog steeds 100 procent van zijn allocatie. Het kostenmodel voor GPU lijkt meer op gecommitteerde gereserveerde capaciteit dan op on-demand CPU. Behandel het als on-demand totdat het op de rekening verschijnt is de meest voorkomende GPU-kostverrassing die we tegenkomen.
De fix: voeg per-query-kosten toe aan je evaluatiedashboard naast kwaliteitsmetrics. Stel een kosten-per-query-budget per feature in voor de lancering. Verbind een kostenanomaliemelding aan hetzelfde on-call-pad als je latentiemeldingen. Als GPU-uitgaven met 30 procent stijgen zonder een overeenkomstige stijging van het query-volume, is er iets mis met de modelselectie of het prompt-template.