Sa operationaliserar du leverantorsskyldigheter utan att bromsa produktleverans

Leverantörsskyldigheter ska vara en del av leveransen, inte en sen juridisk kontroll. Enligt EU AI Act kan leverantörsrollen bli relevant när ett SaaS-bolag utvecklar ett AI-system, låter någon utveckla det, släpper det på EU-marknaden under eget namn, väsentligt ändrar ett högrisksystem, ändrar avsett syfte eller tillhandahåller en generell AI-modell.

Börja med ett rollbeslut per AI-flöde. Samma bolag kan vara användare för ett internt verktyg, leverantör för en kundfunktion och GPAI-modellleverantör för ett modell-API. Dokumentera AI-tillgången, syftet, varumärket, ändringarna, kundkontexten och vem som startar omprövning när fakta ändras.

Artikel 16 blir praktisk när den översätts till produktgrindar. I discovery kontrollerar teamet om funktionen använder AI och om en högriskkontext kan uppstå. I arkitekturgranskning dokumenteras dataflöden, modellkälla, mänsklig tillsyn, loggar, noggrannhet, robusthet och cybersäkerhet. I leverantörsgranskning samlas downstream-information och säkerhetsbevis. Före release bekräftas teknisk dokumentation, test, kundinstruktioner, övervakning och godkännande.

Artikel 25 hör hemma tidigt i inköp och integration. White-label, wrapper, fine-tuning, materiell omkonfiguration eller försäljning av ett leverantörssystem som egen produkt kan skapa leverantörsansvar. Fråga om kunden ser leverantören, om syftet ändras, om trösklar eller automationsgrad ändras och om leverantörens dokumentation räcker.

Skapa ett enda register för leverantörsskyldigheter. Det kopplar AI-inventering, produktticket, leverantörsgranskning och lanseringschecklista. Ta med tillgång, syfte, användare, rollslutsats, riskklassificering, skyldigheter, dokumentationsplats, testbevis, kundinformation, övervakning, incidentväg och omprövningstriggers.

Håll GPAI-modellskyldigheter separat. Artikel 53 gäller teknisk dokumentation, information till nedströmsleverantörer, copyrightpolicy, offentlig sammanfattning av träningsinnehåll och samarbete med myndigheter. Att använda en tredjepartsmodell gör inte automatiskt bolaget till GPAI-modellleverantör, men bolaget kan vara leverantör av AI-systemet som erbjuds.

Kunddokumentation är release readiness. Kunder behöver syfte, begränsningar, mänsklig tillsyn, stödda användningar, data, övervakning, support och information om materiella ändringar. Definiera omprövning vid nytt syfte, nytt segment, högriskkontext, modelländring, mindre mänsklig granskning, nya leverantörsvillkor eller incidenter.

Bästa starten är ett ensidigt register för en verklig AI-funktion. Lägg sedan in samma frågor i discovery, arkitektur, leverantörsgranskning, release approval och change management. Då tar teamet bort osäkerhet innan kund, tillsynsmyndighet eller revisor frågar vem som ansvarar och var bevisen finns.

FAQ

Vad är det praktiska syftet?

Att göra roll, klassificering, teknisk dokumentation, bevis, kundinstruktioner, övervakning, korrigerande åtgärder och omprövning synliga i produktarbetet.

När kan det gälla SaaS-team?

När de utvecklar eller beställer ett AI-system, säljer det under eget namn, väsentligt ändrar ett högrisksystem, ändrar syftet eller tillhandahåller en GPAI-modell.

Vad bör dokumenteras först?

Ett register per AI-flöde: tillgång, syfte, roll, klassificering, skyldigheter, bevisägare, dokumentationsplats, releaseblockerare, kundinstruktioner och omprövningstriggers.