Leverantorsskyldigheter checklista for grundare och complianceansvariga

Leverantorsskyldigheter ska kontrolleras fore forsaljning, lansering, materiell andring eller enterprise review. Checklistan avgor om bolaget ar leverantor, vilket AI-tillgang som granskas, vilken riskbana som galler, vilka skyldigheter som foljer och nar beslutet maste omprovas.

1. Bekrafta AI-tillgangen

Granska inte "AI i produkten" som ett brett amne. Identifiera system, modellintegration, scoring, rekommendation, API, internt verktyg eller GPAI-modell. Dokumentera produktomrade, agare, fas, anvandare, berorda personer, data, modellkalla, leverantor och kundresa.

2. Bestam AI Act-roll

Dokumentera om bolaget ar leverantor, anvandare, importor, distributer, tillverkare, GPAI-modellleverantor eller flera roller. Forklara vem som bestammer syftet, saljer funktionen, styr UX, andrar trosklar och ger kundinstruktioner.

3. Kontrollera vardekedjan

Artikel 25 ar viktig nar teamet white-labelar, fine-tunar, omkonfigurerar eller saljer ett tredjepartssystem som eget. Fraga om kunden ser leverantoren, om ert marke anvands, om syfte eller beteende andras och om leverantorsdokument racker.

4. Klassificera risken

Koppla checklistan till AI-klassificering. Notera om tillgangen ar forbjuden, high-risk, transparens, minimal risk, GPAI eller utanfor scope. Vid mojlig high-risk: use case, syfte, berorda personer, mansklig tillsyn och outputkonsekvens.

5. Mappa high-risk-skyldigheter

For high-risk-system kraver artikel 16 agare for krav, kvalitetssystem, teknisk dokumentation, loggar under leverantorskontroll, konformitet, EU-deklaration, CE-markning, registrering, korrigerande atgarder, myndighetssamarbete och tillganglighet.

6. Hall GPAI separat

Om bolaget kan leverera en GPAI-modell, bedom artikel 53 separat: teknisk dokumentation, downstreaminformation, copyrightpolicy, offentlig sammanfattning av traningsinnehall, myndighetssamarbete och standarder eller codes. Att anvanda tredjepartsmodell racker inte.

7. Bygg bevisspaket

Spara roll, klassificering, leverantorsdokument, teknisk dokumentation, tester, mansklig tillsyn, loggning, sakerhet, kundinstruktioner, releaseticket, residualrisk, overvakning, incidentvag och omprovning. Ordna kring beslut.

8. Forbered kunddokumentation

Kunder kan fraga om syfte, granser, tillsyn, overvakning, stoda anvandningar, modellberoenden, data, andringsnotiser och support. Sales, trust center, hjalp, avtal och fragesvar ska anvanda samma godkanda kalla.

9. Definiera overvakning och korrigering

Utse agare for incidenter, klagomal, leverantorsuppdateringar, modelldrift, eskaleringar och korrigeringar. Definiera nar funktionen pausas, kunder meddelas, instruktioner uppdateras eller legal och compliance kopplas in.

10. Satt omprovningstriggers

Oppna checklistan igen vid nytt syfte, nytt segment, mer automatisering, mindre mansklig granskning, nya data, leverantorsmodellandring, high-risk-kontext, incident eller ny officiell guidance.

FAQ

Vad ar det praktiska syftet?

Att visa roll, skyldigheter, bevis, kundinstruktioner, overvakning och omprovning for AI-systemet som erbjuds eller andras.

Nar galler det SaaS?

Nar teamet utvecklar eller bestaller ett AI-system, saljer det under eget namn, andrar ett high-risk-system, andrar syfte eller levererar en GPAI-modell.

Vad dokumenteras forst?

Ett register per AI-flode: roll, klassificering, skyldigheter, bevisagare, tekniska dokument, kunddokumentation, overvakning, launchblockerare och omprovning.