Aanbesteden van AI in de zorg: eisen die je wél en niet moet stellen

Een goede AI-aanbesteding in de zorg draait om de juiste eisen, niet om de meeste. Wél stellen: een echte verwerkersovereenkomst (verplicht zodra een leverancier persoonsgegevens voor je verwerkt, artikel 28 AVG), ondersteuning bij je verplichte DPIA, harde afspraken over dataminimalisatie en waar de gegevens blijven, aantoonbare menselijke controle over de uitkomst, een auditrecht en begrijpelijke technische documentatie [1][2][4]. Voor de contractkant kun je de Europese modelcontractvoorwaarden voor AI-inkoop als bijlage gebruiken, met een aparte set voor hoog- en voor laag-risicotoepassingen [1]. Niet (zo) stellen: "moet NEN 7510-gecertificeerd zijn" als knock-outeis — de norm is verplicht, maar certificering is dat niet; vraag naar aantoonbaar voldoen [3][5]. En timmer je bestek niet dicht op één techniek of leverancier, want dan koop je een leverancier in plaats van een oplossing. Dit artikel loopt de eisen die tellen en de valkuilen die niets bewijzen één voor één langs.

Waarom je uitvraag nu belangrijker wordt

AI in de zorg is geen "later"-onderwerp meer. Zilveren Kruis is de eerste zorgverzekeraar die van zorgaanbieders verwacht dat ze uiterlijk eind 2026 een duidelijke strategie voor de toepassing en implementatie van AI hebben — een verwachting die geldt voor de eerstelijnszorg, wijkverpleging en grotere instellingen in de ggz en medisch-specialistische zorg [6]. AI verschuift daarmee van een optionele ambitie naar iets wat je inkoop en beleid raakt.

Dat maakt je aanbesteding het moment waarop je je risico's afdekt — of ze binnenhaalt. De verwerking van bijzondere persoonsgegevens (gezondheid) met AI valt onder de strengste regels van de AVG, en je bent als zorgaanbieder eindverantwoordelijk voor die verwerking; die verantwoordelijkheid kun je niet doorschuiven naar je leverancier [4]. Een scherpe uitvraag is dus geen bureaucratie, maar de plek waar je vastlegt dat een systeem controleerbaar, aantoonbaar veilig en van jou blijft. En omgekeerd: vage of verkeerde eisen leveren een contract op dat op papier klopt maar in de praktijk niets afdwingt.

Eisen die je wél moet stellen

Begin bij wat je écht wilt weten: doet het systeem wat je nodig hebt, en houd je de controle? Vertaal dat naar concrete, toetsbare eisen.

• Een echte verwerkersovereenkomst. Zodra een leverancier namens jou persoonsgegevens verwerkt, is een verwerkersovereenkomst wettelijk verplicht (artikel 28 AVG). Algemene voorwaarden of een "terms of service" van de leverancier volstaan niet [4]. Leg vast dat de leverancier alleen op jouw instructie verwerkt, welke sub-verwerkers zijn toegestaan, en of je gegevens wel of niet gebruikt mogen worden om modellen te trainen — spreek dat laatste expliciet uit.
• Ondersteuning bij je DPIA. Voor het verwerken van bijzondere persoonsgegevens met AI is een Data Protection Impact Assessment in de regel verplicht, en die hoort vóór ingebruikname [4]. Eis dat de leverancier de documentatie levert die je nodig hebt om die DPIA te kunnen maken — de inkoop van AI laat de DPIA-plicht namelijk niet vervallen.
• Dataminimalisatie en datalocatie. Vraag concreet: welke gegevens verlaten mijn organisatie, waar worden ze verwerkt en opgeslagen, en hoe lang? Zorg voor dataminimalisatie, pseudonimisering waar mogelijk en een heldere grondslag [2][4]. Laat de leverancier het antwoord aantoonbaar maken, niet alleen beloven.
• Aantoonbare menselijke controle. Eis dat een AI-uitkomst een concept blijft dat een mens beoordeelt en goedkeurt vóór het meetelt. De AVG en de toezichthouder verwachten juist die menselijke controle bij AI [4]. Beloof nooit foutloosheid; eis controleerbaarheid.
• Auditrecht en risicoclassificatie. Neem het recht op een audit expliciet op in de contractvoorwaarden, zodat je later kunt controleren of het model en de onderliggende data juist werken [2]. Vraag de leverancier ook om te helpen bij de risicoclassificatie van het AI-systeem onder de AI-verordening.
• Begrijpelijke documentatie en transparantie. Vraag technische documentatie, audits en transparantie over de gebruikte data, de beveiliging en het algoritme [2][4]. Zonder begrijpelijke uitleg kun je noch je DPIA, noch je verantwoording aan de FG rondmaken.

Voor de contractvorm hoef je het wiel niet zelf uit te vinden: de Europese Commissie stelde in september 2023 modelcontractvoorwaarden voor AI-inkoop beschikbaar, met een aparte set voor hoog-risico- en een set voor laag-risicotoepassingen. Ze vervangen je gewone IT-inkoopvoorwaarden niet, maar je kunt ze als bijlage toevoegen om transparantie en verantwoord gebruik af te dwingen [1].

Eisen die je niet (zo) moet stellen

Net zo belangrijk zijn de eisen die goed klinken maar averechts werken, niets bewijzen of je keuze onnodig versmallen.

• "Moet NEN 7510-gecertificeerd zijn" als knock-out. NEN 7510 is voor zorgaanbieders verplicht sinds 2008, maar een certificaat is wettelijk niet verplicht [3]. Als je certificering hard afdwingt, sluit je soms goede leveranciers uit die aantoonbaar voldoen zonder duur keurmerk — en een certificaat op zich zegt niets over deze specifieke oplossing. Vraag daarom naar aantoonbaar voldoen (zie hieronder), niet alleen naar een logo.
• Eén techniek of leverancier voorschrijven. Zodra je in je bestek een specifiek product, cloudplatform of algoritme voorschrijft, koop je een leverancier in plaats van een oplossing. Beschrijf functioneel wát het systeem moet doen en welke waarborgen het moet bieden, en laat de markt met een invulling komen. Zo houd je ook ruimte voor lokale, on-premise opties naast cloudoplossingen.
• Alles dubbel dichttimmeren wat de wet al regelt. De AI-verordening en de AVG stellen zelf al eisen, afhankelijk van de risicoclassificatie [2][4]. Verwijs daarnaar en toets erop, in plaats van tientallen overlappende eigen clausules te schrijven die elkaar tegenspreken en leveranciers vooral tijd kosten om te weerleggen.
• Foutloosheid of "100% nauwkeurig" eisen. Geen enkel AI-systeem is foutloos, en een leverancier die het belooft, belooft iets wat niet waargemaakt kan worden. Eis in plaats daarvan controleerbaarheid: kun je per uitkomst terug naar de bron en corrigeren vóór goedkeuring?
• Vertrouwen op "EU-servers" als bewijs. Dat data op Europese servers staat, zegt weinig als het beheer of moederbedrijf onder buitenlandse wetgeving valt. Vraag daarom niet "staat het in de EU?", maar "wie kan er technisch én juridisch bij, en hoe toon je dat aan?"

NEN 7510 in je bestek: certificaat versus aantoonbaar voldoen

Dit misverstand komt zó vaak terug in aanbestedingen dat het een eigen kopje verdient. De Inspectie Gezondheidszorg en Jeugd is er helder over: "Sinds 2008 staat in de wet dat zorgaanbieders zich moeten houden aan de NEN 7510." Maar over certificering zegt de IGJ net zo duidelijk: "De wet stelt dit niet verplicht" [3]. Wat de wet wél vraagt, is dat je aantoonbaar volgens de norm werkt — en dat kun je laten zien met een onafhankelijke beoordeling, in de praktijk minstens eens per drie jaar [3]. NEN 7510 zelf beschrijft een managementsysteem voor informatiebeveiliging, gebouwd op de internationale ISO-normen met een zorgspecifieke invulling [5].

Praktisch betekent dit: vraag in je uitvraag naar de beveiligingsmaatregelen en naar bewijs dat de leverancier aantoonbaar volgens NEN 7510 werkt — een onafhankelijke beoordeling, een assessment of, als ze het hebben, een certificaat. Maar maak "gecertificeerd" geen knock-outeis. Een eerlijke leverancier zal zeggen dat een product is ontworpen om jouw NEN 7510-verantwoording te ondersteunen, niet dat het jouw certificering vervangt; die verantwoordelijkheid blijft namelijk bij jou als zorgaanbieder. Zo bouwt bijvoorbeeld Verbinn bewust lokaal, zodat je in je DPIA en beveiligingsdossier kunt laten zien dat gegevens je pand niet verlaten — controleerbaar, niet op je blauwe ogen.

Een uitvraag in tien eisen

Als je één lijstje meeneemt naar je programma van eisen, dan dit:

• Functionele beschrijving: wat moet het systeem doen, voor welk gesprekstype of proces?
• Verwerkersovereenkomst conform artikel 28 AVG, met afspraken over sub-verwerkers en trainen op jouw data [4].
• Documentatie die je DPIA mogelijk maakt, aangeleverd vóór ingebruikname [4].
• Dataminimalisatie, datalocatie en bewaartermijnen, aantoonbaar [2][4].
• Menselijke controle: uitkomst blijft concept tot een mens goedkeurt [4].
• Aantoonbaar voldoen aan NEN 7510 (niet per se een certificaat) [3][5].
• Auditrecht op werking van model en onderliggende data [2].
• Ondersteuning bij risicoclassificatie onder de AI-verordening [1][2].
• Transparantie over data, beveiliging en algoritme, in begrijpelijke taal [2].
• Exit- en overdraagbaarheidsafspraken, zodat je niet vastzit aan één leverancier.

Wil je deze eisen in de praktijk toetsen in plaats van alleen op papier? Draai dan eerst een gecontroleerde proef met vaste slaagcriteria — hoe je dat opzet, lees je in een pilot draaien met een AI-scribe: meetplan en slaagcriteria.

Aanbesteden is een bestuurlijk besluit

Een AI-aanbesteding hoort niet alleen bij inkoop of ICT. Je bestuur is eindverantwoordelijk voor de verwerking van persoonsgegevens en kan die verantwoordelijkheid niet bij de leverancier neerleggen [4]. Betrek daarom je FG of DPO al bij het opstellen van de eisen, niet pas bij de gunning. Het Algoritmekader van de Rijksoverheid raadt aan om vóór de uitvraag te bepalen welk probleem je oplost, welk risiconiveau erbij hoort en welke publieke waarden in het geding zijn — dat bepaalt hóé streng je eisen moeten zijn [2].

En denk voorbij de handtekening: de meeste AI-initiatieven in de zorg blijven steken in enthousiaste pilots, terwijl een breed gedragen strategie ontbreekt [6]. Een goed bestek regelt daarom niet alleen de aankoop, maar ook de opschaling erna — eigenaarschap, review-routines en fasering. Hoe je van een geslaagde proef naar organisatiebrede inzet komt zonder chaos, staat in van pilot naar organisatiebreed: opschalen zonder chaos. Zo koop je geen los product, maar een oplossing die je bestuurlijk kunt verantwoorden.