Due diligence av AI-leverantörer: praktisk guide för SaaS-team

Due diligence fungerar när en föreslagen användning omvandlas till ett försvarbart operativt beslut. Teamet måste förstå funktion, data och berörda personer, modell- och infrastrukturleverantörer, tester, rättsliga roller, avtalsåtaganden och ändringsövervakning. Resultatet är inte ett ifyllt frågeformulär utan godkännande, villkorat godkännande, begränsad pilot, eskalering eller motiverat avslag med ansvariga.

EU:s AI-förordning innehåller ingen universell checklista som heter ”AI vendor due diligence”. Djupet beror på system, ändamål, klassificering, roll i värdekedjan, databehandling och sektorsregler. En mötesassistent och ett system som rangordnar arbetssökande behöver olika granskningar. Börja med användningsfallet och begär bevis som står i proportion till konsekvenserna.

Varför vanlig leverantörsgranskning inte räcker

Åtkomst, kryptering, tillgänglighet, underleverantörer, incidenter och radering är fortsatt viktiga. Men en AI-tjänst kan byta modeller, retrievalkällor, filter eller användning av prompter och resultat utan en vanlig release. Kvalitet kan variera efter språk, grupp eller indata, och ”beslutsstöd” kan under tidspress bli faktiskt avgörande.

Granska både leverantör och system: företag, hosting, modeller, säkerhet, avtal och kontinuitet; samt ändamål, användare, berörda, data, beteende, mänsklig tillsyn, integrationer och efterföljande åtgärder. Att separera dem återskapar problemet med manuella leverantörsriskgranskningar vid skalning.

När granskningen ska fördjupas

Fördjupa när personuppgifter, konfidentiella, reglerade eller kundstyrda data går in; resultat påverkar viktiga beslut; tjänsten agerar autonomt eller ändrar produktion; egen kunskap ansluts; fel är svåra att upptäcka eller återställa; kedjan är oklar; eller ett fel orsakar väsentlig skada.

Härled inte klassificering från marknadsföring. Enligt AI-förordningen avgör ändamål och roll. Artikel 25 kan flytta leverantörsansvar vid omprofilering, väsentlig ändring eller nytt högriskändamål. Leverantörer av högrisksystem och tredje parter som levererar komponenter måste utbyta nödvändig information genom skriftliga arrangemang. Den 30 augusti 2026 gäller en stor del av AI-förordningen; de ändrade datumen är 2 december 2027 för bilaga III och 2 augusti 2028 för reglerade produkter. Använd tiden till förberedelse.

Bevis att begära

1. System och kedja: gräns, modeller och leverantörer, regioner, integrationer, källor, underleverantörer, tillåtna och förbjudna användningar, begränsningar, versioner och meddelanden.
2. Data och integritet: ändamål, plats, åtkomst, lagring, radering, träning och vidareöverföring för prompter, uppladdningar, resultat, feedback, metadata och loggar. Om leverantören är GDPR-biträde kräver artikel 28 tillräckliga garantier och rätt avtal. EDPB beskriver en specifik och fortlöpande bedömning av expertis, tillförlitlighet, resurser, policyer, revisioner och certifieringar.
3. Säkerhet och motståndskraft: rapporter och omfattning, sårbarheter, incidenter, kryptering, identiteter, tenantseparering, återställning och beroenden. För GenAI: promptinjektion, läckage, osäkra verktyg och förgiftade källor.
4. Prestanda och påverkan: testade grupper och språk, baslinje, trösklar, villkor, begränsningar och fel. Testa den egna konfigurationen med svåra indata, eskalering, mänsklig override och återställning.
5. Styrning: leverantörsansvariga för säkerhet, integritet, AI governance, incidenter och meddelanden; interna verksamhets- och riskägare; klagomål, skadliga resultat och bevis efter avslut.

NIST:s frivilliga AI RMF anger policyer, dokumenterade kontroller, beredskapsprocesser och övervakning för tredjeparts-AI. GenAI-profilen nämner inköpsgranskning, SLA, granskningsrapporter och insyn i leveranskedjan. De är designstöd, inte bevis på rättslig efterlevnad.

Avtal och beslut

Avtalet ska följa bevisen: ändamål, användare och data; träning; modeller, underleverantörer, platser och meddelanden; säkerhet, incidenter och samarbete; dokumentation; begränsningar och tillsyn; ändringar; kontinuitet, portabilitet, radering och exit; proportionerligt ansvar. Ett avtal lagar inte ett olämpligt system men skyddar informationsrättigheter och påföljder.

1. Beskriv ändamål, användare, berörda, indata, resultat, integrationer, automatisering, mänsklig kontroll och efterföljande åtgärd.
2. Sätt preliminär nivå och AI Act-/GDPR-roller; notera överföringar, sektorsregler och osäkerhet.
3. Begär proportionerliga bevis och återanvänd aktuella dokument som faktiskt svarar.
4. Testa konfigurerad produkt med lagliga representativa data; bevara versioner och resultat.
5. Hantera luckor med rättelse, kompensation, begränsad omfattning, tidsbegränsad pilot, riskacceptans eller avslag.
6. Ompröva vid ändrat ändamål, modell, leverantör, data, integration, autonomi, incident eller lag.

Beslutsunderlaget innehåller produkt och version, tillåten och förbjuden användning, kedja, nivå, roller, motivering, bevis, tester, luckor, avtal, beslut, villkor, tidsfrister och övervakning. Förändrade AI governance-förväntningar kräver aktuella bevis.

FAQ

Vad är det praktiska syftet?

Att försvarbart avgöra om och hur en viss tjänst får användas, hitta luckor tidigt, fördela kontroller och bevara bevis för kunder, revisioner, incidenter och omprövning.

Vad dokumenteras först?

Exakt användning: användare, berörda, data, indata, resultat, integrationer, mänsklig kontroll och efterföljande åtgärd. Utan denna gräns kan svar och rättsliga roller inte bedömas tillförlitligt.

Vilket är det största misstaget?

Att behandla due diligence som ett engångsutbyte av dokument. En stark granskning binder ihop omfattning, bevis, tester, avtal, villkor, övervakning och tydliga utlösare för omprövning.