AI Governance en Audit voor Enterprise LLM's: Virtual Keys, RBAC en Compliance-Grade Logs

Wanneer LLM's van een pilot naar productie schalen over meerdere teams, is governance niet langer optioneel. Iemand zal vragen wie welk model mag aanroepen, met welk budget, op wiens data — en of elke call gereconstrueerd kan worden voor een audit. Dit artikel is de control plane die die vragen beantwoordt: virtual keys die toegang loskoppelen van provider credentials, RBAC en policy-as-code, budgetten en quota als governance, compliance-grade audit logs, data-residentie, en hoe deze gateway-controls zich verhouden tot verplichtingen zoals de EU AI Act — ingestoken vanuit wat ze helpen vervullen, niet als een compliance-garantie.

Kwartaaleinde bij Northwind. Mei, de platform lead, kreeg een vraag van het security- en compliance-team die ze niet kon beantwoorden: welke teams hadden het afgelopen kwartaal klantdata naar welke modelproviders gestuurd, en kon ze de gegevens daarvan overleggen. Dat kon ze niet. Elke service riep de modelproviders aan via één gedeelde API key, die jaren geleden in een configuratie was ingevoerd. Er was geen attributie per team, geen vastlegging van welke verzoeken klantdata bevatten, geen manier om de toegang van één team in te trekken zonder de key voor iedereen te roteren, en geen audit trail buiten de ondoorzichtige facturering van de providers zelf. Het LLM-gebruik was gegroeid van één prototype naar een tiental productiediensten, en de governance was niet meegegroeid.

Er was niets misgegaan, niet echt — geen datalek, geen overschrijding die iemand was opgevallen. Maar "we kunnen de vraag niet beantwoorden" is een bevinding op zich, en het is precies de bevinding die van een routine-audit een omvangrijk project maakt. Dit artikel behandelt de control plane die de vraag beantwoordbaar maakt voordat iemand hem stelt.

Wat TrueFoundry's AI Gateway Hier Biedt

Alles in dit artikel — virtual keys, RBAC, budgetten, rate limits, audit logs, residentieregels en guardrails als gehandhaafd beleid — is iets wat TrueFoundry's AI Gateway uitdrukt als configuratie in één control plane. Toegangsbeheer definieert wie (gebruikers, teams, virtuele accounts) welke provider-accounts en modellen mag aanroepen; Personal Access Tokens en Virtual Account Tokens zijn de manier waarop applicaties authenticeren bij de gateway in plaats van ruwe provider keys te bewaren; rate-limit- en budgetconfiguraties gelden per gebruiker, team, virtueel account, model of elke aangepaste metadata-key; en guardrails — inclusief Cedar en OPA als policy-as-code bij de MCP-toolgrens — draaien als gehandhaafde regels op vier lifecycle-hooks.

Elk verzoek doorloopt hetzelfde pad: authenticeer, herleid de identiteit van de aanroeper, evalueer toegangsbeleid en budgetten per key, evalueer rate-limit-regels op volgorde (eerste match wint), voer input-guardrails uit, routeer naar een provider, genereer een audit-grade trace en voer vervolgens output-guardrails uit. Dezelfde weergave wordt het overzicht dat een auditor nodig heeft: wie riep wat aan, wanneer, tegen welk beleid, met welke guardrail-resultaten. Request Traces en OpenTelemetry-export zorgen ervoor dat het spoor in uw SIEM terechtkomt in plaats van in een vendor-dashboard dat u niet kunt bevragen.

‍

De applicatiecode blijft ongewijzigd ten opzichte van een standaard OpenAI-compatible call — de governance zit in het bearer token en de metadata-header, niet in de client-logica. Een Personal Access Token herleidt naar een gebruiker; een Virtual Account Token herleidt naar een niet-menselijke identiteit voor productiediensten. De X-TFY-METADATA header bevat de gestructureerde velden (team, project, cost_center, environment) waar beleid, budgetten en audit logs op matchen:

De gateway aanroepen met een identiteit en audit-metadata (Python, OpenAI-compatibel)

1. Waarom Governance Onmisbaar Wordt in Productie

Eén enkel prototype dat één model aanroept met één key heeft geen governance nodig. Tientallen services over meerdere teams, die verschillende providers aanroepen met data van uiteenlopende gevoeligheid, hebben een control plane nodig — omdat de risico's niet langer theoretisch zijn. Een gedeelde key betekent dat er geen gebruiksattributie is, dus u kunt finance niet vertellen welk team de kosten veroorzaakt of security niet vertellen welk team klantdata heeft geraakt. Geen uitgavenlimieten betekent dat één doorgedraaide agent (denk aan de stille escalatie uit het artikel over routing) het budget kan opmaken voordat iemand het merkt. Geen audit trail betekent dat u niet kunt reconstrueren wat er is gebeurd voor een incident of een auditor. En geen toegangsbeheer betekent shadow AI: teams die modellen koppelen zonder dat iemand het bijhoudt.

Bovenop de operationele druk komt regelgevende druk. De EU AI Act fasereert verplichtingen rond verslaglegging, transparantie en menselijk toezicht in (sectie 7), en sectorale kaders — SOC 2, HIPAA, financiële regelgeving — verwachten al lang toegangsbeheer en auditmogelijkheden. De rode draad is dat ze er allemaal van uitgaan dat u Mei's vraag kunt beantwoorden. AI governance is het werk dat nodig is om dat te kunnen.

2. Virtual Keys: Toegang Loskoppelen van Provider Credentials

De kernoorzaak van Mei's probleem is de gedeelde provider key. Een virtual key lost dit op: in plaats van teams de echte provider credential te geven, geeft u elk team of elke app een eigen, door de gateway beheerde key die op de gateway wordt gekoppeld aan de onderliggende provider key. De applicatie authenticeert met de virtual key; de gateway beheert de echte key.

Die enkele tussenstap levert het grootste deel van de governance op. Gebruik wordt toegeschreven aan de virtual key, zodat uitgaven en datatoegang per team kunnen worden gerapporteerd (het artikel over kostenattributie bouwt hier direct op voort). Intrekking is lokaal — u kunt de virtual key van één team uitschakelen zonder de provider key voor alle anderen te roteren. En toegang is af te bakenen — een virtual key kan worden beperkt tot specifieke modellen, routes of dataklassen. De provider credentials bevinden zich op één plek, de gateway, in plaats van verspreid over een dozijn serviceconfiguraties waar ze niet overzichtelijk bijgehouden of geroteerd kunnen worden. In TrueFoundry's AI Gateway zijn virtual keys de eenheid die gebruik, budgetten en toegangsbeleid koppelt aan een team of applicatie in plaats van aan een ondoorzichtige gedeelde credential.

3. RBAC en Policy-as-Code: Wie Mag Wat Aanroepen

Virtual keys stellen de identiteit vast; RBAC en policy bepalen wat die identiteit mag doen. De vragen zijn concreet: welke teams mogen het kostbare frontier model gebruiken, welke mogen een specifieke provider bereiken, welke mogen welke tools aanroepen (in een MCP-setting), en welke dataklassen mogen waarheen worden gestuurd. Door dit vast te leggen als policy-as-code — met een engine zoals Cedar of OPA — worden de regels expliciet, toetsbaar en te beheren via versiebeheer, in plaats van te bestaan als informele kennis of verspreide voorwaarden in de code.

Toegangsbeleid ter illustratie (conceptueel — het precieze schema is gateway-specifiek)# Alleen het research-team mag het frontier model aanroepen.allow if principal.team == "research" and resource.model == "gpt-5.5"# Verzoeken met klantdata moeten op een binnen de EU gehost model blijven.deny  if request.data_class == "customer_pii"      and resource.region != "eu"# Het finance-team mag geen externe providers aanroepen — alleen self-hosted.allow if principal.team == "finance" and resource.kind == "self_hosted"

De waarde van policy-as-code is dat het "wie wat mag aanroepen" verandert in iets dat u kunt beoordelen in een pull request, kunt testen en kunt bewijzen aan een auditor — dezelfde governance-discipline die wordt toegepast op MCP-tooltoegang in TrueFoundry's MCP security werk, waar Cedar en OPA controleren welke tools een agent mag aanroepen. De gateway is het handhavingspunt omdat het de enige plek is die elk verzoek passeert voordat het een provider of tool bereikt.

4. Budgetten, Quota en Rate Limits als Governance

Budgetten en rate limits worden meestal gezien als bescherming tegen misbruik of onbeheersbare kosten. In een governance-context zijn het ook middelen voor eerlijke verdeling en verantwoording: elk team krijgt een gedefinieerd aandeel, overschrijdingen zijn zichtbaar en geen enkel team kan ongemerkt het volledige modelbudget van de organisatie verbruiken. Het mechanisme bestaat uit harde en zachte limieten per team of virtual key, waarschuwingen wanneer een limiet wordt genaderd, en handhaving — doorgaans een 429-melding — wanneer deze wordt overschreden, hetzelfde handhavingspad als beschreven in het artikel over kostenattributie.

De benadering vanuit governance verandert de manier waarop u ze instelt. Een zachte limiet met alerting is een hulpmiddel voor verantwoording — het laat een budgethouder weten dat zijn team afstevent op een overschrijding, zonder de productie te verstoren. Een harde limiet is een waarborg tegen extreme gevallen, zoals de stil escalerende cascade uit het routing-artikel. Rate limits per key fungeren tevens als een meganisme voor eerlijk gebruik bij gedeelde capaciteit, om te voorkomen dat een batchjob van het ene team het interactieve verkeer van een ander team blokkeert. Door deze in te stellen op de TrueFoundry AI Gateway gelden ze consistent per virtual key, in plaats van dat ze per service opnieuw moeten worden geïmplementeerd.

Het schema is bewust regelgebaseerd, zodat een policy leest zoals u het aan een auditor zou uitleggen: wie (entities: gebruikers, teams, virtuele accounts of een aangepaste metadata-key), wat (modellen), hoeveel (limiet en eenheid — verzoeken of tokens per minuut, uur of dag), en hoe afgebakend (één gedeelde limiet, of een afzonderlijke limiet per gebruiker / per model / per metadata-waarde via rate_limit_applies_per). Regels worden op volgorde geëvalueerd en de eerste match wint, waardoor specifieke regels boven algemene opvangers staan:

gateway-rate-limiting-config (werkelijk schema uit TrueFoundry-documentatie)

Onder de motorkap maakt de handhaving gebruik van een sliding-window token-bucket algoritme met twaalf buckets van 5 seconden, opgeteld over een venster van 60 seconden — flexibel genoeg om een korte piek op te vangen zonder een team te blokkeren, maar strikt genoeg om een doorgedraaid script binnen enkele seconden te stoppen. Omdat de gateway de identiteit herleidt (PAT of VAT → gebruiker, team, virtueel account) en bij elke call de X-TFY-METADATA uitleest, dekt dezelfde regelstructuur de vier governance-doelgroepen die één beleid meestal moet bedienen: een ontwikkelaar met een limiet per key, een team met een gezamenlijke limiet, een model met een globale limiet en een project met een limiet op basis van een metadata-tag.

Het auditverhaal is de andere helft. Elke rate-limit-beslissing, elk guardrail-resultaat, elke fallback-stap en elke model-call komt terecht op dezelfde request trace (x-tfy-trace-id in de respons). Diezelfde trace is wat wordt getoond via Request Traces in de UI en wordt geëxporteerd via OpenTelemetry. Dat is wat "we hebben logs" verandert in "we hebben een audit trail die we aan een toezichthouder kunnen overleggen."

5. Compliance-Grade Audit Logs: Wanneer een Log Standhoudt

"We hebben logs" en "we hebben een compliance-grade audit trail" zijn twee verschillende beweringen. Een log die standhoudt bij een audit heeft vier eigenschappen. Hij is onveranderlijk (immutable) — invoer kan achteraf niet worden bewerkt of verwijderd. Hij is compleet — elke call legt vast wie (welk team/welke virtual key), wat (model, route, actie), wanneer, en welke datacategorie erbij betrokken was. Hij is tamper-evident — gegevens bevatten bijvoorbeeld een cryptografisch trace ID of hash-keten zodat aanpassingen aantoonbaar zijn. En hij is exporteerbaar — hij streamt naar uw SIEM in plaats van alleen te bestaan in een vendor-dashboard dat u niet kunt bevragen.

Dit is de laag waarmee Mei haar vraag had kunnen beantwoorden: een onveranderlijk, per team en per datacategorie getagd overzicht van elke call, geëxporteerd naar de SIEM, achteraf opvraagbaar. Dit bouwt rechtstreeks voort op de tracing uit het OpenTelemetry-artikel — dezelfde spans die observability mogelijk maken, maar met de volledigheid en onveranderlijkheid die een audit vereist.

6. Data-Residentie en Soevereiniteit

Bij gereguleerde data is de locatie waar een verzoek wordt verwerkt op zichzelf een governance-beslissing, die wordt afgedwongen via routing. Regio-bewuste routing zorgt ervoor dat verzoeken met Europese persoonsgegevens op endpoints binnen de EU blijven. Provider-beperkingen voorkomen dat specifieke dataklassen bepaalde providers überhaupt bereiken. En voor de meest gevoelige data zorgen self-hosted open-weight modellen ervoor dat de verwerking volledig binnen uw eigen infrastructuur blijft, zodat gereguleerde inhoud uw omgeving nooit verlaat.

Deze beslissingen sluiten aan op de policy-engine uit sectie 3: beleid dat stelt dat "klant-PII alleen mag worden verwerkt op een in de EU gehuisvest model" is een residentieregel uitgedrukt als toegangsbeleid, en de gateway dwingt dit af door overeenkomstig te routeren — of te weigeren te routeren. Omdat TrueFoundry's AI Gateway gehoste en self-hosted modellen via één interface ontsluit, wordt residentie een routingregel in plaats van een afzonderlijke integratie, en wordt de keuze waar een dataklasse wordt verwerkt net als elke andere beslissing gelogd.

7. Gateway-Controls Afstemmen op de EU AI Act (Zorgvuldig)

De EU AI Act wordt gefaseerd ingevoerd: verboden praktijken en verplichtingen rond AI-geletterdheid gelden sinds februari 2025, verplichtingen voor AI-modellen voor algemene doeleinden sinds augustus 2025, en de verplichtingen voor hoog-risicosystemen — risicobeheer, data governance, verslaglegging/logging, transparantie en menselijk toezicht — worden verwacht rond augustus 2026. De planning voor specifieke toepassingen van hoog-risicosystemen (Bijlage III) is echter onderhevig aan het Digital Omnibus-vereenvoudigingsvoorstel van de Commissie, dat zich op het moment van schrijven in de triloogfase bevindt en delen kan uitstellen naar december 2027. De datums veranderen; beschouw dit als een bewegend vlak en controleer altijd de actuele regelgeving.

Waar een gateway ondersteunt, is de operationele basis die bij verschillende van deze verplichtingen wordt verondersteld. Verslaglegging en automatische logging sluiten aan op het compliance-grade audit log (sectie 5). Menselijk toezicht sluit aan op de human-in-the-loop controlepunten die in het prompt-injection-artikel zijn besproken voor acties met een hoog risico. Data governance sluit aan op residentie-routing en PII-guardrails. Transparantieverplichtingen worden ondersteund door te kunnen aantonen wat het systeem heeft gedaan en met welke data.

8. Guardrails als Gehandhaafd Beleid

Governance gaat niet alleen over toegang en budgetten; het gaat ook over welke inhoud mag doorstromen. De guardrails uit de rest van deze reeks — PII/PHI-detectie, bescherming tegen prompt-injection, contentmoderatie, detectie van geheimen — zijn governance-controls wanneer ze worden gehandhaafd als beleid in plaats van overgelaten aan de keuze van afzonderlijke applicaties. "Klant-PII wordt op elke route gecensureerd" en "outputs worden gecontroleerd voordat ze in een logging-systeem terechtkomen" zijn beleidsregels, en de aangewezen plek om deze uniform af te dwingen is de gateway.

Dit maakt de cirkel rond met de eerdere artikelen. De vier invoegpunten uit het PII-artikel, de input/output-guardrails uit het prompt-injection-artikel, en de RBAC en audit uit dit artikel zijn facetten van één control plane: identiteit bepaalt wie, policy bepaalt wat ze mogen aanroepen, guardrails bepalen welke inhoud mag passeren, budgetten bepalen hoeveel, residentie bepaalt waar, en het audit log legt alles vast. TrueFoundry's guardrails draaien op de LLM- en MCP-hooks als gehandhaafd, configureerbaar beleid, wat van goede intenties een vorm van governance maakt die een auditor daadwerkelijk kan verifiëren.

9. Veelgestelde Vragen

Wat is het verschil tussen een virtual key en simpelweg gescheiden provider keys per team?

Gescheiden provider keys bieden enige attributie, maar laten de echte credentials verspreid achter in serviceconfiguraties, waar ze moeilijk te roteren zijn en snel kunnen lekken, en ze bevatten geen beleid. Een virtual key wordt beheerd door de gateway: deze wordt centraal gekoppeld aan de echte provider key, bevat het RBAC-, budget- en residentiebeleid van het team, en kan worden ingetrokken of aangepast zonder de provider credential of andere teams te raken. Het gaat om de tussenlaag.

Beteekent een audit log dat de prompts zelf worden gelogd?

Nee — en dat moet u meestal ook niet willen. Log de metadata die nodig is om te reconstrueren wat er is gebeurd: team, model, route, actie, datacategorie, guardrail-events, tijdstempel en een trace ID. Het loggen van ruwe prompt-inhoud veroorzaakt opnieuw het probleem met gevoelige data dat PII-guardrails juist moeten voorkomen. Compliance-grade betekent compleet qua metadata en onveranderlijk, niet een letterlijk transcript van gebruikersdata.

Maken gateway-controls ons compliant met de EU AI Act?

Nee. Het helpt te voldoen aan specifieke operationele verplichtingen — verslaglegging, logging, ondersteuning van menselijk toezicht, data governance — maar compliance hangt af van uw risicoclassificatie, uw rol als aanbieder of gebruiker, documentatie en conformiteitsbeoordelingen die geen enkele gateway uitvoert. Beschouw de gateway als noodzakelijke infrastructuur en raadpleeg de wetgeving en juristen voor wat uw specifieke toepassing vereist. De tijdlijnen veranderen bovendien nog onder het Digital Omnibus-voorstel.

Is dit niet gewoon hetzelfde als het artikel over kostenattributie?

Ze delen de basis van virtual keys en attributie per team, maar de invalshoek verschilt. Het kosten-artikel gaat over uitgaven — wie ze veroorzaakt, budgetten, verrekening. Dit artikel gaat over beheer en verantwoording — wie wat mag aanroepen, welke inhoud mag stromen, wat er wordt vastgelegd voor een audit, waar gereguleerde data wordt verwerkt. Dezelfde control plane, maar met andere verplichtingen die erop rusten.

Waar moet governance worden toegepast — in de app of in de gateway?

In de gateway, omdat governance per definitie organisatiebreed is: één consistente set regels voor toegang, budget, residentie en audit over elke service, gehandhaafd op het centrale punt waar elk verzoek langs komt. Governance per app leidt tot afwijkingen en hiaten — zo kan een gedeelde key jarenlang blijven bestaan. De applicatie blijft wel eigenaar van domeinspecifieke beslissingen, zoals bepalen welke acties voldoende risico dragen om menselijke goedkeuring te vereisen.

Mei's auditbevinding was geen datalek; het was het onvermogen om vragen te beantwoorden. Governance is het werk om die vragen vooraf beantwoordbaar te maken — wie, wat, hoeveel, waar en op wiens data — en de gateway is de plek waar die antwoorden worden gehandhaafd en vastgelegd, verzoek voor verzoek.

Over TrueFoundry

TrueFoundry's AI Gateway is een enterprise-grade control plane die zich bevindt tussen uw applicaties en 1.600+ modellen — waaronder OpenAI, Anthropic, Google, AWS Bedrock, Azure OpenAI en uw eigen self-hosted modellen — achter één enkele OpenAI-compatibele API. Het verandert de governance-controls uit dit artikel in configuratie in plaats van code per service: Virtual Accounts voor niet-menselijke productie-identiteiten, Personal Access Tokens voor ontwikkeling, RBAC afgebakend per provider-account, rate-limit- en budgetregels uitgedrukt in YAML met scopes per gebruiker/team/model/metadata, en policy-as-code guardrails (Cedar en OPA) bij de MCP-toolgrens.

Omdat de gateway al bij elk verzoek betrokken is en een complete trace genereert voor elke call, is dit ook de plek waar compliance-grade audit praktisch uitvoerbaar wordt. Identiteit, beleidsbeslissingen, guardrail-resultaten, modelkeuze, aantallen tokens en kosten komen allemaal terecht op hetzelfde trace ID — zichtbaar in Request Traces in de UI, exporteerbaar via OpenTelemetry en toegankelijk via API voor SIEM-integratie. Dezelfde gateway biedt exacte en semantische caching, fallbacks en retries, en observability-dashboards. Het kan worden ingezet als SaaS of in uw VPC, on-premise, of air-gapped met SOC 2, HIPAA en ITAR compliance, en is erkend in Gartner's Market Guide voor AI Gateways. Bekijk de documentatie over toegangsbeheer, rate limiting en guardrails, of het AI Gateway-overzicht voor meer informatie.

Referenties

• TrueFoundry AI Gateway — virtual keys, RBAC, budgetten en audit
• TrueFoundry — AI Gateway guardrails als gehandhaafd beleid
• Europese Commissie — Regelgevingskader voor AI (de AI Act)
• Cedar en Open Policy Agent (OPA) — policy-as-code engines

Northwind en Mei zijn ter illustratie. De governance-patronen — virtual keys, RBAC, policy-as-code, audit logging, residency routing — zijn standaard control-plane-practices toegepast op LLM-verkeer. EU AI Act-datums en -verplichtingen zijn samengevat uit de door de Europese Commissie gepubliceerde tijdlijn en rapportage per mei 2026 en zijn onderhevig aan lopende wijzigingen (met name het Digital Omnibus-voorstel in de triloog); deze post is technische begeleiding, geen juridisch advies, en de beschreven gateway-controls helpen bij het voldoen aan specifieke verplichtingen in plaats van compliance te garanderen. Bevestig de huidige vereisten aan de hand van de wetgeving en gekwalificeerde juridische adviseurs voor jouw use case.