LLM-deployment in gereguleerde sectoren: HIPAA-, SOC2- en GDPR-playbook voor 2026

De technische uitdaging van het deployen van een Large Language Model in een gereguleerde onderneming is in de eerste plaats geen machine learning-probleem. De modellen bestaan, ze werken en ze zijn krachtig genoeg voor serieuze klinische, financiële en verzekeringsgerelateerde use cases. De uitdaging ligt in de architectuur rondom het model: wie beheert de data, waar stroomt deze naartoe, wat wordt er gelogd, wie heeft de leverancier goedgekeurd en hoe kan het compliance-team dat alles aantonen aan een toezichthouder.

Medtronic, met 90.000 werknemers en een door de FDA gereguleerde apparatenportfolio, draait AI in productie. Innovaccer verwerkt beschermde gezondheidsinformatie op schaal binnen een beheerd klinisch intelligentieplatform. Aviva, dat valt onder de UK GDPR, zet AI in voor verschillende verzekeringsworkflows. Siemens Healthineers heeft AI gelijktijdig in meerdere regelgevende jurisdicties gedeployed. Dit zijn geen proofs of concept. Het zijn enterprise-scale productie-deployments die de juridische, compliance- en IT-beveiligingsreviews met succes hebben doorstaan.

De architectuur die al deze deployments mogelijk maakte, is het onderwerp van dit playbook. Het behandelt de specifieke regelgevingsvereisten voor de gezondheidszorg, financiële dienstverlening en verzekeringen, de technische keuzes die door deze vereisten worden gedreven, en hoe een beheerde, VPC-geïsoleerde deployment er in de praktijk uitziet voor teams die zich voorbereiden op hetzelfde goedkeuringsproces.

Wat AI-deployment in gereguleerde sectoren anders maakt

De verschillen tussen gereguleerde en niet-gereguleerde AI-deployment zijn niet primair technisch van aard. De onderliggende modellen zijn hetzelfde. Het verschil zit in de wettelijke verplichtingen, de verantwoordelijkheidsstructuur en de auditlast, en die zaken veranderen de architectuurbeslissingen vanaf de basis.

• Regels voor dataverwerking worden extern vastgesteld. In gereguleerde omgevingen worden toegestane manieren van datagebruik bepaald door de wet, niet door het oordeel van engineers. Een AI-systeem dat patiëntdossiers naar een externe API stuurt, kan technisch elegant zijn en tegelijkertijd een HIPAA-schending vormen. De technische verfijning van de implementatie is niet relevant voor de juridische norm. Wat telt is waar de data naartoe is gegaan en of er toestemming was om deze daarheen te sturen.

• AI-systemen vallen nu binnen de scope van regelgevende audits. Toezichthouders in de gezondheidszorg, financiële dienstverlening en verzekeringen verwachten in toenemende mate dat organisaties documenteren tot welke data hun AI-systemen toegang hadden, op welke beslissingen die systemen invloed hadden, wie de deployment heeft geautoriseerd en hoe het proces van menselijk toezicht eruitzag. De HIPAA Security Rule vereist passende waarborgen, waaronder encryptie at rest en in transit, op basis van een risicoanalyse. De bewijslast voor compliance rust te allen tijde bij de organisatie.

• Uw AI-leverancier valt binnen uw compliance-scope. Elke leverancier die namens u beschermde gezondheidsinformatie aanmaakt, ontvangt, onderhoudt of verzendt, is onder HIPAA een Business Associate en vereist wettelijk een ondertekende BAA voordat PHI hun infrastructuur raakt. De meeste standaard openbare LLM API-aanbiedingen vallen niet standaard onder een BAA en vereisen enterprise-overeenkomsten of alternatieve deploymentmodellen. AWS Bedrock en Azure OpenAI Service bieden opties die in aanmerking komen voor een BAA met specifieke configuratievereisten, maar geschiktheid is niet hetzelfde als compliance.

• Dataresidentie kan SaaS-opties volledig uitsluiten. Een Europese verzekeraar die persoonsgegevens verwerkt die onder de GDPR vallen, mag die data juridisch niet via in de VS gevestigde infrastructuur routeren zonder een regeling op basis van Standard Contractual Clauses of een ander goedgekeurd GDPR-doorgiftemechanisme. Veel SaaS AI gateway-producten zijn in de VS gevestigd, wat betekent dat documentatie voor gegevensoverdracht van de EU naar de VS moet zijn afgerond voordat er een technische deployment begint. Voor sommige organisaties en datatypen sluit dit de SaaS-optie volledig uit.

• Audit trails zijn niet optioneel, en gestructureerde trails hebben de voorkeur. Elke toegang tot gereguleerde data, inclusief AI-ondersteunde toegang, moet een auditrecord genereren. Voor HIPAA moet dat record een tijdstempel, de identiteit van de persoon/het systeem dat toegang zoekt, de uitgevoerde actie en een verwijzing naar de geopende PHI bevatten. AI-systemen die deze records automatisch in gestructureerd JSON-formaat genereren, zijn deploybaar. Systemen die handmatige logcorrelatie achteraf vereisen, veroorzaken compliance-lacunes die toezichthouders niet als gelijkwaardig accepteren.

Gezondheidszorg: HIPAA-vereisten voor LLM-deployments

HIPAA is van toepassing op elk systeem dat Protected Health Information verwerkt. Een LLM-deployment valt binnen de scope als het model PHI kan ontvangen in prompts, als PHI verschijnt in retrieval-augmented generation-context die aan het model wordt doorgegeven, of als model-outputs beslissingen over individuele patiënten beïnvloeden. Samenvattingen van klinische notities, analyses van patiëntendossiers, diagnostische hulpmiddelen en ondersteuning bij voorafgaande toestemming (prior authorization) vallen allemaal binnen deze grens.

Drie HIPAA-regels geven rechtstreeks vorm aan de architectuur van LLM-deployments. De Privacy Rule regelt waar PHI voor mag worden gebruikt en wie er toegang toe heeft, inclusief de norm van het "minst noodzakelijke" (minimum necessary) die de blootstelling van data beperkt tot wat nodig is voor de specifieke taak. De Security Rule vereist administratieve, fysieke en technische waarborgen voor elektronische PHI, inclusief access controls, audit logging en transmissiebeveiliging. De Breach Notification Rule bepaalt wat er gebeurt als waarborgen falen. Alle drie hebben ze technische implementatievereisten die tot uiting komen in de manier waarop de AI-infrastructuur is ontworpen, niet alleen in de beleidsdocumenten.

PHI-isolatie: Waarom de meeste cloud LLM-API's niet geschikt zijn voor klinische use cases

• Standaard consumenten-API-aanbiedingen van OpenAI, Anthropic en Google zijn over het algemeen niet ontworpen voor door HIPAA gereguleerde workloads en bieden doorgaans geen Business Associate Agreements (BAA's) voor hun openbare eindpunten. Wanneer PHI wordt verzonden naar een dienst van derden die optreedt als business associate zonder dat er een BAA is ingesteld, vormt dit een schending van de HIPAA-compliance. Dit is een van de meest voorkomende faalmodi bij vroege AI-deployments in bedrijven die sneller bewegen dan hun governanceprocessen voor leveranciers.

• AWS en Microsoft bieden beiden HIPAA Business Associate Agreements die specifieke geschikte diensten binnen hun platforms dekken. AWS omvat geschikte diensten onder de standaard BAA, terwijl Microsoft dekking biedt via het Online Services Data Protection Addendum. Compliance hangt echter af van het uitsluitend gebruiken van diensten die binnen de scope vallen en het correct configureren ervan. Encryptie at rest en in transit, audit logging en least-privilege IAM-controls zijn verplicht. Het ondertekenen van een BAA is een voorwaarde, niet de eindstatus van compliance.

• Voor klinische use cases waarbij PHI betrokken is, biedt een VPC-geïsoleerde of zelf-gehoste model-deployment de meest heldere architectonische grens. Wanneer modellen draaien binnen het eigen cloudaccount van de organisatie, blijft PHI binnen de enterprise-perimeter en wordt het niet blootgesteld aan externe modelaanbieders. Dit neemt de noodzaak weg voor een afzonderlijke BAA met een externe model-API-leverancier, hoewel een BAA met de onderliggende cloudprovider (bijvoorbeeld AWS of Azure) vereist blijft als onderdeel van de algehele compliancestatus.

• Voor organisaties die in beperkte scenario's externe model-API's moeten gebruiken, kan datamasking of anonimisering een bruikbaar patroon zijn. Gevoelige velden worden verwijderd of getokeniseerd voordat het verzoek wordt verzonden, en pas binnen de gecontroleerde omgeving gereconstrueerd nadat de respons is ontvangen. Om compliant te zijn, moet de transformatie ervoor zorgen dat er geen identificeerbare PHI wordt blootgesteld aan de externe dienst, en moet het proces worden gedocumenteerd, gevalideerd en aantoonbaar zijn voor auditors als onderdeel van de compliance-controls van de organisatie.

HIPAA auditlog-vereisten voor AI-systemen

• De HIPAA Security Rule vereist dat gedekte entiteiten en business associates audit-controls implementeren die de activiteit registreren en onderzoeken in systemen die elektronische PHI verwerken. In de praktijk betekent dit dat systemen logs moeten genereren die toegangsevents vastleggen op een manier die onderzoek en verantwoording ondersteunt. Hoewel de regelgeving geen exacte velden voorschrijft, bevatten implementaties volgens de industriestandaard tijdstempels, gebruikers- of systeemidentiteit, de uitgevoerde actie en de geopende data of het geopende systeem. Voor LLM-deployments strekt dit zich uit tot het vastleggen van welke gebruiker of agent een verzoek heeft geïnitieerd, welk model het heeft verwerkt, en voldoende context om te reconstrueren wat er is gebeurd. Geaggregeerde gebruiksmetrieken alleen zijn niet voldoende om audits of incidentenonderzoek te ondersteunen.

• HIPAA vereist dat documentatie met betrekking tot beveiligingscontroles, inclusief auditrecords waar van toepassing, minimaal zes jaar wordt bewaard. Bovendien moeten systemen integriteitscontroles implementeren om logs te beschermen tegen ongeautoriseerde wijziging of verwijdering. In de praktijk wordt dit vaak bereikt door middel van onveranderlijke opslagmechanismen zoals write-once-read-many (WORM)-configuraties, strikte access controls en gecentraliseerde logbeheersystemen die wijziging door operationele teams voorkomen.

• HIPAA vereist mechanismen om gebruikers die toegang hebben tot systemen met ePHI uniek te identificeren en te authenticeren. Als gevolg hiervan moeten auditlogs toegangsevents kunnen toeschrijven aan een specifieke individuele of systeemidentiteit. Implementaties die uitsluitend vertrouwen op gedeelde service-accounts of API-sleutels zonder toeschrijving op gebruikersniveau veroorzaken lacunes in de verantwoording en maken het moeilijk om aan audit- en onderzoeksvereisten te voldoen. In moderne AI-systemen vereist dit doorgaans de integratie van identiteitsbewuste access controls, zodat acties die via agents of gateways worden uitgevoerd, kunnen worden teruggeleid naar de oorspronkelijke gebruiker.

Access Control-vereisten

• HIPAA vereist dat de toegang tot PHI wordt gecontroleerd via technische en administratieve waarborgen, waaronder unieke gebruikersidentificatie, authenticatie en role-based access controls. Bovendien handhaaft de Privacy Rule de norm van het "minst noodzakelijke" (minimum necessary) voor het gebruik en de openbaarmaking van PHI. In de praktijk betekent dit dat toegang moet worden toegewezen en beheerd via een gedocumenteerd proces, waarbij de rechten zijn afgestemd op de rol van de gebruiker. Voor AI-systemen heeft dit twee implicaties. Ten eerste moet de toegang worden gekoppeld aan individuele identiteiten via de identity provider van de organisatie, niet aan gedeelde API-sleutels die niet aan specifieke gebruikers kunnen worden toegeschreven. Ten tweede moeten role-based controls ervoor zorgen dat gebruikers alleen toegang hebben tot AI-functionaliteiten die passen bij hun functie, bijvoorbeeld door facturatie-workflows te scheiden van klinische workflows met verschillende PHI-blootstelling.

• De norm van het minst noodzakelijke geldt voor hoe PHI binnen een systeem wordt gebruikt, niet alleen voor welke gebruiker de toegang initieert. In AI-systemen strekt dit zich uit tot de data die is opgenomen in model-prompts en -context. Het doorgeven van volledige patiëntendossiers wanneer slechts een subset van gestructureerde velden vereist is, is mogelijk niet in lijn met het principe van het minst noodzakelijke. Hoewel HIPAA niet expliciet definieert hoe dit van toepassing is op AI-prompts, wordt van organisaties verwacht dat ze de blootstelling van PHI beperken tot wat nodig is voor de taak. Het afdwingen hiervan op de infrastructuurlaag, bijvoorbeeld via een AI-gateway die contextbewuste databepalingen toepast op basis van gebruikersrol en use case, is een aanpak om consistente naleving te garanderen in plaats van te vertrouwen op implementatie op applicatieniveau.

Financiële dienstverlening: SOC2 en regelgevende vereisten voor LLM-deployments

Financiële instellingen die LLM's deployen, hebben te maken met een gelaagde regelgevende omgeving. SOC2 Type II-vereisten zijn van toepassing op de technologie-infrastructuur. Richtlijnen van de OCC, Federal Reserve en FINRA op het gebied van AI en modelrisico zijn van toepassing op modellen die worden gebruikt bij financiële beslissingen. En bepalingen uit de EU AI Act voor AI-systemen met een hoog risico, die vanaf augustus 2026 handhaafbaar zijn voor EU-activiteiten, voegen nog een laag toe voor internationale organisaties. Deze kaders overlappen elkaar op manieren die specifieke architectuurvereisten creëren voor AI-gateway- en modeldeployment-infrastructuur.

SOC2 Type II-controls voor AI-infrastructuur

• AI-gateways en modeldeployment-platforms die financiële data verwerken, vallen binnen de scope voor SOC2 Type II-beoordelingen wanneer ze in aanraking komen met data of systemen die onder de audit vallen. De relevante trust service criteria zijn CC6 (logische en fysieke access controls), CC7 (monitoring van systeemoperaties), CC8 (wijzigingsbeheer) en CC9 (risicobeperking). Elk criterium vereist specifieke technische controls die aanwezig moeten zijn in of naast de AI-gateway.

• De meest voorkomende SOC2-bevinding bij deployments van AI-gateways is ontoereikende access control op API-niveau: gedeelde service-accounts die toegang niet aan individuen kunnen toeschrijven, API-sleutels die in de broncode zijn opgeslagen, of AI-platforms die de door CC6 vereiste fijnmazige access controls niet ondersteunen. Door te kiezen voor een platform dat integreert met de enterprise identity provider en RBAC afdwingt op model- en teamniveau, worden deze bevindingen geëlimineerd voordat de auditperiode begint.

• SOC2 Type II vereist continu bewijs van de werking van controls gedurende de auditperiode, doorgaans zes tot twaalf maanden. Dit betekent dat auditlogs continu moeten worden gegenereerd en gedurende de gehele periode moeten worden bewaard, en niet pas op verzoek worden verzameld wanneer auditors erom vragen. AI-gatewayplatforms die vanaf de eerste dag van de deployment gestructureerde, continue logs produceren, zijn aanzienlijk eenvoudiger te auditeren dan systemen waar logging achteraf is toegevoegd. Het auditbewijs moet aantonen dat de controls gedurende de gehele periode consistent hebben gewerkt, niet alleen op het moment van de audit.

Model Risk Management (SR 11-7) voor LLM's

• De OCC- en Federal Reserve-richtlijn SR 11-7 inzake Model Risk Management is van toepassing op AI- en LLM-modellen die worden gebruikt bij kredietbeslissingen, risicobeoordeling en andere processen die relevant zijn voor de regelgeving. De richtlijn vereist drie dingen voor elk model dat binnen de scope valt: documentatie van het doel, de trainingsdata en de testmethodologie; onafhankelijke validatie aan de hand van gedefinieerde prestatienormen; en voortdurende monitoring met prestatie-tracking en drift-detectie.

• Voor LLM's in de financiële dienstverlening strekt de SR 11-7-documentatielast zich uit tot de infrastructuur waarop het model draait. Welke LLM wordt gebruikt, door welke teams, voor welke beslissingen, tegen welke kosten, met welke latency en met welk waargenomen outputgedrag: dit moet allemaal worden gedocumenteerd en beschikbaar zijn voor beoordeling door toezichthouders. Een AI-gateway die deze data automatisch verzamelt als onderdeel van zijn standaard-logging, levert het bewijs voor modeldocumentatie als bijproduct van de normale bedrijfsvoering. Dit vermindert wat anders een aanzienlijke handmatige documentatie-inspanning zou zijn voor elk model dat binnen de scope valt.

Verzekeringen: Dataresidentie en GDPR-vereisten

Verzekeraars die in meerdere jurisdicties actief zijn, worden geconfronteerd met beperkingen op het gebied van dataresidentie en grensoverschrijdende gegevensoverdracht die de keuzes voor de AI-architectuur rechtstreeks beperken. GDPR, UK GDPR en de privacywetten van Amerikaanse staten bevatten allemaal bepalingen die van invloed zijn op waar en hoe klantgegevens kunnen worden verwerkt, inclusief de vraag of deze naar een AI-model-API kunnen worden gestuurd voor inference.

• GDPR-rechtsgrond voor verwerking: AI-systemen die persoonsgegevens verwerken, moeten beschikken over een gedocumenteerde rechtmatige grondslag onder GDPR Artikel 6. Voor de meeste AI-use cases in de verzekeringsbranche is de grondslag hetzij gerechtvaardigd belang, hetzij contractuele noodzaak. Beide vereisen dat de verwerking wordt gedocumenteerd, in verhouding staat tot het doel en wordt vermeld in de privacyverklaring van de organisatie. AI-systemen die persoonsgegevens verwerken zonder een gedocumenteerde rechtmatige grondslag zorgen voor directe blootstelling aan regelgeving binnen een kader waarin boetes kunnen oplopen tot 4% van de wereldwijde jaaromzet.

• Beperkingen op grensoverschrijdende doorgifte: Het verzenden van persoonsgegevens van inwoners van de EU naar niet-EU AI-infrastructuur vereist hetzij een regeling op basis van Standard Contractual Clauses, hetzij een ander goedgekeurd GDPR-doorgiftemechanisme. Veel AI SaaS-aanbieders zijn in de VS gevestigd. Documentatie ter naleving van gegevensoverdracht van de EU naar de VS moet met juridische betrokkenheid worden afgerond voordat de technische deployment begint. Voor sommige datatypen en voor de risicotolerantie van sommige organisaties vereist deze eis in feite een Europese of volledig VPC-geïsoleerde deployment waarbij geen data de grenzen van de jurisdictie overschrijdt.

• Verwerkingsregister onder Artikel 30: De GDPR vereist dat organisaties een register van verwerkingsactiviteiten bijhouden dat ook betrekking heeft op AI-systemen, waarin het verwerkingsdoel, de datacategorieën, eventuele internationale overdrachten en de toegepaste beveiligingsmaatregelen worden beschreven. Auditlogs van AI-gateways leveren de ruwe data voor deze registers, maar moeten zo worden geconfigureerd dat ze de vereiste velden vastleggen, waaronder datacategorie, verwerkingsdoel en bestemming van de overdracht, in een formaat dat het compliance-team op verzoek aan een toezichthouder kan overleggen.

• Recht op uitleg bij geautomatiseerde besluitvorming: GDPR Artikel 22 beperkt volledig geautomatiseerde besluiten die individuen aanzienlijk treffen en geeft individuen het recht op een duidelijke uitleg over hoe het besluit tot stand is gekomen. AI-systemen in de verzekeringssector die ondersteunen bij acceptatie of schadeafhandeling moeten zo worden ontworpen dat de mogelijkheid tot menselijke beoordeling en de generatie van uitleg in de workflow zijn ingebouwd, en niet als bijzaak zijn toegevoegd. De architectuurbeslissing over hoe AI-aanbevelingen naar menselijke besluitvormers stromen, is een compliance-beslissing, niet alleen een keuze voor productontwerp.

De VPC-geïsoleerde architectuur: Hoe het er in de praktijk uitziet

VPC-geïsoleerde LLM-deployment is het architectuurpatroon dat gelijktijdig voldoet aan de meest uiteenlopende vereisten in gereguleerde sectoren. PHI-isolatie voor HIPAA, dataresidentie voor GDPR, netwerkbeveiligingscontroles voor SOC2 en operationele verantwoording voor toezichthouders in de financiële sector vloeien allemaal voort uit een correct geïmplementeerde VPC-deployment. Begrijpen wat dit daadwerkelijk inhoudt, is wat compliance-, infrastructuur- en beveiligingsteams nodig hebben voorafgaand aan een goedkeuringsgesprek.

• AI-gateway binnen de perimeter: De gateway draait als een gecontaineriseerde dienst binnen de VPC van de organisatie. Alle LLM API-calls lopen via deze interne gateway. Geen enkele applicatie communiceert rechtstreeks met een externe modelaanbieder. De gateway is het enige component met egress-functionaliteit naar externe API's, en alleen wanneer de gedeployde architectuur externe modeltoegang toestaat voor specifieke use cases waarbij geen gereguleerde data betrokken is. Bij volledig geïsoleerde deployments ontbreekt zelfs die egress.

• Model-serving binnen de perimeter: Voor HIPAA en strikte vereisten voor dataresidentie draait de LLM zelf binnen de VPC. AWS Bedrock benaderd binnen hetzelfde AWS-account, Azure OpenAI Service binnen een Azure-abonnement met passende BAA-dekking, of zelf-gehoste open-source modellen op GPU-infrastructuur binnen het cloudaccount voldoen allemaal aan deze eis. Bij volledig geïsoleerde deployments verlaat op geen enkel moment in de levenscyclus van het verzoek data van model-inference de grenzen van het cloudaccount van de organisatie.

• Auditlogs in opslag van de klant: Alle auditlogs worden geschreven naar de eigen logging-infrastructuur van de organisatie: CloudWatch, Azure Monitor, Splunk of een door de klant gespecificeerde SIEM. Logdata, die zelf gereguleerde informatie kan bevatten, wordt nooit doorgegeven aan de SaaS-loggingdienst van een leverancier. Bewaarbeleid, access controls en configuraties voor onveranderlijke opslag worden beheerd door het compliance-team van de organisatie, zonder afhankelijk te zijn van de bewaarinstellingen van een leverancier.

• Geen toegang voor leveranciers tot productieverkeer: In een correct geïmplementeerde VPC-geïsoleerde deployment blijven het productie-inferenceverkeer, de prompt-inhoud en de modelrespons binnen de cloudomgeving van de klant, in plaats van te worden gerouteerd via door de leverancier beheerde infrastructuur. Dit vermindert de externe zichtbaarheid in gevoelige datastromen aanzienlijk en sluit aan bij de vereisten voor dataresidentie en privacy. Ondersteuningstoegang, waar vereist, wordt geregeld via gecontroleerde, tijdgebonden "break-glass"-procedures met uitdrukkelijke goedkeuring van de klant, in plaats van permanente toegang. Deze architectuur minimaliseert de blootstelling van de leverancier aan gereguleerde data in het productiepad, hoewel de leveranciersrelatie voor platformsoftware en ondersteuning binnen de algehele compliance-scope van de organisatie blijft.

Hoe TrueFoundry LLM-deployment in gereguleerde sectoren oplost

TrueFoundry wordt volledig gedeployed binnen het cloudaccount van de klant op AWS, Azure of GCP. Geen enkele productiedata, inclusief prompt-inhoud, modelrespons, parameters voor MCP-toolaanroepen of auditlogdata, verlaat de perimeter van de onderneming naar de infrastructuur van TrueFoundry. Dit is geen optionele deploymentkeuze. Het is de standaardarchitectuur voor enterprise-deployments, geen premium tier.

• Standaard VPC-geïsoleerde deployment: TrueFoundry wordt in het eigen cloudaccount van de klant gedeployed met behulp van infrastructure-as-code. De AI-gateway, MCP-gateway, beheer-UI en opslag van auditlogs draaien allemaal binnen de perimeter van de klant. Vier deploymentopties dekken het volledige spectrum af, van volledig beheerde SaaS zonder infrastructuurkosten tot het volledige Control Plane plus Gateway Plane binnen het account van de klant tegen ongeveer $800 tot $1.000 per maand aan infrastructuurkosten. Voor gereguleerde workloads zorgen Optie 3 en 4 ervoor dat er geen data via de infrastructuur van TrueFoundry reist. TrueFoundry-ondersteuningstoegang maakt gebruik van gedocumenteerde break-glass-procedures met goedkeuring van de klant.

• Gestructureerde auditlogs afgestemd op HIPAA, SOC2 en GDPR: Elke LLM-call genereert een gestructureerde JSON-auditlog-entry via de X-TFY-LOGGING-CONFIG-header. Op gatewayniveau zorgt REQUEST_LOGGING-MODE: ALWAYS bij zelf-gehoste deployments ervoor dat elk verzoek wordt vastgelegd zonder configuratiedrift. Logvelden omvatten gebruikersidentiteit, model, aantallen tokens, latency, kosten, beleidsbeslissing en output. Logs worden via OpenTelemetry geëxporteerd naar Grafana, Datadog, Splunk of elke met OTLP compatibele SIEM. Bij zelf-gehoste deployments wordt logdata naar de eigen AWS S3-, GCS- of Azure Blob-opslag van de klant geschreven in Parquet-formaat met instelbare bewaartermijnen. S3 Object Lock in WORM-modus voldoet aan de HIPAA-eis voor onveranderlijke bevaring voor het minimum van zes jaar.

• SSO-integratie met klinische en enterprise-identiteitssystemen: TrueFoundry integreert met Okta, Azure Active Directory, PingFederate en elke met SAML 2.0 of JWKS compatibele identity provider. Access provisioning volgt het standaardproces voor identiteitslevenscyclusbeheer van de organisatie. Developers die zich bij een team aansluiten, krijgen toegang tot de AI-gateway via dezelfde IdP-workflow die hun andere systemen provisiont. Bij vertrekkende developers wordt de toegang ingetrokken via dezelfde offboarding-workflow. Er is geen afzonderlijk authenticatiesysteem voor de AI-gateway dat onafhankelijk moet worden onderhouden of geauditeerd.

• Goedgekeurde modelcatalogus voor gereguleerde workloads: Platformbeheerders bepalen welke modellen zijn goedgekeurd voor specifieke datatypen en use cases. Een klinisch team kan prompts met PHI niet routeren naar een model dat niet in aanmerking komt voor een BAA, omdat de gateway beleidsregels voor model-to-use-case afdwingt in de routinglaag voordat het verzoek de perimeter verlaat. Deze beleidshandhaving vindt plaats bij de AI-gateway, niet op de applicatielaag, wat betekent dat deze consistent geldt, ongeacht welke applicatie of agent het verzoek initieert.

• Geverifieerde productiedeployments in gereguleerde sectoren: Medtronic, met door de FDA gereguleerde portfolio's van medische hulpmiddelen, draait TrueFoundry in productie. Siemens Healthineers gebruikt het binnen wereldwijde medische technologieactiviteiten die te maken hebben met regelgeving in meerdere rechtsgebieden. Innovaccer verwerkt maandelijks ongeveer 17 miljoen klinische AI-inferentieverzoeken binnen AWS GovCloud onder HIPAA zonder dat er gegevens hun cloudgrens verlaten, waarbij gebruik wordt gemaakt van de gateway van TrueFoundry met OpenTelemetry die Grafana-dashboards voedt. Aviva draait TrueFoundry voor Britse verzekeringsactiviteiten onder GDPR. ResMed gebruikt het voor digitale gezondheidstoepassingen. Dit zijn productiedeployments op enterprise-schaal met goedkeuring voor naleving van de regelgeving, geen pilots.