AI informatiebeveiliging in de zorg, technische en organisatorische maatregelen

AI informatiebeveiliging in de zorg is de laag maatregelen die ervoor zorgt dat AI-tools binnen een zorginstelling niet de aanvalsroute worden waarlangs medische gegevens weglekken, en tegelijkertijd niet de black-box waarvan niemand achteraf kan reconstrueren wat er met een patiëntdossier is gebeurd. Deze gids beschrijft hoe AI informatiebeveiliging in de zorg zich verhoudt tot de bestaande NEN 7510-controles die zorgorganisaties al kennen, welke technische en organisatorische maatregelen aanvullend nodig zijn wanneer een LLM of ander AI-systeem in de workflow zit, en hoe een incidentrespons er in de praktijk uitziet als er iets misgaat.

De doelgroep is de CISO, de informatiebeveiligingscoördinator of de bestuurder in een Nederlandse zorginstelling die verantwoordelijk is voor het antwoord op de vraag "kunnen we deze AI-tool aanzetten zonder een datalek te riskeren of een IGJ-inspectie te verliezen". Voor het bredere beleidskader zie AI governance in de zorg. Voor de privacyaspect is er AI in de zorg en de AVG en voor de operationele lijst met controles AI in de zorg en NEN 7510. Deze pagina zit op het snijvlak van die drie en beschrijft de dagelijkse informatiebeveiliging als proces.

Waarom AI de informatiebeveiliging in de zorg opnieuw op scherp zet

De informatiebeveiliging van Nederlandse zorginstellingen was voor de introductie van generatieve AI al een aparte discipline met een eigen normenkader (NEN 7510) en een sector-CERT (Z-CERT). AI-tools voegen daar drie nieuwe risicovectoren aan toe die de bestaande controles niet automatisch afvangen.

Data-uitstroom via promptverkeer. Elke prompt aan een AI-tool is een uitgaande dataflow. Als de tool bij een externe leverancier draait, verlaten patiëntgegevens de eigen infrastructuur op het moment dat een medewerker een dossier in de prompt plakt. Een gebruikelijke oplossing voor logging die HTTP-uitgaand verkeer volgt registreert dat er iets naar api.example.com gaat, maar niet wat er in de payload zit. Voor NEN 7510-controle 8.15 (logging van gebeurtenissen) is die granulariteit onvoldoende.

Onduidelijke modelketen. Een AI-leverancier gebruikt zelf vaak weer een cloud-hyperscaler voor GPU-capaciteit, een separaat bedrijf voor content-filtering, en soms een derde partij voor logging. Voor de zorginstelling is de vraag onder de AVG en de AI-Verordening: welke subverwerker heeft welke gegevens op welk moment gezien. Zonder een vooraf gedocumenteerde subverwerkersketen kan die vraag na een incident niet meer beantwoord worden.

Prompt-injectie en modelmanipulatie. Een AI-systeem dat een e-mail of een geüpload document verwerkt kan door tekst in dat document geïnstrueerd worden om iets anders te doen dan de gebruiker vroeg. Dat is een nieuw type aanval waar traditionele endpoint-security niet op is ingericht. Z-CERT signaleert dit type incident sinds 2024 in de sectorrapportages.

Dat zijn de drie technische veranderingen. Daarnaast is er een organisatorische verschuiving: waar informatiebeveiliging historisch gericht was op de ICT-afdeling en de EPD-leverancier, zit AI-inzet nu vaak decentraal bij afdelingen die geen directe lijn met de CISO hebben. Een verpleegkundige die een consumer-ChatGPT gebruikt voor overdrachten hoort niet in de bestaande workflow voor security thuis, maar het is wel een vraagstuk rond informatiebeveiliging.

Technische maatregelen voor AI informatiebeveiliging in de zorg

De technische kant valt uiteen in vijf lagen die elk hun eigen controles vragen.

Netwerksegmentatie en uitgaand verkeer. Alle AI-verkeer hoort via een centrale uitgaande proxy te lopen die per applicatie kan bepalen welke bestemmingen zijn toegestaan. Dat is minder een AI-vraagstuk en meer een klassiek netwerkontwerp, maar wordt in de praktijk pas afgedwongen als AI-tools het volume opdrijven. Zonder dit is ongeautoriseerd gebruik van consumer tooling door personeel technisch onzichtbaar.

Encryptie in transit en at rest. TLS voor het uitgaand verkeer naar de AI-leverancier is standaard. De vraag die specifieker is voor zorg is of de leverancier de prompts na verwerking versleuteld opslaat en zo ja, met welke sleutelbeheer-opstelling. Voor de meeste AI-leveranciers is deze informatie in de subverwerkersovereenkomst of het security-whitepaper vindbaar. Als de leverancier deze informatie niet openbaar heeft, is dat op zichzelf al een signaal.

Identiteits- en toegangsbeheer. Elke AI-aanroep moet aan een geïdentificeerde gebruiker koppelbaar zijn, niet aan een gedeelde API-sleutel. In de praktijk betekent dit een koppeling tussen de AI-tool en de identity provider die de zorginstelling al gebruikt (Microsoft Entra, Google Workspace, of een sectorale IDP). Zonder deze koppeling is een audit-trail per gebruiker technisch niet mogelijk en is de controle op logging uit NEN 7510 controle 8.15 niet aantoonbaar.

Logging op verzoeksniveau. Voor elke AI-aanroep moet vastgelegd worden: wie, wanneer, welke tool, welk model, welke categorie data (persoonsgegevens ja/nee), en de uitkomst. De inhoud van de prompt zelf hoeft niet altijd bewaard (dat is een aparte afweging vanuit AVG-minimalisatie), maar de metadata rond de aanroep wel. Deze logs moeten minimaal zes maanden bewaard blijven om aan artikel 19 van de AI-Verordening (Verordening (EU) 2024/1689) te voldoen voor hoog-risico-systemen, en langer als de eigen bewaartermijnen dat vereisen.

Monitoring en anomalie-detectie. Een piek in AI-aanvragen buiten kantoortijden, een enkele gebruiker die plotseling honderden dossiers per uur door een tool haalt, of een tool die opeens naar een nieuwe bestemming verkeer stuurt zijn alle drie signalen die een SOC-omgeving zou moeten oppakken. Voor zorginstellingen zonder eigen SOC is het praktisch om deze signalering via Z-CERT of een managed security provider te laten lopen.

Organisatorische maatregelen voor AI informatiebeveiliging in de zorg

De technische laag werkt alleen als de organisatorische omhulling klopt. Zes elementen zijn in de praktijk de kritieke:

AI-toelatingsbeleid en lijst met tools. Een gepubliceerde interne lijst van welke AI-tools zijn goedgekeurd, voor welke taken, en welke expliciet verboden zijn. Zonder deze lijst kiest elke afdeling zelf en ontstaat het schaduw-AI-probleem dat de rest van de maatregelen ondermijnt.

Awareness en periodieke training. Personeel dat weet waarom consumer-ChatGPT in een dossier plakken problematisch is, maakt de fout minder vaak. De IGJ verwacht sinds de handreiking "Verantwoord gebruik van AI in de zorg" van 2024 dat zorginstellingen dit aantoonbaar hebben georganiseerd. Wij zien in de praktijk dat een jaarlijkse basistraining plus een bondige toevoeging aan onboarding voldoende blijkt.

Incident-response met AI-scenario opgenomen. Het bestaande incidentresponsplan van de zorginstelling moet uitgebreid worden met AI-specifieke scenario's: promptinjectie, ongewenste modeluitvoer die tot een klinische beslissing leidde, uitlek via een AI-tool. Voor elk scenario een verantwoordelijke, een escalatiepad naar Z-CERT en Autoriteit Persoonsgegevens, en een communicatielijn naar betrokkenen.

Ketensamenwerking met de AI-leverancier. Vooraf afspraken over wie welke informatie deelt bij een incident, binnen welke termijn, en via welk kanaal. Standaard-verwerkersovereenkomsten dekken dit vaak onvoldoende voor AI-specifieke incidenten. Een aanvullende bijlage werkt beter.

Documentatie voor inzage door toezichthouder. IGJ-inspecteurs en AP-onderzoekers vragen bij een incident consistent naar drie soorten documenten: de lijst met tools en autorisatiebeleid, de logs van het betreffende systeem in het incident-venster, en de DPIA of AI-Verordening-risico-inschatting die vooraf is gedaan. Wie deze documenten niet binnen een dag kan overleggen komt in een zwakkere positie in het inspectiegesprek.

Aansluiting op informatiegestuurd beleid. De data uit AI-monitoring (welke afdelingen gebruiken welke tools, welke risicoscores komen eruit, welke incidenten) hoort periodiek terug te komen in het bestuurlijk overleg. AI-informatiebeveiliging als apart onderwerp op de RvB-agenda, minimaal per kwartaal, koppelt de operationele data terug naar het strategische besluitvormingsniveau. Dit is de plek waar informatiebeveiliging en informatiegestuurd beleid in de zorg elkaar in de praktijk raken.

Verhouding tot NEN 7510 en de BIO

NEN 7510 is voor zorginstellingen de dominante norm voor informatiebeveiliging. Voor zorgorganisaties die ook publieke taken uitvoeren of aan publieke opdrachten deelnemen komt daar de Baseline Informatiebeveiliging Overheid (BIO) bij. AI-informatiebeveiliging vervangt geen van beide normen. De controles uit NEN 7510 en de BIO blijven onverkort gelden en moeten worden aangevuld met AI-specifieke invulling.

Een praktische mapping van NEN 7510-controles die extra aandacht vragen zodra AI in scope komt:

• Controle 5.34 (Bescherming van persoonsgegevens): verplicht als AI-tools met persoonsgegevens in aanraking komen, wat in de zorg vrijwel altijd het geval is.
• Controle 8.10 (Verwijdering van informatie): vereist duidelijkheid over of en hoe de AI-leverancier prompts verwijdert na verwerking.
• Controle 8.15 (Logging): vraagt om logs van aanroepen die aan een gebruiker koppelbaar zijn.
• Controle 8.24 (Cryptografie): vraagt om documentatie van de encryptie in transit en at rest bij de AI-leverancier.
• Controle 5.14 (Verantwoordelijkheden bij informatiebeveiligingsgebeurtenissen): vraagt om helderheid over wie waarvoor verantwoordelijk is als een AI-tool onderdeel van een incident is.

De pagina AI in de zorg en NEN 7510 beschrijft het controleniveau in detail en dient als operationele bijlage bij dit verhaal over informatiebeveiliging.

Waar Ciralgo past in deze maatregelen

Ciralgo is geen NEN 7510-certificerende partij en vervangt geen intern beleid. Ciralgo is een EU-gehoste LLM-proxy die enkele van de technische maatregelen uit dit hoofdstuk implementeert: alle uitgaande AI-verzoeken via één centraal punt met logging per gebruiker, identity-koppeling aan de bestaande identity provider, en aanroep-metadata die voldoen aan artikel 12 van de AI-Verordening en aan NEN 7510-controle 8.15.

Voor Nederlandse zorginstellingen die al één AI-tool centraal beheren en verder geen brede AI-inzet hebben, is een proxy-laag overbodig; de bestaande vendor-oplossing volstaat. Voor zorginstellingen met meerdere AI-tools of met een expliciete audit-plicht onder de AI-Verordening (relevant voor hoog-risico-toepassingen) wordt de proxy-laag de plek waar de logs en de jurisdictie-controle samenkomen. Meer over de technische opzet in wat een EU-gehoste LLM-proxy is en over Ciralgo.

Wat te doen bij een AI-security-incident in de zorg

Een incident met een AI-tool in een zorgomgeving vraagt om een aanpak die parallel loopt aan een klassiek datalekincident maar op enkele punten afwijkt.

Binnen het eerste uur: identificeer welke AI-tool bij het incident betrokken is, welke gegevens de tool heeft gezien in het incident-venster, en of het incident actief nog gaande is (bijvoorbeeld een geautomatiseerde workflow die nog draait). Onderbreek de uitvoer van de tool waar nodig via een noodmaatregel op de proxy of firewall.

Binnen 24 uur: stel vast of er sprake is van een meldingsplichtig datalek in de zin van de AVG (dat vergt melding aan de Autoriteit Persoonsgegevens binnen 72 uur na ontdekking) en of er sprake is van een IGJ-meldingsplichtig calamiteitenincident (dat vergt melding binnen 3 werkdagen na ontdekking). Deze twee stromen zijn gescheiden en verschillende personen zijn ervoor verantwoordelijk. Laat één persoon de regie voeren op beide.

Binnen een week: incident-review met de AI-leverancier, verantwoording naar de RvB, en aanpassing van de lijst met tools of het toelatingsbeleid als het incident daar aanleiding voor geeft. Z-CERT biedt voor aangesloten instellingen ondersteuning bij het incident-review en het opstellen van lessons-learned.

Veelgestelde vragen over AI informatiebeveiliging in de zorg

Is een AI-tool die "AVG-conform" wordt genoemd automatisch geschikt voor Nederlandse zorginstellingen?

Nee. AVG-conformiteit is een noodzakelijke voorwaarde, geen voldoende. Voor zorginstellingen komen daar bovenop NEN 7510-conformiteit, aansluiting op de eigen incidentresponse, expliciete Z-CERT-melding-afspraken en, waar van toepassing, BIO-controles. Een leverancier die uitsluitend "AVG-conform" claimt zonder deze extra lagen te adresseren mist doorgaans zorgspecifieke ervaring.

Wie is verantwoordelijk voor AI informatiebeveiliging in de zorg binnen de instelling?

Formeel: de RvB als eindverantwoordelijke, de CISO of informatiebeveiligingscoördinator als operationeel verantwoordelijke. In de praktijk vraagt het een driehoek tussen CISO, functionaris gegevensbescherming en de kwaliteitsverantwoordelijke voor patiëntveiligheid, omdat AI-incidenten alle drie de domeinen raken.

Moeten prompts en modeluitvoer bewaard blijven voor audit?

De metadata rond elke AI-aanroep moet bewaard blijven (minimaal 6 maanden onder artikel 19 AI-Verordening voor hoog-risico-systemen). De inhoud van prompts en uitvoer zelf is een aparte afweging: bewaren geeft betere reconstructie na een incident, niet bewaren beperkt de AVG-minimalisatie-blootstelling. De praktische middenweg is bewaren van inhoud waar patiëntveiligheid direct raakt (bijvoorbeeld klinische beslissingsondersteuning) en alleen metadata bewaren waar dat niet zo is.

Wat is het verschil tussen AI informatiebeveiliging en AI governance in de zorg?

AI informatiebeveiliging is de operationele laag: technische controles, incidentresponse, awareness. AI governance in de zorg is de bestuurlijke laag: beleid, verantwoordelijkheden, RvB-agendering, aansluiting op kwaliteitssysteem. De governance zet het kader waarbinnen de informatiebeveiliging opereert. De informatiebeveiliging levert op haar beurt de data waarmee de governance stuurt.

Wat kost het opzetten van AI informatiebeveiliging in een middelgrote zorginstelling?

Bij een instelling van 200 tot 500 medewerkers vraagt een eerste opzet doorgaans één FTE gedurende drie tot zes maanden voor beleid en documentatie, plus een investering in een centrale AI-proxy of gateway (variabel afhankelijk van leveranciers) en een terugkerende trainingscyclus. Wij zien in de praktijk dat instellingen die al NEN 7510-gecertificeerd zijn de doorlooptijd substantieel korter houden dan instellingen die dit parallel oppakken.

Verder lezen

• AI in de zorg, praktische gids
• AI in de zorg en NEN 7510
• AI in de zorg en de AVG
• AI governance in de zorg
• AI in de zorg voorbeelden, tien concrete cases
• Z-CERT sectorrapportages
• NEN 7510 normteksten via NEN

Laatst herzien: 18 augustus 2026. AI-Verordening en NEN 7510-interpretaties evolueren, dus verifieer bij Z-CERT en NEN voor de actuele stand.