AI Agents, HIPAA en het probleem van toegang tot PHI

Zorgorganisaties zetten AI-agenten in met een steeds hoger tempo. Klinische documentatieassistenten, workflows voor voorafgaande autorisatie, generatoren van ontslagrapporten en tools voor patiëntintake hebben één ding gemeen: ze hebben toegang tot beschermde gezondheidsinformatie. Dat maakt ze onderhevig aan HIPAA, op precies dezelfde manier als elke menselijke medewerker of business associate die PHI benadert onderhevig is aan HIPAA.

De nalevingsverplichtingen veranderen niet omdat de gebruiker een machine is. De Privacy Rule, Security Rule en Breach Notification Rule van HIPAA zijn geschreven rond de data, niet rond de persoon of het systeem dat deze raadpleegt. Een AI-agent die een patiëntendossier opvraagt, een laboratoriumresultaat ophaalt of een klinische samenvatting genereert, voert een gereguleerd data-accessevenement uit. Wat telt voor HHS en auditors is of die toegang geautoriseerd, gecontroleerd, versleuteld en gelogd was. De HIPAA Security Rule-wijzigingen van 2025 — de meest ingrijpende herziening van de Security Rule in jaren — maken deze verplichtingen specifieker en veeleisender, waardoor veel van de implementatieflexibiliteit waarop gedekte entiteiten eerder vertrouwden, verdwijnt.

Deze post legt uit wat HIPAA vereist in een agentische omgeving, behandelt wat de Security Rule-wijzigingen van 2025 toevoegen aan die vereisten, identificeert waar AI-inzet tekortschiet en schetst beste practices voor het opbouwen van een verdedigbare compliancepositie voor AI-agenttoegang tot PHI.

Samenvatting voor het management

Belangrijkste idee: HIPAA legt verplichtingen op voor toegangscontrole, audittrail, minimaal noodzakelijke toegang en encryptie op elk systeem dat PHI verwerkt — inclusief AI-agenten. De meeste zorgorganisaties hebben AI ingezet in PHI-gerelateerde workflows zonder governance-infrastructuur die aan deze verplichtingen voldoet, waardoor een groeiende categorie ongecontroleerde, niet-gereguleerde PHI-toegang ontstaat die materiële HIPAA-risico’s met zich meebrengt.

Waarom dit relevant is: HHS OCR heeft duidelijk gemaakt dat AI-tools die PHI benaderen onder de bestaande HIPAA-vereisten vallen. De Security Rule-wijzigingen van 2025 versterken dit verder door eerder ‘addressable’ beveiligingen — waaronder encryptie — om te zetten in verplichte vereisten en de aansprakelijkheid van business associates uit te breiden. Een gedekte entiteit die niet kan aantonen wie PHI heeft benaderd, met welke autorisatie en onder welke controles, kan geen verdedigbare compliancepositie innemen bij een audit. In een agentische context is één controlefout geen incident op zich — het is een systemisch probleem, omdat de agent mogelijk duizenden dossiers heeft benaderd zonder één gereguleerde interactie.

Belangrijkste punten

1. HIPAA is van toepassing op AI-agenten, ongeacht hoe ze zijn gebouwd of welk model ze gebruiken. De regelgeving regelt de toegang tot PHI, niet de technologie die de toegang uitvoert. Of een agent een commercieel LLM of een eigen klinisch model gebruikt, is voor een auditor niet relevant. Wat telt is toegangsautorisatie, minimaal noodzakelijke reikwijdte, encryptie en audittrail.
2. Systeemprompts zijn geen HIPAA-toegangscontroles. Een AI-agent instrueren om bepaalde PHI-categorieën niet te benaderen, geldt niet als technische toegangscontrole onder de Security Rule van HIPAA. Systeemprompts kunnen worden omzeild door prompt-injectie, overschreven door modelupdates of omzeild in meerstapsworkflows. Alleen handhaving op datalaag geldt als een audit-verdedigbare controle.
3. Minimaal noodzakelijke toegang moet op operationeel niveau worden afgedwongen, niet op systeemniveau. Een agent die gemachtigd is om een patiëntsamenvattingsmap te lezen, mag niet automatisch alle bestanden downloaden, dossiers extern verplaatsen of acties op niet-gerelateerde data uitvoeren. De toegangsreikwijdte moet per operatie worden geëvalueerd, niet per sessie.
4. Elke AI-agentinteractie met PHI is een potentieel auditrecord. De Audit Controls-standaard van HIPAA (§164.312(b)) vereist mechanismen om activiteiten op systemen met PHI op operationeel niveau vast te leggen en te onderzoeken. Als AI-agentinteracties niet worden vastgelegd in een manipulatieresistente auditlog, kan de organisatie niet aan deze vereiste voldoen.
5. De Security Rule-wijzigingen van 2025 dichten gaten waar AI-inzet doorheen glipte. Verplichte encryptie, strengere vereisten voor risicoanalyse, uitgebreide aansprakelijkheid van business associates en gecodificeerde cyberbeveiligingscontroles hebben direct invloed op hoe AI-agenten moeten worden gereguleerd. Organisaties waarvan de compliancepositie ouder is dan hun AI-inzet, lopen nu al achter.

Wat HIPAA vereist van AI-systemen

De Security Rule van HIPAA stelt technische beveiligingen vast die gelden voor elk systeem dat elektronische PHI benadert, opslaat of verzendt. Er is geen uitzondering voor AI-agenten, geautomatiseerde workflows of machine learning-toepassingen. Vier standaarden zijn direct van toepassing op agentische inzet.

Toegangscontrole en unieke gebruikersidentificatie (§164.312(a)(1) en §164.312(a)(2)(i))

Alleen geautoriseerde personen of softwareprogramma’s mogen ePHI benaderen, en elk moet een unieke identificatie hebben zodat toegang kan worden toegewezen. AI-agenten werken vaak via gedeelde serviceaccountgegevens of API-sleutels die geen agentniveau-identiteit of workflow-attributie bieden. Wanneer een auditor vraagt welke agent een patiëntendossier heeft benaderd en wie dat heeft geautoriseerd, biedt een gedeelde API-sleutel geen antwoord.

Audit Controls (§164.312(b))

Gedekte entiteiten moeten mechanismen implementeren om activiteiten in PHI-bevattende systemen vast te leggen en te onderzoeken. Voor AI-agenten moet het auditrecord de uitgevoerde operatie, de benaderde data, de agentidentiteit, de menselijke autorisator en de tijdstempel vastleggen — niet alleen dat er een sessie was. Standaard API-call logs en LLM-inferentielogs leggen gebeurtenissen vast op het verkeerde detailniveau om aan deze standaard te voldoen.

Minimaal noodzakelijke toegang (Privacy Rule §164.502(b))

PHI-toegang moet worden beperkt tot wat nodig is voor de specifieke taak. Wanneer een AI-agent via een serviceaccount toegang krijgt tot een PHI-repository, heeft deze technisch toegang tot elk dossier dat dat account kan bereiken. Niets in de standaard AI-inzetarchitectuur beperkt de agent tot alleen de data die de huidige workflow vereist. Voldoen aan dit principe vereist beleidsevaluatie op operationeel niveau, niet credentialing op sessieniveau.

Encryptie (§164.312(a)(2)(iv) en §164.312(e)(2)(ii))

Onder de oorspronkelijke Security Rule was encryptie ‘addressable’, wat betekende dat gedekte entiteiten een gelijkwaardig alternatief konden documenteren. De wijzigingen van 2025 nemen deze flexibiliteit weg, waardoor encryptie van ePHI onderweg en in rust verplicht wordt. Elk AI-agent datapad — API-calls naar PHI-repositories, agentgeheugen, tijdelijke caches, outputkanalen — moet gevalideerde cryptografische modules gebruiken. Standaard TLS-implementaties zonder bevestigde FIPS 140-3-validatie voldoen niet meer.

Wat de HIPAA Security Rule-wijzigingen van 2025 betekenen voor AI-governance

De Security Rule-wijzigingen van 2025 kwamen op het moment dat AI-agentinzet in de zorg versneld werd, en ze pakken direct de gaten aan die agentische architecturen uitbuiten. Vier veranderingen zijn van wezenlijk belang voor organisaties die AI inzetten op PHI.

Encryptie is nu verplicht

Het verwijderen van de ‘addressable’ status voor encryptie is de meest impactvolle wijziging. Elk PHI-datapad dat een AI-agent aanraakt — inclusief tijdelijke opslag en inferentie-pijplijnen — moet nu gevalideerde cryptografische encryptie gebruiken. Organisaties die vertrouwen op onbevestigde TLS of agentcaches onversleuteld laten, hebben nu een ondubbelzinnige verplichte verplichting om die gaten te dichten.

Risicoanalyse moet AI-systemen omvatten

De wijzigingen verscherpen §164.308(a)(1) en vereisen grondigere en gedocumenteerde risicobeoordelingen. Een risicoanalyse die AI-agenten niet noemt in een omgeving waar ze actief PHI benaderen, voldoet niet aan de nieuwe standaard. De analyse moet elk AI-systeem inventariseren, de controles beoordelen die de PHI-toegang reguleren en een plan voor herstel van tekortkomingen documenteren.

Aansprakelijkheid van business associates is direct afdwingbaar

Business associates dragen nu directe Security Rule-aansprakelijkheid, niet alleen contractuele BAA-verplichtingen. AI-leveranciers waarvan de infrastructuur PHI verwerkt, hebben onafhankelijke complianceverplichtingen. Zorgorganisaties moeten bevestigen dat AI-leveranciers Security Rule-compliance zelfstandig kunnen aantonen en BAAs hierop herzien.

Cybersecurity-basiscontroles zijn nu gecodificeerd

MFA, netwerksegmentatie en kwetsbaarheidsbeheer zijn nu verplichte vereisten. Voor AI-inzet moet de netwerkarchitectuur die PHI-databronnen blootstelt aan agent-API-calls voldoen aan de nieuwe segmentatievereisten — niet alleen de applicatielaagconfiguratie van de agent zelf.

Waar AI-inzet tekortschiet

De meeste AI-inzet in de zorg volgt hetzelfde architectuurpatroon: een agent verbonden met een PHI-databron via API, gereguleerd door een serviceaccount en een systeemprompt. Deze architectuur schiet op meerdere HIPAA-punten tegelijk tekort.

Geen agentidentiteit, geen delegatieketen

Serviceaccountgegevens authenticeren het systeem, niet de agent of de workflow. Wanneer meerdere agenten een credential delen, of wanneer het toegangsrecord geen link bevat naar de menselijke operator die de workflow autoriseerde, is er geen chronologische documentatie. Dit is een directe schending van de unieke gebruikersidentificatiestandaard — en betekent dat een onderzoek naar een datalek de meest basale vraag niet kan beantwoorden: wie heeft deze toegang geautoriseerd?

Logs leggen niet vast wat HIPAA vereist

Standaard applicatielogs leggen vast dat er een sessie was, niet welke PHI binnen die sessie is benaderd, welke operatie is uitgevoerd of welk beleid de beslissing bepaalde. De audittrailvereiste van HIPAA is operationeel en data-specifiek. API-call logs en LLM-inferentielogs zijn dat niet — en ze zijn niet manipulatieresistent.

Minimaal noodzakelijke toegang ontbreekt structureel

Wanneer een agent elk dossier kan bereiken dat een serviceaccount kan bereiken, is minimaal noodzakelijke toegang geen configuratieprobleem — het ontbreekt structureel. Herstel vereist beleidsevaluatie op operationeel niveau: elk datarequest wordt geëvalueerd op basis van de specifieke taak, patiëntcontext en uit te voeren operatie. Geen enkele standaard AI-inzetarchitectuur biedt dit zonder een speciale governance-laag.

Beste practices voor HIPAA-conforme AI-agenttoegang tot PHI

1. Authenticeer elke AI-agent en behoud de delegatieketen

Elke AI-agent die PHI benadert, moet een unieke identiteitstoken krijgen op workflow-niveau en gekoppeld zijn aan de menselijke operator die deze autoriseerde. Het authenticatie-evenement en de volledige delegatieketen moeten in elk toegangsrecord worden vastgelegd. Gedeelde serviceaccounts en API-sleutels voldoen niet aan deze vereiste, ongeacht de reikwijdte.

2. Handhaaf toegangsbeleid op operationeel niveau

Implementeer op attributen gebaseerde toegangscontrole (ABAC: Attribute Based Access Control) die elk datarequest evalueert op basis van het geauthenticeerde agentprofiel, de PHI-dataclassificatie, de workflowcontext en de specifieke operatie. Een agent die gemachtigd is om een actueel encounter-rapport te lezen, is niet automatisch gemachtigd om het volledige longitudinale dossier te downloaden of data naar een extern systeem te sturen.

3. Implementeer operationele, manipulatieresistente auditlogging

Elke AI-agentinteractie met PHI moet op operationeel niveau worden gelogd: agentidentiteit, menselijke autorisator, type operatie, geraadpleegde dossiers, beleidscontext en tijdstempel. De log moet manipulatieresistent zijn en direct worden doorgevoerd naar de SIEM van de organisatie, zodat PHI-toegangsafwijkingen realtime zichtbaar worden — niet pas bij forensisch onderzoek achteraf.

4. Bevestig FIPS 140-3 gevalideerde encryptie over elk datapad

Controleer elk onderdeel in het AI-agent datapad — API-calls, modelhosting, vectordatabases, tijdelijke opslag, outputlevering — en bevestig de FIPS 140-3 validatiestatus van elk. Onder de wijzigingen van 2025 zijn algemene AES-256 Encryptie-claims onvoldoende. Gevalideerde modulecertificering is vereist.

5. Werk uw risicoanalyse bij om AI-inzet te omvatten

Werk de HIPAA-risicobeoordeling van de organisatie bij om elke AI-agent die PHI benadert te inventariseren, de controles te beoordelen die elk reguleren en een herstelplan met tijdlijnen te documenteren. Onder de wijzigingen van 2025 is een risicoanalyse die ouder is dan de AI-inzet van de organisatie niet compliant — en het ontbreken ervan is op zichzelf al een auditbevinding.

Hoe Kiteworks HIPAA-conforme AI-agentgovernance mogelijk maakt

Traditionele HIPAA-compliance tools zijn gebouwd voor door mensen geïnitieerde datainteracties. AI-agenten werken op een andere schaal en snelheid — ze doen API-calls, roepen MCP-tools aan en voeren meerstapsworkflows uit die handmatige controle niet kan reguleren. De Security Rule-wijzigingen van 2025 leggen de lat nog hoger. Governance moet op de datalaag werken, onafhankelijk van het model, en op de snelheid van de agent.

Het Kiteworks Private Data Network biedt gedekte entiteiten en business associates een governance-laag die elke AI-agentinteractie met PHI onderschept voordat deze plaatsvindt — waarbij agentidentiteit wordt geverifieerd, ABAC-beleid wordt geëvalueerd, FIPS 140-3 gevalideerde encryptie wordt toegepast en een manipulatieresistente auditlog van elke operatie wordt vastgelegd. Elke agentworkflow erft HIPAA-compliancecontroles automatisch, ingebouwd in de architectuur in plaats van achteraf toegevoegd na inzet.

Agentidentiteit en delegatieketen

Kiteworks verifieert de identiteit van elke AI-agent voordat PHI-toegang plaatsvindt en koppelt deze aan de menselijke autorisator die de workflow delegeerde. De volledige delegatieketen wordt in elk auditrecord vastgelegd, waarmee wordt voldaan aan §164.312(a)(2)(i) en auditors voorzien van traceerbaar, gedocumenteerd bewijs van geautoriseerde toegang.

Operationele ABAC en handhaving van minimaal noodzakelijke toegang

Kiteworks’ Data Policy Engine evalueert elk agentdatarequest tegen een multidimensionaal beleid: geauthenticeerd agentprofiel, PHI-dataclassificatie, workflowcontext en de specifieke aangevraagde operatie. Een agent die gemachtigd is om een patiënt-encounter-samenvatting te lezen, kan niet automatisch het volledige dossier downloaden of data extern doorsturen — beperkingen die worden afgedwongen door de governance-laag, niet door een systeemprompt.

FIPS 140-3 encryptie en manipulatieresistente audittrail

Alle PHI die via Kiteworks wordt benaderd, is beschermd door FIPS 140-3 Level 1 gevalideerde encryptie in transit en in rust, waarmee wordt voldaan aan de nu verplichte vereisten van de vernieuwde HIPAA Security Rule. Elke agentinteractie met PHI wordt vastgelegd in een manipulatieresistente log die direct wordt doorgevoerd naar de SIEM van de organisatie. Wanneer een auditor om een bewijspakket vraagt, is het antwoord een rapport, geen onderzoek.

Gereguleerde klinische documentatie-operaties

Kiteworks Compliant AI’s Governed Folder Operations en Governed File Management-mogelijkheden stellen AI-agenten in staat klinische documentatie te structureren en patiëntendossier-hiërarchieën te beheren, waarbij elke actie wordt afgedwongen door de Data Policy Engine. Map-hiërarchieën erven automatisch RBAC/ABAC-controles, waarmee wordt voldaan aan de HIPAA-vereisten voor dossiersegregatie zonder handmatige toewijzing.

Voor zorgorganisaties die AI-adoptie willen versnellen zonder compliance-schuld op te bouwen, maakt Kiteworks elke AI-agentinteractie met PHI verdedigbaar by design. Lees meer over de HIPAA-compliance mogelijkheden van Kiteworks of vraag een demo aan.

Aanvullende bronnen

• Blog Post
  Zero‑Trust strategieën voor betaalbare AI-privacybescherming
• Blog Post
  Hoe 77% van de organisaties faalt op AI-databeveiliging
• eBook
  AI Governance Gap: Waarom 91% van kleine bedrijven Russisch roulette speelt met databeveiliging in 2025
• Blog Post
  Er bestaat geen “–dangerously-skip-permissions” voor uw data
• Blog Post
  Toezichthouders zijn klaar met vragen of u een AI-beleid heeft. Ze willen bewijs dat het werkt.