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: adequaatheidsbesluit, standaard contractbepalingen of bindende bedrijfsregels.
De praktische implicatie: je keuze van modelleverancier wordt beperkt door de gegevens die je in prompts plaatst. 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.
Voor gevoeliger gegevens (gezondheidsgegevens, financiële gegevens, HR-gegevens) is het risicoprofiel van het versturen van prompts naar een externe leverancier mogelijk niet acceptabel op welk tier dan ook. In die gevallen verschuift de architectuur naar lokaal gehoste modellen binnen je eigen tenant, of naar prompt-engineering die persoonsgegevens verwijdert voor inferentie.
AI Act: hoog-risicoclassificatie en wat het operationeel betekent
De EU AI Act is vanaf augustus 2024 gefaseerd in werking getreden. Hoog-risico-AI-systemen (Bijlage III) omvatten systemen gebruikt bij arbeidsbesluiten, kredietscore, toegang tot essentiële diensten en veiligheidskritieke toepassingen. 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.