20 min

    AI-resiliens i bank før EBA samordner tilsynet i 2027

    EBA klassifiserer AI i kredittvurdering som høyrisiko og samordner tilsynet i 2026 og 2027. Slik kartlegger norske banker AI-avhengighetene sine og bygger fallback som holder.

    Bransje & SektorAI-resiliens i bankAI Act bankAI-risiko i finanssektorenkredittvurdering med AIfallback i AI-arkitekturGenAI i bankAI i norske banker
    AI-resiliens i bank før EBA samordner tilsynet i 2027

    Nøkkelpunkter per 10. september 2026:

    • Kredittvurdering av privatpersoner er høyrisiko under AI Act, som trådte i kraft i august 2024, med krav til styring, dokumentasjon og menneskelig kontroll (EU-kommisjonen, 2025).
    • EBA fant ingen betydelige motsetninger mellom AI Act og eksisterende banklovgivning, men vil fremme felles tilsynstilnærming i 2026 og 2027 (EU-kommisjonen, 2025).
    • 86 prosent av finansbedriftene øker AI-budsjettet i 2026, mens styring og dokumentasjon sjelden skaleres i samme tempo (alura.no, 2026).
    • Flaskehalsen er kulturell, ikke teknisk: kun et mindretall av lederne stoler på at automatiserte beslutninger kan operere selvstendig (PwC).
    • Det norske finanssystemet er dominert av banker, som gjør leverandørkonsentrasjon i AI til et spørsmål om finansiell stabilitet (Norges Bank).

    Hva AI-resiliens betyr i bank i dag

    AI-resiliens er bankens evne til å levere kritiske tjenester videre når en modell, en leverandør eller et API svikter, og samtidig kunne dokumentere hvordan beslutningene ble tatt underveis. I bankvirksomhet har resiliens historisk betydd regulatorisk kapital, stresstesting og risikostyringsdisiplin, men avhenger i dag også av digital modenhet (PwC). Forskjellen er praktisk: kapitalkrav måles i kroner, mens AI-avhengighet måles i hvor mange prosesser som stopper hvis en tredjepart har en dårlig dag.

    Definisjonen er operativ, ikke filosofisk. Den kan besvares med et register, en test og en logg. Alura mener AI-resiliens hører hjemme i operasjonell risikostyring, ikke i et frittstående IT-prosjekt, fordi det er der banken allerede har språket, rapporteringslinjene og revisjonssporet som tilsynet forventer å finne.

    Fra kapitaldekning til digital smidighet

    Resiliens i finanssektoren handler ikke lenger bare om å forberede seg på neste nedgang eller neste regulatoriske eksamen, men om digital smidighet (PwC). Det er et skifte i hva som faktisk er sårbart. En bank med solid kjernekapital kan fortsatt stanse kredittbehandlingen i et døgn fordi en modelltjeneste er utilgjengelig. AI og intelligent automatisering er ikke lenger perifere teknologier i finanssektoren, men omformer bransjens fundament, og da flytter risikoen seg fra balansen til driften.

    Tre spørsmål som avgjør om dere er resiliente

    Det første: hvilke prosesser stopper hvis en bestemt modelltilbyder er nede i åtte timer? Det andre: kan dere rekonstruere hvorfor en kunde fikk avslag for et halvt år siden, med den modellversjonen som faktisk kjørte da? Det tredje: hvem tar beslutningen manuelt når automatikken kobles ut, og har de kapasitet til det? En bank som ikke kan svare presist på alle tre, har ikke et teknologiproblem, men et styringsproblem.

    AI-resiliens er ikke det samme som AI-sikkerhet

    Sikkerhet handler om å hindre at noe uønsket skjer: datalekkasje, promptinjeksjon, uautorisert tilgang. Resiliens handler om hva som skjer etterpå, når noe uønsket likevel har skjedd. De to henger sammen, men de eies ofte av ulike miljøer og måles på ulike ting. Banker som slår dem sammen i et felles «AI-prosjekt» ender typisk med et sikkerhetsregime uten fallback, eller en fallback ingen har testet. Vi har beskrevet den samme grenseoppgangen for datakontroll i Samsung-saken.

    Rammeverk for å kartlegge AI-avhengigheter

    Kartleggingen er den billigste delen av arbeidet og den som oftest hoppes over. Alura mener dere skal kartlegge avhengigheter til modeller og leverandører før dere skalerer bruken, ikke etterpå, av en enkel grunn: etter skalering er registeret et arkeologisk prosjekt, mens det før skalering er en halv dags arbeid per bruksområde.

    Felt i avhengighetsregisteretHva det skal fangeHvorfor det betyr noe
    BruksområdeKonkret prosess, ikke «kundeservice»Klassifisering under AI Act følger bruken, ikke teknologien
    Modell og versjonLeverandør, modellnavn, versjonsstrengUten versjon kan ikke en beslutning rekonstrueres
    LeverandørkjedeAPI-tilbyder, skyplattform, mellomleddAvdekker skjult konsentrasjon på ett punkt
    Konsekvens ved bortfallHva som stopper, og for hvemRangerer hva som trenger fallback først
    FallbackManuell, regelbasert eller alternativ modellGjør resiliens til noe testbart
    EierNavngitt forretningseier, ikke en avdelingAnsvar som ikke kan fordampe i en omorganisering

    Klassifiser etter konsekvens, ikke etter teknologi

    En stor språkmodell som skriver utkast til interne notater og en stor språkmodell som scorer kredittsøknader er samme teknologi og helt ulik risiko. AI-systemer for kredittvurdering av fysiske personer er klassifisert som høyrisiko under AI Act (EU-kommisjonen, 2025). Registeret må derfor sortere på hva systemet brukes til og hvem det treffer, ikke på hvilken modell som ligger under. Banker som sorterer på leverandør får et innkjøpsdokument, ikke et risikodokument.

    Konsentrasjonsrisiko mot noen få leverandører

    Markedet for grunnmodeller er smalt, og korrelert nedetid er ikke et teoretisk scenario: ChatGPT, Grok og Claude har vært nede samtidig (The Verge). For en bank betyr det at «vi har en alternativ leverandør» ikke er et svar hvis begge kjører på samme underliggende infrastruktur. Kartlegg derfor ikke bare hvem dere kjøper fra, men hvor tjenesten faktisk kjører. Redundans som deler feilpunkt er ikke redundans.

    Modellkjeden er lengre enn de fleste tror

    Et typisk bruksområde involverer en modelltilbyder, en skyplattform, et vektordatabaselag, et orkestreringsbibliotek og et internt API. Hvert ledd har egen tilgjengelighet, egne vilkår og egen evne til å endre atferd uten varsel. En modelloppgradering hos leverandøren kan flytte utfallet i en scoringsmodell uten at noe i banken er endret. Registeret bør derfor notere om dere kjører mot en pinnet versjon eller mot et alias som oppdateres av andre. Det skillet avgjør om dere i det hele tatt kontrollerer egen modellrisiko.


    Les også: AI-pipelines i norske banker: stresstest mot AI Act. Fra 2.


    Praktisk: fra inventar til testet fallback

    Dette er arbeidet som faktisk kan starte på mandag, uten budsjettvedtak og uten ny plattform. Rekkefølgen er viktigere enn verktøyet: inventar, klassifisering, fallback, test, dokumentasjon. Banker som starter med verktøyvalg ender med et pent register over feil ting.

    Uke en: finn alt som allerede kjører

    Begynn med fakturaer og tilgangslogger, ikke med spørreskjema. Innkjøp vet hvilke AI-abonnementer som betales, identitetsplattformen vet hvem som logger inn hvor, og nettverksloggene viser hvilke API-er som kalles fra bankens miljøer. Skyggebruk avdekkes raskere av en utgiftsrapport enn av en rundspørring. Målet i første runde er ikke fullstendighet, men å få de kritiske prosessene på plass i registeret med navngitt eier.

    Definer fallback for hvert kritisk bruksområde

    Fallback i AI-arkitektur er ikke det samme som en reservemodell. For noen prosesser er svaret en enklere regelmotor, for andre er det en kø til et menneske, og for noen er det å stanse tjenesten kontrollert med tydelig kundekommunikasjon. Alura mener modeller som brukes i kredittvurdering trenger en definert manuell fallback, fordi alternativet er at banken enten stanser kredittgivningen eller lar en utestet reservemodell ta beslutninger den aldri er validert for.

    BruksområdeRisikoprofilFallback ved modellsviktDokumentasjonsbehov
    Kredittvurdering av privatpersonerHøyrisiko under AI ActManuell saksbehandling med definert kapasitetFullt: versjon, data, logg, menneskelig kontroll
    SvindeldeteksjonKritisk driftRegelbasert terskelmotorHøyt: terskler, treffrate, etterkontroll
    Kundesenter og chatKundeeksponertKø til agent, redusert selvbetjeningMiddels: eskaleringsregler, samtalelogg
    Interne rutiner og rapportutkastLavManuell utforming som førLavt: bruksveiledning og kildekontroll
    Kodeassistanse i utviklingLav til middelsUtvikling uten assistanseMiddels: gjennomgangskrav før merge

    Test fallbacken, ikke planen

    En fallback som aldri har vært kjørt i produksjon er en hypotese. Sett av et vindu, koble ut modelltjenesten for et avgrenset bruksområde og mål hva som faktisk skjer: hvor lang tid tar omkoblingen, hvor mange saker hoper seg opp, og oppdager kundene det. Banker er vant til denne øvelsen fra beredskapstester av betalingssystemer, og AI-avhengigheter fortjener samme behandling. Dokumenter resultatet, inkludert det som gikk galt. Testrapporten er selve beviset på resiliens, ikke prosedyredokumentet.

    Lavrisiko-bruksområder gir raskest resiliens

    Tidlige brukere lykkes ved å starte med veldefinerte lavrisiko-bruksområder som utkast til interne retningslinjer, generering av rutinerapporter eller automatisering av administrative oppgaver (PwC). Poenget er ikke at disse gir størst gevinst, men at de gir banken en fungerende styringsmodell før innsatsen blir høy.

    Hva som kvalifiserer som lavrisiko i praksis

    Et bruksområde er lavrisiko når feil oppdages av et menneske før det får konsekvenser, når ingen kunde påvirkes direkte, og når prosessen kan utføres manuelt uten dramatikk. Interne rutinebeskrivelser, møtereferater, oppsummering av regelverksendringer og førsteutkast til standardrapporter treffer alle tre kriteriene. Kredittbeslutninger gjør det ikke, uansett hvor godt modellen presterer i test. Skillet er verdt å skrive ned eksplisitt, fordi det er der diskusjonen med revisjon starter.

    Bygg dokumentasjonen fra første leveranse

    Alura mener dere skal starte med lavrisiko-bruksområder og bygge dokumentasjonen fra første leveranse. Grunnen er kostnad: å dokumentere et system i drift krever at noen rekonstruerer valg som ble tatt for et år siden, ofte av folk som har byttet jobb. Å dokumentere mens dere bygger koster noen timer per leveranse. Når høyrisikosystemet kommer, har banken da allerede en mal, en eier og et sted å legge det. Regulatorer signaliserer allerede forventninger om klar dokumentasjon, robust styring og evne til å demonstrere ansvarlig bruk (PwC).

    Markedsbildet: budsjettene vokser raskere enn styringen

    86 prosent av finansbedriftene øker AI-budsjettet i 2026 (alura.no, 2026). Samtidig oppgir 58 prosent av CFO-ene at de investerer i AI og avansert analyse (PwC). Pengene er der. Spørsmålet er om styringsapparatet vokser i samme takt, og der er svaret i de fleste banker nei.

    Bruksområde nevnt av bankledereAndelTypisk risikoklasse
    Augmentering av kunnskapsarbeidere55 %Lav til middels
    Sanntids overvåking av samtaler52 %Middels, personopplysninger
    Generering av syntetiske data46 %Middels, modellvalidering
    Automatisering av compliance36 %Høy, tilsynseksponert

    GenAI i bank er ikke lenger et pilotspørsmål

    Ifølge Gartner rapporterte 75 prosent av bankledere i 2024 at de hadde implementert eller var i ferd med å implementere GenAI (devoteam.com, 2025). Når tre av fire allerede er i gang, er den interessante variabelen ikke adopsjon, men hvor mange som kan redegjøre for hva de har koblet på. Fordelingen av bruksområder over viser hvorfor: compliance-automatisering er minst utbredt, men mest tilsynseksponert, og den andelen kommer til å øke.

    Modellene blir mer spesialiserte, og avhengigheten dypere

    Gartner spår at over 50 prosent av GenAI-modellene vil være bransje- eller funksjonsspesifikke innen 2027 (devoteam.com, 2025). Spesialisering gir bedre treffsikkerhet og dårligere byttemulighet. En generisk modell kan erstattes av en annen generisk modell på en ettermiddag. En bransjespesifikk modell med finjustering på bankens egne data kan ikke det. Dette er en innelåsingsrisiko som hører hjemme i leverandørvurderingen før kontrakten signeres, ikke i en fornyelsesdiskusjon tre år senere.

    Kostnad og gevinst i svindeldeteksjon og kundesenter

    De to bruksområdene der bankene har mest dokumentert erfaring er svindeldeteksjon og kundedialog. Begge er interessante for resiliens, fordi de er kontinuerlige tjenester der bortfall merkes umiddelbartt av kunden eller av risikoavdelingen.

    Gevinsten i svindeldeteksjon ligger i færre falske positiver

    AI-drevet svindeldeteksjon kan redusere falske positiver med 50-70 prosent sammenlignet med regelbaserte systemer (alura.no, 2026). Det er en kostnadsgevinst i to lag: færre manuelle undersøkelser, og færre kunder som får kortet sperret på feil grunnlag. Baksiden er at den regelbaserte motoren fortsatt må vedlikeholdes hvis den skal fungere som fallback. Banker som lar regelmotoren forfalle etter at modellen er i drift, har byttet ut et system med et annet, ikke lagt et lag på toppen.

    Kundesenter: volumet er argumentet

    En AI-løsning for en stor portugisisk bank behandler nå 2 780 000 samtaler per år, og posttjenesten CTT fikk en 40-poengs økning i NPS etter lanseringen av chatboten «Helena» (devoteam.com, 2025). Tall i den størrelsesorden endrer bemanningsplanen. Da endrer de også fallback-regnestykket: hvis modellen faller ut og alt skal tilbake til agenter, må banken vite hvor mange agenter som faktisk finnes. En fallback som forutsetter en bemanning dere sa opp i fjor, er ikke en fallback.

    Kostnadene som ikke står i lisensprisen

    KostnadspostHvem eier denUndervurderes fordi
    Modellbruk og API-kallTeknologiVolumet vokser med adopsjonen, ikke med budsjettet
    DatatilretteleggingData og forretningLigger ofte i et annet prosjekt
    Validering og modellrisikoRisikostyringKommer først når systemet skal i produksjon
    Dokumentasjon og loggingComplianceRegnes som etterarbeid, ikke som leveranse
    Vedlikehold av fallbackDriftIngen ser verdien før den trengs
    Opplæring og endringsledelseHR og linjeledelseMåles ikke i prosjektregnskapet

    Devoteams eget markedsføringsmateriale oppgir at over 80 prosent av AI-prosjekter mislykkes, samtidig som gjennomsnittlig avkastning for GenAI-prosjekter oppgis til rundt 3,7x (devoteam.com, 2025). Begge tallene kommer fra en leverandør med interesse i konklusjonen, og bør leses deretter. Det nyttige i dem er spredningen: gevinsten er reell for de som kommer i mål, og de fleste kommer ikke i mål. Kostnadstabellen over forklarer mesteparten av frafallet. For utviklingsverktøy har vi sett samme mønster i token-budsjett.

    AI Act gjør kredittvurdering til høyrisiko

    EUs AI Act trådte i kraft i august 2024, og AI-systemer for kredittvurdering av fysiske personer er klassifisert som høyrisiko (EU-kommisjonen, 2025). For en norsk bank er dette den enkeltavklaringen som får størst praktisk betydning, fordi kredittvurdering er kjernevirksomhet og fordi klassifiseringen følger bruken uansett hvilken modell som ligger under.

    Hva høyrisiko krever av banken i praksis

    Høyrisikoklassifiseringen betyr at systemet må ha et styringsregime rundt seg: risikostyring gjennom hele livsløpet, datakvalitetskrav, teknisk dokumentasjon, logging som muliggjør sporbarhet, informasjon til brukeren og reell menneskelig kontroll. Ingen av delene er fremmed for en bank som allerede driver modellvalidering under kapitalkravsregelverket. Forskjellen er at kravene nå følger bruksområdet, ikke bare kapitalmodellen, og at de treffer systemer som i dag eies av forretningssiden uten formell modellstatus.

    Fristen som allerede er passert

    Europakommisjonen hadde frist til 2. februar 2026 for å utstede retningslinjer om klassifisering av høyrisiko brukstilfeller (EU-kommisjonen, 2025). Banker som ventet på den fristen før de startet kartleggingen, har nå kortere tid enn de hadde planlagt for. Kartleggingen fra EBA må uansett ses i lys av fremtidige retningslinjer og harmoniserte standarder, og utgjør i seg selv verken veiledning eller tilsynsforventninger. Det betyr at usikkerheten i detaljene fortsatt er reell, mens plikten til å vite hva man har er det ikke.

    TidspunktHva som skjerHva banken bør ha klart
    August 2024AI Act trer i kraftOversikt over hvilke AI-systemer som er i bruk
    2025EBA kartlegger AI Act mot sektorlovgivningKlassifisering av egne bruksområder
    2. februar 2026Frist for Kommisjonens retningslinjer om høyrisikoklassifiseringDokumentasjonspakke for kredittmodeller
    2026/2027EBA fremmer felles tilsynstilnærming og samarbeidTestet fallback og logg som tåler ettersyn

    Menneskelig kontroll må være ekte, ikke formell

    En saksbehandler som godkjenner nesten alle modellforslag på et kvarter utøver ikke reell kontroll, uansett hva prosessbeskrivelsen sier. Menneskelig kontroll krever tid, kompetanse og faktisk mulighet til å overprøve. Det koster bemanning, og den kostnaden må stå i businesscasen fra start. Her møtes regelverket og resiliensen: den samme manuelle kapasiteten som gir reell kontroll er også fallbacken når modellen er utilgjengelig. Vi har gått gjennom hvordan dette slår inn i eksisterende dataflyt i AI-pipelines i bank.


    Les også: Tolv AI-agenter per bedrift endrer CRM for norske SMB-er. Organisasjoner kjorer i snitt tolv AI-agenter, og adopsjonen ventes a oke 67 prosent pa to ar.


    EBAs kartlegging og tilsynet som samordnes

    EBA kartla AI Act-kravene mot sektorlovgivningen i 2025 og fant ingen betydelige motsetninger mellom AI Act og EUs bank- og betalingslovgivning (EU-kommisjonen, 2025). EBA har heller ikke identifisert behov for nye eller reviderte retningslinjer umiddelbartt. Det er gode nyheter for planleggingen og dårlige nyheter for de som håpet på utsettelse.

    Ingen motsetninger betyr ikke ingen krav

    Konklusjonen om at regelverkene er forenlige leses fort som at banken kan fortsette som før. Den riktige lesningen er motsatt: kravene i AI Act kommer i tillegg, og de eksisterende rammeverkene for modellrisiko og outsourcing er stedet de skal legges inn. En bank som allerede har et modellregister og en tredjepartsvurdering har infrastrukturen. Den mangler bare radene for AI-systemer som i dag ikke regnes som modeller. Det er en utvidelse, ikke et nytt program.

    Felles tilsynstilnærming i 2026 og 2027

    EBA vil i 2026/2027 fremme en felles tilsynstilnærming og samarbeid mellom nasjonale myndigheter og markedsovervåkingsmyndigheter, gi innspill til AI Office og delta i AI Board Subgroup on Financial Services (EU-kommisjonen, 2025). Praktisk betyr det at forventningene til hva en bank skal kunne fremvise blir mer ensartede, og at avstanden mellom nasjonale tolkninger krymper. Banken som venter på et norsk rundskriv før den begynner, planlegger for en samordning som allerede går i motsatt retning.

    Norsk kontekst: bankdominert system og Strategi 28

    Det norske finansielle systemet er dominert av banker (Norges Bank). Det gjør AI-avhengigheter til noe mer enn et foretaksanliggende. Hvis mange banker bygger kredittprosesser på de samme få modelltilbyderne, blir leverandørkonsentrasjon en systemisk variabel, ikke bare en post i den enkelte bankens risikoregister.

    Strategi 28 og betalingssystemet

    Norges Bank skal fremme finansiell stabilitet, velfungerende finansmarkeder og et effektivt og sikkert betalingssystem, og har et særlig ansvar for systemet for oppgjør mellom bankene (Norges Bank). Strategien frem mot 2028 er eksplisitt et svar på blant annet geopolitiske spenninger og ny teknologi. For en bank som vurderer hvor mye AI som kan legges inn i tidskritiske betalingsprosesser, er det signalet verdt å ta bokstavelig: robusthet vurderes ovenfra, ikke bare av den enkelte aktør.

    Hva NBIM viser og ikke viser

    Rundt halvparten av NBIMs 700 ansatte koder egne AI-verktøy, og Nicolai Tangen har uttalt at AI genererer besparelser i milliardklassen (alura.no, 2026). Det er et sterkt eksempel på intern kapasitetsbygging, men det er en kapitalforvalter uten kredittvurdering av privatpersoner og uten høyrisikoklassifisering å forholde seg til. Overføringsverdien ligger i kompetansemodellen, ikke i risikoprofilen. Banker som siterer NBIM som argument for å gå fort frem, siterer feil case.

    Kultur og tillit er den største flaskehalsen

    Den største utfordringen for finanssektoren er ikke teknisk, men kulturell, ettersom kun et mindretall av ledere stoler på at automatiserte beslutninger kan operere selvstendig (PwC). Det er en fornuftig skepsis i en bransje der feil koster kunder og konsesjoner. Men skepsis uten struktur gir det verste utfallet: systemer settes i drift uten at noen tør å definere hvor grensen for autonomi går.

    AI-adopsjon overlever ikke i siloer

    AI-adopsjon kan ikke lykkes i siloer fordi finansinstitusjoner er komplekse organisasjoner med avhengige funksjoner (PwC). En modell i kredittavdelingen påvirker kapitalplanlegging, kundeklager, compliance-rapportering og bemanning i kundesenteret. Når eierskapet ligger hos ett miljø alene, blir konsekvensene for de andre oppdaget i produksjon. Tverrfunksjonelt eierskap er derfor ikke en organisasjonspreferanse, men en forutsetning for at fallback-planen henger sammen på tvers.

    Tillit bygges med logg, ikke med demoer

    Ledere som ikke stoler på automatiserte beslutninger endrer sjelden mening etter en godt regissert demonstrasjon. De endrer mening når de kan se hva systemet har gjort over tid, hvor ofte mennesker overprøvde det, og hva som skjedde de gangene det tok feil. Bygg derfor rapporteringen før dere ber om tillit. Overprøvingsraten er den mest undervurderte styringsindikatoren i AI-drift, fordi den både måler modellkvalitet og avslører om den menneskelige kontrollen er reell.

    Vanlige feil når banker bygger AI-resiliens

    Feilene under går igjen på tvers av størrelse og modenhet. Ingen av dem skyldes manglende teknisk kompetanse. De skyldes at AI-arbeidet organiseres som et prosjekt med sluttdato, mens resiliens er en driftsegenskap som må vedlikeholdes.

    Å behandle leverandørrisiko som en innkjøpssak

    Kontrakten regulerer pris, SLA og databehandling. Den regulerer ikke at leverandøren kan endre modellatferd, deprekere en versjon eller endre vilkårene for finjustering. Banker som avslutter leverandørvurderingen når signaturen er på plass, mister sporet av den viktigste risikoen. Legg inn versjonspolicy og varslingsplikt ved modellendring som eksplisitte punkter, og følg opp i driftsmøtene. Konsentrasjonsrisikoen mot noen få tilbydere hører til på samme sted.

    Å dokumentere etter at systemet er i produksjon

    Dokumentasjon skrevet i etterkant beskriver systemet slik noen tror det ble bygget. Det er verdiløst i en tilsynssak og aktivt villedende i en feilsøking. Kravet fra regulatorene handler om evnen til å demonstrere ansvarlig bruk, og den evnen kan ikke rekonstrueres bakover. Den andre varianten av samme feil er å dokumentere pilotversjonen og ikke oppdatere når systemet endres. Et utdatert modellkort er verre enn ingen, fordi det gir falsk trygghet.

    Å skalere piloten uten å klassifisere den på nytt

    Et verktøy som startet som beslutningsstøtte for saksbehandlere ender ofte som de facto beslutningstaker, fordi forslagene godkjennes rutinemessig. Klassifiseringen som var riktig ved lansering er da ikke riktig lenger, uten at noen har tatt en beslutning om det. Sett en fast revurdering av klassifisering når volum, autonomi eller kundeeksponering endrer seg. Den samme mekanismen gjelder når AI-agenter kobles på flere systemer, slik vi beskrev for AI-agenter i CRM.

    Ofte stilte spørsmål om AI-resiliens i bank

    Spørsmålene under er de som oftest kommer opp i ledergrupper og risikoutvalg når AI-resiliens settes på agendaen første gang.

    Hva er AI-resiliens i bank, kort forklart?

    Det er bankens evne til å opprettholde kritiske tjenester når AI-komponenter svikter, og samtidig kunne dokumentere hvordan beslutninger ble tatt. Historisk har resiliens i bank handlet om regulatorisk kapital, stresstesting og risikostyringsdisiplin, men i dag inngår også digital modenhet (PwC). Konkret består det av tre ting: et register over avhengigheter, en testet fallback per kritisk bruksområde, og logger som gjør beslutninger sporbare.

    Er alle AI-systemer i banken høyrisiko?

    Nei. Klassifiseringen følger bruksområdet. AI-systemer for kredittvurdering av fysiske personer er høyrisiko under AI Act (EU-kommisjonen, 2025), mens et verktøy som skriver utkast til interne rutiner normalt ikke er det. Feilen banker gjør er å klassifisere per teknologi eller per leverandør. Klassifiser per prosess, og revurder når prosessen endrer seg.

    Må vi ha manuell fallback på kredittvurdering?

    Alura mener ja, og begrunnelsen er dobbel. Reell menneskelig kontroll forutsetter uansett at mennesker kan behandle sakene, og en høyrisikoprosess uten alternativ vei gjennom er en enkeltavhengighet i kjernevirksomheten. Fallbacken må ha definert kapasitet, definert tidsvindu og en dokumentert test. En reservemodell alene holder ikke, fordi den sjelden er validert for beslutningen den da faktisk tar.

    Hvem bør eie AI-resiliens internt?

    Operasjonell risikostyring, med forretningseiere per bruksområde og teknologi som utfører. Compliance definerer kravene, men kan ikke eie driften. Grunnen til at ansvaret ofte havner i et eget AI-team er at det er raskest i starten, og at det er derfor det bryter sammen ved skalering: AI-adopsjon lykkes ikke i siloer i organisasjoner med avhengige funksjoner (PwC).

    Hvor begynner en bank som ikke har startet?

    Med inventaret, og med de bruksområdene som allerede er i drift. Deretter klassifisering, deretter fallback på det som er kritisk. Ikke start med en plattformanskaffelse. Start heller med et lavrisiko-bruksområde som gir teamet trening i dokumentasjonsløypa, slik tidlige brukere har gjort med interne retningslinjer og rutinerapporter (PwC). For prosessautomatisering som ikke krever modeller i det hele tatt, er RPA ofte et enklere sted å begynne.

    Oppsummering: dette gjør du først

    AI-resiliens i bank er ikke et nytt fagfelt. Det er eksisterende operasjonell risikostyring utvidet med en type avhengighet bankene ikke hadde for få år siden. Arbeidet som gir mest tilbake er også det minst glamorøse: vite hva dere har, vite hva som stopper, og ha testet hva dere gjør da.

    Rekkefølgen som fungerer

    Start med inventaret av modeller og leverandører, hentet fra fakturaer og logger. Klassifiser hvert bruksområde etter konsekvens, og merk hvilke som treffer kredittvurdering. Definer fallback for de kritiske, med navngitt eier og faktisk kapasitet. Test minst en av dem i produksjon før nyttår, og skriv ned hva som gikk galt. Legg dokumentasjonen inn i det modellrisikorammeverket dere allerede har, ikke i et nytt system. Alt dette kan gjøres uten å stanse en eneste pågående AI-leveranse.

    Spørsmålet styret bør stille i neste møte

    Ikke «hvor mye AI bruker vi», men «hvilke av våre kritiske prosesser kan ikke kjøre uten en ekstern modelltilbyder, og hva skjer da». Svaret bør være en tabell, ikke en presentasjon. Med 86 prosent av finansbedriftene som øker AI-budsjettet (alura.no, 2026) og EBA som samordner tilsynstilnærmingen mot 2027 (EU-kommisjonen, 2025), er tidsvinduet for å bygge dette rolig i ferd med å lukke seg. Det koster lite nå og mye senere.

    I Alura jobber vi med norske bedrifter på tvers av bransjer: finans, helse, bygg, e-handel, industri. Vi vet hva som fungerer i din sektor og hva som ikke gjør det, fordi vi har bygget løsninger der allerede.

    Bestill en bransje-vurdering: vi presenterer hva andre i din sektor faktisk gjør med AI, hva som gir avkastning, og hvor du har uutnyttede muligheter. Uforpliktende.

    Kilder

    A

    Alura

    Praktisk kunnskap om AI-automatisering og effektivisering for norske bedrifter.