Agentisk ingenjörskonst för banker: en plan för 2026 för företagsledningen och ingenjörerna som ska bygga den

TL;DR. Agentisk AI har gått från pilot till produktion i banksektorn världen över. 70 % av instituten använder den i någon utsträckning; bara ett av fem har en mogen styrningsmodell. Samtidigt opererar autonoma motståndare i maskinhastighet, det äldre COBOL-beståndet som de nya systemen måste samverka med skrevs för 1960-talets antaganden om batchbearbetning, och EU:s AI Act har tolv veckor kvar till sin högrisktidsfrist i augusti 2026. Detta är den ingenjörs- och styrningsposition en bank behöver hålla.

Viktiga slutsatser

Året då agentisk ingenjörskonst blev oundviklig. Samtalet om AI inom finansiella tjänster har fram till helt nyligen dominerats av två närliggande men skilda saker: generativa chattgränssnitt (användbara men avgränsade) och mönster för Retrieval-Augmented…
Läget för införandet i banksektorn. Den samlade bilden är entydig.
Tre riskvektorer som banker måste internalisera. Före varje arkitektursamtal bör styrelsens uppmärksamhet vila på tre risker som är specifika för agentiska system och som infaller tidigare än de flesta banker har planerat för.
Varför vibe coding inte kan vara standardläget i banksektorn. Det är värt att vara precis om varför vibe coding, alltså kort prompt, observera resultatet, iterera, misslyckas som standardarbetsflöde i ett reglerat systembestånd.

Agentisk AI har gått från pilot till produktion i banksektorn världen över. Sjuttio procent av instituten använder den i någon utsträckning; bara ett av fem har en mogen styrningsmodell. Samtidigt opererar autonoma motståndare i maskinhastighet, det äldre COBOL-beståndet som de nya systemen måste samverka med skrevs för 1960-talets antaganden om batchbearbetning, och EU:s AI Act har tolv veckor kvar till sin tidsfrist för högrisksystem. Detta är den ingenjörs- och styrningsposition en bank behöver hålla.

Viktiga slutsatser

Övergången från vibe coding till specifikationsdriven utveckling är inte längre en ambition. Andrej Karpathy, som myntade begreppet ”vibe coding” i februari 2025, medgav ett år senare ⧉ att eran går mot sitt slut och att det nya standardläget för yrkesverksamma är agentisk ingenjörskonst, det vill säga att orkestrera agenter mot detaljerade specifikationer under mänsklig tillsyn.

Införandet i banksektorn är verkligt och accelererar. 70 % av bankföretagen ⧉ uppger att de använder agentisk AI i någon utsträckning (16 % i produktion, 52 % i pilot, EY 2026); 44 % av finansfunktionerna kommer att använda den i år, en ökning på över 600 % jämfört med föregående år enligt Wolters Kluwer.

Styrningen har inte hängt med. Deloittes State of AI 2026 visar att bara ett av fem företag har en mogen styrningsmodell för autonoma AI-agenter. Deloittes analys av MIT AI Risk Database identifierar fler än 350 risker ⧉ som kan uppstå ur autonomt eller agentiskt beteende.

Hotbilden har industrialiserats. Anthropic avslöjade i november 2025 att den kinesiska statsunderstödda gruppen GTG-1002 kapade Claude Code för att bedriva autonomt spionage mot omkring 30 mål, där AI:n hanterade 80–90 % av de taktiska operationerna på egen hand. Flashpoint noterade en ökning på 1 500 % av illegala AI-relaterade diskussioner ⧉ enbart mellan november och december 2025.

Det äldre systembeståndet är den tysta begränsningen. Underhåll av äldre system förbrukar 70–75 % av IT-budgetarna inom finansiella tjänster, 63 % av bankerna förlitar sig fortfarande på kod skriven före år 2000, och de flesta banker uppger att de bara har en eller två personer internt som kan underhålla den COBOL som deras kärnplattformar körs på. Agentisk AI är nu det dominerande sättet att sluta det gapet.

Regelverksstacken konvergerar. Enligt EU:s AI Act inträder full tillämplighet för högrisk-AI-system den 2 augusti 2026 (bilaga III omfattar uttryckligen kreditvärdering och bedömning av kreditvärdighet). DORA är redan i kraft. SR 11-7 har i tillsynspraxis utvidgats till att omfatta LLM:er och agentiska system. Sanktionsavgifterna vid överträdelse uppgår till 35 miljoner euro eller 7 % av den globala årsomsättningen.

Mänsklig tillsyn är inte ett enda begrepp. Skillnaden mellan HITL (Human-in-the-Loop, där agenten inte kan utföra en åtgärd utan uttryckligt mänskligt godkännande) och HOTL (Human-on-the-Loop, där agenten agerar autonomt under mänsklig övervakning) är nu det arbetsramverk som styr efterlevnaden av artikel 14 i EU:s AI Act, och varje högriskagent behöver en uttrycklig ståndpunkt om vilken modell som gäller.

De flesta agenter kommer att köpas, inte byggas. Tredjepartsriskhantering enligt DORA är 2026 års mest påtagliga men underskattade utmaning. Leverantörer kommer att tillhandahålla merparten av den agentiska förmåga som bankerna driftsätter; det regulatoriska ansvaret ligger kvar hos banken, och de flesta befintliga leverantörsavtal kan inte uppfylla dokumentationskraven i artikel 13.

Agentisk ingenjörskonst är inte ”ChatGPT plus MCP-servrar”. Det är en strukturell ägarposition över institutets flöden från början till slut: kundresor, transaktionslivscykler, kontrollplan, revisionssubstrat och en kvantsäker kryptografisk grund, byggd och driven av institutets egen ingenjörsfunktion, inte utlagd på en chattbot.

Året då agentisk ingenjörskonst blev oundviklig

Samtalet om AI inom finansiella tjänster har fram till helt nyligen dominerats av två närliggande men skilda saker: generativa chattgränssnitt (användbara men avgränsade) och mönster för Retrieval-Augmented Generation lagda ovanpå företagsdata (användbara, också de avgränsade). Det som förändrades mellan slutet av 2025 och början av 2026 är att den tredje kategorin, autonoma agenter som planerar, utför och slutför flerstegsarbetsflöden med begränsad mänsklig övervakning, gick från teknisk demonstration till operativ verklighet och korsade samtidigt gränsen både in i företaget och in hos hotaktören.

Andrej Karpathy, som myntade begreppet ”vibe coding” i februari 2025 ⧉, tillbringade det följande året med att se yrkesverksamma ingenjörer gå bortom det. Hans omtolkning, ”agentisk ingenjörskonst”, är nu det gängse begreppet i hela branschen. Innebörden av skiftet är enkel: i seriöst mjukvaruarbete under 2026 skriver ingenjörerna inte koden direkt 99 % av tiden. De orkestrerar agenter som gör det, medan de själva utövar tillsyn. Arbetet består inte längre i att knappa in tecken i en editor; det består i att ta fram specifikationer som begränsar vad agenterna får generera, att utforma de verifieringsgrindar som resultatet måste passera och att kurera de arkitekturbeslut som agenterna implementerar.

Detta skifte låter som ett samtal för ingenjörsteamet. I banksektorn är det inte det. Det är ett samtal på styrelsenivå, eftersom samma agentiska förmåga som skriver om hur intern kod produceras också skriver om hur externa motståndare opererar, hur tillsynsmyndigheter förväntar sig att tillsyn ska utövas och hur institutets perimeter definieras. En bank som inte äger sin ståndpunkt om agentisk ingenjörskonst vid utgången av 2026 är inte en bank som har undvikit frågan. Det är en bank vars leverantörer, motståndare och tillsynsmyndigheter har besvarat frågan åt den.

Läget för införandet i banksektorn

Den samlade bilden är entydig. Enligt forskning sammanställd från flera undersökningar under 2026 uppger 70 % av bankcheferna ⧉ att deras företag redan använder agentisk AI i någon utsträckning. Gartner prognostiserar ⧉ att omkring 40 % av alla företag inom finansiella tjänster kommer att köra AI-agenter i någon form vid utgången av 2026. AI-utgifterna inom finansiella tjänster är på väg att nå 67 miljarder dollar år 2028 (IDC). McKinsey uppskattar att agentisk AI kan frigöra 10–12 timmar per vecka åt relationsansvariga i bank.

Bilden av genomförandet är mindre uppmuntrande. KPMG rapporterar ⧉ att 99 % av företagen planerar att sätta autonoma agenter i produktion men att bara 11 % har gjort det. EY konstaterar att 34 % av ledarna har börjat använda AI-agenter och att endast 14 % har implementerat dem fullt ut. Forrester finner att 57 % av organisationerna anser sig sakna den interna förmågan att dra nytta av agentisk AI. Gapet mellan avsikt och genomförande är inte en marknadsföringsartefakt. Det speglar det ingenjörs-, styrnings- och kulturarbete som ännu inte har gjorts.

Storbritanniens Financial Conduct Authority har offentligt uttryckt oro ⧉ över att driftsättningstakten överstiger styrningens mognad, en spänning som FCA:s Chief Data Officer Jessica Rasu har beskrivit som en näraliggande risk för privatkunder. McKinsey varnade separat för att banker som inte anpassar sina affärsmodeller ⧉ riskerar att urholka upp till 170 miljarder dollar i globala vinster fram till 2030. Båda observationerna är samtidigt korrekta. Frågan är inte om man ska agera, utan hur man ska agera med den operativa och styrningsmässiga integritet som regleringen av finansiella tjänster alltid har krävt och som agentiska system gör skarpare.

Tre riskvektorer som banker måste internalisera

Före varje arkitektursamtal bör styrelsens uppmärksamhet vila på tre risker som är specifika för agentiska system och som infaller tidigare än de flesta banker har planerat för.

1. Den autonoma motståndaren

Den mest desorienterande utvecklingen under 2026 är operationaliseringen av agentisk AI på angreppssidan. I augusti 2025 avslöjade Anthropic en aktivitetskategori som företaget kallade vibe hacking ⧉: cyberkriminella som använder agentisk AI för att utföra avancerade angrepp i stor skala, med AI:n inbäddad genom spaning, insamling av inloggningsuppgifter, nätverksintrång och analys av stulna data. I november 2025 ⧉ avslöjade Anthropic att företaget hade avbrutit en kampanj som drevs av en kinesisk statsunderstödd grupp (betecknad GTG-1002) och som kapade instanser av Claude Code för att bedriva autonomt spionage mot omkring trettio mål inom försvar, energi och teknik, där AI:n hanterade 80–90 % av de taktiska operationerna och opererade med tusentals förfrågningar per sekund, hastigheter som är omöjliga för mänskliga operatörer.

I januari 2026 komprometterades Step Finance, en DeFi-portföljförvaltare byggd på Solana, på ett sätt som förvandlade ett enhetsintrång till en förlust på 27–30 miljoner dollar, eftersom företagets AI-handelsagenter hade behörighet att utföra stora överföringar utan mänskligt godkännande. Angriparen social-manipulerade själva AI:n och utgav sig för att driva ett auktoriserat bug bounty-program. Lärdomen ⧉ var inte att AI i sig är osäker; den var att en AI-agent som godtar en påstådd auktorisering utan verifiering är en svaghet i perimetern.

Det är den samlade trenden som bankerna måste internalisera. Flashpoints 2026 Global Threat Intelligence Report identifierade en ökning på 1 500 % av illegala AI-relaterade diskussioner ⧉ mellan november och december 2025, där angripare aktivt utvecklar autonoma system som skrapar data, roterar infrastruktur, justerar budskap och lär av misslyckade försök utan kontinuerlig mänsklig tillsyn. JPMorgans Jamie Dimon har varit offentligt tydlig ⧉ med att det inledande övertaget i den här tekniken går till angreppet, inte till försvaret. Implikationen är obekväm: en bank som bedriver klassiska säkerhetsoperationer mot agentiska motståndare befinner sig strukturellt i en schackspelares situation vars motståndare har fått en dator.

2. Regressionen i kodkvalitet

Den andra vektorn är intern och tystare. LLM-genererad kod levereras, i avsaknad av specifikationsdisciplin och rigorös verifiering, med defekter i en takt som är väsentligt högre än mänskligt skriven kod. En SonarQube-analys av fem ledande LLM:er ⧉ som genererade Java-kod fann att över 70 % av de upptäckta sårbarheterna i utdata från Llama 3.2 90B klassades som BLOCKER, och att ungefär två tredjedelar av sårbarheterna hos GPT-4o och OpenCoder-8B klassades som BLOCKER eller CRITICAL. Pearce m.fl. (IEEE S&P) fann att omkring 40 % av de LLM-genererade programmen i säkerhetskänsliga sammanhang innehöll sårbarheter. Yan m.fl. (2025) anger intervallet till 9,8–42,1 % över sina benchmarks. En separat katalog från Fu m.fl. identifierade 43 CWE:er i tre verktyg för AI-kodgenerering.

För en oreglerad bransch är detta en produktivitetsskatt. För en bank är det en regulatorisk och operativ risk som ackumuleras. Kod som levereras med en hög sårbarhetstakt in i ett system som hanterar betalningar, avveckling eller kunddata är inte en kodkvalitetsfråga i abstrakt mening; det är den yta som motståndare av GTG-1002-klass kommer att sondera 2027 med samma agentiska verktyg som producerade den. Försvaret är inte att förbjuda LLM-genererad kod (kommersiellt omöjligt) utan att omge den med den verifierings- och specifikationsinfrastruktur som säkerställer att defekter kommer upp till ytan före driftsättning. Detta är det praktiska skälet till att specifikationsdriven utveckling införs i snabb takt av ingenjörsorganisationer i företag som inte är teknikföretag i grunden.

3. Ankaret av äldre system

Den tredje vektorn är den som bankerna redan förstår bäst och som den agentiska övergången har gjort både mer brådskande och mer hanterbar. Mer än 70 % av Fortune 500-företagen förlitar sig fortfarande på stordatorer, noterar Computer Weeklys analys ⧉, ofta byggda på decennier av sammanflätad COBOL och RPG med skräddarsydd affärslogik. Inom finansiella tjänster specifikt förbrukar äldre tekniker 70–75 % av de årliga IT-utgifterna ⧉. En CIO-studie som citeras i branschanalyser för 2026 fann att 63 % av bankerna fortfarande förlitar sig på kod skriven före år 2000, och att mer än 75 % uppgav att de bara har en eller två personer internt med kompetensen att underhålla den.

Det som förändrades i februari 2026 var att det kom trovärdiga agentiska verktyg för modernisering av äldre system. Anthropics tillkännagivande att Claude Code kunde kartlägga COBOL-beroenden, dokumentera arbetsflöden och identifiera risker ⧉ som mänskliga analytiker skulle behöva månader för att få fram, i kombination med liknande förmågor från Microsoft (GitHub Copilot för COBOL, Watsonx Code Assistant) och AWS (Mainframe Modernization med agentisk AI), har komprimerat kostnadskurvan för modernisering påtagligt. Reaktionen i IBM:s aktiekurs (ett fall på 13 % dagen för tillkännagivandet) var en oelegant men träffsäker marknadssignal. AI står nu för ungefär en tredjedel av företagens moderniseringsinvesteringar, och mer än 75 % av företagen använder AI i sin moderniseringsstrategi. Ankaret av äldre system är, för första gången, ett hanterbart ingenjörsproblem snarare än ett generationsproblem.

Varför vibe coding inte kan vara standardläget i banksektorn

Det är värt att vara precis om varför vibe coding, alltså kort prompt, observera resultatet, iterera, misslyckas som standardarbetsflöde i ett reglerat systembestånd. Felläget är inte det uppenbara (att LLM:en ibland hallucinerar). Felläget är strukturellt och visar sig på fyra ställen samtidigt.

Det första är avsaknaden av gemensamma konventioner. Flera ingenjörer som arbetar via chattprompter kommer att producera fem olika sätt att göra samma sak i samma kodbas inom loppet av ett enda kvartal. I ett oreglerat sammanhang är detta teknisk skuld. I ett reglerat sammanhang är det den yta som brister vid en granskning.

Det andra är kontextförfall. AI-agenter är tillståndslösa. I ett stort projekt överskrider konversationerna kontextfönstren, och resonemanget bakom tidigare arkitekturbeslut förångas. Samma agent kommer två veckor senare att fatta det motsatta beslutet i en ny chatt, eftersom ingenting bevarar motiveringen bakom det första. För system som behöver ett revisionsspår för tillsynsmyndigheter är detta strukturellt oförenligt.

Det tredje är osynlig ackumulering av defekter. Resultaten från Pearce, Yan och SonarQube som citeras ovan är inte gränsfall. De är den grundtakt med vilken LLM:er genererar sårbar kod i avsaknad av specifikationsdisciplin och rigorös testning. En bank som kör vibe coding-arbetsflöden i produktion ackumulerar dessa defekter i samma takt, utan den synlighet på ytan som krävs för att veta vad som har levererats.

Det fjärde är problemet med regulatorisk spårbarhet. Artikel 12 i EU:s AI Act kräver automatisk loggning av in- och utdata för högrisk-AI-system. SR 11-7 kräver dokumenterade roller för modellägare och validerare, ändringshantering för modelluppdateringar och rapportering till styrelsen om risken i AI-modeller. DORA kräver en heltäckande hantering av IKT-risker med dokumenterade belägg. Ingen av dessa skyldigheter kan uppfyllas av ett arbetsflöde vars primära artefakt är en chatthistorik som ingen bevarar.

Slutsatsen är inte att LLM:er är olämpliga för banksektorn. Slutsatsen är att arbetsflödet runt dem måste producera specifikationer, revisionsspår och verifieringsgrindar som förstklassiga resultat snarare än som eftertankar. Det är detta som specifikationsdriven utveckling är, operativt sett.

Specifikationsdriven utveckling i ett reglerat systembestånd

Specifikationsdriven utveckling (SDD) vänder på arbetsordningen. I stället för att hoppa in i implementeringen och iterera med en agent tar teamet först fram en specifikation, med arkitekturbeslut, krav, gränssnittskontrakt, framgångskriterier och säkerhetsbegränsningar, och agenten genererar kod som uppfyller specifikationen. Verifieringen är strukturerad: specifikationen anger vad resultatet ska göra, och en separat process (testgenerering, kodgranskning, formell verifiering där det är tillämpligt) kontrollerar om det har gjorts.

Den praktiska verktygsuppsättningen har konsoliderats under slutet av 2025 och början av 2026. GitHubs Spec Kit ⧉ (lanserad i slutet av 2025) formaliserar avsikten före kodgenerering. AWS bäddar in spec-first-arbetsflöden direkt i sin Kiro IDE. JetBrains och Cursor har infört planeringslägen som strukturerar interaktionen med AI:n. Ramverk som BMAD (Breakthrough Method for Agile AI-Driven Development) går längre med team av specialiserade AI-agenter som speglar rollerna analytiker, arkitekt, utvecklare och QA genom hela SDLC. Constitutional SDD, formaliserad i en arXiv-artikel i februari 2026, bäddar in uttryckliga säkerhetsbegränsningar med CWE-sårbarhetsmappningar i själva specifikationen.

För en bank är den variant som spelar roll det som Augment Codes analys kallar specifikationsförankrad utveckling: specifikationerna kommer först, AI:n genererar kod som begränsas av dem, och ytterligare styrningslager (konstitutionella begränsningar, tillsynskontrollpunkter, grindar för mänskligt godkännande) placeras mellan generering och sammanslagning. Detta är den enda variant som producerar det revisionsspår som artikel 12 i EU:s AI Act förväntar sig, den dokumenterade validerarroll som SR 11-7 kräver och den ändringshanteringsdisciplin som DORA fordrar.

Den investering som krävs är verklig, men den är också hanterbar. De institut som gör detta väl har flyttat ingenjörernas vardag från att knappa in tecken till att producera två artefakter: en specifikation som agenten ska uppfylla och en verifieringsrigg som resultatet måste passera. Den kognitiva belastningen på ingenjören är högre i vissa avseenden (tydlighet i avsikten spelar större roll än någonsin) och lägre i andra (det mekaniska arbetet med att skriva standardkod är borta). De institut som ännu inte har gjort detta skifte arbetar fortfarande i ett läge där LLM:en är en snabbare maskinskrivare. Den positionen är inte hållbar i ett reglerat systembestånd bortom de kommande tolv månaderna.

Regelverksstacken som nu gäller

Den regulatoriska perimetern kring AI i banksektorn 2026 är inte längre en checklista; den är en stack av överlappande skyldigheter som måste resoneras kring tillsammans. Det enskilt mest avgörande datumet är 2 augusti 2026, då EU:s AI Act gör skyldigheterna för högrisksystem fullt tillämpliga ⧉. Bilaga III klassificerar uttryckligen kreditvärdering, bedömning av kreditvärdighet, riskbedömning inom liv- och sjukförsäkring samt utvärdering eller klassificering av enskildas ekonomiska ställning som högrisk. De skyldigheter som följer av den klassificeringen omfattar bedömningar av överensstämmelse, kvalitetsledningssystem, ramverk för riskhantering, teknisk dokumentation, registrering i EU:s databas, robust datastyrning, mänsklig tillsyn och skydd för cybersäkerhet. Sanktionsavgifterna vid överträdelse av högriskskyldigheterna uppgår till 35 miljoner euro eller 7 % av den globala årsomsättningen, beroende på vilket som är högst.

Vid sidan av AI Act:

DORA (Digital Operational Resilience Act) har varit i kraft sedan januari 2025 och skapar 22 skyldigheter för hantering av IKT-risker som uttryckligen omfattar AI-system som används i kritiska finansiella funktioner. Hantering av IKT-risker, tillsyn av tredje part, incidentrapportering och testning av operativ motståndskraft gäller AI-komponenter i lika hög grad som varje annan IKT-tillgång.
SR 11-7, Federal Reserves och OCC:s vägledning för hantering av modellrisk som ursprungligen skrevs 2011, har i tillsynspraxis utvidgats ⧉ till att omfatta LLM:er och agentiska system. FFIEC-granskningar omfattar nu uttryckligen AI-styrning. Institut som inte kan ta fram en förteckning över AI-modeller och riskbedömningar på begäran får anmärkningar redan i dag.
NIST AI RMF (1.0, januari 2023) är frivilligt i USA men refereras som en baslinje av federala tillsynsmyndigheter. Dess fyra funktioner (Govern, Map, Measure, Manage) mappar rent mot de strukturella kraven i EU:s AI Act.
ISO/IEC 42001 (publicerad i december 2023) är den första certifierbara standarden för ledningssystem för AI, uppbyggd som ISO/IEC 27001 för informationssäkerhet. Efterfrågan på 42001-certifiering ökade kraftigt under första kvartalet 2026 när upphandlingskrav började hänvisa till den.
Brittiska SM&CR och Consumer Duty: Senior Managers and Certification Regime kräver nu namngivet ansvar för varje högrisk-AI-system. Consumer Duty har i nyligen utfärdad FCA-vägledning ⧉ utvidgats till att omfatta utfall för privatkunder som påverkats av AI.
G7:s postkvant-färdplan (januari 2026), NCSC:s trestegsramverk för migration och slutsatserna från BIS Project Leap ligger vid sidan av denna stack. Skärningspunkten spelar roll: ett AI-system som tränats eller drivs på ett kryptografiskt substrat som inte överlever postkvantövergången är ett AI-system vars revisionsspår och integritetspåståenden har en halveringstid på mindre än ett decennium. Samtalet om agentisk ingenjörskonst och samtalet om postkvantkryptografi är, i allt högre grad, samma samtal. (För den fördjupade bilden av den kryptografiska sidan, se maj 2026-artikeln om postkvantmigration inom företagsfinans.)

Tre lägen av AI-assisterad utveckling jämförda

Dimension	Vibe coding	Specifikationsdriven utveckling	Agentisk ingenjörskonst
Primär indata	Kort prompt	Formell specifikation	Specifikation + plan för agentorkestrering
Ingenjörens roll	Promptitererare	Specifikationsförfattare	Orkestrerare och verifierare
Disciplin för utdata	Direkt kodgenerering	Kod begränsad av specifikationen	Fleragentsarbetsflöden som producerar kod, tester, dokumentation
Revisionsspår	Chatthistorik (bevaras inte)	Specifikation + genererad kod + tester	Specifikation + agentspår + verifieringsartefakter
Defekttakt (endast LLM)	10–40 % sårbarhetstakt (baslinje i litteraturen)	Väsentligt reducerad av specifikationsbegränsningar	Lägst med verifieringsgrindar
Regulatorisk spårbarhet	Otillräcklig för högrisk-AI	Förenlig med artikel 12 i EU:s AI Act	Utformad för artikel 12 + SR 11-7 + DORA
Lämplig för banksektorn?	Nej, för produktion	Ja, med styrning	Ja, med mogen styrning
Förmågetak	Begränsat av enstegsprompt	Begränsat av specifikationens kvalitet	Begränsat av orkestreringens kvalitet

Källa: syntes av Karpathys kommentarer (2026), Augment Codes SDD-analys ⧉, CGI:s analys av specifikationsdriven utveckling ⧉ och den akademiska litteraturen om sårbarhetstakten i LLM-kodgenerering (Pearce m.fl., Yan m.fl., Fu m.fl., 2023–2025).

Att bygga den agentiska banken: en arkitekturvy

Den strategiska positionen bakom dessa arbetsflöden är vad företagsledningen behöver äga uttryckligen. Agentisk ingenjörskonst i banksektorn är inte ett initiativ för utvecklarproduktivitet. Det är en institutionell förmåga som berör kundresor från början till slut, hela transaktionslivscykeln och det kryptografiska substrat och revisionssubstrat som ligger till grund för båda. Fyra lager av den förmågan förtjänar direkt uppmärksamhet från ledningen, uppifrån och ner:

Lager 4 – Agentkontrollplan Styrning, revision, nödstopp, detektering av beteendeavvikelser, mänsklig åsidosättning. Tillsynskonfigurationer för HITL och HOTL per agentklass.

Lager 3 – Agentiska arbetsflöden Kundresor, intern drift, utvecklingspipeline. Specifikationsdrivet som standard för högriskflöden.

Lager 2 – Data- och modellager AIBOM (AI Bill of Materials), modellregister, hämtningssubstrat, versionshantering av promptmallar, härkomst för finjusteringar.

Lager 1 – Kvantsäker grund ML-KEM, ML-DSA, hybrid-PKI, kryptoagilitet. Det substrat som varje högre lagers integritetspåståenden beror på.

Lager 1 – Den kvantsäkra grunden. Varje lager ovanför detta förutsätter det kryptografiska substratets integritet. Med G7:s färdplan, NCSC:s trestegsplan och BIS Project Leap alla offentligt dokumenterade är detta inte längre en nischfråga. Agentiska system vars revisionsspår är signerade under klassisk ECDSA, eller vars nyckeletablering är beroende av RSA eller ECDH, kommer att se sina integritetspåståenden förfalla i takt med kryptografin. De institut som får detta rätt drar postkvantarbetet uppströms och behandlar ML-KEM, ML-DSA och hybrid-PKI som det substrat på vilket varje högre lagers garantier för revision och integritet vilar.

Lager 2 – Data- och modellagret. Det är här AI Bill of Materials (AIBOM) finns. I analogi med den Cryptographic Bill of Materials som används vid planering av postkvantmigration är AIBOM förteckningen över varje modell, datamängd, promptmall, hämtningsindex, finjustering och tredjeparts-AI-beroende som institutet driver. Det är den artefakt som artikel 49 i EU:s AI Act i praktiken kräver, den förteckning som SR 11-7-granskningar nu efterfrågar och grunden för varje trovärdig styrningshållning. De flesta institut har ingen. De kommer att behöva en till augusti.

Lager 3 – Agentiska arbetsflöden. Detta är det lager som de flesta institut för närvarande bygger, ofta utan tillräcklig uppmärksamhet på lager 1, 2 och 4. Arbetsflödena sträcker sig från interna (kodgenerering, framtagning av regulatoriska dokument, triage i kundtjänst) till kundvända (copiloter för relationsansvariga, onboarding, KYC-orkestrering, transaktionsövervakning, FX-optimering) till fullt autonoma (treasury-verksamhet, vissa handels- och riskhanteringsfunktioner där tillsynsmyndighetens tolerans tillåter). Den strategiska disciplinen på detta lager är att behandla det som systemingenjörskonst, inte applikationsutveckling: orkestreringsmönster, eskaleringsregler, human-in-the-loop-grindar och revisionsutsändning är förstklassiga designfrågor.

Lager 4 – Agentkontrollplanet. Detta är vad Deloitte har beskrivit som ”agenternas kontrollrum” ⧉: den infrastruktur för revision i realtid, åtgärdsloggning, detektering av beteendeavvikelser, nödstopp och mänsklig åsidosättning som omger varje agent i produktion. Förlusten i Step Finance var, tekniskt sett, inte ett AI-fel. Det var ett fel i kontrollplanet: agenterna hade behörigheter som de inte borde ha haft, och den beteendeavvikelse som borde ha utlöst ett stopp gjorde inte det. De institut som bygger kontrollplanet först, innan de skalar upp driftsättningen av agenter, är de som inte kommer att se incidenter av Step Finance-klass 2027.

Den relevanta jämförelsen för företagsledningen är inte ”gör vi mer AI än våra konkurrenter?”. Den är huruvida institutet äger alla fyra lager, eller om ett eller flera lager i tysthet läggs ut på en leverantör utan avtalsmässig förmåga att uppfylla dokumentationskraven i artikel 13 i EU:s AI Act. Det senare är en position som ser bra ut ända tills en tillsynsmyndighet öppnar frågan.

Mänsklig tillsyn i praktiken: HITL kontra HOTL

Den enskilda distinktion inom lager 4 som tillsynsmyndigheterna är mest inriktade på 2026 är den mellan två tillsynsmodeller. Båda är former av mänsklig övervakning; de skiljer sig åt i latens, skala och i det antagande som tillsynsmyndigheten är villig att göra om agentens beteende.

Human-in-the-Loop (HITL) är modellen där en agent inte kan utföra en betydelsefull åtgärd utan uttryckligt mänskligt godkännande. Agenten förbereder beslutet, presenterar det och väntar. En KYC-åtgärdsagent som flaggar ett konto för avslut men inte kan avsluta det utan en compliance officers godkännande är HITL. Avvägningen är operativ: HITL är säkrare och producerar ett entydigt revisionsspår enligt artikel 14, men den skalar inte till arbetsflöden med hög volym och låg latens.

Human-on-the-Loop (HOTL) är modellen där en agent agerar autonomt inom avgränsade parametrar, med människor som övervakar telemetri i realtid och behåller befogenheten att stoppa agenten när som helst. En agent för bedrägeriscreening i realtid som automatiskt blockerar transaktioner som matchar särskilda riskmönster, med ett mänskligt driftteam som bevakar larmvolymen och ingriper vid avvikelser, är HOTL. Avvägningen är den omvända: HOTL skalar, men den är beroende av att agentens parametrar är korrekt inställda och av en detektering av beteendeavvikelser som fångar avdrift innan skada ackumuleras.

Artikel 14 i EU:s AI Act föreskriver inte HITL eller HOTL; den kräver att den mänskliga tillsynen är meningsfull. Den praktiska implikationen är att varje högriskagent som banken driver måste ha en uttrycklig, dokumenterad ståndpunkt om vilken modell som gäller, varför, och vilken eskaleringsväg som finns när agenten stöter på situationer utanför sina avgränsade parametrar. De flesta banker som körde piloter under 2025 hade inte denna dokumentation. De flesta banker som driver produktionsagenter i augusti 2026 kommer att behöva den.

Beslutsregeln är inte komplex. För betydelsefulla, lågvolyms- och oåterkalleliga åtgärder, såsom kreditavslag för en fysisk person, kontoavslut, auktorisering av högvärdesöverföringar och inlämnande av regulatoriska rapporter, är HITL det försvarbara standardvalet. För åtgärder med hög volym, som är reversibla och parameteravgränsade, såsom larm från transaktionsövervakning, dokumentklassificering och rutinmässig triage i kundtjänst, är HOTL lämpligt, förutsatt att detekteringen av beteendeavvikelser och nödstoppsinfrastrukturen är mogen. Banker som behandlar varje arbetsflöde som HITL kommer inte att fånga den operativa hävstången i agentiska system. Banker som behandlar varje arbetsflöde som HOTL kommer förr eller senare att få ett Step Finance-ögonblick.

Köpa kontra bygga: problemet med tredjepartsagenter

Den verklighet för 2026 som har smugit sig på de flesta banker är att de i huvudsak inte kommer att bygga agentisk förmåga. De kommer att köpa den. Leverantörsutbudet, med Oracles agentiska bankplattform som lanserades i februari 2026, IBM:s Watsonx, Microsofts Copilot-svit, AWS Bedrock Agents, Salesforce Agentforce, ServiceNows NowAssist och vågen av fintech-specialiserade agentleverantörer, rör sig snabbare än bankernas interna ingenjörskonst förmår. Den strategiska konsekvensen är att de flesta agenter som är i drift inuti en bank 2027 kommer att ha skrivits av någon annan, och styrningsfrågan är inte längre ”kan vi lita på våra agenter?” utan ”kan vi lita på de agenter vi har upphandlat, och kan vi bevisa för en tillsynsmyndighet att vi kan?”.

Detta är den mest påtagliga men underskattade utmaningen under DORA. Artiklarna 28–30 i förordningen gör hanteringen av IKT-risker hos tredje part till ett aktivt tillsynsområde, med uttryckliga krav som omfattar avtalsvillkor, löpande övervakning, bedömning av koncentrationsrisk och exitstrategier. De europeiska tillsynsmyndigheterna för ett register över kritiska IKT-tredjepartsleverantörer, med direkta tillsynsbefogenheter över dem som utsetts till sådana. Den nya operativa verkligheten är att 2026 års AI-leverantörer, alltså leverantörer av ledande modeller, leverantörer av agentplattformar och AI-baserad SaaS, i allt högre grad är de IKT-tredjeparter som DORA skrevs för att omfatta.

För en bank i köparposition gäller tre praktiska discipliner:

Kräv AIBOM från leverantören. Varje agentprodukt som upphandlas för användning i högriskarbetsflöden måste levereras med en dokumenterad bill of materials som omfattar de underliggande modellerna, träningsdatans härkomst och begränsningar, tillämpade finjusteringar, åtkomna hämtningsindex, versioner av promptmallar och beroendekedjan till nedströms agentkomponenter. Det är den artefakt som banken behöver för att uppfylla dokumentationskraven i artikel 13 i EU:s AI Act. Banken kan inte ta fram den i efterhand från en leverantör som inte avtalsmässigt har åtagit sig att tillhandahålla den.

Testa den svarta lådan, inte broschyren. Utvärderingar vid leverantörsupphandling har historiskt fokuserat på funktionsjämförelser och intervjuer med referenskunder. För agentiska system räcker det inte. Institutet måste genomföra beteendetestning av agenten under förhållanden som liknar den avsedda produktionsdriftsättningen, inklusive antagonistisk sondering för promptinjektion, motståndskraft mot social manipulation (Step Finance-vektorn), avdrift vid förskjutningar i datafördelning samt latensen och fellägena hos vägarna för nödstopp och åsidosättning. De flesta nuvarande leverantörsavtal tillåter inte denna testdjup utan särskild förhandling; den förhandlingen behöver ske innan avtalet undertecknas, inte efter.

Omförhandla avtalen på artikel 13:s villkor. De flesta befintliga avtal med AI-leverantörer innehåller inget av de krav på dokumentation, revisionsrätt, avisering om modelländringar, incidentrapportering eller redovisning av underleverantörer som EU:s AI Act och DORA tillsammans ställer. Regulativs analys av brittiska företag ⧉ var tydlig på denna punkt: den juridiska granskningen av leverantörsavtal tar veckor, och de flesta institut kan inte uppfylla artikel 13 för en modell vars inre funktion deras leverantör aldrig har varit avtalsmässigt skyldig att röja. Det regulatoriska ansvaret ligger hos den som tar systemet i bruk, inte hos leverantören. Upphandlingsteam behöver veta detta före nästa förnyelsecykel, inte efter en regulatorisk förfrågan.

Sammanfattningen på styrelsenivå är att leverantörsrelationen har gått från upphandling till risköverföring, och risken överförs i själva verket inte. Banken förblir den som tar systemet i bruk. Banken förblir ansvarig. Banken behöver de avtalsmässiga instrument och den testdisciplin som gör dess ansvar hanterbart snarare än enbart formellt.

Vad detta innebär per banktyp

Det rätta svaret varierar. Mönstret nedan är en grov segmentering, inte en föreskrift.

Universalbanker i första nivån

Institut med balansräkningar på över 1 biljon dollar och global närvaro är samtidigt de mest exponerade (bredaste regulatoriska perimetern, största beståndet av äldre system, mål med högst värde för autonoma motståndare) och de bäst resurssatta. Den strategiska prioriteringen är att bygga kontrollplanet först, lager 4 i arkitekturen ovan, och att föra in disciplinen specifikationsdriven utveckling i den interna ingenjörsfunktionen innan driftsättningen av agenter skalas upp ytterligare. Den konkurrensmässiga konsekvensen av att få detta rätt är betydande; konsekvensen av att få det fel är existentiell, med tanke på sanktionsexponeringen under EU:s AI Act och den operativa exponeringen mot hotmönster av GTG-1002-klass.

Medelstora och regionala banker

Konkurrensfrågan för banker i andra nivån är skarpare än för dem i första nivån. De möter samma regulatoriska perimeter utan samma styrningsbudget, samma hotyta utan samma försvarsresurser och en kundbas som i allt högre grad jämför dem med AI-nativa fintechbolag. Det praktiska svaret är att standardisera hårt kring en liten uppsättning granskade leverantörer (med avtal som uppfyller dokumentationskraven i artikel 13), att investera i disciplinen specifikationsdriven utveckling snarare än i skräddarsydd plattformsingenjörskonst, och att använda agentiska verktyg för att komprimera den tidslinje för COBOL-modernisering som har varit ett strategiskt ankare i två decennier. De institut som agerar tidigt här kommer, i materiell mening, att sluta teknikgapet till bankerna i första nivån för första gången på en generation.

Fintechbolag, betaltjänstleverantörer och kryptonära institut

Segmentet fintech och betalinstitut har det omvända problemet: smidigheten är hög, styrningen ofta lägre än hos jämförbara banker, och sanktionsexponeringen under EU:s AI Act är för ett medelstort fintechbolag potentiellt existentiell. Den strategiska disciplinen är att behandla AI-styrning som en grind för produktmognad snarare än ett efterlevnadslager, det vill säga att bygga in AIBOM, revisionssubstratet och de specifikationsdrivna arbetsflödena i ingenjörskulturen från början i stället för att eftermontera dem under regulatoriskt tryck. För institut vars betalinfrastruktur skär in i SWIFT CBPR+-tidsfristen för strukturerade adresser i november 2026 är investeringen i agentisk ingenjörskonst också den naturliga mekanismen för att industrialisera åtgärdsarbetet med strukturerade adresser: valideringsreglerna, upprätthållandet av datakvalitet och integrationen i CI-pipelinen är just de mönster som specifikationsdrivna arbetsflöden gör hanterbara.

Interna ingenjörsfunktioner

För de ingenjörer och forskare som läser detta är den arbetsdisciplin som spelar roll den dagliga. Flytta arbetets tyngdpunkt från att knappa in tecken till att producera specifikationer och verifieringsriggar. Behandla agentspår, mellanliggande planer och godkännandegrindar som förstklassiga artefakter i er versionshantering. Investera i verktyg, såsom Spec Kit, Kiro, Cursors planläge och Claude Code med skill-filer på projektnivå, som gör specifikationen till den varaktiga artefakten och den genererade koden till den utbytbara. Det ergonomiska skiftet är verkligt. Den professionella utdelningen är att den disciplin som införs i frontlinjen också är den disciplin som överlever regulatorisk granskning.

Den 12 veckor långa handlingsplanen fram till augusti 2026

För den verkställande sponsor som driver ett program för agentisk ingenjörskonst mellan nu och EU:s AI Act-tillämpningsdatum komprimeras arbetet till en tolv veckor lång sekvens. Planen nedan är inte uttömmande; den är det minimum som en styrelse bör förvänta sig att ett trovärdigt program har slutfört till den 2 augusti 2026.

Vecka 1–2 – Ta fram AIBOM. Upprätta den centraliserade förteckningen över varje AI-system, modell, datamängd, promptmall, hämtningsindex, finjustering och tredjeparts-AI-beroende i produktion eller under utveckling. Mappa varje post till klassificeringen enligt bilaga III i EU:s AI Act. Leveransen är en enda sanningskälla som CRO, CCO, CISO och CTO var för sig kan söka i.

Vecka 3–4 – Klassificera tillsynsmodell per system. För varje högrisk- och betydelsefull agent, dokumentera uttryckligen om tillsynsmodellen är HITL eller HOTL, motiveringen, eskaleringsvägen och den namngivna person som är ansvarig enligt SM&CR (Storbritannien) eller motsvarande nationellt regelverk. Där svaret är oklart, tillämpa HITL som standard tills analysen är klar.

Vecka 5–6 – Bygg eller härda agentkontrollplanet. Åtgärdsloggning i realtid, detektering av beteendeavvikelser samt vägar för nödstopp och åsidosättning i drift på varje produktionsagent. Där kontrollplanet ännu inte finns för ett system försätts det systemet i status för begränsad driftsättning tills det gör det.

Vecka 7–8 – Granskning av leverantörsavtal. Juridik och upphandling går igenom varje aktivt AI-leverantörsavtal med avseende på dokumentationsrättigheter enligt artikel 13, avisering om modelländringar, incidentrapportering, revisionsrätt och redovisning av underleverantörer. Resultatet är en nivåindelad lista: efterlevande, åtgärd krävs, ersättning krävs. Beslut om ersättning behöver inledas nu för att ha någon chans att slutföras i år.

Vecka 9–10 – Öva igenom bedömningen av överensstämmelse. För varje högrisksystem enligt bilaga III, genomför arbetsflödet för bedömning av överensstämmelse som om ett anmält organ skulle komma veckan därpå. Detta får luckor att komma fram som ser mindre ut på papperet men är operativt allvarliga vid en granskning. Åtgärda det som kan åtgärdas; dokumentera det som återstår.

Vecka 11–12 – Validering före övergång och styrelsegodkännande. Slutlig genomgång av AIBOM, HITL/HOTL-klassificeringarna, beläggen för kontrollplanet, statusen för leverantörsåtgärder och utfallen från bedömningen av överensstämmelse. Namngivet ansvar på senior manager-nivå bekräftat. För in ståndpunkten i styrelseprotokollet. Underrätta tillsynsmyndigheten där regelverket förväntar sig föranmälan.

De institut som slutför denna tolv veckor långa sekvens kommer inte att ha löst agentisk ingenjörskonst. De kommer att ha etablerat det golv som ett trovärdigt program kräver. De institut som inte har börjat när den här artikeln publiceras är inte, som Regulativs analys uttryckte samma poäng på SWIFT-sidan, unikt försumliga. De är majoriteten. Frågan som varje CCO, CRO och CTO behöver besvara under de kommande två veckorna är om företaget agerar i maj eller får panik i juli.

Slutsats

Den hårda observation som har kristalliserats i hela branschen de senaste sex månaderna är att de gamla sätten att operera i företagsskala överträffas inte av en ny teknik utan av ett nytt arbetsmönster. Agentiska verktyg har blottlagt, ibland i produktion, ibland i incidentrapporter, brister och luckor i äldre systembestånd som i tysthet har ackumulerats i åratal. Samma verktyg har gett illasinnade aktörer de resurser som tidigare krävde stöd från statliga aktörer. Samma verktyg, använda internt och med disciplin, är den mest trovärdiga väg instituten har för att sluta gapet mot äldre system, uppfylla den regulatoriska tidsfristen i augusti 2026 och nå det operativa tempo som kundernas förväntningar och konkurrensverkligheten nu kräver.

De institut som äger denna position internt, som behandlar agentisk ingenjörskonst som en strukturell förmåga hos banken snarare än ett produktivitetslager upphandlat från en leverantör, kommer att tillbringa de kommande två åren med att bygga upp fördelar. De institut som inte gör det kommer att tillbringa de kommande två åren med att upptäcka, i incidentrapporter och anmärkningar från tillsynsmyndigheter, vad de borde ha byggt. Valet mellan dessa två utfall är ett styrelsebeslut för 2026, inte ett teknikbeslut för 2028.

För tidigare sammanhang på denna sajt: april 2026-artikeln om kvanttrösklar behandlade den hårdvarubana som underbygger lager 1 i arkitekturen ovan, maj 2026-artikeln om postkvantmigration för företagsfinans behandlade det kryptografiska substratet på djupet, maj 2026-analysen av pacs.008-tidsfristen för strukturerade adresser behandlade den regulatoriska och ingenjörsmässiga disciplin som specifikationsdriven validering gör hanterbar, och det öppna Rust-arbetet med KyberLib, pain001 och pacs008 ingår i den bredare strävan att lägga primitiver av produktionskvalitet, kvantsäkra, betalningskompatibla och redo för revision, i händerna på de ingenjörsteam som ska bygga den agentiska banken. Kopplingen mellan dessa artiklar är inte en tillfällighet. Den är formen på det arbete de kommande två åren kräver.

Vanliga frågor

Vad är skillnaden mellan generativ AI, agentisk AI och agentisk ingenjörskonst?

Generativ AI producerar innehåll som svar på en prompt; den är reaktiv. Agentisk AI eftersträvar definierade mål autonomt, får åtkomst till data, använder verktyg och vidtar åtgärder över flerstegsarbetsflöden utan att kräva en mänsklig prompt i varje steg. Agentisk ingenjörskonst, det begrepp som Karpathy anammade 2026 ⧉, är arbetsdisciplinen att orkestrera agenter mot detaljerade specifikationer under mänsklig tillsyn. För banksektorn spelar distinktionen roll eftersom den regulatoriska perimetern, hotmodellen och ingenjörsdisciplinen skiljer sig åt för varje kategori. Ett chattgränssnitt och en fullt autonom handelsagent tillhör inte samma regulatoriska klass, och att behandla dem som om de gjorde det skapar exponering i båda ändar.

Varför är augusti 2026-tidsfristen i EU:s AI Act så avgörande för banker?

Bilaga III i AI Act klassificerar uttryckligen flera centrala AI-användningsfall inom bank som högrisk: bedömning av kreditvärdighet och kreditvärdering av fysiska personer, riskbedömning och prissättning inom liv- och sjukförsäkring samt utvärdering eller klassificering av enskildas ekonomiska ställning. Från och med den 2 augusti 2026 måste de som tar dessa system i bruk visa efterlevnad av kvalitetsledningssystem, ramverk för riskhantering, teknisk dokumentation, bedömningar av överensstämmelse, registreringar i EU:s databas, robust datastyrning, mänsklig tillsyn och skydd för cybersäkerhet. Artikel 12 kräver automatisk loggning av in- och utdata. Artikel 14 kräver meningsfull mänsklig tillsyn (HITL eller HOTL, beroende på systemet). Sanktionsavgifterna vid överträdelse uppgår till 35 miljoner euro eller 7 % av den globala årsomsättningen. Arbetet med att uppfylla dessa skyldigheter är ingenjörsarbete, inte dokumentationsarbete, och det är det praktiska skälet till att den specifikationsdrivna disciplinen har accelererat under första kvartalet 2026.

Vad är den praktiska skillnaden mellan HITL och HOTL, och när bör var och en tillämpas?

HITL (Human-in-the-Loop) innebär att agenten inte kan utföra betydelsefulla åtgärder utan uttryckligt mänskligt godkännande. HOTL (Human-on-the-Loop) innebär att agenten agerar autonomt inom avgränsade parametrar, med människor som övervakar telemetri och behåller befogenheten att stoppa när som helst. Artikel 14 i EU:s AI Act kräver att tillsynen är meningsfull men föreskriver inte vilken modell. Beslutsregeln är att tillämpa HITL där åtgärden är betydelsefull, lågvolym och oåterkallelig (kreditavslag, kontoavslut, auktorisering av högvärdesöverföring, inlämnande av regulatorisk rapport), och HOTL där åtgärden har hög volym, är reversibel och parameteravgränsad (larm från transaktionsövervakning, dokumentklassificering, rutinmässig triage i kundtjänst). Båda kräver att infrastrukturen för nödstopp och åsidosättning är i drift och testad; skillnaden är om människan finns uppströms om utförandet (HITL) eller vid sidan av det (HOTL).

De flesta av våra agenter kommer från leverantörer. Hur uppfyller vi DORA och EU:s AI Act för system vi inte har byggt?

Det regulatoriska ansvaret ligger hos den som tar systemet i bruk, inte hos leverantören. Det praktiska svaret är tredelat. För det första, kräv en dokumenterad AIBOM från leverantören före undertecknande: modellhärkomst, träningsdatans ursprung, finjusteringar, promptmallar, hämtningsindex, beroendekedja. För det andra, genomför beteendetestning av agenten under förhållanden som liknar produktion, inklusive antagonistisk sondering för promptinjektion och motståndskraft mot social manipulation. För det tredje, omförhandla leverantörsavtalen så att de omfattar dokumentationsrättigheter enligt artikel 13, avisering om modelländringar, incidentrapportering, revisionsrätt och redovisning av underleverantörer; de flesta befintliga avtal har inget av detta. DORA artiklarna 28–30 omfattar hanteringen av IKT-risker hos tredje part och är det relevanta regulatoriska ankaret på den europeiska sidan; FFIEC-vägledningen är motsvarigheten på den amerikanska sidan. Arbetet är omfattande; det kan inte skjutas upp.

Hur oroliga bör banker egentligen vara för agentiska motståndare?

Det ärliga svaret är att hotet är verkligt och operativt skilt från tidigare cyberhot. Anthropics avslöjande av GTG-1002 i november 2025 är det kanoniska exemplet: agentisk AI som hanterar 80–90 % av de taktiska operationerna i en statsunderstödd spionagekampanj mot omkring trettio mål inom försvar, energi och teknik, med tusentals förfrågningar per sekund. Step Finance-incidenten i januari 2026, en förlust på 27–30 miljoner dollar orsakad av AI-handelsagenter med överdriven behörighet, är det kanoniska exemplet på hur en intern AI-driftsättning kan bli en angreppsyta. Flashpoints 2026 GTIR noterade en ökning på 1 500 % av illegala AI-relaterade diskussioner under en enda månad. Detta är inte hypotetiska scenarier; det är material från incidentrapporter 2025–2026. Banker som bedriver klassiska försvarsoperationer mot agentiska motståndare är strukturellt asymmetriskt exponerade, och det korrekta svaret är att bygga en försvarsförmåga av typen AI-mot-AI snarare än att bromsa den agentiska övergången på angreppssidan.

Är agentisk AI bara ”ChatGPT plus MCP-servrar”?

Nej, och detta är en av de mest följdriktiga missuppfattningarna på dagens marknad. Ett chattgränssnitt utökat med MCP-servrar är ett användbart mönster för att hämta och agera på data inom en avgränsad session. Agentisk ingenjörskonst är en strukturell förmåga hos institutet: AIBOM, agentkontrollplanet, pipelinen för specifikationsdriven utveckling, revisionssubstratet, den kvantsäkra kryptografiska grunden och orkestreringsmönstren över kundresor från början till slut. Detta är inte funktioner köpta från en leverantör; det är en institutionell ägarposition. Banker som behandlar frågan som ett upphandlingsbeslut hamnar med ytliga driftsättningar som fallerar vid granskning. Banker som behandlar den som en fråga om ägarskap över ingenjörskonst och styrning hamnar med en tillgång som bygger på sig själv.

Vad är det enskilt viktigaste en bank bör göra under de kommande tolv veckorna?

Tre saker, i sekvens. För det första, ta fram AI Bill of Materials: den fullständiga förteckningen över varje AI-system, modell, datamängd, promptmall, hämtningsindex och tredjeparts-AI-beroende i produktion eller under utveckling, med varje post klassificerad mot bilaga III i EU:s AI Act. Det institut som inte kan ta fram denna när en tillsynsmyndighet begär den är det institut som kommer att få anmärkningar. För det andra, bygg agentkontrollplanet för varje AI-system som för närvarande fattar eller väsentligt påverkar beslut som berör kunder: revisionsloggning, detektering av beteendeavvikelser, mänsklig åsidosättning och nödstopp som standardinfrastruktur, inte som en framtida punkt på färdplanen. För det tredje, flytta den interna ingenjörskulturen från vibe coding till specifikationsdriven utveckling i det arbete som betyder mest: högrisksystem, reglerade arbetsflöden och pipelinen för modernisering av äldre system. De två första är efterlevnadsarbete; det tredje är konkurrensarbete. De institut som gör alla tre kommer att stå i en väsentligt starkare position än de som gör ett eller inget. Den fullständiga tolv veckor långa sekvensen beskrivs i handlingsplansavsnittet ovan.

Referenser

Sebastien Rousseau, (2026). Säkra huvudboken: en vägledning på styrelsenivå för postkvantmigration inom företagsfinans.
Sebastien Rousseau, (2026). pacs.008-tidsfristen för strukturerade adresser i november 2026: en sexmånadersvy.
Sebastien Rousseau, (2026). Kvanttrösklarna rör sig igen.
Sebastien Rousseau, (2023). CRYSTALS-Kyber: skyddsalgoritmen i kvantåldern.
Mansurova, M. (2026). From Vibe Coding to Spec-Driven Development ⧉. Towards Data Science.
CGI, (2026). Spec-driven development: From vibe coding to intent engineering ⧉. CGI.
Augment Code, (2026). What Is Spec-Driven Development? A Complete Guide ⧉. Augment Code.
BCMS, (2026). Spec-Driven Development: The Definitive 2026 Guide ⧉. BCMS.
Deloitte, (2026). Managing the new wave of risks from AI agents in banking ⧉. Deloitte Center for Financial Services.
Anthropic, (2025). Detecting and countering misuse of AI: August 2025 ⧉. Anthropic.
Anthropic, (2025). Disrupting the first reported AI-orchestrated cyber espionage campaign ⧉. Anthropic.
Flashpoint, (2026). 2026 Global Threat Intelligence Report ⧉. HSToday / Flashpoint.
Beam AI, (2026). 5 Real AI Agent Security Breaches in 2026 and Their Lessons ⧉. Beam.
Congressional Research Service, (2026). Agentic Artificial Intelligence and Cyberattacks ⧉. Congress.gov.
Europeiska kommissionen, (2024). Förordning (EU) 2024/1689 om artificiell intelligens (EU:s AI Act).
Knowlee, (2026). EU AI Act for Financial Services: Annex III Obligations for Banks, Fintechs, and Insurers ⧉. Knowlee.
Regulativ, (2026). The EU AI Act's August 2026 Deadline: What Financial Services Firms Must Do Now ⧉. Finextra.
AegisAI Compliance, (2026). AI Governance for Banks: SR 11-7 & EU AI Act Compliance Guide ⧉. AegisAI.
The Financial Brand, (2026). How Autonomous AI Agents Will Really Redefine Banking Growth ⧉. The Financial Brand.
UXDA, (2026). Could Agentic AI Banking Threaten Global Financial Services? ⧉. UXDA.
Neurons Lab, (2026). Agentic AI in Financial Services: A Research Roundup for 2026 ⧉. Neurons Lab.
Computer Weekly, (2026). AI to help mainframes remain business critical in 2026 ⧉. Computer Weekly.
The Financial Revolutionist, (2026). Legacy systems are putting banks at risk ⧉. The Financial Revolutionist.
CIO Magazine, (2025). Using AI to modernize mainframes: Turning legacy tech into a strategic advantage ⧉. CIO Magazine.
Microsoft Azure, (2025). How We Use AI Agents for COBOL Migration and Mainframe Modernization ⧉. Microsoft DevBlogs.
VentureBeat, (2026). Agentic coding at enterprise scale demands spec-driven development ⧉. VentureBeat.
The News (Pakistan), (2026). Why British banks' push for agentic AI is worrying UK regulators ⧉. The News International.
CNBC, (2026). Anthropic's Mythos set off a cybersecurity 'hysteria' ⧉. CNBC.

Senast granskad 2026-08-06.

Återpublicera den här artikeln

Agentisk ingenjörskonst för banker: en plan för 2026 för företagsledningen och ingenjörerna som ska bygga den — Sebastien Rousseau

Agentisk AI har gått från pilot till produktion i banksektorn världen över. 70 % av instituten använder den i någon utsträckning; bara ett av fem har en mogen styrningsmodell. Samtidigt opererar autonoma motståndare i maskinhastighet, det äldre COBOL-beståndet som de nya systemen måste samverka med skrevs för 1960-talets antaganden om batchbearbetning, och EU:s AI Act har tolv veckor kvar till sin högrisktidsfrist i augusti 2026. Detta är den ingenjörs- och styrningsposition en bank behöver hålla.

Den här artikeln är licensierad under Creative Commons Attribution 4.0 International. Återpublicering kräver attribution till den kanoniska URL:en.

Agentisk ingenjörskonst för banker: en plan för 2026 för företagsledningen och ingenjörerna som ska bygga den — Sebastien Rousseau

Agentisk AI har gått från pilot till produktion i banksektorn världen över. 70 % av instituten använder den i någon utsträckning; bara ett av fem har en mogen styrningsmodell. Samtidigt opererar autonoma motståndare i maskinhastighet, det äldre COBOL-beståndet som de nya systemen måste samverka med skrevs för 1960-talets antaganden om batchbearbetning, och EU:s AI Act har tolv veckor kvar till sin högrisktidsfrist i augusti 2026. Detta är den ingenjörs- och styrningsposition en bank behöver hålla.

Originally published at https://sebastienrousseau.com/sv/2026-05-17-agentisk-ingenjorskonst-banker-blueprint-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER