Amerikansk AI i banksektoren: hvad der faktisk gælder
Ja, der er intet kategorisk forbud mod at en bank bruger amerikansk AI. Men banken skal dokumentere data residency, overførselsmekanisme og kæden af underdatabehandlere, og alle fire store leverandører hører i sidste ende under amerikansk jurisdiktion. Bruges AI-output i kreditvurdering, bliver systemet højrisiko, og så gælder forpligtelserne i artikel 26.
Det er finanssektorens mest almindelige indvending: “Vi er en bank, vi må vel ikke bruge amerikansk AI?” Det korte svar er at der ikke findes noget kategorisk forbud. Det ærlige svar er at der er en række krav der skal være opfyldt og dokumenteret og at kreditvurdering er et særtilfælde der ændrer hele billedet.
Grundsvaret: et betinget ja
Ingen regel siger ligeud at en bank ikke må bruge amerikansk AI. Men retten til det er betinget. Banken skal kunne dokumentere tre ting:
- Data residency: hvor data faktisk lagres og behandles.
- Overførselsmekanisme: på hvilket retsgrundlag data eventuelt overføres til et tredjeland.
- Kæden af underdatabehandlere: hele rækken af parter der rører ved data.
Og én grundforudsætning gælder uanset leverandør: Alle fire store leverandører hører i sidste ende under amerikansk jurisdiktion. Det kan ikke vælges fra, kun håndteres: via hvor inferensen sker, hvilke nøgler I selv har og hvordan overførslen er analyseret.
Branchens skærpelse: kreditvurdering
Her bliver det bankspecifikt. Kreditvurdering er et tilfælde under bilag III i AI-forordningen. Det betyder at hvis AI-output bruges i kreditbeslutninger, klassificeres systemet som højrisiko, og så gælder idriftsætterens forpligtelser i artikel 26.
Det afgørende er at det gælder uanset hvordan værktøjet blev solgt. Et værktøj der er markedsført som en generel produktivitetshjælp, bliver et højrisikosystem i det øjeblik dets output påvirker en kreditbeslutning. Det er anvendelsesområdet der styrer risikoklassen, ikke produktbladet. Mange banker opdager det sent når et “hjælpemiddel” viser sig at være gledet ind i en beslutningskæde.
Den operationelle risiko der undervurderes
Ud over det juridiske er der en praktisk kollision som er let at overse: korte udfasningsvinduer over for formel genvalidering.
En bank kan ikke skifte model fra den ene dag til den anden. Hver ny model skal valideres efter interne processer. Men leverandøren kan udfase en model hurtigere end valideringen kan nå at blive færdig. Resultatet er et hul hvor banken enten kører videre på en udfaset model eller bliver tvunget til at tage en uprøvet model i brug.
Modtrækket er at køre parallelle modelversioner under genvalideringen. Så kan den gamle model leve videre indtil den nye er godkendt, i stedet for at en udfasningsdato tvinger et skifte igennem som compliance ikke har nået at gennemgå.
Forestil dig at leverandøren varsler at den model I har valideret, udfases om nogle uger. Jeres interne genvalidering af afløseren tager længere tid end det. Uden forberedelse står I over for et umuligt valg: at køre videre på noget der snart ikke understøttes, eller at lukke en model ind som endnu ikke har bestået jeres kontrol. Med parallelle versioner og en testet reservevej bliver samme besked håndterbar: I migrerer i jeres eget tempo i stedet for i leverandørens.
Pakken af risikoreducerende tiltag
Samlet set er der en pakke tiltag der gør et “ja” forsvarligt:
| Tiltag | Hvad det sikrer |
|---|---|
| EU-inferens via aktiv konfiguration | At behandlingen faktisk sker inden for EU, ikke kun på papiret |
| Kundekontrollerede nøgler | At banken bevarer kontrollen over krypteringen |
| Dokumenteret TIA- eller DPF-analyse | At overførslen er analyseret og begrundet |
| Testet reserveleverandør | Kontinuitet hvis hovedleverandøren falder bort |
Pointen med pakken er at kunne vise kontrol: hvor data behandles, hvem der har nøglerne, hvorfor overførslen er lovlig og hvad der sker hvis leverandøren forsvinder. Det er den dokumenterede kontrol, ikke leverandørens oprindelse i sig selv, som en gennemgang vurderer.
Hvad der afgør om beslutningen holder
For en bank er det ikke nok at tiltagene findes. De skal kunne fremvises i den rækkefølge et tilsyn eller en intern revision spørger efter dem. Det praktiske beslutningskriterium bliver derfor: Kan vi for hvert AI-dataflow pege på hvor data behandles, hvilken overførselsmekanisme der gælder, hele kæden af underdatabehandlere og vores plan hvis leverandøren falder bort? Kan I det, er beslutningen forsvarlig. Kan I det kun for nogle af dataflowene, er det dér arbejdet ligger.
To faldgruber er særligt almindelige i finanssektoren. Den første er at behandle AI som et IT-værktøj og overse at anvendelsesområdet kan gøre det til et højrisikosystem. Kreditvurderingen er det tydeligste eksempel, men lignende logik gælder for andre beslutninger der vedrører kunder. Den anden er at glemme kontinuiteten: Et kort udfasningsvindue der støder sammen med en formel genvalidering, kan tvinge et skifte igennem som banken ikke har nået at godkende hvis der ikke er parallelle versioner og en testet reserve på plads.
At veje disse spørgsmål op mod hinanden i en reguleret organisation er krævende, og det rigtige svar afhænger af bankens konkrete situation. Vil I have en sparringspartner til at strukturere indførelsen af AI, kan du læse om vores AI-tjenester eller kontakte os. Denne side er beslutningsstøtte, ikke juridisk rådgivning. En endelig beslutning bør afstemmes med jeres compliancefunktion.
Ofte stillede spørgsmål
Er det forbudt for banker at bruge amerikansk AI?
Nej, der er intet kategorisk forbud. Men banken skal kunne dokumentere data residency for lagringen, hvilken overførselsmekanisme der gælder, og hele kæden af underdatabehandlere. Og alle fire store leverandører hører i sidste ende under amerikansk jurisdiktion, hvilket skal håndteres snarere end ignoreres.
Hvorfor er kreditvurdering særligt følsomt?
Kreditvurdering er et tilfælde under bilag III. Bruges AI-output dér, bliver systemet højrisiko efter AI-forordningen, og idriftsætterens forpligtelser i artikel 26 gælder, uanset at værktøjet blev markedsført som en produktivitetshjælp. Det er anvendelsesområdet og ikke etiketten på produktet der afgør risikoklassen.
Hvad er den største operationelle risiko?
At korte udfasningsvinduer støder sammen med formel genvalidering. En model kan blive udfaset hurtigere end bankens gennemgang kan nå at godkende en afløser. Løsningen er at køre parallelle modelversioner under genvalideringen så en igangværende validering ikke tvinger et uprøvet skifte igennem.
Hvilke tiltag reducerer risiciene?
En pakke af risikoreducerende tiltag: EU-inferens via aktiv konfiguration, kundekontrollerede nøgler, en dokumenteret TIA- eller DPF-analyse af overførslen og en testet reserveleverandør. Tilsammen gør de at banken kan vise kontrol over hvor data behandles og hvad der sker hvis leverandøren falder bort.
Er denne side juridisk rådgivning?
Nej. Siden er beslutningsstøtte der beskriver de spørgsmål og krav I skal håndtere, ikke formel juridisk rådgivning. En faktisk AI-beslutning i en bank bør afstemmes med jeres compliancefunktion og jeres juridiske ekspertise ud fra jeres konkrete situation.