KI og avvikshåndtering i tannhelse

Når KI er involvert i en hendelse, blir “avvik” ofte uklart: Var det en teknisk feil? En feilbruk? En leverandørendring? Et personvernbrudd? Eller en pasientsikkerhetshendelse?

En praktisk måte å tenke på er dette:

KI-relaterte avvik er ikke én avvikstype. Det er en hendelse der KI (eller KI-bruk) er en del av årsakskjeden, og derfor må håndteres gjennom klinikkens eksisterende avvikssystem, men med noen ekstra spørsmål og dokumentasjonskrav.

1) Hva er et KI-relatert avvik?

Et KI-relatert avvik kan være:

• Feil output (f.eks. feil markering på røntgen, feil risikoscore, feil tekstforslag som brukes ukritisk)

• Feil bruk (KI brukt utenfor tiltenkt bruk, eller uten menneskelig kontrollpunkt)

• Uautorisert bruk (“shadow AI”) (ansatte bruker verktøy uten godkjenning)

• Leverandør-/modellendring (oppdatering som endrer oppførsel/ytelse)

• Datahåndtering som avviker (pasientopplysninger delt i ikke-godkjent tjeneste, eller loggføring/lagring som ikke er avklart)

NIST AI RMF vektlegger at AI-risiko må styres kontinuerlig, inkludert å identifisere og følge opp “emergent risks” i drift – altså at risiko kan endre seg etter at løsningen er tatt i bruk. 

2) Tre “spor” du alltid bør vurdere samtidig

Når noe går galt med KI, vurder hendelsen i tre spor (ofte overlapper de):

Spor A: Pasientsikkerhet og faglig kvalitet

• Påvirket KI en klinisk vurdering eller et behandlingsvalg?

• Ble det gjort en feil eller en nesten-feil (“nesten-hendelse”)?

• Var menneskelig kontroll tydelig og faktisk brukt?

Spor B: Personvern og informasjonssikkerhet

• Inneholder hendelsen brudd på personopplysningssikkerheten (f.eks. deling/lekkasje/tilgang)?

• Hvis ja: vurder meldeplikt. Datatilsynet beskriver at brudd normalt skal meldes innen 72 timer, og at man kan melde trinnvis hvis ikke alt er klart. 

• Helsedirektoratets “Normen” peker på samme 72-timers krav når avviket er et brudd på personopplysningssikkerheten. 

Spor C: Styring, leverandør og etterprøvbarhet

• Var verktøyet godkjent, dokumentert og brukt i tråd med interne rammer?

• Har leverandør endret noe (modell, dataflyt, vilkår) uten at klinikken har fanget det opp?

• Finnes det tilstrekkelig logg/dokumentasjon til å forstå hendelsen?

3) En praktisk prosess: “KI-avvik” i 6 steg

Dette kan kjøres som en enkel playbook i klinikken.

Steg 1: Stans og sikre

• Stopp videre bruk i den konkrete situasjonen.

• Sikre nødvendig dokumentasjon: skjermbilder, tidspunkt, hvilken funksjon som ble brukt, hvilken data som ble lagt inn (uten å spre mer pasientdata).

Steg 2: Triage (hvor alvorlig er dette?)

Klassifiser raskt:

• Pasientsikkerhet: skade / potensiell skade / nesten-hendelse / “kun kvalitetsavvik”

• Personvern: inneholder dette et sikkerhetsbrudd? (ja/nei/uklart)

• Omfang: én pasient, flere pasienter, systematisk?

Steg 3: Avgrens og midlertidige tiltak

• Deaktiver funksjon / fjern tilgang / stopp integrasjon ved behov.

• Informer intern rolle (faglig ansvarlig, kvalitet/risk, IT/personvern) etter fast rutine.

Steg 4: Vurder melde- og varslingsbehov

• Ved mulig personvernbrudd: vurder 72-timers melderegel og dokumenter vurderingen. 

• Ved cyber-/IKT-hendelser: NSM anbefaler grunnprinsipper og strukturert hendelseshåndtering som del av virksomhetens sikkerhetsstyring. 

Steg 5: Årsaksanalyse (hva var “svikten” egentlig?)

For KI-hendelser er det ofte nyttig å skille:

• Teknisk svikt (feil i systemet)

• Bruks-/prosessvikt (manglende kontrollpunkt, uklare rutiner)

• Kompetansevikt (feil tolkning av output)

• Endringsvikt (oppdatering uten kontroll)

• Styringsvikt (uautorisert verktøy / manglende godkjenningsløp)

NIST AI RMF Playbook er laget nettopp for å operasjonalisere styring og tiltak på tvers av “Govern–Map–Measure–Manage”, altså fra governance til håndtering i drift. 

Steg 6: Læring og forebygging (kontrollert iterasjon)

• Oppdater policy, opplæring eller verktøylisten.

• Legg inn et kontrollpunkt i arbeidsflyten (f.eks. “KI-output skal alltid vurderes mot X før beslutning”).

• Loggfør endringen i endringslogg (dato, hva, hvorfor, forventet effekt, når evalueres).

4) Hva bør dokumenteres i avviket? (minimum)

For at et KI-avvik skal være etterprøvbart, holder det sjelden med “KI tok feil”.

Minimumsfelt i avviksskjema:

• Hvilket verktøy/funksjon (navn, versjon hvis kjent)

• Bruksformål (hva var hensikten i situasjonen?)

• Input-type (røntgen/foto/tekst/journalutdrag – uten å kopiere inn mer enn nødvendig)

• Output (hva ble vist/foreslått?)

• Menneskelig kontroll: hva gjorde behandler før beslutning?

• Konsekvens (pasient, kvalitet, tid, feilinformasjon)

• Dataflyt: ble pasientopplysninger delt med ekstern tjeneste?

• Midlertidige tiltak og hvem som ble varslet

• Vurdering av meldeplikt (og begrunnelse)

5) Typiske “mønstre” som gir gjentatte KI-avvik

• Uklare rammer for bruk (folk gjetter hva som er lov)

• Ingen definert tolkning av output (“score” uten klinisk brukskontekst)

• Shadow AI som bypasser leverandørvurdering og avtaler

• Oppdateringer uten kontroll (ytelse endrer seg uten at noen følger med)

• For lite opplæring (særlig på begrensninger og feilkilder)

Avslutning

God KI-avvikshåndtering handler ikke om å “straffe teknologi”. Det handler om å gjøre KI-hendelser klassifiserbare, dokumenterbare og lærbare – slik at klinikken kan vise kontroll over pasientsikkerhet, personvern og drift.