Agentic Treasury har brug for en kill switch: Design autopilot som et anlæg

Jeg har intet imod autonomi. Jeg har brugt år omkring systemer, der kører uden at spørge om lov hvert minut. Frekvensomformere regulerer motorer. Konvertere stabiliserer processer. Building controls holder brugere komfortable. De systemer kan man have tillid til, fordi de er konstrueret som anlæg: med tydelige operating envelopes og hårde stop.

Treasury bevæger sig mod det samme punkt. Agentic AI flytter løftet fra “copilot” til “autopilot” i funktioner som cash positioning, forecasting, payments og exception handling, som beskrevet i Finextra’s gennemgang af agentic AI’s effekt på treasury. Ambitionen er forståelig. Risikoen er også åbenlys: i modsætning til en rapport eller et dashboard ændrer treasury-handlinger verden. De flytter penge, skaber eksponering og udløser kontraktlige forpligtelser.

Mit syn er kontant. Hvis du ikke kan stoppe agenten sikkert, bør du ikke lade den styre. Agentic treasury har brug for en kill switch, og den skal designes på samme måde, som vi designer sikker autonomi i industrielle miljøer: lagdelte kontroller, auditérbar adfærd og en nedlukning, der er øvet på forhånd.

Fejlslutningen om treasury-autopilot: “Det er software, så vi kan jo bare patche”

I industriel teknologi regner vi med fejl. Ikke fordi teamet er svagt, men fordi virkeligheden er rodet. Sensorer driver. Netværk jitter. Operatører improviserer. Leverandører ændrer komponenter. Processen forbliver sikker, fordi vi begrænser autonomien.

Da jeg arbejdede med power electronics til automation, vand og spildevand samt HVAC, betragtede vi aldrig styringslogik som “smart”. Vi betragtede den som ansvarlig. Hvis en variabel kom uden for grænserne, degraderede systemet kontrolleret eller lukkede ned. Det diskuterede ikke. Det rationaliserede ikke. Det eksekverede en defineret sikkerhedsadfærd.

Agentic AI introducerer en anden fejltype. Det er ikke kun “forkert output”. Det er “forkert handling”. Det kan også være rigtigt af de forkerte grunde, hvilket gør post-mortems svære, hvis du ikke kan replaye den præcise beslutningssti.

Så før du spørger, hvad agenten kan, så spørg, hvad den aldrig må. I treasury er “aldrig”-listen typisk kort og ikke til forhandling. Det er der, dit design begynder.

Konstruér autonomi i gates, ikke gradients

Operatører siger ofte: “Vi starter småt og øger autonomien over tid.” Det lyder fornuftigt, men det skjuler en fælde. Hvis autonomi er en glidende skala, ender du med uklart ansvar. Hvis autonomi er gated, får du rene kontrolpunkter.

Her er et mønster, jeg bruger—lånt fra industriel commissioning og tilpasset AI-agenter:

1. Observe mode: agenten læser data og producerer anbefalinger. Ingen side effects. Alt logges.
2. Propose mode: agenten forbereder eksekverbare artefakter (betalingsbatches, hedge-forslag, cash sweeps), men kan ikke indsende dem. Et menneske godkender.
3. Constrained execute mode: agenten kan eksekvere inden for stramme limits (beløb, modpart, valuta, tidsvindue og formål). Exceptions ryger i en kø.
4. Supervised autopilot: agenten eksekverer inden for et bredere envelope, men kun under real-time monitoring og med automatiske trip conditions.

Nøglen er, at hver gate har eksplicitte entry-kriterier og eksplicit rollback. Hvis du ikke kan beskrive gaten på én side, har du ikke en gate. Du har håb.

Det er her, meget “AI governance” kollapser i møder. Jeg foretrækker at bygge selve operating system i stedet. Hvis du vil have en praktisk vinkel, er mit indlæg om AI architecture som operatørens tjekliste den samme idé anvendt på tekniske designvalg.

Replaybar auditability: treasury’s svar på en flight recorder

I produktion og industriel drift debugger man ikke ud fra hukommelsen. Man debugger ud fra spor. Man ser på events, timestamps, sensorværdier, setpoints, operatørhandlinger og alarmer.

Treasury har brug for samme disciplin, hvis en agent er involveret. “Modellen foreslog det” er ikke et audit trail. “Agenten eksekverede det” er ikke en forklaring.

Replaybar auditability betyder, at du deterministisk kan rekonstruere, hvad agenten så, og hvad den gjorde. Ikke med screenshots. Med strukturerede logs. Du skal kunne besvare spørgsmål som:

• Hvilke datakilder blev brugt til beslutningen, og hvad var deres timestamps?
• Hvilke policy-regler var gældende (limits, approvals, segregation of duties)?
• Hvilke tool calls blev foretaget (ERP, TMS, bank-API’er), og hvad var svarene?
• Hvilke usikkerheds- eller confidence-signaler var til stede, og hvilke thresholds gjaldt?
• Hvilke alternative handlinger blev overvejet og fravalgt—og hvorfor?

Da jeg ledede en international forretningsenhed inden for smart-building controls, skabte forbundne enheder endeløse “måske”-diskussioner, medmindre vi havde skarp telemetry og event logs. I det øjeblik vi gjorde adfærd observerbar, blev reliability en driftsdisciplin—ikke en debat. Agentic treasury vil følge samme spor.

Helt praktisk vil jeg have to artefakter for hver autonom handling:

• Et execution record: hvad der blev gjort, hvornår, af hvilken identitet og med hvilke rettigheder.
• Et decision record: hvilke input, constraints og rationale der førte til handlingen—fanget på en måde, så det kan replayes.

Hvis du ikke kan replaye det, kan du ikke forbedre det. Og hvis du ikke kan forklare det, bør du ikke automatisere det.

Kill switch: ikke en knap, men en testet procedure

De fleste teams behandler en kill switch som et UI-element. En toggle. En stor rød knap. I anlæg er en stopmekanisme et komplet design: hvor den er forbundet, hvad den afbryder, hvilken tilstand systemet går i, og hvordan du kommer sikkert tilbage.

En kill switch i treasury skal dække mere end “stop fremtidige handlinger”. Den skal håndtere handlinger undervejs, delvise submissions og reconciliation. Ellers stopper du agenten og arver stadig blast radius.

Her er det minimum viable design, jeg anbefaler til bestyrelser og operatører:

• Tre uafhængige stopveje: pause på applikationsniveau, credential revocation (API keys, tokens) og bank-side kontroller (limits, whitelists, call-backs). Uafhængighed er afgørende. Ét defekt lag må ikke forhindre stop.
• Automatiske trip conditions: usædvanlig volumen, nye modtagere, aktivitet uden for vinduer, gentagne retries, reconciliation-mismatches og brud på data freshness. Stol ikke på, at mennesker opdager drift.
• En definition af safe state: hvad der sker med pending batches, queued approvals og retries, når der stoppes. Safe state skal være eksplicit.
• Et recovery runbook: hvem der tjekker hvad, i hvilken rækkefølge, før autonomi genoptages. Inkludér kommunikationsskridt. Inkludér reconciliation-skridt.
• Kvartalsvise fire drills: I simulerer et dårligt scenarie og trækker i stop. Hvis I aldrig tester, fejler det, når I har brug for det.

Det er samme mindset, jeg brugte, da jeg havde ansvar for drift inden for electrification og energy storage. Du kan ikke opfinde din nødprocedure midt i nødsituationen. Du træner den ind i organisationen.

Den hurtigste måde at gøre det her konkret på er at behandle din agent som et aktiv i en produktionslinje. Giv den en ejer. Giv den en vedligeholdelsesplan. Giv den alarmer og escalation. Giv den en shutdown-protokol. Hvis du ikke gør det, vil den opføre sig som shadow IT med en bankforbindelse.

Et bestyrelses-lens til beslutning, du kan bruge i dette kvartal

Hvis du sidder i en bestyrelse, eller du driver treasury, har du ikke brug for en modeldebat. Du har brug for en kontrolbeslutning. Det her er den tjekliste, jeg ville bruge i et godkendelsesmøde:

1. Scope: Hvilke beslutninger må agenten træffe, og hvilke er permanent human-only?
2. Envelope: Hvad er de hårde limits (beløb, modpart, valuta, timing, formål)?
3. Observability: Kan vi replaye enhver autonom handling end-to-end inden for 24 timer?
4. Separation of duties: Hvem kan ændre policies, hvem kan deploye, hvem kan godkende exceptions, hvem kan stoppe den?
5. Stop design: Har vi uafhængige stopveje, safe state-adfærd og et recovery runbook?
6. Drills: Hvornår er næste kill-switch test, og hvem signerer resultaterne?

Hvis du ikke kan svare klart på de seks, så ship ikke “autopilot”. Bliv i propose mode og harden systemet.

Det er også derfor, jeg kan lide at trække paralleller til bankability i infrastruktur. I energiprojekter får du ikke finansiering ved at love performance. Du får den ved at dokumentere kontroller og containment af downside. Den samme logik gælder for autonomi i finans. Jeg skrev om den tilgang i making grid-scale storage bankable. Anden industri, samme operator-matematik.

Min holdning: autonomi fortjenes, den aktiveres ikke

Agentic AI kan absolut skabe værdi i treasury. Men kun hvis du behandler det som en industriel proces—ikke som en feature. Gated autonomy slår bred autonomi. Replay slår mavefornemmelser. En testet kill switch slår et policy-dokument.

Hvis du vil have upside, så betal for kontrollerne. Det er trade-off’et. Min erfaring er, at teams, der tager det valg tidligt, rykker hurtigere senere, fordi de bruger mindre tid på at diskutere og mere tid på at eksekvere sikkert.

Autopilot er ikke en capability. Det er et kontrolsystem med en stopprocedure.

Byg det som et anlæg, og du kan lade det køre. Byg det som en chatbot, og du vil før eller siden blive tvunget til at slukke det.