AI inkopen voor de overheid: praktische checklist voor privacy, security, aanbestedingsrecht en controle

AI-software inkopen voor een overheid is niet alleen een IT-keuze.

Zodra medewerkers documenten, persoonsgegevens, aanbestedingsstukken of besluitvormingsinformatie in een AI-systeem verwerken, komen vragen samen over privacy, informatiebeveiliging, aanbestedingsrecht, AI-governance, menselijke controle, archivering en leveranciersafhankelijkheid.

Een overtuigende demonstratie zegt daar weinig over.

De betere vraag is:

Kan de leverancier aantonen dat de oplossing binnen onze organisatie veilig, controleerbaar en bestuurbaar kan worden gebruikt?

Deze checklist helpt publieke organisaties om AI-leveranciers op dezelfde punten te toetsen — zowel tijdens marktverkenning en aanbesteding als tijdens een pilot, acceptatie en contractering.

Dit artikel biedt algemene informatie en is geen juridisch of informatiebeveiligingsadvies voor een specifieke organisatie of toepassing.

1. Begin met het concrete gebruik, niet met “we willen AI”

De risico's van AI hangen sterk af van wat het systeem daadwerkelijk gaat doen.

Een tool die openbare aanbestedingen samenvat heeft een ander risicoprofiel dan een oplossing die:

• vertrouwelijke inschrijvingen analyseert;
• persoonsgegevens verwerkt;
• conceptbesluiten voorbereidt;
• leveranciers scoort;
• juridische documenten opstelt;
• interne beleidsinformatie gebruikt;
• medewerkers aanbevelingen geeft die beslissingen beïnvloeden.

Beschrijf daarom vóór de leveranciersselectie minimaal:

welke gebruikers → welke gegevens → welke handelingen → welke beslissingen → welke systemen → welke menselijke controle.

Zonder dat kader kan een leverancier bijna iedere beveiligings- of compliancevraag beantwoorden met “dat hangt af van de implementatie”.

2. Welke beslissingen mag AI ondersteunen — en welke niet?

Leg vast welke rol de AI krijgt.

Mag het systeem alleen:

• zoeken;
• samenvatten;
• structureren;
• conceptteksten maken;
• ontbrekende informatie signaleren?

Of mag het ook:

• een risico classificeren;
• een compliancebevinding voorstellen;
• een score voorbereiden;
• een leverancier rangschikken;
• een besluitvoorstel genereren?

Hoe dichter de AI bij een materieel besluit komt, hoe belangrijker het wordt dat een professional de onderliggende informatie kan controleren en de AI-uitkomst kan afwijzen.

Vraag daarom:

Wie blijft verantwoordelijk voor het besluit en hoe ondersteunt het systeem die menselijke verantwoordelijkheid aantoonbaar?

3. Welke gegevens mogen in het systeem worden verwerkt?

Maak vooraf een dataclassificatie.

Denk onder andere aan:

• openbare documenten;
• interne documenten;
• bedrijfsvertrouwelijke informatie;
• persoonsgegevens;
• bijzondere persoonsgegevens;
• leveranciersinformatie;
• offertes en inschrijvingen;
• financiële informatie;
• beveiligingsinformatie;
• juridische adviezen.

Vraag de leverancier niet alleen of het product “AVG-compliant” is.

Vraag welke gegevenscategorieën contractueel en technisch zijn toegestaan, welke beperkingen gelden en welke gegevens expliciet niet in de dienst mogen worden verwerkt.

De Autoriteit Persoonsgegevens publiceert een handreiking over generatieve AI en de AVG.

4. Wie is verwerkingsverantwoordelijke en wie is verwerker?

Wanneer persoonsgegevens worden verwerkt, moet duidelijk zijn welke AVG-rol iedere partij heeft.

Vraag onder andere:

• treedt de leverancier als verwerker op;
• verwerkt de leverancier gegevens ook voor eigen doeleinden;
• is een verwerkersovereenkomst beschikbaar;
• welke instructies kan de organisatie geven;
• welke rechten heeft de leverancier rond gebruiks- of telemetriegegevens;
• hoe worden verzoeken van betrokkenen ondersteund;
• wanneer is een DPIA nodig?

Een algemene privacyverklaring is hiervoor niet genoeg.

5. Waar worden gegevens verwerkt?

“Hosting in Europa” beantwoordt niet de hele vraag.

Breng de volledige gegevensstroom in kaart:

opslag → modelverwerking → logging → back-ups → monitoring → support → incidentonderzoek.

Vraag:

• in welke landen vindt verwerking plaats;
• waar staan primaire data en back-ups;
• waar draaien de gebruikte modellen;
• kunnen supportmedewerkers buiten de EER toegang krijgen;
• welke internationale doorgiften vinden plaats;
• op welke juridische grondslag gebeurt dat?

Laat de leverancier de gegevensstroom schriftelijk vastleggen.

6. Welke subprocessors en modelleveranciers worden gebruikt?

Veel AI-producten zijn opgebouwd uit verschillende diensten.

De leverancier kan bijvoorbeeld zelf in Europa hosten, maar voor modelverwerking, logging, monitoring of support andere partijen gebruiken.

Vraag daarom om:

• actuele subprocessorlijst;
• functie van iedere subprocessor;
• verwerkingslocatie;
• wijzigingsprocedure;
• meldtermijn bij nieuwe subprocessors;
• mogelijkheid om bezwaar te maken;
• voorwaarden van onderliggende modelaanbieders.

Controleer ook of de contractuele garanties van de AI-leverancier daadwerkelijk doorwerken naar de onderliggende partijen.

7. Worden uw gegevens gebruikt voor modeltraining of productverbetering?

Vraag dit expliciet voor iedere gegevenscategorie:

• prompts;
• geüploade documenten;
• modeluitvoer;
• feedback van gebruikers;
• correcties;
• telemetrie;
• loggegevens;
• supporttickets.

Een antwoord als “wij trainen niet op klantdata” is onvoldoende als een onderliggende modelaanbieder andere voorwaarden hanteert.

Vraag:

Geldt de uitsluiting van training en productverbetering contractueel voor de volledige verwerkingsketen?

8. Welke bewaartermijnen gelden en hoe werkt verwijdering?

Breng bewaartermijnen apart in kaart voor:

• documenten;
• prompts;
• resultaten;
• auditlogs;
• technische logs;
• back-ups;
• supportdata.

Vraag vervolgens wat “verwijderen” betekent.

Wordt informatie direct verwijderd uit primaire opslag? Wanneer verdwijnen back-ups? Kunnen logs persoonsgegevens bevatten? Wat gebeurt er na beëindiging van de overeenkomst?

Maak verwijdering onderdeel van de exitprocedure en laat aantonen hoe deze werkt.

9. Welke informatiebeveiligingsmaatregelen dekken de aangeboden dienst?

Een ISO 27001-certificaat kan belangrijk bewijs zijn, maar controleer altijd:

• welke rechtspersoon is gecertificeerd;
• welk toepassingsgebied op het certificaat staat;
• of de aangeboden dienst binnen die scope valt;
• welke certificerende instelling het certificaat heeft afgegeven;
• geldigheidsduur;
• relevante uitsluitingen.

“Wij werken volgens ISO 27001” is niet hetzelfde als “de aangeboden dienst valt onder een actuele certificering”.

Voor overheidsorganisaties is daarnaast de Baseline Informatiebeveiliging Overheid relevant. Digitale Overheid publiceert informatie over BIO2 en de relatie met de Cyberbeveiligingswet.

Laat uw eigen CISO of informatiebeveiligingsfunctie bepalen welke maatregelen voor de concrete toepassing nodig zijn.

10. Zijn rollen, functiescheiding en toegangsregistratie beschikbaar?

Een AI-systeem voor publieke organisaties moet niet alleen onderscheid maken tussen “gebruiker” en “beheerder” als de werkprocessen meer rollen kennen.

Vraag of u bijvoorbeeld kunt onderscheiden tussen:

• aanvrager;
• inkoper;
• inhoudelijk expert;
• beoordelaar;
• jurist;
• budgethouder;
• beheerder;
• auditor.

Controleer daarnaast:

• multifactorauthenticatie;
• single sign-on;
• rollen en rechten;
• least privilege;
• logging van toegang;
• beheer van accounts;
• periodieke toegangsreview;
• functiescheiding.

Bij procurement kan het bijvoorbeeld relevant zijn dat een beoordelaar alleen de onderdelen ziet die voor zijn of haar taak nodig zijn.

11. Welke bronnen gebruikt de AI — en kunt u de versie terugvinden?

Voor een publieke organisatie is “de AI kent Nederlandse wetgeving” geen bruikbare controle.

Vraag:

• welke bronnen worden gebruikt;
• welke versie;
• wanneer de bron is bijgewerkt;
• wie bepaalt dat een bron actueel is;
• of eigen beleidsregels kunnen worden toegevoegd;
• hoe conflicten tussen bronnen worden behandeld;
• of de gebruiker de relevante passage kan terugvinden.

Dit is vooral belangrijk wanneer AI wordt gebruikt rond aanbestedingsregels, contractvoorwaarden of intern beleid.

Voor Nederlandse aanbestedingen kunnen onder meer de Aanbestedingswet en andere aanbestedingsregels, de Gids Proportionaliteit, het ARW en organisatiespecifieke voorwaarden relevant zijn.

12. Hoe worden Nederlandse regels en eigen beleid gevalideerd?

Vraag niet:

“Is het systeem compliant met de Aanbestedingswet?”

Vraag:

“Welke concrete controles zijn ingericht, tegen welke bronnen en versies zijn die gevalideerd, en welke testgevallen tonen aan wat de controle wel en niet herkent?”

Een volwassen antwoord bevat bijvoorbeeld:

• naam van de controle;
• relevante bron;
• bronversie;
• verwachte uitkomst;
• positieve test;
• negatieve test;
• bekende beperking;
• moment waarop menselijke beoordeling vereist is.

Dat voorkomt dat “compliance” een marketingterm wordt.

13. Hoe blijft menselijke controle zichtbaar?

Een menselijke beoordelaar die alleen op “akkoord” kan klikken nadat AI al een volledige conclusie heeft gepresenteerd, is niet automatisch betekenisvolle menselijke controle.

Vraag of gebruikers:

• de onderliggende broninformatie kunnen zien;
• de AI-uitkomst kunnen wijzigen;
• de AI-uitkomst kunnen afwijzen;
• een eigen motivering kunnen toevoegen;
• kunnen zien wat door AI en wat door een mens is toegevoegd;
• eerdere versies kunnen terugvinden;
• correcties kunnen uitvoeren zonder het oorspronkelijke spoor te verliezen.

Voor publieke besluitvorming is vooral van belang dat achteraf duidelijk kan worden gemaakt hoe een conclusie tot stand kwam.

14. Hoe ondersteunt het systeem beoordeling tegen vooraf vastgestelde criteria?

Bij aanbestedingen mag AI niet tijdens de evaluatie ongemerkt nieuwe beoordelingscriteria introduceren.

Vraag daarom:

• worden de gepubliceerde criteria als vast beoordelingskader gebruikt;
• kan AI alleen informatie aan die criteria koppelen;
• wie mag criteria wijzigen;
• wordt een wijziging gelogd;
• blijven bronpassages zichtbaar;
• kunnen meerdere beoordelaars afzonderlijk werken;
• hoe worden afwijkende beoordelingen behandeld;
• blijft de uiteindelijke menselijke motivering bewaard?

Gebruik liever termen als gestructureerde, consistente en traceerbare beoordeling dan een niet onderbouwde belofte van “volledig objectieve AI-scoring”.

15. Welke audit- en dossierinformatie kunt u exporteren?

Een audit trail die alleen in het leveranciersplatform kan worden bekeken, is niet automatisch een bruikbaar aanbestedingsdossier.

Vraag welke informatie u kunt exporteren, bijvoorbeeld:

• documentversies;
• gebruikte criteria;
• gekoppelde bronpassages;
• AI-analyses;
• menselijke wijzigingen;
• goedkeuringen;
• tijdstippen;
• gebruikers;
• beoordelingsresultaten;
• opmerkingen;
• workflowhistorie.

Controleer of het formaat aansluit op uw archiverings- en informatiebeheerbeleid.

16. Welke koppelingen bestaan daadwerkelijk?

Maak onderscheid tussen:

beschikbaar in productie → standaardconnector → maatwerk → roadmap.

Vraag per integratie:

• is deze vandaag beschikbaar;
• welke richting stroomt de data;
• welke velden worden verwerkt;
• wie beheert de koppeling;
• wat gebeurt er bij fouten;
• hoe worden autorisaties geregeld;
• is export mogelijk zonder de integratie?

Voor Nederlandse aanbestedingen geldt bijvoorbeeld dat een AI-platform niet automatisch TenderNed vervangt. TenderNed beschrijft hoe aankondigingen worden gepubliceerd.

17. Hoe voorkomt u leveranciersafhankelijkheid?

Vraag vóór contractering wat er gebeurt als u wilt stoppen.

Controleer:

• export van documenten;
• export van metadata;
• workflowhistorie;
• auditinformatie;
• gebruikersinformatie;
• eigen templates;
• configuraties;
• verwijdering na export;
• ondersteuning bij migratie;
• kosten van exit.

Een goed exitplan wordt opgesteld voordat de leverancier onmisbaar is.

18. Hoe gaat de leverancier om met modelwijzigingen?

AI-producten kunnen veranderen zonder dat de gebruikersinterface zichtbaar verandert.

Een nieuw model kan andere antwoorden, samenvattingen of classificaties geven.

Vraag daarom:

• welke wijzigingen de leverancier mag doorvoeren;
• wanneer klanten worden geïnformeerd;
• of kritieke workflows opnieuw worden getest;
• of een modelversie kan worden vastgezet;
• of resultaten reproduceerbaar genoeg zijn voor uw gebruik;
• welke rollback- of incidentprocedure bestaat.

Voor hoog-impact workflows is “we gebruiken altijd automatisch het nieuwste model” niet vanzelfsprekend een voordeel.

19. Welke verplichtingen uit de AI-verordening zijn relevant?

Niet iedere toepassing van AI door een overheid valt automatisch in dezelfde risicocategorie.

Beoordeel daarom de concrete toepassing, de rol van uw organisatie en de relevante ingangsdata.

Vraag onder andere:

• welke rol de leverancier onder de AI-verordening vervult;
• welke rol uw organisatie vervult;
• welke documentatie beschikbaar is;
• hoe AI-geletterdheid wordt ondersteund;
• hoe monitoring en incidenten zijn ingericht;
• of de use case door een wijziging van inzet in een andere categorie kan vallen.

De Autoriteit Persoonsgegevens publiceert uitleg over de AI-verordening.

20. Welke acceptatiecriteria gelden vóór ingebruikname?

Sluit een pilot niet af met:

“De gebruikers waren enthousiast.”

Definieer vooraf meetbare acceptatiecriteria.

Bijvoorbeeld:

Onderdeel	Voorbeeld van acceptatiebewijs
Broncontrole	Gebruiker kan iedere belangrijke conclusie terugvoeren naar bron en passage
Toegangsbeheer	Rollen en rechten zijn getest met representatieve gebruikers
Gegevensverwerking	Gegevensstroom, subprocessors en bewaartermijnen zijn schriftelijk bevestigd
Menselijke correctie	AI-uitkomst kan worden afgewezen en gemotiveerd gewijzigd
Nederlandse controles	Afgesproken testgevallen geven de verwachte waarschuwingen en bekende beperkingen
Dossierexport	Een compleet testdossier kan in afgesproken formaat worden geëxporteerd
Verwijdering	Testdata kan volgens de afgesproken procedure worden verwijderd
Incidentproces	Contactpunten, termijnen en escalatie zijn vastgelegd
Modelwijzigingen	Procedure voor relevante modelupdates is contractueel afgesproken

Zo wordt een pilot een echte acceptatietest.

Een compacte leveranciersscorecard

Vraag iedere leverancier minimaal om dezelfde bewijsstukken:

1. actuele architectuur- en gegevensstroom;
2. subprocessorlijst;
3. privacy- en verwerkersvoorwaarden;
4. actuele beveiligingscertificaten inclusief scope;
5. overzicht van rollen en rechten;
6. overzicht van bewaartermijnen;
7. beschrijving van training en productverbetering met klantdata;
8. lijst van beschikbare integraties;
9. voorbeeld van audit- en dossierexport;
10. documentatie van menselijke review en overrides;
11. relevante AI-verordening-documentatie;
12. testplan voor uw concrete use case;
13. exit- en verwijderingsprocedure.

Laat de bewijsstukken onderdeel worden van de beoordeling, niet alleen van een gesprek na gunning.

Wat betekent dit voor AI bij publieke procurement?

Voor procurement-AI komt daar nog een extra laag bij.

Een leverancier kan uitstekende beveiliging hebben en toch onvoldoende controle bieden op:

• de gebruikte gunningscriteria;
• proportionaliteitsrisico's;
• documentversies;
• menselijke beoordelaars;
• bronpassages;
• interne goedkeuring;
• aansluiting op het eigen inkoopbeleid.

Informatiebeveiliging en aanbestedingscontrole zijn daarom aanvullend, niet uitwisselbaar.

Lees voor de vergelijking van verschillende procurement-AI-benaderingen ook AI voor Nederlandse aanbestedingen: Daliio, Tenpu en Juriaan.ai vergeleken.

Bekijk daarnaast welke productinformatie en bewijsstukken Daliio beschikbaar maakt op Vertrouwen en beveiliging.

Veelgestelde vragen

Is ISO 27001 voldoende om AI-software veilig in te kopen?

Nee. ISO 27001 kan relevant bewijs leveren over het informatiebeveiligingsmanagement van een organisatie, maar u moet controleren welke rechtspersoon en dienst binnen de certificeringsscope vallen. Daarnaast blijven privacy, gegevensstromen, toegangsbeheer, AI-governance, concrete gebruiksrisico's en contractuele afspraken relevant.

Moet een overheid altijd een DPIA uitvoeren voor AI?

Dat hangt af van de concrete verwerking en risico's. Beoordeel dit met uw privacyfunctie of functionaris gegevensbescherming op basis van de werkelijke use case en gegevensverwerking.

Mag een leverancier onze documenten gebruiken om AI-modellen te trainen?

Dat hangt af van de contracten en technische inrichting. Vraag expliciet of prompts, documenten, resultaten, feedback en telemetrie voor training of productverbetering worden gebruikt, inclusief door onderliggende modelaanbieders.

Is hosting in de EU voldoende?

Nee. Breng de volledige verwerkingsketen in kaart, inclusief modelverwerking, support, logging, back-ups en subprocessors.

Is AI automatisch in strijd met aanbestedingsregels?

Nee. Het gebruik moet worden beoordeeld in de context van de concrete werkzaamheden. De aanbestedende dienst blijft verantwoordelijk voor procedure, criteria, gelijke behandeling, motivering en andere toepasselijke verplichtingen.

Moet een AI-leverancier TenderNed ondersteunen?

Niet noodzakelijk. Dat hangt af van de rol die de oplossing in uw architectuur krijgt. Als formele publicatie onderdeel van de oplossing moet zijn, is een aantoonbare TenderNed-koppeling relevant. Als de AI-oplossing alleen voorbereiding, analyse of beoordeling ondersteunt, kan publicatie via een bestaand aanbestedingssysteem blijven lopen.

Beoordeel AI met uw eigen documenten en risico's

Een generieke productdemo laat vooral zien wat een leverancier graag demonstreert.

Een betere test gebruikt uw eigen representatieve proces, veilig te gebruiken documenten, vooraf bepaalde risico's en meetbare acceptatiecriteria.

Wilt u zien hoe Daliio documentcreatie, interne workflows, analyse en menselijke beoordeling kan ondersteunen zonder uw bestaande procurementproces automatisch te vervangen?

Plan een demonstratie met een bestaande aanbesteding of eigen template.