Hoppa till innehåll
Nätfiske för problem –
IO Podcasten återvänder för säsong 2
Lyssna nu

Vad är risken för AI-leverantörer?

AI-leverantörsrisk är den exponering din organisation bär när en tredje part levererar, hostar, utbildar eller bäddar in AI-kapacitet i dina produkter, processer eller beslut. Den är bredare än klassisk IT-leverantörsrisk eftersom en AI-leverantör inte bara bearbetar dina data – de kan forma de resultat dina anställda och kunder förlitar sig på, med beteende som förändras över tid allt eftersom modeller omskolas och uppdateras.

Femstegslivscykel för riskhantering för AI-leverantörer, från due diligence före avtal, kontraktsklausuler, onboardingbaslinje, kontinuerlig övervakning till förnyelse eller avslut med dataåterlämning

I de flesta organisationer idag faller AI-leverantörer inom fyra överlappande kategorier:

  • Leverantörer av stiftelsemodeller såsom OpenAI, Anthropic, Google, Mistral och Cohere, åtkomliga via API och inbäddade i interna verktyg, agenter eller kundvända funktioner.
  • AI-inbyggda SaaS-verktyg såsom anteckningsskrivare, kodningsassistenter, kundsupportmedpiloter, säljstödjande verktyg och analysplattformar där AI är produkten.
  • Inbyggd AI i företagsprogramvara såsom AI-sammanfattning i CRM, AI-poängsättning i HR-system, AI-granskning i kontraktshantering eller AI-triage i tjänstehantering, där AI:n är en ny funktion i en befintlig leverantörsrelation.
  • Leverantörer av datamärkning och utbildningsdata som ligger före alla modeller du bygger, med betydande inflytande över partiskhet, kvalitet och laglig grund för utbildning.

Varje kategori medför olika risker, men de delar ett gemensamt problem: leverantören kontrollerar beteendet du är ansvarig för. Tillsynsmyndigheter, kunder och försäkringsbolag förväntar sig i allt högre grad att du bevisar att du aktivt har bedömt och övervakat det beteendet – inte bara skrivit under ett kontrakt och gått vidare.

Varför har AI-leverantörsrisker blivit ett styrelserumsproblem?

Tre krafter har flyttat tillsynen av AI-leverantörer från att vara en upphandlingsuppgift till en angelägenhet på styrelsenivå.

Koncentrerat beroende. En handfull leverantörer av grundläggande modeller ligger nu under tusentals AI-funktioner i nästan varje företagsstack. Modellavbrott, policyändringar, prisändringar och geografiska begränsningar sprider sig omedelbart till dina produkter och kundresor. Det är en koncentrationsrisk som styrelsen måste ta ansvar för.

Icke-deterministiskt beteende. Till skillnad från en traditionell SaaS-leverantör vars programvara gör samma sak idag som igår, kan en AI-leverantör ändra modellviktningar, systemprompter, säkerhetsfilter och träningsdata utan föregående meddelande. Den utdata du validerade i testningen kanske inte är den utdata din kund ser i produktion sex månader senare.

Regulatorisk ansvarsskyldighet. ISO 42001, den EU:s AI-lag, sektorsregulatorer (FCA, PRA, NHS Digital, Ofcom) och dataskyddsmyndigheter ställer nu alla uttryckliga skyldigheter på den som distribuerar ett AI-system, inte bara på byggaren. Att peka på sin leverantör är inte längre ett försvar. Du måste visa att du valde en lämplig leverantör och fortsatte att hålla koll på dem.

Den praktiska konsekvensen: AI-leverantörsrisk hör hemma i företagsriskregistret, i revisionskommitténs paket och i AI-policy, inte begravd i upphandling.

Vad säger ISO 42001 om AI-leverantörstillsyn?

ISO 42001 behandlar AI-relationer med tredje part direkt i bilaga A.10, ett av nio kontrollområden i bilaga A. Kontrollområdet omfattar leverantörer, ansvarsfördelning mellan organisationer och kunder, eftersom du i en AI-leveranskedja kan vara alla tre samtidigt – leverantör till en part, distributionsleverantör till en annan och kund till en tredje part.

Bilaga A.10 kräver att du:

  • Upprätta en process för att identifiera AI-leverantörer och de AI-system de tillhandahåller dig
  • Fördela ansvaret tydligt och skriftligt mellan dig och dina leverantörer, så att det inte finns några luckor i ansvarsskyldigheten för AI-risker, påverkan och prestanda.
  • Ta hänsyn till AI-specifika överväganden vid leverantörsval, kontraktering och löpande hantering, inte bara generiska informationssäkerhetstermer
  • Se till att kunderna till era AI-system har den information de behöver för att använda dem ansvarsfullt

Bilaga B (som är normativ, inte informativ) ger implementeringsvägledning för varje kontroll i bilaga A, inklusive A.10. Vid sidan av bilaga A.10 berör tillsynen av AI-leverantörer även A.2 (policyer relaterade till AI), A.3 (intern organisation och ansvar), A.5 (bedömning av effekterna av AI-system), A.7 (data för AI-system) och A.8 (information för intresserade parter). För en fullständig uppsättning, se vår Bilaga A kontroller referens och den dedikerade Bilaga A.10 Tredjeparts- och kundrelationer sida.

Dina Förklaring om tillämplighet bör dokumentera hur du tillämpar var och en av dessa kontroller på din AI-leverantörsfastighet, inklusive eventuella undantag och motiveringen för dem.




Allt du behöver för ISO 42001, på ISMS.online

Strukturerat innehåll, kartlagda risker och inbyggda arbetsflöden som hjälper dig att styra AI ansvarsfullt och med självförtroende.




Hur bedömer man en AI-leverantör?

Due diligence för AI-leverantörer måste gå utöver ett säkerhetsfrågeformulär. Du bedömer inte bara hur leverantören skyddar dina data, utan också hur de bygger, driver, ändrar och tar bort det AI-system du är beroende av. Ramverket nedan täcker de nio områden som varje bedömning av AI-leverantörer bör beröra, med ett exempel på frågor att ställa och de varningssignaler som bör stoppa ett kontrakt.

Area Frågor att ställa röd flagga
Datautbildning Vilka data användes för att träna modellen? Användes någon av våra data för utbildning som standard? Kan vi skriftligen välja bort detta? Vilken är den rättsliga grunden för utbildningsdata (samtycke, berättigat intresse, licensiering)? Leverantören kan inte uppge källorna till utbildningsdata, använder kunddata för utbildning som standard utan möjlighet att välja bort det, eller förlitar sig på skrapad data utan rättslig grund för försvar.
Modelltransparens Kan ni tillhandahålla ett modellkort eller systemkort? Vilka är de kända begränsningarna och fellägena? Hur är modellen versionsstyrd? Kommer vi att meddelas om modellbyten eller större omskolning? Ingen modelldokumentation, tysta modellbyten, ingen versionshantering eller vägran att beskriva modellen alls (svart låda utan garanti)
Säkerhetsställning Är leverantören certifierad enligt ISO 27001 och SOC 2? Hur separeras kunddata? Vilka är krypteringen, nyckelhanteringen och åtkomstkontrollerna kring inferenstrafik och loggar? Ingen erkänd certifiering, delad hyresrätt utan segregering, uppmaningar och utdata loggade i klartext på obestämd tid, eller ingen SSO och MFA
Sekretess och GDPR Var behandlas och lagras data? Finns ett databehandlingsavtal? Finns det tillräckliga överföringsmekanismer för internationella flöden? Hur hanteras de registrerades rättigheter för in- och utdata? Inget dataskyddsavtal, överföringar utanför Storbritannien och EES utan skyddsåtgärder, ingen mekanism för att stödja begäranden om åtkomst eller radering av uppgifter, eller otydlig lagring av uppmaningar
Specifikationer Är ni certifierade enligt ISO 42001? Innehar ni ISO 27001 och SOC 2 Typ II? När genomfördes de senaste övervakningsrevisionerna? Kan vi se certifikaten och omfattningsbeskrivningarna? Ingen ISO 42001 (eller ingen trovärdig färdplan för den), utgångna certifikat, omfattningsbeskrivningar som exkluderar den tjänst du köper, eller endast egencertifiering
Incidentrespons Hur definierar ni en AI-incident? Vad är ert SLA för aviseringar till kunder? Hur hanterar ni modellhallucinationer, skadliga utdata, biasincidenter och säkerhetsintrång? Kan vi se en redigerad rapport efter incidenten? Ingen AI-specifik incidentdefinition, aviseringsfönster längre än 72 timmar, ingen rapportering efter incidenten eller oförmåga att visa tidigare hanterade incidenter från början till slut.
Ändra hanteringen Hur hanterar ni ändringar av modellvikter, systemmeddelanden, säkerhetsfilter och skyddsräcken? Får vi meddelanden? Kan vi behålla en låst version? Hur testas ändringar före lansering? Löpande uppdateringar utan förvarning, inget alternativ för versionslåsning, ingen testning förhandsversion av företagstrafik eller ingen återställningsmekanism
Underprocessorer Vilka är era underleverantörer, inklusive webbhotell, modellwebbhotell, utvärdering och datamärkning? Hur godkänns och granskas de? Får vi meddelanden om ändringar? Ofullständig lista över underbiträden, ogenomskinlig användning av underbiträden, ingen rätt att invända mot nya underbiträden eller användning av underbiträden i motsatta jurisdiktioner
Avslutningsplan Hur får vi tillbaka våra data? Hur länge sparas de efter avslutad konfiguration? Raderas prompter, utdata och finjusteringsdata helt? Finns det ett portabilitetsformat för anpassad konfiguration eller utvärderingsdata? Ingen definierad utgång, kvarhållning mätt i år snarare än dagar, inget exportformat eller låsning via proprietära utvärderingsdata

Poängsätt varje område, vikta det enligt risken i AI-användningsfallet och koppla resultatet till leverantörsposten i ditt leverantörsregister. Målet är ett försvarbart beslut, inte en perfekt poäng.

Vilka avtalsvillkor bör du kräva av AI-leverantörer?

AI-leverantörsavtal måste gå utöver standardvillkor för SaaS. Säkerhetsscheman och databehandlingsavtal hanterar datalagret, men AI-beteende, förändring och ansvarsskyldighet behöver sina egna klausuler. Checklistan nedan är det minimum vi kan förvänta oss i alla väsentliga AI-leverantörsavtal:

  • Rätt till revision. En avtalsenlig rätt att granska leverantören, eller förlita sig på oberoende revisionsrapporter (ISO 42001-certifikat, SOC 2 typ II, sammanfattningar av penetrationstest) enligt en definierad kadens, som täcker det specifika AI-system du köper.
  • Meddelande om modelländring. Skriftligt meddelande om väsentliga ändringar av modellvikter, systemmeddelanden, säkerhetsfilter eller skyddsräcken, med en definierad meddelandeperiod (vanligtvis 30 till 90 dagar för företagsanvändningsfall) och ett versionslåsningsalternativ för reglerade arbetsbelastningar.
  • Begränsningar för dataanvändning. Uttryckligt förbud mot att använda kundens indata, utdata, finjusteringsdata eller metadata för att träna leverantörens allmänna modeller utan skriftligt samtycke, med åtaganden om datasegregering.
  • Åtaganden för utdatanoggrannhet. Representationer om avsedd användning, kända begränsningar och eventuella noggrannhets- eller säkerhetsriktmärken som leverantören publicerar, med åtgärder om leverantören tar bort dokumenterade funktioner.
  • Incidentmeddelande. Ett definierat servicenivåavtal för AI-incidentaviseringar (med sikte på 24 till 72 timmar beroende på allvarlighetsgrad) som täcker säkerhetsintrång, biasincidenter, skadliga utdatahändelser och långvarig tjänsteförsämring.
  • Immateriella rättigheter. Tydlig allokering av IP i indata, utdata och alla härledda verk, med ersättning mot IP-krav från tredje part som uppstår från modellutdata.
  • Skadestånd och ansvar. Skräddarsydda ersättningar för dataskyddsintrång, intrång i immateriella rättigheter i modellutdata och böter där leverantörens beteende är den direkta orsaken, med ansvarstak som står i proportion till risken för AI-användningsfallet.
  • Utgång och dataåtergång. Definierad avslutningsprocess med garanterade exportformat, raderingscertifikat och en maximal lagringsperiod för kvarvarande data efter uppsägning (vanligtvis 30 till 90 dagar).
  • Meddelande till underbiträden. En lista över nuvarande underleverantörer i avtalet, skriftligt förhandsmeddelande om ändringar och rätt att invända på dokumenterade riskgrunder.
  • Certifieringsunderhåll. Ett åtagande att upprätthålla angivna certifieringar (ISO 42001, ISO 27001, SOC 2) under kontraktsperioden, med meddelande om någon certifiering upphör att gälla eller omfattningen ändras.

Dessa klausuler bör vara risknivåindelade. En leverantör av grundläggande modeller i en kundorienterad beslutsfattande pipeline garanterar varje klausul; ett internt produktivitetsverktyg med låg risk kan köras på en enklare uppsättning med övervakade förnyelser.

Hur övervakar ni AI-leverantörer efter kontrakt?

Due diligence vid onboarding är nödvändigt men inte tillräckligt. AI-leverantörer förändras, och det gör även din användning av dem. Kontinuerlig övervakning behöver kombinera schemalagda omvärderingar med händelsedrivna triggers.

Schemalagda aktiviteter som bör finnas i din AI-leverantörs övervakningskalender:

  • Årlig due diligence för högriskleverantörer, två gånger per år för medelhög risk, täcker samma nio områden som onboarding med en deltagranskning
  • Kvartalsvis granskning av leverantörsmodell, underleverantörs- och policyändringsloggar mot din fastställda baslinje.
  • Årlig granskning av leverantörens ISO 42001-, ISO 27001- och SOC 2-certifikat och omfattningsbeskrivningar
  • Granskning av leverantörspublicerade incident- och transparensrapporter (där sådana finns) vid varje ledningsgranskningscykel
  • Omgranskning av leverantörsavsnittet i din Förklaring om tillämplighet närhelst leverantörens omfattning väsentligt ändras

Händelsedrivna utlösare som bör tvinga fram en omedelbar omvärdering:

  • En leverantör meddelar dig om en väsentlig modelländring, ett byte av underleverantör eller en policyändring
  • Leverantören drabbas av en offentligt avslöjad säkerhets-, trygghets- eller partiskhetsincident
  • Leverantören förlorar, ändrar omfattningen av eller misslyckas med att förnya en tillförlitlig certifiering
  • Du ändrar användningsfallet för AI (till exempel flyttar ett internt verktyg till ett kundorienterat arbetsflöde eller en högriskkontext enligt EU:s AI-lag)
  • En ny förordning, sektorvägledning eller verkställighetsåtgärd ändrar dina skyldigheter som distributionsföretag väsentligt.

Varje övervakningsaktivitet bör producera bevis kopplade till leverantörsregister, relevanta kontroller i bilaga A och de AI-riskregisterposter som leverantören bidrar till. Så här förvandlar du leverantörstillsyn från en upphandlingsritual till granskningsbar styrning.




ISMS.onlines kraftfulla instrumentpanel

En av våra introduktionsspecialister kommer att guida dig genom vår plattform för att hjälpa dig komma igång med självförtroende.




Hur förändrar EU:s AI-lag AI-leverantörers skyldigheter?

Ocuco-landskapet EU:s AI-lag skapar en strukturerad uppsättning skyldigheter som följer AI-leveranskedjan. Om du distribuerar ett AI-system med hög risk, eller en leverantör som bäddar in en tredjepartsmodell, blir dina leverantörsval val av efterlevnad.

Viktiga konsekvenser nedströms för tillsyn av AI-leverantörer:

  • Leverantörsskyldigheter når dina leverantörer. Leverantörer av generella AI-modeller (GPAI) har sina egna skyldigheter gällande teknisk dokumentation, sammanfattningar av träningsdata, upphovsrättspolicy och (för systemiska riskmodeller) kontradiktorisk testning, incidentrapportering och cybersäkerhet. Du bör be leverantörer av grundläggande modeller att visa hur de uppfyller dessa skyldigheter.
  • Distributörens skyldigheter når dig. Om du använder ett AI-system med hög risk har du skyldigheter gällande mänsklig tillsyn, logglagring, övervakning, incidentrapportering och (i många fall) en konsekvensbedömning av grundläggande rättigheter. För att uppfylla dessa krav krävs information från leverantören, vilket måste avtalas.
  • Informationsflödet neråt i kedjan. Leverantörer måste förse driftsättarna med den tekniska dokumentation och bruksanvisning som behövs för att uppfylla deras skyldigheter. Din due diligence-analys bör verifiera att detta material faktiskt finns för alla AI-komponenter med hög risk som du anskaffar.
  • Betydande modifieringsrisk. Om du finjusterar, omarbetar eller omformar en allmän modell till den grad att den behöver modifieras väsentligt, kan du bli en egen leverantör – med den därmed sammanhängande bördan av överensstämmelsebedömning. Leverantörsavtal måste tydliggöra vilka modifieringar som är och inte är tillåtna, och vilka garantier som följer med dem.
  • Förbjudna metoder. Vissa AI-användningar (social scoring, oriktade ansiktsskrapningar, känslomässig inledning på arbetsplatser och i utbildningsväsendet, med mera) är förbjudna. Er AI-policy och leverantörsbedömning måste granska användningsfall mot dessa förbud innan avtal ingås, inte efteråt.

ISO 42001 och EU:s AI-lag kompletterar varandra. Standarden ger dig ledningssystemet för byggnadsställningar; lagen definierar de rättsliga skyldigheter som byggnadsställningar har. En välskött leverantörstillsynsprocess tjänar båda.

Hur ISMS.online driver AI-leverantörsriskhantering

ISMS.online ger AI-leverantörsövervakning ett strukturerat hem i ditt bredare AI-hanteringssystem. Istället för att sprida leverantörsdata över upphandlingsblad, säkerhetsfrågeformulär, juridiska mappar och regelefterlevnadsspårare, konsoliderar plattformen livscykeln i en sammankopplad arbetsyta:

  • Leverantörsregister med AI-specifika fält. Varje AI-leverantör har en post med leverantörstyp (grundmodell, AI SaaS, inbäddad AI, datamärkning), användningsfall, risknivå, certifieringar, underleverantörer och relevanta kontrollänkar enligt bilaga A.
  • AI due diligence frågeformulär. Färdiga mallar som täcker de nio bedömningsområdena, med poängsättning, godkännande och lagrade bevis bifogade till leverantörsregisteret.
  • Kontrakts- och klausuluppföljning. Viktiga AI-klausuler (revisionsrättigheter, meddelande om modelländring, dataanvändning, incident-SLA, avslut) spåras som fält i leverantörsposten, så att du kan rapportera om din AI-tillgång med en snabb blick.
  • Löpande övervakning av arbetsflöden. Schemalagda omvärderingar, aviseringar om certifikatutgång, granskningar av ändringsloggar och utlösarbaserade omvärderingar, allt kopplat till leverantörsposten och till AI-riskregistret.
  • Länkade risk- och konsekvensbedömningar för AI. Leverantörsposter kopplas direkt till AI-riskregisterposter (klausul 6.1.2) och konsekvensbedömningar av AI-system (klausul 6.1.4), så leverantörsrisk behandlas som en del av den övergripande AI-riskbilden, inte ett parallellt universum.
  • Revisionsbevis på kontrollnivå. Varje bedömning, granskning och omvärdering producerar bevis kopplade till den specifika kontroll enligt bilaga A som den stöder, redo för övervakningsrevisioner.

Det praktiska resultatet: när en revisor frågar hur ni uppfyller bilaga A.10 för er AI-leveranskedja, är svaret en enda detaljerad granskning – leverantör, bedömning, kontrakt, övervakningshistorik, bevis – inte en vecka med skärmdumpar och kalkylblad.

Varför välja ISMS.online för AI-leverantörsrisk?

ISMS.online är byggd för AI-styrning från början till slut, så leverantörsövervakning är en förstklassig del av plattformen snarare än en påbyggnad. Här är vad du får:

  • AI-specifikt leverantörsregister. Specialbyggda fält för AI-leverantörstyp, användningsfall, risknivå, certifieringar, underleverantörer och modellversioner, inte en generisk leverantörslista som hämtats från ett IT-tillgångsverktyg.
  • Färdiga mallar för AI-due diligence. Frågeformulär anpassade till ISO 42001 bilaga A.10, vägledning i bilaga B och nedströmsskyldigheter enligt EU:s AI-lag, så att teamen börjar från en standardanpassad baslinje snarare än att skriva frågor från grunden.
  • Integrerad med AI-riskregistret. Leverantörsrisker är direkt kopplade till AI-risker (klausul 6.1.2) och konsekvensbedömningar av AI-system (klausul 6.1.4), med poängsättning, behandling och granskningscykler på ett ställe.
  • live Förklaring om tillämplighet. Leverantörsavsnittet i ert SoA förblir aktuellt allt eftersom leverantörer, kontroller och motiveringar ändras, och är inte fryst i ett Word-dokument.
  • Kontinuerlig övervakning inbyggd. Schemalagda omvärderingar, aviseringar om certifikatutgång och händelseutlösta granskningar håller leverantörsövervakningen aktiv under hela kontraktets livscykel.
  • Återanvändning av flera standarder. Leverantörsregister delas mellan ISO 42001 och leverantörskontrollerna i era befintliga ISO-ledningssystem, så att ni kör ett leverantörsprogram, inte flera. För överlappningen, se ISO 42001 vs ISO 27001.
  • Metod med säkrade resultat. Beprövad implementeringsmetod, implementeringsstöd och livehjälp så att tillsynen av AI-leverantörer är igång inom veckor, inte kvartal.

Oavsett om du börjar från noll eller uppgraderar ett befintligt tredjepartsriskprogram till AI-specifika standarder, ISMS.online ger dig verktygen för att hantera risker för AI-leverantörer i enlighet med ISO 42001 och EU:s AI-lag. För fullständig implementeringskontext, se vår implementeringsguide, eller huvud tillbaka till ISO 42001-hubben.

Redo att se plattformen i aktion? Boka demo.

Vanliga frågor

Vad är riskhantering för AI-leverantörer?

Riskhantering för AI-leverantörer är processen att identifiera, bedöma, anlita och övervaka tredjeparter som levererar AI-kapacitet till din organisation. Den omfattar leverantörer av grundläggande modeller, AI-inbyggda SaaS-verktyg, inbäddade AI-funktioner i företagsprogramvara och leverantörer av datamärkning eller utbildningsdata. Den utökar klassisk tredjepartsrisk med AI-specifika överväganden som utbildningsdata, modelltransparens, icke-deterministiskt beteende och ändringshantering av modellviktningar och systemprompter.


Kräver ISO 42001 bedömningar av AI-leverantörer?

Ja. Bilaga A.10 i ISO 42001 behandlar tredjeparts- och kundrelationer direkt och kräver att organisationer identifierar AI-leverantörer, fördelar ansvar och hanterar AI-specifika överväganden under hela leverantörens livscykel. Bilaga B (normativ) ger implementeringsvägledning. Din ISMS.online Tillämplighetsförklaringen bör dokumentera hur ni tillämpar dessa kontroller på era AI-leverantörer, med motiveringar för eventuella undantag.


Vilka är de största varningssignalerna vid en bedömning av AI-leverantörer?

De vanligaste problemen är: utbildning på kunddata som standard utan möjlighet att välja bort, ingen modelldokumentation eller versionskontroll, inga erkända certifieringar (ISO 42001, ISO 27001, SOC 2) eller utgångna, inget AI-specifikt incidentsvar eller SLA för aviseringar, tysta modelländringar utan föregående meddelande, ogenomskinliga arrangemang för underleverantörer och ingen definierad avslutningsprocess. Vilken som helst av dessa bör utlösa ett riskbeslut på högre nivå innan kontrakt undertecknas.


Hur ofta bör vi omvärdera AI-leverantörer?

Årlig omvärdering är en rimlig baslinje för AI-leverantörer med hög risk, med tvåårig granskning för leverantörer med medelhög risk och enklare övervakning för leverantörer med låg risk. Utöver schemat bör händelsedrivna utlösare – väsentlig modell- eller underleverantörsändring, offentliggjort incident, certifieringsförlust, ändrat användningsfall, ny reglering – tvinga fram en omedelbar omvärdering oavsett kalender.


Påverkar EU:s AI-lag våra avtal med AI-leverantörer?

Ja. EU:s AI-lag ställer skyldigheter på leverantörer, driftsättare och importörer av AI-system, och information måste flöda nedåt i kedjan för att dessa skyldigheter ska uppfyllas. Avtal med leverantörer av grundläggande modeller och nedströms AI-leverantörer bör kräva den tekniska dokumentation, bruksanvisningar, transparensinformation och incidentanmälan som behövs för att du ska kunna uppfylla dina skyldigheter som driftsättare eller leverantör. Finjustering eller väsentlig modifiering av en allmän modell kan också omvandla en driftsättare till en leverantör, vilket måste hanteras kontraktuellt.


Räcker det med en ISO 27001-certifierad leverantör för AI-användningsfall?

Nej. ISO 27001 täcker informationssäkerhetshantering och är en stark baslinje, men den tar inte upp AI-specifika risker såsom utbildningsdatas ursprung, modelltransparens, påverkan på berörda individer, partiskhet eller hantering av modelländringar. För väsentliga AI-användningsfall bör du också leta efter ISO 42001 (eller en trovärdig färdplan mot den), SOC 2 Typ II som täcker den AI-tjänst som omfattas, och explicita AI-klausuler i kontraktet som går utöver informationssäkerhetsvillkor.


Kan ISMS.online hantera AI-leverantörsrisker tillsammans med generella leverantörsrisker?

Ja. ISMS.online är en plattform med flera standarder, så AI-leverantörer sitter i samma leverantörsregister som era övriga tredjeparter, med AI-specifika fält, due diligence-mallar och övervakningsarbetsflöden ovanpå. Det innebär ett leverantörsprogram, en uppsättning bevis och en revisionslogg – som täcker ISO 42001 bilaga A.10 och leverantörskontrollerna i era befintliga ledningssystem i en enda vy.



Max Edwards

Max arbetar som en del av ISMS.online-marknadsföringsteamet och ser till att vår webbplats uppdateras med användbart innehåll och information om allt som rör ISO 27001, 27002 och efterlevnad.

Ta en virtuell rundtur

Starta din kostnadsfria 2-minuters interaktiva demo nu och se
ISMS.online i aktion!

plattformsinstrumentpanelen är helt nyskicklig

Vi är ledande inom vårt område

4/5 stjärnor
Användare älskar oss
Ledare - Sommaren 2026
Högpresterande - Sommaren 2026 Small Business UK
Regional ledare - Sommaren 2026 EU
Regional ledare - Sommaren 2026 EMEA
Regional ledare - Sommaren 2026 Storbritannien
Högpresterande - Sommaren 2026 Mellanmarknad EMEA

"ISMS.Online, enastående verktyg för regelefterlevnad"

— Jim M.

"Gör externa revisioner till en lek och länkar ihop alla aspekter av ditt ISMS sömlöst"

— Karen C.

"Innovativ lösning för att hantera ISO och andra ackrediteringar"

— Ben H.