Het snelle antwoord: een AI-leverancier evalueren betekent om bewijs in plaats van beloften te vragen. Voordat u ondertekent, wilt u vier dingen schriftelijk: onafhankelijke testresultaten die u kunt controleren, duidelijke voorwaarden over hoe uw gegevens worden gebruikt en opgeslagen, een verbintenis om het systeem na go-live te controleren, en een manier om elke veiligheidsclaim van de leverancier te verifiëren zonder hun woord ervoor te nemen. De rest van deze gids maakt daar een werkend proces van, een vragenlijst die u naar leveranciers kunt sturen, en de contractvoorwaarden die de antwoorden kracht bijzetten.

AI due diligence verschilt van een gewone softwaretoetsing omdat een AI-systeem een zelfverzekerd fout antwoord kan geven, van zijn eigen regels af kan worden gepraat, gegevens kan lekken of gedrag kan veranderen na een modelupdate die de leverancier op een dinsdag uitrolt. U vindt deze risico's door gedrag te testen, en u beheerst ze met contractvoorwaarden die zeggen wat er gebeurt wanneer het gedrag afwijkt.

Waarom due diligence voor AI-leveranciers nu een formele verwachting is

Het kopen van AI werd ooit behandeld als een softwareaankoop met een extra alinea over gegevens. Publieke kopers en wetgevers aan beide zijden van de Atlantische Oceaan hebben dat veranderd.

US federale kopers: OMB-memorandum M-25-22

Op 3 april 2025 gaf het White House Office of Management and Budget memorandum M-25-22 uit: Driving Efficient Acquisition of Artificial Intelligence in Government. Dit is van toepassing op contracten die zijn toegekend op basis van aanbestedingen die 180 dagen of meer na het memorandum zijn uitgegeven, en op verlengingsopties die na dat moment worden uitgeoefend. Sectie 4(d) zegt dat instanties "voorwaarden moeten opnemen die aandacht besteden aan" een lijst met onderwerpen in contracten voor AI-systemen en -diensten. Onder meer:

• Doorlopende prestatiecontrole. Contracten moeten de instantie toestaan om regelmatig de prestaties, risico's en doeltreffendheid van het systeem te controleren en evalueren, met driemaandelijkse of tweejaarlijkse reviews als voorbeelden.
• Onafhankelijke testen. Instanties moeten testen met hun eigen datasets die "niet toegankelijk mogen zijn voor de leverancier", leveranciers moeten "de toegang en tijd bieden die nodig zijn voor instanties om onafhankelijke evaluatie uit te voeren", en testresultaten moeten "gedetailleerd genoeg zijn zodat testen onafhankelijk kunnen worden geverifieerd of gereproduceerd, voor zover praktisch mogelijk."
• Bescherming tegen lock-in. Voorwaarden kunnen kennisoverdracht, "data- en modeloverdraagbaarheid" en transparantie over licenties en prijzen omvatten.
• Beperkingen op training met uw gegevens. Sectie 3(e) vereist dat contracten "permanent het gebruik van niet-openbare inputgegevens van instanties en outputresultaten verbieden" voor verdere training van openbaar of commercieel beschikbare AI, tenzij de instantie hier expliciet toestemming voor geeft.
• Kennisgeving voorafgaand aan wijzigingen. Organisaties kunnen overwegen om leveranciers te verplichten hen in kennis te stellen voordat nieuwe AI-verbeteringen worden geïntegreerd, en worden aangeraden leveranciers te verplichten aan prestatiesnormen te voldoen voordat nieuwe versies worden uitgerold en zo nodig terug te draaien.

Een tweede memorandum, OMB M-26-04 van 11 december 2025, zegt dat het "aanvult" op M-25-22. Voor contracten voor grote taalmodellen geeft het een lijst van informatie die organisaties van leveranciers zouden moeten aanvragen: een aanvaardingsbeleid, model-, systeem- of datakaarten, resources voor eindgebruikers en een mechanisme voor feedback van eindgebruikers. Het stelt organisaties ook in staat om meer aan te vragen, zoals evaluatieresultaten.

Deze memoranda zijn bindend voor federale organisaties, niet voor particuliere bedrijven. Ze vormen nog steeds de meest gedetailleerde openbare verklaring van wat een geavanceerde AI-koper vraagt, en particuliere inkoopteams kunnen hun structuur rechtstreeks overnemen.

EU-implementeerders: wat de AI-wet van de koper vraagt

De EU AI-wet, Verordening (EU) 2024/1689, noemt de organisatie die een AI-systeem onder haar eigen gezag gebruikt de "implementeerder". Als u een AI-systeem met hoog risico aanschaft en ingebruik neemt, plaatst artikel 26 verplichtingen op u, apart van de verplichtingen op de leverancier. In de geconsolideerde tekst die op het AI Act-serviceloket van de Europese Commissie is gepubliceerd, staat in artikel 26:

• Implementeerders "zullen passende technische en organisatorische maatregelen treffen om ervoor te zorgen dat zij dergelijke systemen overeenkomstig de gebruiksaanwijzing die bij de systemen is gevoegd gebruiken" (artikel 26(1)).
• Implementeerders "zullen menselijk toezicht toewijzen aan natuurlijke personen die de nodige bevoegdheid, opleiding en gezag hebben" (artikel 26(2)).
• Implementeerders "zullen de werking van het AI-systeem met hoog risico monitoren op basis van de gebruiksaanwijzing" en als zij reden hebben te denken dat het systeem een risico vormt, moeten zij de leverancier of distributeur en de bevoegde markttoezichtsautoriteit informeren en het gebruik opschorten (artikel 26(5)).
• Implementeerders "zullen de logboeken die automatisch door dat AI-systeem met hoog risico worden gegenereerd, bewaren" voorzover die logboeken onder hun toezicht staan, gedurende ten minste zes maanden tenzij ander recht anders bepaalt (artikel 26(6)).
• Implementeerders van Annex III-systemen die besluiten over personen nemen of helpen nemen, "zullen de natuurlijke personen informeren dat zij onderwerp zijn van het gebruik van het AI-systeem met hoog risico" (artikel 26(11)).

Elk van die verplichtingen hangt af van informatie die u alleen van de leverancier kunt krijgen. U kunt geen gebruiksaanwijzingen volgen die u nooit hebt ontvangen, geen logboeken bewaren die het systeem niet exporteert, en geen gedrag controleren dat u geen manier hebt om te meten. Artikel 13 is de leverancierszijde van dezelfde overeenkomst: systemen met hoog risico moeten vergezeld gaan van gebruiksaanwijzingen die onder meer "het nauwkeurigheidsniveau, inclusief de meetwaarden, robuustheid en cyberbeveiliging" bevatten (artikel 13(3)(b)(ii)). Zorgvuldigheid is waar u bevestigt dat die materialen bestaan en goed genoeg zijn opdat u uw deel kunt doen.

Timing is belangrijk. Onder de Digital Omnibus-wijzigingen zijn nu de regels voor hoog risico van artikel artikel 113 van toepassing vanaf 2 december 2027 voor alleenstaande systemen vermeld in Annex III en vanaf 2 augustus 2028 voor AI ingebed in producten onder Annex I. Contracten die u vandaag ondertekent, zullen op die data vaak nog steeds van kracht zijn, dus het is zinvol om de verplichtingen nu op te nemen. Afzonderlijk vraagt artikel 4 aan aanbieders en implementeerders van AI-systemen in het algemeen, niet alleen risicovolle systemen, om "maatregelen te treffen ter ondersteuning van de ontwikkeling van AI-geletterdheid" van het personeel dat deze bedient en gebruikt. Voor het bredere juridische beeld, zie onze volledige gids over de EU AI-wet en Amerikaanse AI-wetten.

De vrijwillige kaders wijzen dezelfde kant op

Het NIST AI Risk Management Framework kerngedeelte geeft AI van derden zijn eigen categorie. GOVERN 6.1 luidt "Beleid en procedures zijn op hun plaats om risico's van AI van derde partijen aan te pakken", GOVERN 6.2 luidt "Noodprocedures zijn op hun plaats om storingen of incidenten in gegevens of AI-systemen van derden aan te pakken die als hoog risico worden beschouwd", en MANAGE 3.1 zegt dat risico's van middelen van derden "regelmatig moeten worden gemonitord en risicocontroles moeten worden toegepast en gedocumenteerd." Als uw organisatie al aansluit bij NIST AI RMF of een ISO/IEC 42001-beheersysteem voert, is zorgvuldigheid ten aanzien van leveranciers hoe u aan die verwachtingen voor de AI die u aanschaft voldoet. Onze gids over NIST AI RMF, ISO/IEC 42001 en gerelateerde normen behandelt hoe de kaders samengaan.

De zes evaluatiegebieden

Elke AI-leveranciersevaluatie komt neer op zes gebieden.

1. Wat het systeem is en waarvoor het is

Begin met het bereik. Welke modellen liggen onder het product, en is de leverancier hun ontwikkelaar of een wederverkoper die iemand anders inpakken? Welke beoogde toepassing documenteert de leverancier, en valt uw geplande gebruik daarin? Onder de EU AI-wet is beoogde toepassing het eerste item dat de gebruiksaanwijzing moet vermelden, en het gebruiken van een systeem daarbuiten betekent het risico nemen dat de leverancier nooit heeft getest.

2. Bewijs van veilig gedrag

Dit is het gebied dat de meeste kopers het slechtst aanpakken, omdat het het moeilijkst is om ernaar te vragen in een vragenlijst. "Test je op vooroordelen?" krijgt van iedereen een ja. Betere vragen vragen naar methode en resultaat: wat werd getest, tegen welke scenario's, met welk slagingspercentage, door wie en wanneer. De gedragsrisico's die het waard zijn om te behandelen, sluiten aan bij de zeven pijlers van het A.E.G.I.S.™-framework:

• Hallucination Integrity: stelt het systeem onwaarheden als feiten, vooral onder druk, onduidelijkheid of domeinspecifieke vragen?
• Guardrail Resistance: kan het worden gemanipuleerd tot onveilig gedrag via jailbreak-pogingen of prompt-injectie?
• Data Handling & Privacy: wat verzamelt, bewaart en lekt het, inclusief persoonlijke gegevens?
• Ethical Alignment: gedraagt het zich passend met kwetsbare gebruikers en gevoelige onderwerpen?
• Autonomy & Control: hoe ver kan het op eigen initiatief handelen, en kan een mens het stoppen?
• Adversarial Robustness: hoe gaat het ermee om tegen een gemotiveerde aanvaller?
• Explainability & Transparency: kan het gedrag ervan worden begrepen en achteraf worden gecontroleerd?

Voor meer informatie over hoe elk van deze aspecten wordt getest, zie hoe AI-systemen op veiligheid worden getest. Voor een koper is het belangrijkste onderscheid tussen resultaten die de leverancier zelf heeft opgesteld en resultaten van een onafhankelijke partij. Interne tests hebben waarde, maar het is de leverancier die zijn eigen huiswerk nakijkt. M-25-22 maakt hetzelfde punt vanuit het perspectief van de koper wanneer het vraagt om tests die gedetailleerd genoeg zijn om "onafhankelijk te worden geverifieerd of gereproduceerd."

3. Gegevensverwerking

Vraag waar uw gegevens naartoe gaan, hoe lang ze blijven, wie ze kan zien en of ze iets trainen. De federale standaard in M-25-22 is een nuttig referentiepunt: leveranciers mogen agencygegevens alleen verzamelen en bewaren wanneer dit "redelijkerwijs noodzakelijk" is voor het contract, en niet-openbare invoer en uitvoer mogen niet worden gebruikt om openbare of commerciële modellen te trainen zonder toestemming. Vraag ook of de systeemlogboeken voor u beschikbaar zijn, omdat deployers van hoog-risicosystemen in de EU de logboeken onder hun controle moeten houden.

4. Toezicht en controle

Ontdek wat een persoon kan doen wanneer het systeem fout zit. Kan een operator uitvoer beoordelen of negeren, of het systeem pauzeren? Artikel 26(2) gaat ervan uit dat u competente mensen aan het toezicht toewijst; de leverancier moet hen iets geven om mee te werken.

5. Veranderingenbeheer en monitoring

AI-producten veranderen onder u: een nieuw basismodel of hertraining, en het gedrag dat u heeft goedgekeurd is niet langer het gedrag in productie. Vraag hoe de leverancier u over wezenlijke veranderingen informeert, of u een nieuwe versie kunt testen voordat deze uw gebruikers bereikt, en of een versie kan worden teruggedraaid. M-25-22 vraagt agentschappen alle drie in overweging te nemen of voor te schrijven. Vraag vervolgens welke monitoring na go-live bestaat en of resultaten met u worden gedeeld.

6. Incidenten en verantwoordelijkheid

Vraag naar het incidentresponsproces van de leverancier voor AI-specifieke fouten, zoals schadelijke uitvoer of een geslaagde jailbreak. Deployers van hoog-risicosystemen in de EU moeten de provider en de markttoezichtautoriteit informeren wanneer zij geloven dat een systeem een risico vormt, dus uw contract moet ervoor zorgen dat de leverancier met u werkt wanneer dit gebeurt. Onze gids over gedocumenteerde AI-incidenten en welke tests deze opvangen toont de foutpatronen die het waard zijn om voor in te plannen.

Een vragenlijst die u naar AI-leveranciers kunt sturen

Kopieer deze naar uw RFP. Elk vraagt om iets dat u kunt controleren.

Omvang en doel

1. Welke modellen drijven het product aan, wie ontwikkelt elk model, en welke versies zijn vandaag in productie?
2. Wat is het gedocumenteerde beoogde gebruik, en zijn er toepassingen die u afraadt? Deel alstublieft de gebruiksinstructies of gelijkwaardige documentatie.
3. Publiceert u model-, systeem- of datakaarten voor het product? Voeg ze alstublieft toe.
4. Wat is uw beleid voor acceptabel gebruik voor eindgebruikers?

Testen en bewijzen

5. Tegen welke veiligheidsrisico's hebt u het product getest (bijvoorbeeld hallucinatie, jailbreaks en prompt injection, privacylekkage, gedrag bij kwetsbare gebruikers, autonomielimits, adversarial attack, uitlegbaarheid)? Voor elk, wat was de methode en het resultaat?
6. Zijn die tests door een onafhankelijke partij uitgevoerd? Wie, wanneer, tegen welke versie, en kunnen we het resultaat zelf verifiëren?
7. Geeft u ons toegang en tijd om onze eigen evaluatie uit te voeren met testgegevens die u niet ziet?
8. Wat zijn de gedocumenteerde nauwkeurigheids-, robuustheids- en cybersecurityniveaus, en hoe zijn deze gemeten?

Gegevens

9. Welke gegevens van ons gebruik verzamelt en bewaart u, hoe lang, en waarom is elk item noodzakelijk?
10. Zullen onze inputs of outputs gebruikt worden om een model te trainen of te verbeteren, van u of van een derde partij? Kan dit contractueel verboden worden?
11. Welke subverwerkers, inclusief leveranciers van modellen, hebben toegang tot onze gegevens?
12. Welke logboeken genereert het systeem, en kunnen we deze exporteren en behouden?

Controle, wijzigingen en incidenten

13. Welke mogelijkheden voor menselijk toezicht en overschrijving hebben onze operators?
14. Hoe en wanneer stelt u ons op de hoogte van een materiële wijziging van het model of zijn gedrag? Kunnen we een nieuwe versie testen voordat deze onze gebruikers bereikt, en kunnen we terugdraaien?
15. Hoe monitort u het product na implementatie, en zult u de monitoringresultaten met ons delen?
16. Wat is uw incidentresponseproces voor AI-gerelateerde storingen, en wat zijn uw meldingsverplichtingen jegens ons?
17. Als we weggaan, hoe krijgen we onze gegevens en eventuele aanpassingen terug, en in welk formaat?

Antwoorden omzetten in contractvoorwaarden

Antwoorden op vragenlijsten zijn verklaringen. Het contract is waar ze verplichtingen worden. M-25-22 bevat een sjabloon voor de onderwerpen, en particuliere kopers kunnen dit zonder veel wijzigingen aanpassen.

• Prestatie- en veiligheidsverplichtingen. Neem het getest gedrag op in de overeenkomst: de gedocumenteerde nauwkeurigheid en veiligheidsniveaus, een schema voor periodieke controle, en wat er gebeurt als de resultaten eronder vallen.
• Recht op evaluatie. Behoud het recht om eigen testen uit te voeren of door een onafhankelijke partij te laten testen, met toegang en tijd van de leverancier.
• Beperkingen op gegevensgebruik. Verbied trainingen op uw inputs en outputs zonder schriftelijke toestemming, beperk bewaring tot wat nodig is, en vermeld de subverwerkers.
• Kennisgeving van wijzigingen. Vereisen voorafgaande kennisgeving van materiële modelwijzigingen en een testperiode voordat deze in productie gaan, met een terugdraaiopties.
• Logboeken en documenten. Vereisen dat het systeem de logboeken genereert en exporteert die u nodig hebt, en bepaal hoe lang de leverancier deze bewaart.
• Samenwerking bij incidenten. Stel meldingstermijnen voor AI-incidenten en een verplichting in om u te helpen aan uw meldingsverplichtingen te voldoen.
• Draagbaarheid. Behandel gegevens- en modeloverdraagbaarheid, kennisoverdracht en transparante licenties zodat u kunt vertrekken als dat nodig is.

M-26-04 voegt een nuttige opstellingstechniek toe: het vertelt instellingen bepaalde vereisten te identificeren als "materieel voor geschiktheid en betaling onder het contract." Door veiligheids- en transparantievoorwaarden materieel te maken, krijgen ze gewicht, omdat een schending ervan een basis voor rechtsmiddelen wordt in plaats van een voetnoot.

Waar due diligence meestal mislukt

De meeste mislukte AI-leveranciersevaluaties mislukken op een van enkele voorspelbare manieren.

De vragenlijst is een beveiligingsformulier met AI-vragen erop geplakt. Een SOC 2-rapport is volgens AICPA's eigen beschrijving een onderzoek naar controles bij een dienstverlener die relevant zijn voor beveiliging, beschikbaarheid, verwerkingsintegriteit, vertrouwelijkheid of privacy. Dit is waardevol en beantwoordt een ander vraagstuk dan of het model kan worden gehackt of hoe vaak het feiten verzint. Houd informatiebeveiliging en AI-gedrag gescheiden in aparte secties met apart bewijs.

Elk antwoord is zelfgerapporteerd. De reviewer heeft geen manier om het formulier of het bijgevoegde beleid te controleren, dus de koper accepteert claims die hij niet kan verifiëren of geeft opdracht voor eigen testen.

Goedkeuring wordt behandeld als permanent. Zes maanden na aankoop heeft de leverancier het model gewijzigd en niemand heeft het opnieuw gecontroleerd. Zowel M-25-22 als het NIST AI RMF behandelen monitoring als continu, precies om deze reden.

Bewijsmateriaal is niet vergelijkbaar tussen leveranciers. Drie leveranciers beschrijven hun testen op drie verschillende manieren, dus prijs en functies bepalen standaard.

Waarom een verifieerbare onafhankelijke beoordeling het proces versnelt

De laatste twee problemen zijn de dure problemen. Wanneer een AI-systeem door een onafhankelijke partij tegen een standaardkader is geëvalueerd, veranderen er drie dingen voor de koper.

Ten eerste is het bewijs onafhankelijk. RateAI heeft geen belang bij de beoordeling van een systeem en haar honoraria zijn gekoppeld aan evaluatiemijlpalen, niet aan resultaten. Een systeem kan niet-gecertificeerd uitkomen; in dat geval ontvangt de ontwikkelaar een gedetailleerd rapport met bevindingen en een remedieringsplan, en kan zich opnieuw aanmelden voor evaluatie zodra de problemen zijn opgelost.

Ten tweede is het bewijs vergelijkbaar. Elke A.E.G.I.S.™ evaluatie beoordeelt dezelfde zeven pilaren, en de beoordelingsparameters worden vastgesteld op basis van een beoordelingsperiode zodat evaluaties in de loop van de tijd vergelijkbaar blijven. Gecertificeerde systemen ontvangen een A.E.G.I.S.™ scorecard met een algehele veiligheidsbeoordeling van A (Maximale veiligheid) tot F (Gevaarlijk), een cijfer voor elke pijler, en een certificeringszegel van A-5 Guardian tot A-1 Unrestricted. Uw reviewers kunnen in één oogopslag zien waar een systeem sterk is en waar voorzichtigheid geboden is, en kunnen twee leveranciers op dezelfde schaal vergelijken.

Ten derde is het bewijs verifieerbaar en actueel. Elke promptcase, validatorvoting en certificeringsbeslissing wordt geketend met SHA-256-hashing in een onveranderbaar audittrail, zodat records niet kunnen worden gewijzigd of teruggedateerd. Iedereen kan een RateAI-certificatie in het openbare Safety Registry controleren zonder in te loggen, en bevestigen dat deze actueel is en niet is verlaagd. Certificeringen hebben ook een hercertificatiecyclus, en materiële wijzigingen aan een systeem leiden tot herbeoordeling, wat rechtstreeks op het wijzigingsbeheerprobleen hierboven slaat.

Een beoordeling vervangt uw due diligence niet. U hebt nog steeds antwoorden nodig op bereik, contractvoorwaarden, gegevensstromen en geschiktheid voor uw use case, en een RateAI-certificatie is geen juridische bepaling: het ondersteunt uw compliancework, en regelgeving blijft voorbehouden aan de bevoegde instanties. De Pro- en Enterprise-tiers van RateAI omvatten compliancemapping naar de EU AI Act, NIST AI RMF en ISO 42001. Wat een verifieerbare beoordeling doet, is de bewijsvragen, nummers 5 tot 8 op de bovenstaande lijst, beantwoorden met iets dat uw team kan controleren in plaats van vertrouwen. Voor een dieper inzicht in hoe certificatie door derden werkt, leest u wat AI-veiligheidscertificatie is en hoe het werkt.

Een praktische due diligence-workflow

1. Classificeer de use case. Wie wordt door het systeem beïnvloed, kan het zelfstandig handelen, en kan het onder de EU AI Act als hoog risico worden beschouwd? Hogere inzet betekent diepere beoordeling.
2. Verzend de vragenlijst vroeg. Voeg deze in bij het RFP zodat leveranciers die niet kunnen antwoorden er voor uitvallen voordat u tijd in demo's investeert.
3. Controleer op onafhankelijk bewijs. Zoek het product van de leverancier op in elk onafhankelijk register waarin het aangeeft te staan, en bevestig dat de beoordeling, datum en versie overeenkomen met wat u koopt.
4. Test wat overblijft. Waar onafhankelijk bewijs ontbreekt of uw use case niet dekt, voert u uw eigen evaluatie uit op gegevens die de leverancier niet heeft gezien, of commissies dit.
5. Onderhandelings de voorwaarden. Converteer de antwoorden in contractverplichtingen: prestatie, testrechten, gegevensgebruik, wijzigingsbericht, logging, incidenten en overdraagbaarheid.
6. Bepaal de monitorcyclus. Afspreken hoe vaak u prestaties zult beoordelen en wat een herzieningsevaluatie zou triggeren, zoals een modelwijziging of een gemeld incident.
7. Documenteer de beslissing. Bewaar het bewijs, uw scoring en de redenen voor goedkeuring.

Als u aan de leverancierszijde van dit proces staat, vertelt dezelfde lijst u wat kopers gaan vragen. Het hebben van onafhankelijk bewijs klaar voordat de vragenlijst aankomt, verkort elke verkoopscyclus die volgt. De certificerings- en monitortiers van RateAI beschrijven hoe een engagement wordt afgebakend, en een gratis veiligheidsbenchmark voor één AI-agent is beschikbaar als startpunt.

Veelgestelde vragen

Wat is due diligence voor AI-leveranciers?

Dit is het proces van het controleren van het systeem, de gegevenspraktijken en controles van een AI-leverancier voordat u koopt, en deze controles daarna actueel houden. Vergeleken met normale softwarereview voegt het testen van het gedrag van het systeem toe, zoals hallucinatie, weerstand tegen jailbreak en privacylekkage.

Is een SOC 2-rapport voldoende om een AI-leverancier goed te keuren?

Meestal niet op zichzelf. Een SOC 2-rapport onderzoekt de controles van een diensten organisatie die relevant zijn voor veiligheid, beschikbaarheid, verwerkingsintegriteit, vertrouwelijkheid of privacy, dus u hebt nog steeds apart bewijs nodig over hoe het AI-model zich gedraagt, zoals foutieve antwoorden, manipulatie en lekkage van gegevens via outputs.

Wat vereist de EU AI Act van bedrijven die AI kopen?

Organisaties die systemen met hoog risico gebruiken, zijn "deployers" onder artikel 26, en moeten het systeem volgens de instructies gebruiken, bekwaam menselijk toezicht toewijzen, de werking ervan bewaken, de logboeken onder hun controle houden en in sommige gevallen de betrokken personen informeren. Deze regels voor hoog risico gelden vanaf 2 december 2027 voor Annex III-systemen en 2 augustus 2028 voor AI ingebed in producten onder Annex I.

Welke contractvoorwaarden moet een AI-aankoop bevatten?

Minimaal: prestatiegaranties en veiligheidsgaranties, een recht op onafhankelijke testen, beperkingen op het gebruik van uw gegevens voor training, vooraankondiging en testen van modelwijzigingen, logboektoegang, incidentsamenwerking en overdraagbaarheid. OMB-memorandum M-25-22 noemt de meeste hiervan als vereiste onderwerpen voor AI-contracten van de VS federale regering.

Hoe helpt een onafhankelijke AI-veiligheidsbeoordeling bij aanschaffingen?

Het vervangt eigendomsverklaringen door gestandaardiseerde resultaten die een onafhankelijk derde partij heeft gegenereerd en die u kunt verifiëren. Een A.E.G.I.S.™ rating beoordeelt een systeem aan de hand van dezelfde zeven pijlers als elk ander beoordeeld systeem, zodat u verkopers kunt vergelijken en kunt bevestigen dat de certificering actueel is in het publieke Safety Register.

Maakt een RateAI-certificering een AI-systeem juridisch compliant?

Geen certificering kan deze vaststelling doen; formele regelgevingsbeslissingen blijven voorbehouden aan de relevante autoriteiten. RateAI-certificering ondersteunt compliancewerkzaamheden, en de Pro en Enterprise tiers ervan omvatten compliancemapping naar de EU AI Act, NIST AI RMF en ISO/IEC 42001.

Controleer de rating van een verkoper voordat u een contract ondertekent

De snelste due diligence-vraag is of het systeem al onafhankelijk is geëvalueerd. Doorzoek het RateAI Safety Registry om te zien hoe gecertificeerde AI-systemen zijn vermeld, met hun A.E.G.I.S.™ rating en certificeringsstatus, en vraag uw verkopers of hun product erop voorkomt.