AI-leverandørrisikoOpdateret 4. sep. 202610 min.

AI-leverandørreview: 30 spørgsmål før I køber

Et sikkerhedscertifikat og en databehandleraftale er ikke nok. AI-due-diligence skal også dække modeltræning, RAG-rettigheder, agent-handlinger, logning, modelændringer og exit.

Kort svar

Gennemgå hele servicekæden: brug af kundedata, træning og retention, subprocessors, identitet og adgang, isolation, RAG-rettigheder, model- og featureændringer, logging, incident response, robusthed, eksport/sletning og den regulatoriske rolle. Dybden skal afspejle datafølsomhed og konsekvens.

DataVid hvad der indsamles, genbruges, flyttes, bevares og slettes.
KontrolKrav om identitet, rettigheder, logning og ændringsstyring.
EvidensKontraktpåstande skal kunne verificeres teknisk og operationelt.

Data og modeltræning

  1. Bruges kundedata til træning, finetuning eller forbedring af modeller som standard?
  2. Kan dette deaktiveres både kontraktuelt og teknisk?
  3. Hvilke data indsamles ud over prompts og outputs — metadata, filer, embeddings, feedback eller tool traces?
  4. Hvad er retention-perioden for prompts, outputs, filer, logs og backups?
  5. Hvordan propagere sletning til backups, embeddings og afledte artefakter?

Geografi og subprocessors

  1. Hvor lagres og behandles data, inkl. inference, support og logging?
  2. Hvilke subprocessors kan få adgang til information?
  3. Hvordan varsles ændringer i subprocessors?
  4. Hvordan håndteres relevante internationale overførsler?

Identitet, adgang og tenant isolation

  1. Understøtter løsningen SSO, MFA og automatisk provisioning/deprovisioning?
  2. Kan roller begrænse administration, connectors, datakilder, modeller og deling?
  3. Hvordan implementeres og testes tenant isolation?
  4. Kan administratorer begrænse offentlige links, ekstern deling, plugins og unmanaged tools?
  5. Er privilegeret supportadgang kontrolleret og logget?

RAG, connectors og agent-handlinger

  1. Bevarer retrieval rettigheder fra kildesystemet?
  2. Hvordan beskyttes og slettes embeddings og vector indexes?
  3. Hvilke kontroller reducerer direkte og indirekte prompt injection?
  4. Er tool calls afgrænset med least privilege, allowlists og menneskelig godkendelse ved væsentlige handlinger?
  5. Vises kilder, så brugeren kan verificere vigtige svar?

Logging og incidents

  1. Hvilke events logges: login, adminændringer, deling, connector-aktivitet, policy blocks og tool calls?
  2. Kan logs eksporteres til organisationens SIEM?
  3. Hvordan detekteres misbrug, account compromise og datalæk?
  4. Hvilke incident-notification-frister er aftalt?
  5. Hvilken investigation evidence leveres efter en hændelse?

Ændringer, robusthed og exit

  1. Kan leverandøren ændre model, sikkerhedsadfærd eller datavilkår uden godkendelse?
  2. Hvordan kommunikeres model/version changes?
  3. Hvilke availability-, backup- og recovery-forpligtelser gælder?
  4. Kan organisationen eksportere relevante data, konfiguration, knowledge sources og logs?
  5. Hvordan verificeres sletning ved ophør?
  6. Hvilken AI Act-rolle har hver part i det konkrete use case?

Brug et risikoniveau

NiveauEksempelReview
LavOffentlig information uden følsomme dataBasisvilkår, data, identitet og acceptable use
ModeratIntern knowledge assistantFuldt data-, RAG-, logging- og security-review
HøjAI med indflydelse på ansættelse, adgang, sikkerhed eller rettighederJuridisk klassifikation, dyb arkitekturreview, impact assessment og human oversight

ISO/IEC 27001 og SOC-rapporter kan give værdifuld assurance, men besvarer ikke alene AI-specifikke spørgsmål om modeltræning, RAG-rettigheder, agentic tooling eller ændringer i underliggende modeller.

Primære referencer

En governance- og sikkerhedsbaseline, ikke juridisk rådgivning eller erstatning for teknisk test.

Har I brug for et fokuseret AI-leverandørreview?

SundAI kombinerer AI-governance med sikkerhedsarkitektur og leverandørrisiko.

Se AI-sikkerhedsvurdering →
← Alle indsigterNæste: sikker RAG →