Eisen aan een AI-leverancier: complete checklist voor offerte en contract

Definitie en afbakening

Een leveranciersvereiste beschrijft een controleerbare voorwaarde voor selectie, acceptatie of dienstverlening. Functionele eisen zeggen wat de oplossing moet ondersteunen. Niet-functionele eisen behandelen onder meer betrouwbaarheid, beveiliging, responstijd en beheer. Contractuele eisen verdelen rechten, informatieplichten, aansprakelijkheid, audit, wijziging en beëindiging. Samen vertalen zij de use-case naar afdwingbare verwachtingen.

Het herkenbare bedrijfsprobleem

Lijsten bevatten vaak algemene termen als veilig, schaalbaar en AVG-proof. Zulke woorden zijn niet direct testbaar en verschuiven interpretatie naar de leverancier. Ook ontbreekt regelmatig wat gebeurt wanneer een model, prijs, subverwerker of dienst verandert. Een sterke eis bevat context, bewijs en een beslisregel.

Maak onzekerheid zichtbaar in plaats van haar in één percentage te verbergen. Volume kan goed gemeten zijn terwijl adoptie nog een aanname is. Een leverancier kan technische prestaties aantonen zonder bewijs in de eigen workflow. Noteer per getal bron, periode, eigenaar en betrouwbaarheidsniveau. Dat maakt een besluit later herhaalbaar.

Stappenplan voor de eisen aan een AI-leverancier

1. Beschrijf de gebruikscontext

Leg gebruikers, processtap, volumes, gegevens en gevolgen van fouten vast.

2. Maak eisen toetsbaar

Voeg meetmethode, testdata, grens en eigenaar aan elke kritieke eis toe.

3. Scheid harde eisen en voorkeuren

Voorkom dat een mooie extra een noodzakelijke controle compenseert.

4. Vraag bewijs per levensfase

Toets selectie, pilot, acceptatie, productie en wijziging afzonderlijk.

5. Leg informatieplichten vast

Regel melding van model-, prijs-, beveiligings- en subverwerkerwijzigingen.

6. Ontwerp de exit vooraf

Bepaal export, verwijdering, ondersteuning, termijnen en migratiekosten.

Beslismodel

| Beslispunt | Centrale vraag | Gewenst bewijs | Handelingsregel | |---|---|---|---| | Beschrijf de gebruikscontext | Leg gebruikers, processtap, volumes, gegevens en gevolgen van fouten vast. | Procesdata, besluitlog en eigenaar | Doorgaan bij voldoende bewijs | | Maak eisen toetsbaar | Voeg meetmethode, testdata, grens en eigenaar aan elke kritieke eis toe. | Representatieve test, kostenraming en akkoord | Beperkt testen bij onzekerheid | | Scheid harde eisen en voorkeuren | Voorkom dat een mooie extra een noodzakelijke controle compenseert. | Procesdata, besluitlog en eigenaar | Stoppen of herontwerpen bij rode grens | | Vraag bewijs per levensfase | Toets selectie, pilot, acceptatie, productie en wijziging afzonderlijk. | Representatieve test, kostenraming en akkoord | Doorgaan bij voldoende bewijs | | Leg informatieplichten vast | Regel melding van model-, prijs-, beveiligings- en subverwerkerwijzigingen. | Procesdata, besluitlog en eigenaar | Beperkt testen bij onzekerheid | | Ontwerp de exit vooraf | Bepaal export, verwijdering, ondersteuning, termijnen en migratiekosten. | Representatieve test, kostenraming en akkoord | Stoppen of herontwerpen bij rode grens |

Lees dit model als beslisondersteuning voor de eisen aan een AI-leverancier, niet als automatische ranglijst. De stap ‘Leg informatieplichten vast’ verdient apart bewijs.

Praktijkvoorbeeld met invoer, berekening en uitkomst

Situatie

Een klantenserviceorganisatie stelt eisen op voor een antwoordassistent.

Invoer

40 medewerkers, 6.000 antwoorden per maand, maximaal 2 seconden gewenste wachttijd in de workflow, gevoelige klantgegevens en verplichte bronverwijzing. Huidige correctietijd: 3,2 minuut per antwoord.

Berekening

Een eis van 99,9 procent beschikbaarheid staat voor maximaal circa 43,8 minuten ongeplande uitval per maand bij continue meting, maar zegt niets over verkeerde antwoorden. Daarom zijn afzonderlijke kwaliteit- en herstelcriteria nodig.

Zakelijke uitkomst

Acceptatie combineert beschikbaarheid, brononderbouwing, ernstige fouttypen, correctietijd, autorisatie en incidentprocedure. Geen enkele totaalscore kan een harde veiligheidsgrens compenseren.

Kosten en ROI correct berekenen

Bereken voor de eisen aan een AI-leverancier minstens een ondergrens, een realistisch scenario en een bovengrens. Baseer volume, tijd en tarief op de nulmeting en toets expliciet hoe het risico ‘eisen zijn niet meetbaar’ de opbrengst kan verminderen.

Koppeling met de vijf lagen van de ROI-scan

In deze use-case verdient vooral de stap ‘maak eisen toetsbaar’ aandacht, omdat een aanname daar direct doorwerkt in de businesscase.

Lees daarnaast AI-leverancier selecteren, AI-governance model, Voorwaarden AI-implementatie.

Opties en scenario’s

| Scenario | Wanneer passend | Investering | Bewijs vóór opschaling | |---|---|---:|---| | Eerst meten | Leg gebruikers, processtap, volumes, gegevens en gevolgen van fouten vast. | Laag | Nulmeting en een afgebakende hypothese | | Beperkte pilot | Voeg meetmethode, testdata, grens en eigenaar aan elke kritieke eis toe. | Middel | Representatief bewijs voor de tweede proceskeuze | | Gefaseerd invoeren | Voorkom dat een mooie extra een noodzakelijke controle compenseert. | Middel tot hoog | Gehaalde grens en een bevoegde eigenaar | | Niet starten of stoppen | Eisen zijn niet meetbaar | Beperkt verlies | Vastgelegd besluit en een proportioneel alternatief |

Risico’s en beheersmaatregelen

1. Eisen zijn niet meetbaar

Leg in het risicoregister vast hoe het risico ‘eisen zijn niet meetbaar’ bij de eisen aan een AI-leverancier zichtbaar wordt, wie actie neemt en welke grens tot pauzeren leidt. Verbind de maatregel aan leg informatieplichten vast en controleer haar met werkelijk gedrag en procesdata.

2. Privacy en beveiliging worden samengevoegd tot één vinkje

Leg in het risicoregister vast hoe het risico ‘privacy en beveiliging worden samengevoegd tot één vinkje’ bij de eisen aan een AI-leverancier zichtbaar wordt, wie actie neemt en welke grens tot pauzeren leidt. Verbind de maatregel aan ontwerp de exit vooraf en controleer haar met werkelijk gedrag en procesdata.

3. Wijzigingen van onderliggende modellen zijn niet geregeld

Leg in het risicoregister vast hoe het risico ‘wijzigingen van onderliggende modellen zijn niet geregeld’ bij de eisen aan een AI-leverancier zichtbaar wordt, wie actie neemt en welke grens tot pauzeren leidt. Verbind de maatregel aan beschrijf de gebruikscontext en controleer haar met werkelijk gedrag en procesdata.

4. Exit bestaat alleen uit contractopzegging

Leg in het risicoregister vast hoe het risico ‘exit bestaat alleen uit contractopzegging’ bij de eisen aan een AI-leverancier zichtbaar wordt, wie actie neemt en welke grens tot pauzeren leidt. Verbind de maatregel aan maak eisen toetsbaar en controleer haar met werkelijk gedrag en procesdata.

Wanneer deze aanpak niet geschikt is

Dit beslismodel voor de eisen aan een AI-leverancier vervangt geen juridisch, financieel of sectorspecifiek onderzoek. De combinatie van het risico ‘privacy en beveiliging worden samengevoegd tot één vinkje’ en toepassingen met grote gevolgen voor mensen vraagt een concrete beoordeling door bevoegde deskundigen.

Pauzeer de uitvoering als de laatste stap, de stap ‘ontwerp de exit vooraf’, geen bevoegde eigenaar heeft, als representatieve gegevens ontbreken of als noodzakelijke controle niet uitvoerbaar is.

Veelgestelde vragen

Wat is het verschil tussen een eis en een wens?

Een eis is noodzakelijk en leidt bij niet voldoen tot afwijzing of herstel. Een wens levert extra waarde en kan gewogen worden.

Moeten eisen technologieneutraal zijn?

Waar mogelijk wel, zodat de gewenste uitkomst centraal staat. Specifieke technologie kan nodig zijn voor integratie, beveiliging of bestaande architectuur.

Hoe toets je nauwkeurigheid?

Definieer taak, populatie, representatieve testset, foutcategorieën, grenswaarden en onafhankelijke beoordeling.

Welke exit-eisen zijn belangrijk?

Data-export in bruikbaar formaat, aantoonbare verwijdering, overdracht van configuratie en documentatie, ondersteuningstermijn en voorspelbare kosten.

Kan een standaardcontract voldoende zijn?

Alleen wanneer het aantoonbaar aansluit op de concrete data, impact, dienstverlening en eisen. Laat materiële risico’s juridisch beoordelen.

Bronnen en officiële documentatie

• EU AI Act, officiële verordening
• Europese Commissie, regelgevingskader voor AI
• NIST AI Risk Management Framework
• ISO/IEC 42001, AI-managementsystemen

Verder lezen

• AI-implementatie
• AI ROI-scan
• AI-leverancier selecteren
• AI-governance model
• Voorwaarden AI-implementatie