GIBIT 2025: wat verandert er?

De GIBIT is een set standaardvoorwaarden voor ICT-inkoop door gemeenten. Ze bepalen wat een leverancier moet aanleveren, welke risico's hij draagt, welke rechten de opdrachtgever krijgt en hoeveel ruimte er is om gaandeweg iets te veranderen.

Het belang reikt verder dan gemeenten. Provincies, waterschappen, zorginstellingen en woningcorporaties gebruiken de tekst geregeld als vertrekpunt, en commerciële opdrachtgevers halen er losse artikelen uit. Wie een softwarecontract in Nederland leest, komt vroeg of laat formuleringen tegen die hier vandaan komen.

Voor u als opdrachtgever is dat gunstig: u hoeft niet zelf te bedenken wat er in een contract hoort. Voor u als leverancier betekent het dat u de tekst kent, want de kans is groot dat u hem voorgelegd krijgt.

De grootste inhoudelijke wijziging betreft kunstmatige intelligentie. Waar eerdere versies daar niets over zeiden, staan er nu bepalingen over wat een leverancier moet melden als er AI in het geleverde zit, en wat hij daarover moet kunnen uitleggen.

Dat sluit aan bij het probleem dat opdrachtgevers het afgelopen jaar tegenkwamen: functionaliteit die er bij een update ineens bij zit, zonder dat iemand daarover is geïnformeerd. Een klantenserviceomgeving die antwoorden gaat voorstellen, een HR-systeem dat cv's rangschikt.

Wat u hieruit kunt overnemen, ook buiten een aanbesteding om: de verplichting om u te informeren bij toevoeging of wijziging van AI-functionaliteit, en de plicht om desgevraagd toe te lichten welk model wordt gebruikt en wat er met uw invoer gebeurt.

Een tweede vernieuwing gaat over transparantie in de keten: welke componenten van derden zitten er in het geleverde, en welke partijen kunnen daardoor bij uw gegevens of uw systeem.

Dat is dezelfde vraag die vanuit informatiebeveiliging al langer wordt gesteld, nu vertaald naar contractueel recht. In de praktijk komt het neer op een overzicht van gebruikte onderdelen met hun herkomst en versie, en op de plicht om dat overzicht actueel te houden.

De reden dat dit nu opduikt, is niet theoretisch. Vrijwel elk kwetsbaarheidsincident van de laatste jaren begon bij een component die iemand ooit had toegevoegd en waarvan niemand meer wist dat hij erin zat.

• Welke open-source-onderdelen zijn gebruikt en onder welke licentie.
• Wat die licentie betekent voor wat u met het geleverde mag doen.
• Of er licenties tussen zitten die verplichtingen opleggen aan uw eigen code.
• Wie verantwoordelijk is voor het bijwerken van die onderdelen wanneer er een kwetsbaarheid in wordt gevonden.

Op servicelevels is aangescherpt wat er gemeten wordt en hoe daarover wordt gerapporteerd. Dat is een reactie op afspraken die op papier stevig leken maar in de praktijk niet controleerbaar waren, omdat niemand had vastgelegd wie meet en op basis waarvan.

Rond prijsaanpassingen is de ruimte begrensd. Een leverancier mag indexeren, maar niet zonder onderbouwing en niet zonder aankondigingstermijn. Dat raakt precies de post die bij softwarecontracten na een paar jaar het grootste deel van de kostenstijging verklaart.

Voor uw eigen contracten is dat een bruikbaar model, ook als u geen overheid bent: benoem de index, benoem het maximum, benoem de termijn waarop u het hoort, en leg vast wat er gebeurt als u het er niet mee eens bent.

Reken erop dat u deze tekst voorgelegd krijgt en dat er weinig ruimte is om er losse artikelen uit te onderhandelen. Standaardvoorwaarden ontlenen hun waarde juist aan het feit dat ze niet per opdracht worden aangepast.

Waar wél ruimte zit, is in de bijlagen: de beschrijving van wat u levert, de servicelevels die u aangaat, en de termijnen die u haalbaar acht. Dat is de plek waar een gesprek zinvol is, en het is ook de plek waar de meeste geschillen later ontstaan.

Wat u vooraf op orde wilt hebben: een actueel overzicht van uw componenten en hun licenties, een helder verhaal over de AI-functies in uw product, en rapportage over uw servicelevels die u zonder handwerk kunt aanleveren. Alle drie kosten ze tijd als u ze bij de eerste uitvraag moet maken.

Standaardvoorwaarden zijn niet bedoeld om per opdracht te worden aangepast, en een poging daartoe kost u meestal goodwill zonder resultaat. Dat betekent niet dat er niets te bespreken valt.

De ruimte zit in de bijlagen: de beschrijving van wat u levert, de servicelevels die u aangaat, de termijnen die u haalbaar acht, en de aannames waaronder uw prijs geldt. Dat zijn de documenten waar geschillen later over gaan, en het zijn precies de documenten die vaak in de laatste week worden ingevuld.

Besteed daar de tijd aan die u anders aan de algemene voorwaarden zou besteden. Een servicelevel dat u niet kunt halen, is een groter risico dan een aansprakelijkheidsbepaling die u niet mooi vindt.

• Leg naast uw lopende contracten wat er in de nieuwe versie is aangescherpt, en noteer waar uw eigen tekst achterloopt.
• Vraag bij uw huidige leveranciers een overzicht op van gebruikte componenten van derden, inclusief open-source-licenties.
• Vraag schriftelijk of er AI-functionaliteit in het geleverde zit, welke, en of u wordt geïnformeerd bij wijzigingen.
• Controleer of uw indexeringsclausule een index noemt die openbaar wordt gepubliceerd, en of er een maximum en een aankondigingstermijn in staan.
• Neem de aangescherpte rapportage-eisen over in uw eigen servicelevelafspraken, ook als u niet aanbesteedt.

Het meest voorkomende probleem is niet onwil maar onwetendheid. Leveranciers weten vaak zelf niet precies welke componenten er in hun product zitten, omdat die door de jaren heen zijn meegekomen met bibliotheken en frameworks.

Dat is oplosbaar met gereedschap dat een overzicht genereert, maar het kost de eerste keer werk en het levert soms ongemakkelijke uitkomsten op: een component die al jaren niet is bijgewerkt, of een licentie waarvan niemand had gecontroleerd of hij past bij commercieel gebruik.

Het tweede knelpunt zit bij AI-functies die via een derde binnenkomen. Als uw leverancier zelf een dienst afneemt die onder water een model aanroept, gaan uw gegevens naar een partij die niemand heeft gekozen. Dat is precies wat de nieuwe bepalingen zichtbaar willen maken, en het is de vraag waar u het vaakst een vaag antwoord op krijgt.

• Een softwareleverancier kiezen
• Wat hoort in een SLA?
• Prijsverhoging in uw softwarecontract

Wilt u eerst weten of het idee werkt voordat u groot investeert? Bij OneDayBuild laat u in één dag een werkend prototype bouwen.