AI-leverantörsriskUppdaterad 4 sep 202610 min

AI-leverantörsgranskning: 30 frågor innan ni köper

Ett säkerhetscertifikat och ett personuppgiftsbiträdesavtal räcker inte. AI-due-diligence måste också omfatta modellträning, RAG-behörigheter, agentåtgärder, loggning, modelländringar och exit.

Kort svar

Granska hela tjänstekedjan: användning av kunddata, träning och retention, subprocessors, identitet och åtkomst, isolation, RAG-behörigheter, modell- och funktionsändringar, loggning, incident response, robusthet, export/radering och regulatorisk roll. Djupet ska motsvara datakänslighet och konsekvens.

DataVet vad som samlas in, återanvänds, flyttas, sparas och raderas.
KontrollKräv identitet, behörigheter, loggning och change management.
EvidensAvtalslöften ska kunna verifieras tekniskt och operativt.

Data och modellträning

  1. Används kunddata för träning, finetuning eller modellförbättring som standard?
  2. Kan detta stängas av både avtalsmässigt och tekniskt?
  3. Vilka data samlas utöver prompts och outputs — metadata, filer, embeddings, feedback eller tool traces?
  4. Vilka retention-perioder gäller för prompts, outputs, filer, loggar och backups?
  5. Hur sprids radering till backups, embeddings och härledda artefakter?

Geografi och subprocessors

  1. Var lagras och behandlas data, inklusive inference, support och loggning?
  2. Vilka subprocessors kan få tillgång till information?
  3. Hur meddelas förändringar i subprocessors?
  4. Hur hanteras relevanta internationella överföringar?

Identitet, åtkomst och tenant isolation

  1. Stöds SSO, MFA och automatisk provisioning/deprovisioning?
  2. Kan roller begränsa administration, connectors, datakällor, modeller och delning?
  3. Hur implementeras och testas tenant isolation?
  4. Kan administratörer begränsa offentliga länkar, extern delning, plugins och unmanaged tools?
  5. Är privilegierad supportåtkomst kontrollerad och loggad?

RAG, connectors och agentåtgärder

  1. Bevarar retrieval behörigheter från källsystemet?
  2. Hur skyddas och raderas embeddings och vector indexes?
  3. Vilka kontroller reducerar direkt och indirekt prompt injection?
  4. Är tool calls begränsade med least privilege, allowlists och mänskligt godkännande för viktiga åtgärder?
  5. Visas källor så att användaren kan verifiera väsentliga svar?

Loggning och incidenter

  1. Vilka events loggas: login, adminändringar, delning, connector-aktivitet, policy blocks och tool calls?
  2. Kan loggar exporteras till organisationens SIEM?
  3. Hur upptäcks missbruk, account compromise och dataläckage?
  4. Vilka incident-notification-frister gäller?
  5. Vilken investigation evidence levereras efter en incident?

Förändringar, robusthet och exit

  1. Kan leverantören ändra modell, säkerhetsbeteende eller datavillkor utan godkännande?
  2. Hur kommuniceras modell/version changes?
  3. Vilka availability-, backup- och recovery-åtaganden gäller?
  4. Kan organisationen exportera relevant data, konfiguration, knowledge sources och loggar?
  5. Hur verifieras radering vid avslut?
  6. Vilken AI Act-roll har varje part i det konkreta use caset?

Använd risknivåer

NivåExempelGranskning
LågPublik information utan känsliga dataGrundvillkor, data, identitet och acceptable use
ModeratIntern knowledge assistantFull data-, RAG-, logg- och säkerhetsgranskning
HögAI som påverkar anställning, åtkomst, säkerhet eller rättigheterJuridisk klassificering, djup arkitekturgranskning, impact assessment och human oversight

ISO/IEC 27001 och SOC-rapporter kan ge värdefull assurance men besvarar inte ensamma AI-specifika frågor om modellträning, RAG-behörigheter, agentic tooling eller förändringar i underliggande modeller.

Primära referenser

En governance- och säkerhetsbaseline, inte juridisk rådgivning eller ersättning för teknisk testning.

Behöver ni en fokuserad AI-leverantörsgranskning?

SundAI kombinerar AI-styrning med säkerhetsarkitektur och leverantörsrisk.

Se AI-säkerhetsbedömning →
← Alla insikterNästa: säker RAG →