Bij de toepassing van artificiële intelligentie binnen publieke organisaties gaat veel aandacht uit naar het identificeren van geschikte use-cases. Dat is wel terecht, maar ook onvoldoende. AI wordt niet uitsluitend als zelfstandige toepassing verworven, maar ook als functionaliteit binnen primaire en bedrijfsvoeringsapplicaties, zoals elektronische dossiers, eHRM-systemen, financiële applicaties en servicemanagementplatformen. Daarmee wordt AI onderdeel van een bredere ICT-aanbesteding en contractuele relatie.
Dit artikel onderzoekt welke gevolgen dat heeft voor de publieke opdrachtgever. Achtereenvolgens wordt ingegaan op het juridische risicoprofiel van de concrete AI-functionaliteit, gegevensverwerking en de achterliggende AI-leveranciersketen, informatiebeveiliging, prijs- en verbruiksmodellen, wijzigingen binnen SaaS-roadmaps en de aanbestedingsrechtelijke ruimte voor toekomstige AI-functionaliteit. Daarbij komen onder meer de AVG, de AI-verordening, de Cyberbeveiligingswet en BIO2 aan de orde.
Tevens wordt uiteengelegd welke rol algemene IT-inkoopvoorwaarden vervullen. GIBIT 2025 bevat inmiddels specifieke bepalingen over algoritmische toepassingen en AI-systemen. ARBIT 2022 biedt voor de rijksinkoop een generiek contractueel kader dat bij AI op onderdelen nadere concretisering kan verlangen. Aan de hand van geanonimiseerde praktijkvoorbeelden wordt betoogd dat een kansrijke AI-use-case daarom moet worden gevolgd door een specifieke AI-analyse binnen de aanbesteding en contractering van de hoofdapplicatie. Daarbij moeten niet alleen de functionele mogelijkheden, maar ook gegevensstromen, leveranciersafhankelijkheden, structurele kosten en wijzigingen gedurende de contractduur beheersbaar worden gemaakt.
1. De use case als vertrekpunt
Een recente bijdrage van Quarant draagt de titel ‘Succesvol starten met AI begint bij het juiste vraagstuk’. De centrale gedachte is dat een publieke organisatie niet eerst een AI-tool zou moeten selecteren en vervolgens naar toepassingsmogelijkheden moet zoeken, maar moet vertrekken vanuit een concreet probleem in de dagelijkse praktijk. Vervolgens kan worden onderzocht of AI daadwerkelijk waarde kan toevoegen en of toepassing daarvan haalbaar is[1].
Dat uitgangspunt is overtuigend. Een heldere use case voorkomt technologische oplossingen op zoek naar een probleem en maakt het mogelijk de potentiële waarde van een AI-toepassing vooraf te onderzoeken. De use case vormt echter slechts het begin.
Zodra aannemelijk is dat AI daadwerkelijk toegevoegde waarde heeft, moet worden beoordeeld onder welke juridische, organisatorische, beveiligings-technische en financiële voorwaarden deze functionaliteit kan worden verworven en gebruikt. Dat vraagstuk is bij publieke organisaties des te relevanter omdat AI niet noodzakelijk als zelfstandige dienst wordt ingekocht. Steeds vaker wordt AI aangeboden als onderdeel van een applicatie die voor de primaire taak of bedrijfsvoering wordt gebruikt: een elektronisch patiënt-, cliënt- of jeugddossier, een eHRM-oplossing, een financieel systeem, een zaaksysteem of een servicemanagementplatform.
De gebruikte praktijkvoorbeelden zijn ontleend aan recente Nederlandse aanbestedingstrajecten en zijn geanonimiseerd. Zij zijn illustratief en vormen geen representatieve steekproef van de AI-markt.
2. AI in bedrijfsapplicaties: verschillende verschijningsvormen
De toepassing van AI binnen organisaties moet niet uitsluitend worden geassocieerd met medewerkers die rechtstreeks gebruikmaken van generatieve AI-diensten zoals algemene chatbots. Binnen bedrijfsapplicaties zijn ondertussen verschillende andere vormen zichtbaar.
In een recente aanbesteding van een elektronisch dossier bood een leverancier bijvoorbeeld aanvullende AI-functionaliteiten aan voor spraak-naar-tekst, geautomatiseerde conclusiegeneratie, het bevragen van dossierinformatie en ondersteuning van de planning. De leverancier presenteerde deze toepassingen expliciet als optionele uitbreiding op de reguliere functionaliteit[2].
In een andere aanbesteding werd een AI-laag aangeboden die rechtstreeks binnen een elektronisch dossier functioneerde. Daarmee konden omvangrijke dossiers worden samengevat en bevraagd, kon informatie uit behandelrichtlijnen binnen de workflow beschikbaar worden gemaakt en konden documenten worden gegenereerd[3].
Een derde voorbeeld betreft een eHRM-platform. Daarin werd een rol-gestuurde AI-assistent beschreven die vragen van medewerkers en leidinggevenden beantwoordt en hen naar passende acties binnen het systeem leidt. De leverancier vermeldde daarbij uitdrukkelijk dat de AI zelf geen besluiten neemt en geen handelingen zelfstandig uitvoert; de gebruiker blijft daarvoor verantwoordelijk[4].
Daarmee zijn verschillende commerciële en functionele modellen zichtbaar. AI kan als afzonderlijke optie of module worden aangeboden, als geïntegreerde functionaliteit waarvoor afzonderlijke vergoedingen gelden, maar ook deel uitmaken van de reguliere doorontwikkeling van een SaaS-platform. Deze verschijningsvormen zeggen op zichzelf nog weinig over het juridische risicoprofiel. Daarvoor is niet alleen bepalend hoe een leverancier de AI commercieel verpakt, maar voor welk doel de concrete AI-functionaliteit wordt gebruikt en welke betekenis haar output in het proces krijgt.
3. Het beoogde gebruik van AI bepaalt het juridisch risicoprofiel
De enkele aanwezigheid van AI-functionaliteit binnen een applicatie bepaalt niet welke verplichtingen uit de AI-verordening van toepassing zijn. De AI-verordening kent een risico-gebaseerde systematiek. Artikel 6 lid 2 jo bijlage III wijst categorieën AI-systemen aan die op grond van hun beoogde gebruik als hoog risico kunnen kwalificeren. Voor het HR-domein noemt bijlage III, onderdeel 4, onder meer AI-systemen voor werving en selectie en systemen die worden gebruikt voor bepaalde beslissingen over arbeidsrelaties, promotie of beëindiging daarvan, taaktoewijzing op basis van individueel gedrag of persoonlijke kenmerken en monitoring of beoordeling van werknemers[5].
Dat betekent niet dat iedere toepassing van AI binnen een eHRM-systeem automatisch als hoog risico moet worden aangemerkt. Art. 6 lid 3 bepaalt dat een in bijlage III genoemd AI-systeem niet als hoog risico wordt beschouwd wanneer het geen significant risico oplevert voor de gezondheid, veiligheid of grondrechten van natuurlijke personen en de uitkomst van besluitvorming niet wezenlijk beïnvloedt. De bepaling noemt daarbij vier situaties waarin daarvan sprake kan zijn, waaronder het uitvoeren van een beperkte procedurele of voorbereidende taak en het verbeteren van het resultaat van een reeds voltooide menselijke activiteit. Voor AI-systemen die profilering van natuurlijke personen verrichten, geldt deze uitzondering niet[6].
De juridische beoordeling moet daarom op het niveau van de concrete functionaliteit en het beoogde gebruik plaatsvinden. De kwalificatie van bijvoorbeeld het eHRM-pakket of het elektronisch dossier als geheel zegt daarvoor onvoldoende. Relevant is wat de AI-functie doet, welke output zij produceert, welke gegevens daarvoor worden gebruikt en welke betekenis de output krijgt in het daaropvolgende menselijke of geautomatiseerde proces.
Gefaseerde toepasselijkheid van de AI-verordening
Ook de gefaseerde toepasselijkheid van de AI-verordening is bij meerjarige ICT-overeenkomsten van belang. De AI-verordening trad op 1 augustus 2024 in werking en is sinds 2 augustus 2026 in algemene zin van toepassing. Na de wijziging van de verordening in 2026 gelden voor een deel van de hoog-risicoverplichtingen echter latere momenten. De verplichtingen uit hoofdstuk III, afdelingen 1 tot en met 3, zijn voor AI-systemen die op grond van art. 6 lid 2 jo bijlage III als hoog risico kwalificeren van toepassing vanaf 2 december 2027. Voor de in art. 6 lid 1 jo bijlage I bedoelde systemen geldt 2 augustus 2028. Het uitstel houdt onder meer verband met de vertraagde beschikbaarheid van geharmoniseerde normen, gemeenschappelijke specificaties, richtsnoeren en uitvoeringsstructuren[7].
Voor een ICT-aanbesteding waarbij doorgaans een meerjarige overeenkomst wordt gesloten is dus niet uitsluitend relevant welke verplichtingen gelden op de datum van aankondiging of de ingangsdatum van de overeenkomst. De overeenkomst kan ruimschoots doorlopen nadat aanvullende bepalingen van toepassing zijn geworden.
Voor hoog-risico-AI gaat het onder meer om verplichtingen inzake risicobeheer en data governance (art. 9 en 10), technische documentatie en logging (art. 11 en 12), transparantie en gebruiksinstructies (art. 13), menselijk toezicht (art. 14) en nauwkeurigheid, robuustheid en cyberbeveiliging (art. 15). Voor publiekrechtelijke gebruiksverantwoordelijken die een in art. 6 lid 2 bedoeld hoog-risico-AI-systeem in gebruik nemen, kan daarnaast op grond van art. 27 AI-verordening een grondrechten-effect-beoordeling (Fundamental Rights Impact Assessment, FRIA) verplicht zijn. Deze moet worden onderscheiden van de gegevens-beschermings-effectbeoordeling (DPIA) van art. 35 AVG, al kunnen beide beoordelingen gedeeltelijk overlappen.[8]
Dit brengt mee dat bij de uitvraag rekening moet worden gehouden met voorzienbare verplichtingen die gedurende de looptijd van de overeenkomst relevant worden. Die kunnen al bij de oorspronkelijke contractering gevolgen hebben voor eisen, verantwoordelijkheidsverdeling, documentatie, wijzigingsbeheer en kosten.
4. Gegevensbescherming en de achterliggende AI-keten
Wanneer AI binnen een bedrijfsapplicatie gegevens verwerkt, moet de opdrachtgever niet alleen weten wat de zichtbare applicatie doet, maar ook wat zich daarachter bevindt. Bij een elektronisch dossier dat met behulp van een taalmodel kan worden geanalyseerd, zijn bijvoorbeeld vragen relevant als:
- worden volledige dossiers aan het model aangeboden of slechts geselecteerde tekstfragmenten?
- worden prompts en antwoorden bewaard?
- worden embedding of andere afgeleide gegevens gemaakt?
- waar vindt de verwerking plaats?
- voor welke doeleinden mogen de gegevens worden gebruikt?
- en welke andere partijen zijn technisch of contractueel betrokken?
De leverancier van de bedrijfsapplicatie hoeft niet dezelfde partij te zijn als de aanbieder van het gebruikte AI-model. Dat is niet uitsluitend een theoretische mogelijkheid. In een recente offerte voor AI-functionaliteit binnen een bedrijfsapplicatie benoemde de leverancier wijzigingen in de licentie- en prijsmodellen van externe AI-dienstverleners expliciet als een factor waarvan zijn eigen dienstverlening en prijsstelling afhankelijk waren[9]. Daarmee ontstaat achter de directe contractuele relatie tussen opdrachtgever en applicatieleverancier een technische en contractuele keten van andere partijen. De opdrachtgever moet voldoende inzicht hebben in de keten om zijn eigen verantwoordelijkheden te kunnen vervullen.
Een online privacybeleid is geen contractuele waarborg
Bij de beantwoording van vragen over gegevensverwerking wordt regelmatig verwezen naar een online privacy statement, trust center, securitypagina, data policy of lijst met subverwerkers van de achterliggende AI-provider. Die informatie kan belangrijk zijn en moet zeker niet worden genegeerd. De juridische functie ervan moet echter worden onderscheiden van de contractuele afspraken die tussen opdrachtgever en leverancier noodzakelijk zijn.
De informatieverplichtingen tegenover betrokkenen zijn onder meer geregeld in art. 13 en 14 AVG. Een privacyverklaring kan aan die transparantie bijdragen. Wanneer persoonsgegevens daarentegen namens een verwerkingsverantwoordelijke worden verwerkt, verlangt art. 28 lid 3 AVG een bindende overeenkomst of andere rechtshandeling waarin onder meer onderwerp en duur van de verwerking, aard en doel, soorten persoonsgegevens, categorieën betrokkenen en rechten en verplichtingen van de verwerkingsverantwoordelijke zijn geregeld. Art. 28 lid 2 regelt de voorafgaande specifieke of algemene schriftelijke toestemming voor andere verwerkers. Bij een algemene toestemming moet de opdrachtgever over toevoeging of vervanging worden geïnformeerd en gelegenheid krijgen daartegen bezwaar te maken. Art. 28 lid 4 verlangt bovendien doorlegging van de gegevensbeschermingsverplichtingen naar de volgende verwerker, waarbij de oorspronkelijke verwerker tegenover de verwerkingsverantwoordelijke volledig aansprakelijk blijft voor de nakoming van de gegevensbeschermingsverplichtingen door die andere verwerker[10].
Een mededeling op een website dat gegevens bijvoorbeeld niet worden gebruikt om modellen te trainen is daarom op zichzelf onvoldoende. Vastgesteld moet worden op welke concrete dienst, contractvorm en gegevensstroom de toezegging betrekking heeft, welke uitzonderingen bestaan en of deze toezegging daadwerkelijk deel uitmaakt van de rechtsverhouding met de opdrachtgever.
Een verwijzing naar online documentatie verdient bijzondere voorzichtigheid. Privacy statements, trust centers, lijsten met subverwerkers en productvoorwaarden worden door leveranciers regelmatig gewijzigd, soms zonder dat de opdrachtgever daarvan actief kennisneemt. Een hyperlink creëert daardoor onvoldoende zekerheid over welke inhoud op welk moment contractueel geldt. Indien dergelijke documentatie juridisch relevant is voor de aanvaardbaarheid van de dienstverlening, ligt het voor de hand de toepasselijke versie te fixeren. Dat kan door het document als bijlage bij de overeenkomst op te nemen, de versie en datum expliciet te benoemen of een gewaarmerkte kopie vast te leggen. Daarnaast moet worden geregeld of en onder welke voorwaarden wijzigingen gedurende de looptijd zijn toegestaan, welke wijzigingen vooraf moeten worden gemeld en welke gevolgen een wijziging voor de opdrachtgever heeft.
Bij voor de dienstverlening belangrijke onderwerpen, zoals gegevensgebruik, inzet van subverwerkers, verwerkingslocaties of het gebruik van gegevens voor training of modelverbetering, verdient het de voorkeur om de kernverplichtingen rechtstreeks in de overeenkomst of verwerkersovereenkomst op te nemen in plaats van uitsluitend te verwijzen naar wijzigbare online documentatie. Een hyperlink is geen stabiele contractuele waarborg. Dat geldt temeer wanneer de online documentatie afkomstig is van een achterliggende AI-provider waarmee de opdrachtgever zelf geen rechtstreekse contractuele relatie heeft. De relevante contractuele vraag is uiteindelijk niet of een AI-provider een privacy policy publiceert, maar welke verplichtingen de contractspartij jegens de opdrachtgever heeft aanvaard en hoe deze verplichtingen in de achterliggende AI- en verwerkersketen zijn doorgelegd.
5. Van gegevensbescherming naar cyberbeveiliging en ketenrisico
De achterliggende leveranciersketen is niet uitsluitend vanuit de AVG relevant. Op 15 augustus 2026 trad de Cyberbeveiligingswet in werking. Voor essentiële en belangrijke entiteiten waarop de wet van toepassing is, bevat art. 21 een risico-gebaseerde zorgplicht. Tot de onderwerpen die de maatregelen in ieder geval moeten omvatten behoren volgens art. 21 lid 3 onder d. de beveiliging van de toeleveringsketen, waaronder beveiligings-gerelateerde aspecten van de relatie met rechtstreekse leveranciers en dienstverleners, en volgens onderdeel e. beveiliging bij de verwerving, ontwikkeling en onderhoud van netwerk- en informatiesystemen. Art. 21 lid 4 verlangt bij de beoordeling van ketenrisico’s onder meer aandacht voor specifieke kwetsbaarheden en cyberbeveiligingspraktijken van leveranciers[11].
De aanwezigheid van een externe AI-provider achter een bedrijfsapplicatie kan daarmee ook een informatiebeveiligings- en continuïteitsvraagstuk zijn. Dat speelt bijvoorbeeld wanneer een essentieel proces afhankelijk wordt van één modelaanbieder, wanneer aanvullende infrastructuur in de gegevensverwerking wordt geïntroduceerd of wanneer vervanging van de AI-provider leidt tot wijzigingen in de beveiligings- of verwerkingsketen.
BIO2: relatie met inkoop nog concreter
BIO2 versie 1.3 maakt de relatie met inkoop nog concreter. Overheidsmaatregel 5.19.01 verlangt dat informatiebeveiligingseisen bij offerteaanvragen waarin informatievoorziening een rol speelt onderdeel vormen van het pakket aan inkoopeisen. Maatregel 5.20.01 verlangt vervolgens dat deze beveiligingseisen expliciet in de inkoopcontracten worden opgenomen.
Verder verlangt 5.20.06 vóór contractering een risicoafweging over de beheersbaarheid van de afhankelijkheid van een leverancier en een expliciete uitwerking van de exitstrategie. Op grond van 5.21.02 moet de leverancier vóór contractsluiting inzicht geven in de keten van toeleveranciers en de risico’s daarin. De relevante beveiligingseisen moeten volgens 5.21.03 in die keten worden geborgd en op grond van 5.21.04 moeten gedurende de looptijd veranderingen in de toeleveringsketen en de daaraan verbonden risico’s worden gemeld[12].
Voor essentiële entiteiten in de sector overheid, met uitzondering van de waterschappen, waarvoor een afzonderlijke sectorale regeling geldt, wordt de zorgplicht van art. 21 Cyberbeveiligingswet nader uitgewerkt in de ‘Cyberbeveiligingsregeling sector overheid’. Art. 5 van die regeling schrijft voor dat de passende en evenredige beveiligingsmaatregelen ten minste de relevante overheidsmaatregelen uit BIO2 versie 1.3 omvatten[13].
Voor AI-inkoop is de praktische consequentie duidelijk: de leveranciersketen achter de AI-functionaliteit hoort niet pas na gunning bij een beveiligingsonderzoek boven tafel te komen. Informatie daarover kan reeds nodig zijn voor de aanbestedingsstukken, de beoordeling van de aanbieding en de contractuele afspraken.
6. Prijs en schaalbaarheid van AI-functionaliteit
Naast gegevensbescherming en informatiebeveiliging verdient het commerciële model bijzondere aandacht. Bij traditionele SaaS-dienstverlening zijn opdrachtgevers vertrouwd met prijzen per gebruiker, medewerker, module, dossier of organisatie. Bij AI kunnen daar andere prijsdragers bijkomen, zoals aantallen verwerkingen, documenten, gesprekken, via API’s afgenomen gebruik, tokens of gebruikte rekenkracht. Een recent geanonimiseerd voorbeeld illustreert het mogelijke financiële effect. Voor geïntegreerde AI-functionaliteit werd een vaste jaarlijkse licentievergoeding aangeboden, maar daarnaast zouden de onderliggende AI-modellen afzonderlijk op basis van gebruik worden afgerekend. De aanvankelijk geraamde jaarlijkse gebruikskosten bedroegen ongeveer driemaal de vaste jaarlijkse licentievergoeding[14]. De zichtbare licentieprijs vertelde in dat geval dus slechts een deel van het financiële verhaal. In een andere fase van hetzelfde aanbestedingstraject kon aanvullende AI-functionaliteit nog niet definitief worden geprijsd. Eerst moesten onder meer de concrete use-cases, integratie, rollen en rechten en het verwachte gebruiksvolume nader worden bepaald[15]. De leverancier benoemde daarnaast expliciet dat de toekomstige prijs mede kon worden beïnvloed door de beschikbaarheid en prijs van gespecialiseerde hardware, energie- en datacenterkosten, wijzigingen in prijs- en licentiemodellen van externe AI-dienstverleners, ontwikkelingen in het LLM-landschap, regelgeving en het daadwerkelijke gebruiksvolume[16].
Geen uniform AI-prijsmodel
Daartegenover staat een ander marktmodel. In het hiervoor genoemde eHRM-voorbeeld wordt het gehele SaaS-platform tegen één tarief per medewerker per jaar aangeboden, zonder afzonderlijke licentie per gebruikersrol of module[17]. Er bestaat dus geen uniform AI-prijsmodel. AI kan deel uitmaken van de reguliere SaaS-vergoeding, afzonderlijk worden gelicentieerd, verbruiksafhankelijk worden afgerekend of bestaan uit een combinatie van vaste en variabele prijscomponenten.
Een jaarprijs is geen Total Cost of Ownership
Dit stelt bijzondere eisen aan de businesscase en het prijzenblad. Bij een verbruiksafhankelijk model moet niet alleen bekend zijn dát naar gebruik wordt afgerekend. Ook moet worden vastgesteld welke meeteenheid wordt gehanteerd, welk volume in de vaste prijs is inbegrepen, welke eenheidsprijzen of staffels gelden, hoe het verbruik wordt geregistreerd en gecontroleerd en of budgetgrenzen of waarschuwingen kunnen worden ingesteld.
En er moet worden geregeld wat gebeurt wanneer een externe modelprovider zijn prijzen wijzigt of wanneer de applicatieleverancier zelf besluit een ander mogelijk duurder model te gebruiken.
GIBIT 2025 bevat voor gemeentelijke IT-contracten een generiek financieel kader. Art. 11.1 gaat uit van de in de overeenkomst vastgelegde vergoedingen. Art. 11.10 bevat een regeling voor aantoonbare, bij het sluiten van de overeenkomst niet voorzienbare prijsstijgingen van Derdenprogrammatuur en art. 11.11 voor andere aanzienlijke onvoorzienbare kostprijsstijgingen[18]. Die bepalingen beantwoorden echter niet vanzelf de voorafgaande vraag wat de contractuele prijsdrager van de AI-dienst is. Dat moet in de concrete uitvraag en overeenkomst worden vastgesteld. Een pilot met een klein volume kan daardoor een onvolledig beeld van de structurele businesscase geven. De financieel relevante vraag is niet alleen wat een experiment kost, maar vooral: wat kost de toepassing wanneer zij succesvol blijkt en het gebruik daadwerkelijk opschaalt?
7. AI als onderdeel van de SaaS-roadmap
Het vraagstuk wordt nog dynamischer wanneer AI niet als afzonderlijke module wordt afgenomen, maar via de reguliere SaaS-roadmap beschikbaar komt. In het eerder genoemde eHRM-aanbod wordt beschreven dat nieuwe functionaliteit centraal wordt ontwikkeld en via reguliere releases beschikbaar wordt gesteld. De opdrachtgever ontvangt vooraf informatie over nieuwe functionaliteiten, wijzigingen, uitfaseringen en de gevolgen daarvan voor processen, beheer en communicatie[19]. Dat is op zichzelf een gebruikelijk kenmerk van SaaS.
Bij AI krijgt dit echter een bijzondere betekenis. Bij een afzonderlijk geprijsde AI-module bestaat een duidelijk beslismoment: de opdrachtgever besluit de module wel of niet af te nemen. Bij AI die onderdeel wordt van een reguliere release kan dat beslismoment minder nadrukkelijk aanwezig zijn. Contractueel moet daarom worden bepaald wanneer een wijziging van AI-functionaliteit méér is dan regulier productmanagement. Dat kan bijvoorbeeld aan de orde zijn wanneer een ander foundation model[20] of een andere AI-provider wordt gebruikt, nieuwe gegevenscategorieën worden verwerkt, een andere verwerkingslocatie ontstaat, AI een wezenlijk andere rol in het bedrijfsproces krijgt of een nieuwe prijscomponent wordt geïntroduceerd.
De vraag is dan onder meer of voorafgaande informatie voldoende is, of expliciete activering of instemming nodig is, of opnieuw een privacy-, AI- of beveiligingsbeoordeling moet plaatsvinden en onder welke voorwaarden een dergelijke wijziging kan worden geweigerd.
8. Aanbestedingsrechtelijke ruimte voor AI-ontwikkeling tijdens de looptijd
Voor aanbestedende diensten heeft toekomstige AI-functionaliteit bovendien een aanbestedingsrechtelijke dimensie. Wanneer bij de oorspronkelijke aanbesteding voorzienbaar is dat gedurende een meerjarige overeenkomst aanvullende AI-functionaliteit kan worden afgenomen of bestaande functionaliteit wezenlijk kan veranderen, moet worden bezien of en op welke wijze daarvoor reeds in de oorspronkelijke aanbesteding ruimte moet worden gecreëerd.
Art. 2.163c Aanbestedingswet 2012 maakt wijziging van een overheidsopdracht zonder nieuwe aanbestedingsprocedure mogelijk wanneer die mogelijkheid in de oorspronkelijke aanbestedingsstukken is voorzien door duidelijke, nauwkeurige en ondubbelzinnige herzieningsclausules, waaronder opties. Die clausules moeten de omvang en aard van mogelijke wijzigingen of opties en de voorwaarden waaronder daarvan gebruik kan worden gemaakt, omschrijven. Zij mogen bovendien niet voorzien in wijzigingen die de algemene aard van de opdracht veranderen[21]. Deze regeling correspondeert met art. 72 lid 1 onder a Richtlijn 2014/24/EU.
Een algemene contractuele bepaling dat een leverancier gedurende bijvoorbeeld vijf tot acht jaar ‘innovaties’ kan aanbieden, biedt daarom zonder nadere afbakening onvoldoende zekerheid dat iedere toekomstige uitbreiding binnen de oorspronkelijk aanbestede opdracht kan worden gebracht. Anderzijds verlangt het aanbestedingsrecht niet dat de opdrachtgever bij publicatie reeds exact kan voorspellen welke AI-modellen, technieken of functionaliteiten jaren later beschikbaar zullen zijn. De opgave is om voorzienbare functionele ontwikkelruimte vooraf voldoende concreet te structureren.
Voorzienbare AI-ontwikkeling vooraf structureren
Een eerste instrument daarvoor is de marktconsultatie. Daarin kan worden onderzocht welke AI-functionaliteiten leveranciers reeds aanbieden, welke ontwikkelingen zij op hun roadmap voorzien, welke externe modellen of AI-providers daarbij worden gebruikt en welke commerciële modellen worden gehanteerd. Dat helpt de opdrachtgever om vóór publicatie te bepalen welke ontwikkelingen zo voorzienbaar zijn dat daarmee in de scope, eisen, opties en prijsstructuur rekening dient te worden gehouden.
Een tweede mogelijkheid is om concrete categorieën toekomstige AI-functionaliteit als optie in de aanbesteding op te nemen. Bij een elektronisch dossier kan bijvoorbeeld worden gedacht aan spraak-naar-tekst, dossiersamenvatting, dossierbevraging of ondersteuning van administratieve processen. De exacte technische uitvoering of het op dat moment gebruikte AI-model hoeft daarbij niet noodzakelijk al vast te staan. Wel moeten aard en omvang van de optie en de voorwaarden waaronder zij kan worden uitgeoefend voldoende duidelijk zijn beschreven. Daarbij heeft een optie niet alleen gevolgen voor de contractuele scope, maar ook voor de raming van de opdracht. Art. 2.15 lid 2 Aw bepaalt dat bij de berekening van de geraamde waarde wordt uitgegaan van het totale bedrag, met inbegrip van opties en verlengingen zoals deze uitdrukkelijk in de aanbestedingsstukken zijn vermeld[22]. Dezelfde systematiek volgt uit art. 5 lid 1 Richtlijn 2014/24/EU. Een toekomstige AI-optie kan dus niet buiten de raming worden gehouden uitsluitend omdat op het moment van aanbesteding nog onzeker is of zij daadwerkelijk zal worden afgenomen.
Een derde instrument is de herzieningsclausule. Daarin kan vooraf worden geregeld onder welke voorwaarden tijdens de looptijd wijzigingen binnen reeds voorziene AI-functionaliteit zijn toegestaan. Dat kan bijvoorbeeld relevant zijn bij vervanging van het onderliggende AI-model, gebruik van een andere modelprovider of verdere ontwikkeling van een reeds in de opdracht opgenomen functionele categorie.
Bij dergelijke clausules verdient het aanbeveling niet alleen vast te leggen dat een wijziging mogelijk is, maar ook aan welke voorwaarden zij moet voldoen. Daarbij kan worden gedacht aan ten minste gelijkblijvende functionaliteit en prestaties, blijvende naleving van privacy- en beveiligingseisen, voorafgaande informatie over wijzigingen in relevante leveranciers of subverwerkers en afspraken over eventuele financiële gevolgen. Art. 2.163c Aw biedt daarmee ruimte voor technologische ontwikkeling, maar verlangt dat de grenzen van die ruimte vooraf voldoende bepaalbaar zijn. De Uniewetgever heeft bij art. 72 Richtlijn 2014/24/EU uitdrukkelijk onderkend dat duidelijke herzieningsclausules kunnen voorzien in aanpassingen die nodig worden door technologische veranderingen.
Een vierde mogelijkheid is het opnemen van een activeringsmoment. Nieuwe AI-functionaliteit kan technisch onderdeel worden van een SaaS-oplossing zonder dat zij daardoor automatisch door de opdrachtgever in gebruik wordt genomen. Contractueel kan worden bepaald dat activering pas plaatsvindt nadat is vastgesteld dat aan vooraf omschreven voorwaarden is voldaan. Afhankelijk van de functionaliteit kan die beoordeling betrekking hebben op het juridische risicoprofiel, gegevensverwerking, informatiebeveiliging, leveranciersketen en de financiële gevolgen van het gebruik.
Een activeringsmechanisme is in het bijzonder relevant bij SaaS-oplossingen waarbij nieuwe functionaliteit via reguliere releases beschikbaar komt. Het creëert een onderscheid tussen de technische beschikbaarheid van een functionaliteit en de beslissing van de opdrachtgever om deze daadwerkelijk voor zijn organisatie te laten gebruiken.
Ten vijfde kan ook het prijsmodel reeds rekening houden met toekomstige AI-functionaliteit. Wanneer het toekomstige gebruik nog niet betrouwbaar kan worden voorspeld, kunnen inschrijvers bijvoorbeeld prijzen of staffels opgeven voor vooraf omschreven gebruikseenheden of gebruiksscenario’s. Daarmee kan worden voorkomen dat een voorzienbare AI-optie wel onderdeel van de oorspronkelijke opdracht vormt, maar de prijs daarvan na gunning feitelijk eenzijdig door de leverancier kan worden bepaald. Bij verbruiksafhankelijke AI kan daarbij aansluiting worden gezocht bij scenario’s voor bijvoorbeeld laag, verwacht en hoog gebruik.
Geen blanco innovatieclausule
Deze instrumenten betekenen niet dat iedere toekomstige AI-ontwikkeling vooraf volledig moet worden beschreven. Een te gedetailleerde technische specificatie kan juist snel verouderen en onnodig beperkend werken. De aanbestedingsrechtelijke eis ziet niet op het voorspellen van de techniek zelf, maar op voldoende transparantie over de functionele en contractuele ruimte waarbinnen wijzigingen kunnen plaatsvinden. Daarom moet onderscheid worden gemaakt tussen enerzijds ruimte voor doorontwikkeling binnen de oorspronkelijk bepaalde prestatie en anderzijds het later toevoegen van wezenlijk andere functionaliteit. Een generieke bepaling als: ‘Opdrachtgever kan gedurende de looptijd nieuwe innovatieve functionaliteiten van leverancier afnemen’ zal zonder verdere afbakening onvoldoende houvast bieden voor substantiële toekomstige uitbreidingen.
Uit art. 2.163c Aw volgt immers dat de mogelijke wijziging of optie niet alleen vooraf moet zijn genoemd, maar dat ook omvang, aard en toepassingsvoorwaarden voldoende duidelijk moeten zijn en de algemene aard van de opdracht niet mag veranderen.
De aanbestedende dienst hoeft dus niet vandaag het AI-landschap van over vijf of acht jaar te voorspellen. Wel behoort hij bij een meerjarige aanbesteding van een hoofdapplicatie na te gaan welke ontwikkeling van AI-functionaliteit redelijkerwijs voorzienbaar is en welke aanbestedingsrechtelijke en financiële ruimte daarvoor bij aanvang moet worden ingericht.
Toekomstbestendig aanbesteden betekent bij AI daarmee niet dat iedere toekomstige functionaliteit al bekend moet zijn. Het betekent dat voorzienbare ontwikkelrichtingen waar nodig worden vertaald naar voldoende bepaalde opties, herzieningsclausules, activeringsvoorwaarden en prijsmechanismen. Zo kan ruimte voor technologische ontwikkeling worden gecombineerd met de vereiste transparantie over de omvang en mogelijke ontwikkeling van de opdracht.
9. Algemene IT-voorwaarden en technische ontwikkeling
De snelle ontwikkeling van AI maakt zichtbaar dat algemene IT-(inkoop)voorwaarden noodzakelijkerwijs slechts een momentopname vormen. Dat is geen kritiek op die voorwaarden. Algemene voorwaarden moeten breed toepasbaar en voldoende stabiel zijn. Technologie, commerciële modellen en regelgeving ontwikkelen zich daarentegen soms binnen enkele jaren fundamenteel.
ARBIT 2022 vormt daarvan een duidelijk chronologisch voorbeeld. De voorwaarden zijn vastgesteld in augustus 2022 en in september 2022 gepubliceerd. De NIS2-richtlijn dateert van december 2022, de AI-verordening van 2024 en de Cyberbeveiligingswet en BIO2 kregen in 2026 hun huidige wettelijke en normatieve positie[23]. Het zou daarom niet juist zijn ARBIT 2022 te verwijten dat daarin geen volledig contractueel regime is opgenomen voor regelgeving en marktontwikkelingen die nadien tot stand zijn gekomen. Omgekeerd kan uit het enkele feit dat actuele algemene voorwaarden van toepassing zijn evenmin worden afgeleid dat daarmee iedere nieuwe technologische ontwikkeling contractueel is afgedekt.
Binnen het gemeentelijke domein is deze actualiseringscyclus goed zichtbaar. GIBIT 2025 vervangt GIBIT 2023 en is volgens de VNG grondig herzien op basis van actuele wet- en regelgeving en praktijkervaring. AI, digitale grondrechten, cloud, open source en datagebruik behoren uitdrukkelijk tot de onderwerpen waaraan in de nieuwe versie aandacht wordt besteed. De VNG adviseert bij nieuwe IT-contracten GIBIT 2025 te gebruiken[24]. Dat GIBIT 2025 actueler is op het gebied van AI betekent echter niet dat het actualiteitsvraagstuk daarmee definitief is opgelost. De technologie en markt zullen zich ook na 2025 blijven ontwikkelen.
Algemene IT-voorwaarden moeten daarom worden beschouwd als contractueel raamwerk, niet als vervanging van een actuele analyse van de concrete ICT-prestatie.
10. Het toepasselijke kader is geen vrije keuze tussen GIBIT en ARBIT
Bij de bespreking van GIBIT en ARBIT past een belangrijke nuance. Het gaat niet om twee concurrerende sets voorwaarden waaruit een aanbestedende dienst bij iedere AI-inkoop vrij de meest aantrekkelijke kan kiezen. GIBIT is ontwikkeld voor het gemeentelijke IT-domein. De VNG omschrijft GIBIT als een set inkoopinstrumenten voor IT-contracten in het gemeentelijke domein. GIBIT is ontwikkeld voor IT-contracten in het gemeentelijke domein en wordt door gemeenten als uitgangspunt bij ICT-inkoop gehanteerd. Ook gemeentelijke samenwerkingsverbanden kunnen GIBIT toepassen[25].
Voor de inkoop van IT-opdrachten door de Rijksoverheid geldt daarentegen ARBIT 2022[26].
Voor andere organisaties in de periferie van het Rijk of het gemeentelijke domein hangt het toepasselijke kader mede af van hun juridische positie en het vastgestelde inkoopbeleid. De vraag bij AI is daarom niet of GIBIT of ARBIT in abstracto de betere algemene voorwaarden bevat. Het relevante vraagstuk is welke aanvullende eisen en contractuele afspraken de concrete AI-prestatie verlangt binnen het kader dat voor de betreffende opdrachtgever geldt.
11. GIBIT 2025: AI in het reguliere contractuele kader
GIBIT 2025 is relevant omdat AI daarin niet als losstaand technologisch verschijnsel buiten de algemene voorwaarden is gehouden. In de begrippenregeling wordt rekening gehouden met ICT-prestaties die mede uit een algoritmische toepassing of AI-systeem bestaan. Dat sluit aan op de hiervoor beschreven praktijk waarin AI-functionaliteit deel uitmaakt van een groter EPD, EJD, eHRM-systeem of ander SaaS-platform.
Art. 13 GIBIT 2025 bevat bepalingen over algoritmische toepassingen. Daarbij komen onder meer rechtmatigheid van de gegevensverwerking, het tegengaan van fouten en ongewenste vertekening, nauwkeurigheid, informatie over gebruikte data en modellen, uitlegbaarheid en controlemogelijkheden aan de orde.
Art. 14 bevat aanvullende bepalingen voor AI-systemen, onder meer op het gebied van nauwkeurigheid, robuustheid, cyberbeveiliging, menselijk toezicht, risicoclassificatie, logging en ondersteuning bij verplichtingen die uit de AI-verordening kunnen voortvloeien[27].
Andere bepalingen krijgen in een AI-context eveneens bijzondere betekenis. Art. 16 betreft productmanagement en de roadmap. De bepalingen over Derdenprogrammatuur in onder meer art. 3.5 en art. 23 zijn relevant wanneer achter de eigen toepassing software of diensten van derden worden ingezet. Art. 31 betreft verwerking van persoonsgegevens en de relatie met de verwerkersovereenkomst; art. 32 informatiebeveiliging. Daarnaast kan de in art. 25 geregelde informatie over softwarecomponenten en de toeleveringsketen relevant zijn voor het verkrijgen van inzicht in technische afhankelijkheden[28].
Daarmee biedt GIBIT 2025 meer expliciete aanknopingspunten voor AI dan oudere generieke IT-voorwaarden.
Dat betekent echter niet dat voor iedere AI-toepassing kan worden volstaan met het van toepassing verklaren van GIBIT. De VNG benadrukt zelf dat GIBIT geen kant-en-klaar contract is dat zonder verdere beoordeling ‘as is’ wordt gebruikt, maar een toolbox die proportioneel op de concrete situatie moet worden toegepast[29]. Juist bij AI blijft daarom noodzakelijk de concrete functionaliteit, gegevensstroom, leveranciersketen, prijsstructuur en wijzigingsdynamiek te onderzoeken en waar nodig nader te regelen.
12. Drie AI-vraagstukken die nadere concretisering vragen
ARBIT 2022 bevat algemene bepalingen over onder meer gegevensverwerking, informatiebeveiliging, onderaanneming, onderhoud, meerwerk en exit. Daarmee vormt het voor ‘rijksinkoop’ een substantieel contractueel fundament. De snelle ontwikkeling van AI maakt niettemin zichtbaar op welke punten een generiek kader nadere concretisering kan behoeven. Hetzelfde geldt in beginsel voor andere algemene IT-voorwaarden die niet specifiek op AI zijn ingericht. Drie voorbeelden zijn illustratief:
1. Een verandering van AI-model is niet noodzakelijk een ‘Nieuwe versie’.
ARBIT 2022 definieert een Nieuwe versie in art. 1.18 als een opvolgende versie van standaardprogrammatuur met in overwegende mate nieuwe of gewijzigde functionaliteiten. Art. 84 bevat vervolgens een klassiek regime voor verbeterde en nieuwe versies: de leverancier voert een consistent versiebeleid, stelt op verzoek een nieuwe versie beschikbaar voor test- en evaluatiedoeleinden en de opdrachtgever is niet verplicht een nieuwe versie in gebruik te nemen[30]. Voor klassieke software is dat een herkenbare systematiek. Bij AI kan echter een wezenlijke wijziging optreden zonder dat de zichtbare applicatie als nieuwe softwareversie wordt uitgebracht. Een leverancier kan bijvoorbeeld het gebruikte foundation model vervangen, overstappen op een nieuwe modelversie, een andere AI-provider inzetten of wijzigingen aanbrengen in system prompts, guardrails, retrieval-augmented generation[31] of andere configuratieonderdelen.
Voor de gebruiker kan de applicatie uiterlijk hetzelfde blijven, terwijl prestaties, output, gegevensverwerking, beveiligingsrisico’s of de juridische kwalificatie veranderen. Bij relevante AI-functionaliteit verdient daarom een afzonderlijke regeling voor AI-wijzigingsbeheer bestemde overweging. Daarin kan worden vastgelegd welke model- en providerwijzigingen vooraf moeten worden gemeld, welke informatie moet worden verstrekt, wanneer hertoetsing of hernieuwde acceptatie noodzakelijk is en in welke gevallen toestemming van de opdrachtgever vereist is. Ook kan een contractuele baseline nuttig zijn: tegen welk model, welke modelcategorie of welke prestatiecriteria is de aangeboden oplossing getest en onder welke voorwaarden mag daarvan gedurende de looptijd worden afgeweken?
2. Algemene regels over gegevens en onderaanneming geven nog geen volledig inzicht in de AI-keten.
Art. 18 ARBIT 2022 bepaalt onder meer dat de door de opdrachtgever verstrekte en op basis daarvan gegenereerde gegevens uitsluitend voor het verrichten van de prestatie en voor zover noodzakelijk en proportioneel mogen worden gebruikt. Voor persoonsgegevens gelden de toepasselijke wettelijke voorschriften en schriftelijke instructies van de opdrachtgever. Art. 23 verlangt voorafgaande toestemming van de opdrachtgever voor het inschakelen van derden en laat de verantwoordelijkheid van de contractspartij voor nakoming van de overeenkomst in stand[32]. Dat zijn belangrijke uitgangspunten, maar zij beantwoorden nog niet alle AI-specifieke informatievragen.
Voordat de opdrachtgever een AI-keten kan beoordelen, kan hij bijvoorbeeld moeten weten welke model- en cloudproviders worden gebruikt, op welke locaties verwerking plaatsvindt, welke prompts en outputs worden opgeslagen, welke bewaartermijnen gelden, of gegevens worden gebruikt voor training of verbetering, welke verdere subverwerkers worden ingeschakeld en welke gevolgen vervanging van een AI-provider heeft. De generieke contractuele toestemming voor het inzetten van een derde is daarmee iets anders dan voorafgaand inzicht in de relevante eigenschappen en risico’s van de volledige AI-keten.
Juist daar sluiten de latere eisen uit BIO2 over inzicht in toeleveranciers, doorlegging van beveiligingseisen en melding van veranderingen in de keten op aan.
3. Verbruiksafhankelijke AI-kosten zijn niet hetzelfde als meerwerk.
Een derde voorbeeld betreft de prijs. ARBIT 2022 definieert Meerwerk in art. 1.17 als niet in de opdracht begrepen werkzaamheden die leiden tot kosten boven de vergoeding. Art. 14.4 bepaalt vervolgens dat meerwerk tijdig moet worden gemeld, afzonderlijk moet worden gefactureerd en slechts na instemming van de opdrachtgever voor vergoeding in aanmerking komt[33]. Dat beschermt de opdrachtgever tegen ongecontroleerd aanvullend werk. Een stijging van AI-kosten is echter niet noodzakelijk het gevolg van aanvullende werkzaamheden. Wanneer dezelfde overeengekomen functionaliteit twee keer zoveel wordt gebruikt en daardoor twee keer zoveel tokens, API-aanroepen, documenten of rekencapaciteit verbruikt, kan de rekening stijgen zonder dat sprake is van meerwerk in de klassieke betekenis. Een regeling over meerwerk beantwoordt dan niet de relevante commerciële vragen. Daarvoor moeten bijvoorbeeld gebruikseenheden, eenheidsprijzen, inbegrepen volumes, staffels, meetmethoden, rapportage, budgetgrenzen en de gevolgen van prijswijzigingen bij externe AI-providers afzonderlijk worden vastgelegd. Het onderscheid kan eenvoudig worden samengevat: meer gebruik is niet hetzelfde als meerwerk.
13. Van algemene voorwaarden naar concrete contractarchitectuur
De voorgaande analyse heeft ook gevolgen voor de inrichting van de aanbesteding van de hoofdapplicatie. Per relevante AI-functionaliteit moet eerst worden bepaald of zij onderdeel vormt van de basisprestatie, als optie wordt uitgevraagd of slechts als voorzienbare ontwikkeling binnen de roadmap wordt beschouwd. Die keuze moet consequent worden verwerkt in de scope en raming van de opdracht, de eisen, het prijsmodel en, waar relevant, opties en herzieningsclausules.
Daarmee hoeft niet nogmaals een afzonderlijke checklist van AI-risico’s te worden doorlopen. De in de voorgaande paragrafen besproken aspecten rond beoogd gebruik, gegevensverwerking, leveranciersketen, prijs en wijzigingsbeheer moeten worden vertaald naar de aanbestedings- en contractdocumenten waarin zij juridisch en operationeel thuishoren.
Algemene IT-inkoopvoorwaarden vervullen daarbij een belangrijke functie omdat zij terugkerende risico’s op consistente wijze regelen. Zij vormen echter het generieke contractuele kader en niet het eindpunt van de analyse van de concrete AI-prestatie.
Bij een hoofdapplicatie met relevante AI-functionaliteit kan de contractarchitectuur daarom uit meerdere samenhangende documenten bestaan: de hoofdovereenkomst, de toepasselijke algemene IT-voorwaarden, het programma van eisen, de verwerkersovereenkomst, informatiebeveiligingseisen, SLA-afspraken, het prijs- en volumemodel, afspraken over derden en subverwerkers, de roadmap- en wijzigingsprocedure, audit- en rapportageverplichtingen en de exit-regeling.
Daarbij is niet alleen van belang waar een verplichting is opgenomen, maar ook of de verschillende documenten onderling consistent zijn, welke rangorde geldt en hoe wijzigingen en versies worden beheerst. Dat is in het bijzonder relevant wanneer contractstukken verwijzen naar online documentatie van leveranciers of achterliggende AI-providers. Welke mate van uitwerking nodig is, blijft afhankelijk van de concrete toepassing. Voor een eenvoudige AI-assistent die uitsluitend algemene procesinformatie ontsluit, kan een beperkte aanvullende regeling volstaan. Bij een AI-laag die bijzondere persoonsgegevens uit omvangrijke dossiers verwerkt en inhoudelijke conclusies ondersteunt, ligt een aanzienlijk zwaardere contractuele en beveiligings-technische uitwerking voor de hand.
Een afzonderlijk ‘AI-contract’ is daarmee niet noodzakelijk. Wel is een afzonderlijke AI-analyse binnen de aanbestedings- en contractarchitectuur van de hoofdapplicatie noodzakelijk wanneer de aard en risico’s van de functionaliteit daartoe aanleiding geven.
14. Conclusie
Het uitgangspunt dat succesvol gebruik van AI begint bij het juiste vraagstuk is terecht. Voor publieke organisaties vormt de keuze van een kansrijke use-case echter slechts het vertrekpunt. AI wordt niet uitsluitend als zelfstandige dienst verworven, maar kan onderdeel zijn van de hoofdapplicatie waarmee een primair proces of de bedrijfsvoering wordt ondersteund. De AI-functionaliteit moet dan worden beoordeeld binnen de aanbesteding en contractering van die bredere ICT-prestatie.
Daarbij zijn verschillende analyses met elkaar verbonden. Het beoogde gebruik bepaalt mede het juridische risicoprofiel onder de AI-verordening. De feitelijke gegevens- en leveranciersketen is van belang voor gegevensbescherming, informatiebeveiliging en continuïteit. Het gekozen prijsmodel bepaalt of de structurele kosten bij opschaling voldoende voorspelbaar zijn. En bij SaaS moet rekening worden gehouden met wijzigingen van functionaliteit, modellen, providers en prijsdragers gedurende de looptijd. Ook aanbestedingsrechtelijk verdient die ontwikkeling vooraf aandacht. Wanneer aanvullende AI-functionaliteit gedurende een meerjarige overeenkomst voorzienbaar is, moet worden beoordeeld of en hoe deze in de oorspronkelijke scope, raming, opties en herzieningsclausules wordt verwerkt. Toekomstbestendig aanbesteden betekent daarbij niet dat alle toekomstige technologie vooraf bekend moet zijn, maar wel dat voorzienbare ontwikkelruimte voldoende transparant wordt gestructureerd.
Algemene IT-voorwaarden blijven binnen die contractering van grote betekenis. GIBIT 2025 laat zien dat AI-specifieke onderwerpen in een algemeen contractueel kader kunnen worden opgenomen. ARBIT 2022 biedt een generiek kader waarin bij AI op onderdelen nadere concretisering nodig kan zijn. Dat vereist geen afzonderlijk AI-contractenrecht, maar wel een bewuste vertaling van de concrete AI-functionaliteit naar de aanbestedings- en contractarchitectuur van de hoofdapplicatie.
Juist bij AI blijkt dat bestaande begrippen niet altijd één-op-één aansluiten op nieuwe technische en commerciële verschijningsvormen. Een wijziging van het AI-model is niet noodzakelijk een nieuwe softwareversie. Meer gebruik is niet hetzelfde als meerwerk. En toestemming voor het inschakelen van derden verschaft nog geen volledig inzicht in de AI-keten.
De kwaliteit van de aanbesteding van een hoofdapplicatie met AI-functionaliteit wordt daarom niet alleen bepaald door de kwaliteit van de gekozen use-case, maar ook door de mate waarin de opdrachtgever het juridisch risicoprofiel, gegevensstromen, ketenafhankelijkheden, kosten en toekomstige wijzigingen vooraf in een samenhangende aanbestedings- en contractstructuur weet te beheersen.
Noten
[1] J. Poels, ‘Succesvol starten met AI begint bij het juiste vraagstuk’, Quarant, 2 september 2026. De auteur bepleit een probleem- en waarde-gedreven benadering vóór selectie van de technologie.
[2] Geanonimiseerd kansendossier uit een Nederlandse aanbesteding van een elektronisch dossier, 2026, document bij auteur. De aangeboden opties betroffen onder meer spraak-naar-tekst, automatische conclusiegeneratie, dossierbevraging en AI-ondersteunde planning.
[3] Geanonimiseerd kansendossier betreffende een elektronisch dossier, 2026, document bij auteur. De aangeboden AI-laag omvatte onder meer dossiersamenvatting en -bevraging, richtlijnondersteuning en documentgeneratie.
[4] Geanonimiseerd oplossingsvoorstel uit een eHRM-aanbesteding, 2026, document bij auteur. De beschreven AI-assistent is rol-gestuurd; de gebruiker blijft verantwoordelijk voor het uitvoeren van acties en de AI neemt niet zelfstandig besluiten.
[5] Verordening (EU) 2024/1689 van het Europees Parlement en de Raad van 13 juni 2024 tot vaststelling van geharmoniseerde regels betreffende artificiële intelligentie (AI-verordening), PbEU 2024, L 2024/1689, art. 6 lid 2 jo. bijlage III, onderdeel 4, zoals gewijzigd; geconsolideerde tekst van 27 juli 2026.
[6] AI-verordening, art. 6 lid 3. De bepaling noemt vier situaties waarin een in bijlage III opgenomen systeem onder voorwaarden niet als hoog-risicosysteem wordt aangemerkt. De uitzondering geldt niet indien het AI-systeem profilering van natuurlijke personen verricht. Zie de geconsolideerde tekst van 27 juli 2026.
[7] Verordening (EU) 2026/1744 van het Europees Parlement en de Raad van 8 juli 2026 tot wijziging van onder meer Verordening (EU) 2024/1689, considerans 40 en art. 1, punt 40 (wijziging van art. 113 AI-verordening). Hoofdstuk III, afdelingen 1-3, met uitzondering van art. 6 lid 5, is van toepassing vanaf 2 december 2027 voor AI-systemen als bedoeld in art. 6 lid 2 jo bijlage III en vanaf 2 augustus 2028 voor AI-systemen als bedoeld in art. 6 lid 1 jo bijlage I.
[8] AI-verordening, hoofdstuk III, afdeling 2, art. 9-15, betreffende onder meer risicobeheer, data, documentatie, logging, transparantie, menselijk toezicht, nauwkeurigheid, robuustheid en cyberbeveiliging, alsmede art. 27 betreffende de grondrechten-effect-beoordeling voor de daarin aangewezen gebruiksverantwoordelijken. Zie ook art. 27, lid 4: de in 2026 gewijzigde bepaling staat expliciet toe relevante delen van een DPIA in de FRIA te hergebruiken of daarnaar te verwijzen. Geconsolideerde tekst 27 juli 2026.
[9] Geanonimiseerd offertevoorstel betreffende een elektronisch dossier, 2026, document bij auteur. Bij de indicatieve prijsstelling noemt de aanbieder onder meer wijzigingen in licentie- en prijsmodellen van externe AI-dienstverleners als relevante factor.
[10] Verordening (EU) 2016/679 (AVG), PbEU 2016, L 119/1, in het bijzonder art. 13 en 14 inzake informatieverstrekking en art. 28, leden 1-4 inzake verwerkers, verwerkersovereenkomsten en andere verwerkers.
[11] Cyberbeveiligingswet, Stb. 2026, 187, art. 21, in het bijzonder lid 3 onder d en e en lid 4. De Cyberbeveiligingswet en het Cyberbeveiligingsbesluit zijn op 15 augustus 2026 in werking getreden; art. 35 Cyberbeveiligingsbesluit, Stb. 2026, 189.
[12] Baseline Informatiebeveiliging Overheid 2, versie 1.3, 9 januari 2026, Stcrt. 2026, 7416, in het bijzonder overheidsmaatregelen 5.19.01, 5.20.01, 5.20.03-5.20.06 en 5.21.02-5.21.05.
[13] Cyberbeveiligingsregeling sector overheid, Stcrt. 2026, 27679, in het bijzonder art. 5 en de toelichting daarop. Daarin wordt BIO2 versie 1.3 voor de onder de regeling vallende essentiële entiteiten betrokken bij de minimale invulling van de zorgplicht; de toelichting behandelt tevens de positie van BIO2 als verplichtende zelfregulering daarbuiten.
[14] Geanonimiseerd kansendossier betreffende een elektronisch dossier, 2026, document bij auteur. Naast de jaarlijkse licentie werden afzonderlijke, verbruiksafhankelijke kosten voor AI-modellen geraamd; de initiële jaarraming daarvan bedroeg ongeveer driemaal de vaste licentievergoeding.
[15] Geanonimiseerd offertevoorstel betreffende een elektronisch dossier, 2026, document bij auteur. Voor definitieve prijsstelling moesten onder meer use-cases, integratie, rollen en rechten en het verwachte volume nader worden geconcretiseerd.
[16] Geanonimiseerd offertevoorstel betreffende een elektronisch dossier, 2026, document bij auteur. Genoemde prijsfactoren betreffen onder meer gespecialiseerde hardware, energie- en datacenterinfrastructuur, externe AI-dienstverleners, ontwikkelingen in het LLM-landschap, regelgeving en gebruiksvolume.
[17] Geanonimiseerd oplossingsvoorstel uit een eHRM-aanbesteding, 2026, document bij auteur. Het daarin beschreven SaaS-licentiemodel hanteert één prijs per medewerker per jaar en geen afzonderlijke licenties per gebruikersrol of module.
[18] VNG/VNG Realisatie, GIBIT 2025 – Artikelen, art. 11.1, 11.10 en 11.11. De officiële GIBIT 2025-artikelen en de artikelsgewijze toelichting worden door VNG/VNG Realisatie gepubliceerd via de GIBIT-projectpagina.
[19] Geanonimiseerd oplossingsvoorstel uit een eHRM-aanbesteding, 2026, document bij auteur. Nieuwe functionaliteiten worden volgens het voorstel centraal ontwikkeld en via reguliere releases beschikbaar gesteld; de opdrachtgever ontvangt vooraf informatie over wijzigingen en hun impact.
[20] Met foundation model wordt hier in technische zin een breed getraind AI-basismodel bedoeld dat als basis kan dienen voor verschillende vervolgtoepassingen. De AI-verordening hanteert als juridisch begrip onder meer het “AI-model voor algemene doeleinden”; zie art. 3, punt 63, AI-verordening. Beide begrippen worden in de praktijk deels overlappend gebruikt, maar zijn niet zonder meer juridisch gelijk te stellen.
[21] Aanbestedingswet 2012, art. 2.163c; vgl. art. 72 lid 1 onder a en considerans 111 Richtlijn 2014/24/EU. Art. 72 lid 1 onder a verlangt dat herzieningsclausules of opties duidelijk, nauwkeurig en ondubbelzinnig zijn en omvang, aard en toepassingsvoorwaarden van de mogelijke wijziging beschrijven; zij mogen de algemene aard van de opdracht niet veranderen. De considerans noemt technologische veranderingen uitdrukkelijk als voorbeeld van ontwikkelingen waarop voldoende duidelijk geformuleerde herzieningsclausules kunnen anticiperen.
[22] Aanbestedingswet 2012, art. 2.15 lid 2; vgl. art. 5 lid 1 Richtlijn 2014/24/EU. Bij de raming van de opdracht wordt uitgegaan van het totale geraamde bedrag, met inbegrip van eventuele opties en verlengingen zoals deze uitdrukkelijk in de aanbestedingsstukken zijn vermeld.
[23] Besluit van de Minister-President, Minister van Algemene Zaken, van 22 augustus 2022 houdende vaststelling van ARBIT 2022, Stcrt. 2022, 22806 (gerectificeerd Stcrt. 2022, 22806-n1); Richtlijn (EU) 2022/2555 (NIS2) van 14 december 2022, PbEU 2022, L 333/80; Verordening (EU) 2024/1689 (AI-verordening); Cyberbeveiligingswet, Stb. 2026, 187; en BIO2 versie 1.3, Stcrt. 2026, 7416.
[24] VNG/VNG Realisatie, GIBIT, onderdeel ‘GIBIT 2025’. VNG vermeldt dat GIBIT 2025 de GIBIT 2023 vervangt, grondig is herzien op basis van actuele wet- en regelgeving en praktijkervaring en onder meer aandacht besteedt aan AI, digitale grondrechten, cloud, open source en datagebruik.
[25] VNG/VNG Realisatie, GIBIT, waarin GIBIT wordt omschreven als een set inkoopinstrumenten voor IT-contracten in het gemeentelijke domein. Zie tevens VNG/VNG Realisatie, Gemeentelijke ICT-kwaliteitsnormen, waarin wordt vermeld dat gemeenten en gemeentelijke samenwerkingsverbanden GIBIT kunnen gebruiken bij de verwerving van ICT-producten en -diensten.
[26] Rijksoverheid, Voorwaarden voor inkoop bij Rijksopdrachten, onderdeel ‘Voorwaarden inkoop Informatietechnologie (IT)’. Voor IT-opdrachten van de Rijksoverheid gelden ARBIT 2022.
[27] VNG/VNG Realisatie, GIBIT 2025 – Artikelen, art. 13 (‘Algoritmische toepassingen’) en art. 14 (‘AI-systemen’), officiële publicatie via de GIBIT-projectpagina van de VNG.
[28] VNG/VNG Realisatie, GIBIT 2025 – Artikelen, onder meer art. 3.5 en 23 inzake Derdenprogrammatuur, art. 16 inzake productmanagement, art. 25 inzake de Software Bill of Materials en inzicht in softwarecomponenten en de toeleveringsketen, art. 31 inzake de verwerkersrelatie en art. 32 inzake informatiebeveiliging.
[29] VNG/VNG Realisatie, GIBIT. De VNG omschrijft GIBIT expliciet niet als een kant-en-klaar contract dat ‘as is’ wordt gebruikt, maar als een set inkoopvoorwaarden die proportioneel op de specifieke situatie moet worden toegepast met behulp van de overeenkomstengenerator.
[30] ARBIT 2022, Stcrt. 2022, 22806, art. 1.18 (‘Nieuwe versie’) en art. 84 (‘Verbeterde en Nieuwe versies’). Art. 1.18 definieert een Nieuwe versie als een opvolgende versie van standaardprogrammatuur met overwegend nieuwe of gewijzigde functionaliteiten; art. 84 bevat onder meer voorschriften over versiebeleid, test- en evaluatiemogelijkheden en ingebruikname.
[31] Met system prompts worden instructies bedoeld die vooraf door de aanbieder of applicatie worden meegegeven aan het AI-model en die mede bepalen hoe het model zich moet gedragen en antwoorden moet formuleren. Guardrails zijn technische en organisatorische beperkingen of beleidsmatige of configuratieve matregelen waarmee het gebruik en de output van het model worden begrensd, bijvoorbeeld door bepaalde invoer of uitvoer te blokkeren of aanvullende controles toe te passen. Retrieval-augmented generation (RAG) is een techniek waarbij het AI-model bij het genereren van een antwoord eerst relevante informatie uit een externe kennisbron of documentverzameling ophaalt en die informatie als aanvullende context gebruikt. De onderliggende modelgewichten hoeven daarvoor niet te worden aangepast.
[32] ARBIT 2022, art. 18 (‘Verwerking gegevens’) en art. 23 (‘Onderaanneming’). Art. 18 beperkt het gebruik van door de opdrachtgever verstrekte en daaruit gegenereerde gegevens tot de prestatie en het noodzakelijke en proportionele gebruik; art. 23 regelt het inschakelen van derden.
[33] ARBIT 2022, art. 1.17 (‘Meerwerk’) en art. 14.4. Meerwerk wordt gedefinieerd als niet in de opdracht begrepen werkzaamheden die leiden tot kosten boven de vergoeding; het komt volgens art. 14.4 eerst na instemming van de opdrachtgever voor vergoeding in aanmerking.
