Vi er en mellomstor offentlig virksomhet som vurderer å innføre agentisk KI som kan utføre autonome handlinger på tvers av interne systemer, API‑lag, dataplattformer og eksterne tjenester. Agentene vil kunne initiere prosesser, endre data, trigge hendelser, utføre skript og samhandle med tredjeparts‑API‑er uten eksplisitt menneskelig godkjenning for hvert steg.
Teknisk kontekst og begrensninger
---
Uavklarte tekniske beslutninger
---
Spørsmål:
Arkitektur og kontroll
IAM og tilgangsstyring
Integrasjoner og API‑sikkerhet
Logging, revisjon og hendelseshåndtering
Blindsoner og risiko
45 KI-instanser angrep denne problemstillingen parallelt, fordelt på 5 modeller. Hver instans fikk en unik frequency seed — fem vektede ord som farger perspektivet. Resultatet er 5 uavhengige debriefer du kan sammenligne her.
| Modell | Inst. | Tokens inn | Tokens ut | Kostnad | |
|---|---|---|---|---|---|
| Claude Opus 4.6 | 9 | 25,049 | 10,654 | $0.392 (kr 3,67) | |
| Claude Sonnet 4.6 | 9 | 23,118 | 8,637 | $0.199 (kr 1,86) | |
| Gemma Medium | 9 | 19,889 | 7,555 | $0.004 (kr 0,04) | |
| Mistral Large | 9 | 28,617 | 16,608 | $0.335 (kr 3,14) | |
| GPT-5.4 Mini | 9 | 18,866 | 7,311 | $0.166 (kr 1,56) |
Vent vs. implementer nå. Seks instanser (SI_001–003, 006–008) sier vent — bygg fundament først. To instanser (SI_005, SI_009) sier implementer kontrollert med minimal kontrollamme, fordi venting dreper momentum og læringsvindu. SI_004 lander midt i mellom: bygg kill-infrastruktur først, utforsk i skyggemodus.
Startpunkt: Juridisk eller teknisk? SI_007 og SI_008 krever juridisk sonekartlegging (forvaltningsloven, EU AI Act) før teknisk arkitektur. Øvrige starter med tekniske kontroller. Denne spenningen er uløst og kritisk for offentlig sektor.
Ambisjonsnivå for kontrollplanet. SI_009 argumenterer for at 500k og en PostgreSQL-tabell er nok til å starte. SI_002 og SI_003 krever OPA, ABAC-oppgradering og full event-sourcing som forutsetning. Ressursrealismen spriker.
Seeds: strategisk | kortsiktig | samarbeid | mulighet | vent
Min dissens er tydelig: dere bør ikke innføre agentisk KI i produksjon innenfor 6–9 måneder. Ikke fordi muligheten er dårlig, men fordi timingen er feil gitt deres tekniske gjeld. Å rulle ut autonome agenter uten konsolidert logging, uten policy-motor, uten Zero Trust, i et landskap med ikke-deterministiske API-er — det er ikke innovasjon, det er ukontrollert risiko i en offentlig virksomhet.
Vent ≠ passivitet. Vent = bruk pilotvinduet til å bygge fundamentet, ikke agenten.
Kortsiktig (0–6 mnd) — invester i kontrollplanet:
Samarbeid som akselerator:
Kjør agenter i read-only sandkasser mot produksjonsdata (anonymisert). La dem foreslå handlinger uten å utføre dem — «human-in-the-loop» for 100 % av skriveoperasjoner. Dette gir:
Oppsummert: Muligheten er reell, men strategisk tålmodighet er det som skiller kontrollert innføring fra en hendelse dere må forklare til Riksrevisjonen.
Seeds: strategisk | langsiktig | makt | mulighet | vent
Mitt perspektiv, formet av vent og strategisk, bryter med mainstream-entusiasmen: En mellomstor offentlig virksomhet med fragmentert logging, ufullstendig ABAC, ingen OPA, ingen Zero Trust og begrensede DevSecOps-ressurser har ikke den institusjonelle makten til å kontrollere autonome agenter. Å pilotere innenfor 6–9 måneder er ikke en mulighet — det er en felle.
Maktanalyse: Agentisk KI omfordeler beslutningsmakt fra mennesker til programvare. I et system uten konsolidert audit-pipeline og med legacy-monolitter uten deterministiske API-kontrakter, gir dere makt til aktører dere ikke kan observere, begrense eller reversere. Det er ikke innovasjon — det er abdikasjon.
Langsiktig kostnad vs. kortsiktig gevinst: En mislykket pilot med datakorrupsjon, runaway agents eller GDPR-brudd via ukontrollerte eksterne API-kall vil sette organisasjonens KI-ambisjon tilbake 3–5 år. Den politiske og omdømmemessige risikoen i offentlig sektor er asymmetrisk — nedsiden er katastrofal, oppsiden er inkrementell.
Emergent behavior i svake systemer: Systemer uten idempotens, uten transaksjonsgarantier og med latent kobling mellom fagsystemer er designet for uforutsette kjedereaksjoner. Å slippe autonome agenter inn her er å teste worst-case i produksjon.
I stedet for å pilotere agentisk KI, bruk de 6–9 månedene til å bygge infrastrukturen som gjør agentisk KI mulig langsiktig:
Disse tre tiltakene gir dere makt til å kontrollere agenter når dere er klare, og de leverer umiddelbar sikkerhetsverdi.
Kjernebudskap: Den største strategiske muligheten er å ikke være først. Vent, bygg makt gjennom infrastruktur, og innfør agentisk KI fra en posisjon av kontroll — ikke håp.
Seeds: operasjonell | langsiktig | makt | usikkerhet | implementer
La meg være direkte: Dere er i ferd med å innføre en ny maktaktør i systemlandskapet. En agent som kan endre data, trigge prosesser og kalle eksterne API-er er ikke et verktøy — den er en operatør med delegert myndighet. Spørsmålet er ikke om noe går galt, men hvor lenge det tar før en feilkjede eskalerer forbi menneskelig reaksjonstid.
Konsensussvaret er "implementer OPA, Zero Trust og audit-pipeline." Mitt perspektiv: med 6–9 måneder, begrenset DevSecOps og fragmentert logging har dere ikke kapasitet til å bygge kontrollregimet som agentisk KI krever. Å implementere agenter før kontrollplanet er modent er å gi fra seg operasjonell makt under maksimal usikkerhet.
Implementer kontrollplanet først, agentene etterpå:
Worst case er ikke at agenten gjør én feil. Det er at den gjør 200 feil i løpet av 30 sekunder mot et fagsystem uten rate-limiting, og at ingen oppdager det fordi logging er distribuert. Modeller dette eksplisitt: hva skjer dersom agenten looper mot Folkeregisteret, økonomisystemet, arkivsystemet?
Seeds: operasjonell | langsiktig | makt | sårbarhet | utforsk
Kjerneproblemet er ikke teknisk — det er at dere er i ferd med å delegere operasjonell makt til aktører uten ansvarsfølelse. Hver agent som kan endre data, trigge hendelser og kalle eksterne API-er utøver makt i systemlandskapet. Spørsmålet er: hvem eier konsekvensene?
Systemlandskapet deres er sårbarheten. Legacy-monolitter uten deterministiske API-kontrakter betyr at agenten opererer i et miljø der kontrakten mellom intensjon og effekt er ukjent. Dette er fundamentalt annerledes enn å gi en utvikler tilgang — utvikleren stopper når noe virker rart. Agenten gjør det ikke.
Konkret blindsone: Ikke-idempotente endepunkter i fagsystemer. En agent som retrier et mislykket kall kan opprette 47 vedtak i stedet for ett. Uten transaksjonelle garantier i mottakersystemet er dette uløselig med policy-as-code alene.
Mainstream-svaret er OPA, Zero Trust, ABAC. Men med 6-9 måneders pilot og begrensede ressurser er dette arkitekturastronomi. Min anbefaling:
Innen 2-3 år vil agentene bli operasjonelt uunnværlige — og da mister dere forhandlingsmakt over arkitekturen. Det dere aksepterer som «midlertidig pilot-kompromiss» blir permanent. Krev at audit-pipeline og rollback-mekanismer er produksjonsklare før agenter får skrivetilgang. Ikke etter.
En agent som gradvis korrelerer data på tvers av systemer den har lesetilgang til, og dermed konstruerer persondatasett som ingen enkelt tilgang skulle tillate. GDPR-risikoen er ikke i skriveoperasjonen — den er i aggregert lesetilgang.
Seeds: strategisk | kortsiktig | makt | sårbarhet | implementer
La meg være direkte: Dere er i ferd med å delegere makt — evnen til å endre data, trigge prosesser, kalle eksterne tjenester — til en aktør uten dømmekraft. I et landskap med legacy-monolitter uten deterministiske kontrakter er dette ikke et arkitekturprosjekt. Det er et sårbarhetsskapende prosjekt dersom det gjøres feil.
Innenfor 6–9 måneder kan dere ikke bygge Zero Trust, sentralisert policy-motor, konsolidert audit-pipeline og safe execution environments. Alle som sier noe annet, selger. Dere må velge én kontrollflate og implementere den knallhardt.
Min dissens: Ikke start med arkitekturprinsipper. Start med å kartlegge de 5–10 konkrete handlingene agenten skal utføre, og bygg et eksplisitt allow-list-regime. Alt annet er blokkert. Ingen default-tilgang, ingen implisitt tillit.
1. Agent Proxy Gateway (uke 1–6)
Sett en dedikert proxy foran alle agent-interaksjoner. Agenten snakker aldri direkte med fagsystemer. Proxyen har:
2. Ephemeral credentials med 15-minutters TTL (uke 4–8)
Ingen persistent service account. Agenten får scoped tokens fra HashiCorp Vault med eksplisitt policy-binding per sesjon. Nøkkelrotasjon hver 15. minutt. Ved anomali: revoke umiddelbart.
3. Kill switch og blast radius (uke 2–4)
Implementer en hard kill switch — et enkelt API-kall eller Slack-kommando som terminerer alle aktive agent-sesjoner innen 2 sekunder. Definer blast radius: agenten får aldri tilgang til systemer med integritetsklasse høy (folkeregister, økonomi, helse) i piloten.
Seeds: strategisk | historisk | tillit | sårbarhet | implementer
Historisk har offentlig sektor gjentatte ganger innført teknologi med autonomi før kontrollregimet var modent. NAVs Hades-system på 90-tallet, Storbritannias Horizon-skandalen (Post Office), og Boeing 737 MAX-autopiloten viser alle samme mønster: systemer fikk handlekraft før tilliten var forankret i verifiserbare strukturer. Dere står ved nøyaktig samme veiskille.
Mainstream-rådet er å bygge guardrails rundt agenter. Mitt perspektiv er skarpere: behandle enhver KI-agent som en upålitelig intern aktør fra dag én. Ikke fordi teknologien er ondsinnet, men fordi sårbarhetsflatene i deres landskap — legacy-monolitter uten deterministiske API-kontrakter, distribuert logging, fraværende policy-motor — gjør at tillitsantagelser vil kollapse under press.
1. Implementer «Mistillitsbudsjettet»: Hver agent får et kvantifisert handlingsrom — maks 15 skriveoperasjoner/time, maks 3 systemer per kjede, 0 eksterne API-kall uten human-in-the-loop. Bruk OPA som runtime-policy-motor, men start med en hardkodet allow-list, ikke deny-list. Deny-lists er sårbare for det ukjente.
2. Execution graph som førsteklasses audit-objekt: Hver agenthandling genererer en uforanderlig DAG (directed acyclic graph) med prompt, mellomsteg, API-kall, respons og sideeffekter. Lagre i append-only event store (EventStoreDB eller enkel Kafka-topic med compaction=off). Dette er ikke logging — det er bevisføring.
3. IAM: Ephemeral, scoped, revocable. Agenter får aldri service accounts med statiske credentials. Implementer SPIFFE/SPIRE for workload-identitet, 15-minutters token-TTL, og automatisk revokering ved anomali. ABAC-policyer evalueres per kall, ikke per sesjon.
4. Circuit breaker med «sårbarhetsscore»: Hvert målsystem klassifiseres etter integritetsrisiko (1-5). Agenter som treffer systemer med score ≥3 utløser automatisk human-approval-gate. Legacy-monolitter starter på score 4.
Latent coupling via data: Agenten endrer felt X i system A. System B leser X via nattlig batch. Tre uker senere feiler System C. Denne kausalkjeden er usynlig i sanntid. Historisk er dette kilden til de verste feilene — ikke den akutte feilen, men den forsinkede.
Seeds: juridisk | langsiktig | makt | mulighet | utforsk
Kjerneproblemet er ikke teknisk. Det er et maktspørsmål. Når en autonom agent får skrivetilgang til fagsystemer i en offentlig virksomhet, delegerer dere faktisk offentlig myndighetsutøvelse til en ikke-menneskelig aktør. Forvaltningsloven § 2, offentleglova, arkivlova — ingen av disse forutser at en KI-agent initierer vedtaksrelevante prosesser. Denne juridiske blindsonen er farligere enn manglende OPA-policies.
Dissens mot mainstream: De fleste rammeverk starter med teknisk kontroll (Zero Trust, policy-as-code). Jeg argumenterer for at dere starter med juridisk handlingsromskartlegging — før én linje policy skrives.
Konkret: Klassifiser alle agenthandlinger i tre juridiske soner:
Dette er ikke bare risikostyring. Det er langsiktig institusjonell overlevelse. Riksrevisjonen vil om 3-5 år spørre: «Hvem fattet denne beslutningen?» Svaret kan ikke være «agent-42-ephemeral-token-x».
Den reelle muligheten ligger i grønn sone: agenter som utforsker datalandskapet, identifiserer inkonsistens, forbereder beslutningsgrunnlag. Her er gevinsten enorm og risikoen håndterbar. Piloten bør eksklusivt operere her.
For audit-pipeline: Krev juridisk bevisstandard, ikke bare teknisk logging. Hver agenthandling må ha: (a) beslutningsgrunnlag/prompt, (b) vurderte alternativer, (c) valgt handling, (d) faktisk systemrespons — i uforanderlig, signert hendelseslogg. Tenk Noark-kompatibel arkivering, ikke bare Elasticsearch.
Det undervurderte scenariet: latent kompetansetap. Når agenter håndterer kompleksitet i legacy-integrasjoner, mister organisasjonen gradvis evnen til å forstå egne systemer. Om 3 år eier dere ikke lenger kunnskapen om hvorfor ting fungerer. Dette er en irreversibel maktforskyvning fra organisasjon til leverandør/modell.
Seeds: juridisk | kortsiktig | makt | usikkerhet | vent
Mitt perspektiv er ubehagelig men nødvendig: vent.
En autonom agent som endrer data, trigger hendelser og kaller tredjeparts-API-er utøver makt — forvaltningsrettslig, operasjonelt og informasjonsmessig. I en offentlig virksomhet er maktutøvelse bundet av legalitetsprinsippet. Per i dag finnes det ingen norsk lovhjemmel som eksplisitt regulerer autonome agenters rett til å fatte eller iverksette beslutninger med rettsvirkning. EU AI Act artikkel 6/26 klassifiserer offentlig sektorbruk som høyrisiko, med krav (conformity assessment, human oversight, logging) dere ikke kan oppfylle innen 6–9 måneder gitt nåværende modenhet.
Dere mangler ikke én ting — dere mangler fem fundamentale lag samtidig: sentralisert policy-motor, Zero Trust, konsolidert audit, safe execution environments, og finmasket IAM. Å bygge disse parallelt med en agentisk pilot er ikke ambisiøst — det er hasard. Usikkerheten forsterkes av legacy-monolitter uten deterministiske API-kontrakter: agenten opererer i et landskap der dere selv ikke fullt ut kjenner sideeffektene av API-kall.
Pilotvinduet på 6–9 måneder tvinger frem snarveier. Typisk resultat: brede service accounts, manglende rollback, logging som «fikses etterpå». Hver snarvei blir juridisk gjeld — revisjonsfunn, Datatilsynet-pålegg, eller verre: en agent som endrer vedtaksdata i et fagsystem uten sporbar begrunnelse. Forvaltningsloven §§ 24–25 krever etterprøvbar begrunnelse. Hvordan begrunner en agent som har traversert 14 API-kall?
Worst-case er ikke at agenten gjør noe galt. Worst-case er at agenten gjør noe som ser riktig ut — men via en uforutsett koblingskjede (latent coupling) endrer data i et integritets-kritisk system, uten at noen oppdager det før virkningen materialiserer seg uker senere. Uten event-sourcing har dere ingen forensic-kapasitet.
Kjernebudskap: Usikkerhet er ikke et problem å løse med mer teknologi — det er et signal om å vente til fundamentet tåler vekten.
Seeds: økonomisk | kortsiktig | tillit | usikkerhet | implementer
Mainstream-rådet er å etablere Zero Trust, OPA, sentralisert logging og full IAM-redesign før første agent går live. Med 6–9 måneders pilotvindu og begrensede ressurser er dette en oppskrift på at ingenting blir implementert. Kostnaden ved å vente er reell: dere mister læringsdata, organisatorisk momentum og politisk vindu.
En mellomstor offentlig virksomhet har typisk 2–4 dedikerte sikkerhetsressurser. Full Zero Trust-arkitektur koster 8–15 MNOK og 18+ måneder. Dere har ikke råd til dette som forutsetning. I stedet: invester 500k–1M i en minimal kontrollamme som vokser iterativt.
Måned 1–2: Én agent, ett system, human-in-the-loop
Måned 3–5: Utvid med policy-guard
Måned 6–9: Kontrollert skrivetilgang
Dere vil aldri eliminere emergent behavior-risiko fullstendig. Den farligste blindsonen er latent kobling mellom legacy-systemer — en agent som oppdaterer felt X i monolitten kan trigge batch-jobb Y som ingen husker eksisterer. Modeller dette med pre-mortem: «agenten endret noe, og 48 timer senere oppdaget vi...»
Ledelse, datatilsyn og fagsystem-eiere trenger observerbare bevis på kontroll. En fungerende audit-logg fra pilot med 500 reelle transaksjoner er mer tillitvekkende enn en 80-siders sikkerhetsarkitektur.
Tempo vs. forsiktighet: SI_001/SI_003 anbefaler iterativ åpning basert på bevist adferd. SI_004/SI_006 argumenterer for at 6–9 måneder er for kort til å gjøre dette forsvarlig overhodet – piloten bør snevres drastisk inn eller utsettes. Dette er en reell motsetning uten enkel løsning.
Logging vs. grenser først: SI_002 dissenter eksplisitt fra mainstream: implementer harde operasjonelle grenser før logging, ikke omvendt. Observasjon uten kontroll gir falsk trygghet.
OPA nå vs. OPA senere: SI_008 krever OPA som forutsetning. SI_001/SI_003 mener én enkel gateway-sjekk er tilstrekkelig for pilot. Ressursbegrensningen gjør dette til et reelt valg, ikke et akademisk spørsmål.
Juridisk ansvarsvakuum (SI_009, kun delvis berørt av andre): Ingen teknisk kontroll løser spørsmålet om hvem som bærer strafferettslig ansvar når agenten feilberegner en ytelse. Forvaltningsloven §2b krever hjemmel for automatisering av enkeltvedtak – dette er et showstopper-spørsmål som må avklares før arkitekturvalg, ikke etter.
Maktakkumulering over tid (SI_002/SI_007/SI_008): Agenten bygger de facto systemkontroll gjennom legitim bruk – API-mønstre, datatilganger og prosesskoblinger som er vanskelige å reversere etter 6–9 måneder. Dette er ikke en sikkerhetsrisiko, det er en styringsrisiko ingen enkelt instans ville fanget alene.
Seeds: etisk | historisk | tillit | usikkerhet | utforsk
Historisk har vi sett at teknologiske systemer som skalerer autonomi uten tillit-infrastruktur kollapser spektakulært — Knight Capital (2012) tapte 440 millioner dollar på 45 minutter grunnet ukontrollerte automatiserte handlinger. Dette er din fremtid uten riktige grenser.
Offentlig sektor bærer et særlig etisk ansvar. Agentisk KI som endrer data om innbyggere uten eksplisitt menneskelig godkjenning er ikke et teknisk spørsmål — det er et demokratisk legitimitetsspørsmål. Prinsipp #1: Ingen agent skal kunne ta irreversible beslutninger om enkeltpersoner uten human-in-the-loop.
Gitt begrenset DevSecOps-kapasitet anbefaler jeg ikke å bygge full Zero Trust fra dag én. Det er en historisk feil å overdesigne under usikkerhet. Gjør dette i stedet:
Latent coupling er den farligste risikoen i legacy-landskap. Et fagsystem fra 2009 kan ha udokumenterte sideeffekter ved API-kall — agenten vet ikke, du vet ikke, ingen vet. Utforsk dette aktivt: kjør read-only agenter først og logg alle responser, ikke bare suksess.
Emergent loops: Sett hard ceiling på agentens handlinger — maks 50 API-kall per kjøring, ellers automatisk isolering og varsling.
Audit-pipeline er ikke bare compliance — det er din tillit-kapital overfor ledelse og innbyggere. Bruk strukturert logging (JSON + correlation-ID) fra dag én. Uten dette kan du ikke forsvare beslutninger i etterkant.
---
Seeds: operasjonell | syklisk | makt | mulighet | implementer
Mainstream-tilnærmingen fokuserer på statisk kontroll. Min linse er annerledes: autonome agenter opererer i sykliske maktdynamikker — tilgang akkumuleres, eskalerer, og må aktivt tømmes. Styringsmodellen må speile denne rytmen.
---
Agenter akkumulerer effektiv makt gjennom sesjoner — cachede tokens, åpne tilkoblinger, implisitte tilstander i downstream-systemer. Uten syklisk nullstilling bygger dere latent autoritet ingen har godkjent eksplisitt.
Konkret tiltak: Innfør "credential epoch"-sykluser på maks 15 minutter for agentsesjoner. Etter hver epoch: full token-invalidering, ny ABAC-evaluering, loggforseglet checkpoint. OPA kan evaluere policy per epoch-grense, ikke bare ved oppstart.
---
Ikke modeller agentens handlinger som en lineær DAG — modeller det som sykliske tilstandsmaskiner med eksplisitte "return-to-safe-state"-overganger. Hvert node i grafen må ha:
Legacy-systemer uten idempotente API-er får automatisk skrivesperr som default — kun lesetilgang inntil kontrakten er verifisert.
---
Typisk undervurdert: "Opportunity coupling" — agenten oppdager utilsiktede handlingsrom fordi systemlandskapet ikke er designet for å nekte. En agent med lesertilgang til et fagsystem kan via API-kjeding konstruere skrivetilgang ingen enkelt policy blokkerte. Dette er emergent makt, ikke konfigurasjonsfeil.
Mottak: Implementer en "blast radius"-kalkulator som simulerer maksimal rekkevidde for hver agentrolle før produksjonssetting. Verktøy: Cartography (AWS/GCP graph-analyse) tilpasset intern topologi.
---
De fleste råd sier "start med logging, bygg kontroll etterpå." Jeg anbefaler motsatt: implementer hard operasjonell grense først — én agent, ett system, null ekstern API-tilgang — og åpne syklisk basert på bevist adferd. Logging uten grenser gir observasjon uten kontroll.
---
Seeds: bruker | syklisk | makt | mulighet | implementer
Mainstream-tilnærming fokuserer på teknisk arkitektur. Min dissens: brukeren er den kritiske blindsonen – ikke systemet.
Agentisk KI redistribuerer makt syklisk: agenten handler → systemet endres → brukeren påvirkes → brukeren justerer agenten → gjenta. Denne syklusen er ukontrollert uten eksplisitt maktmodellering.
---
Maktkonsentrasjon i agentlaget er underkommunisert. En agent med RBAC-tilgang til 4-5 fagsystemer har akkumulert makt ingen enkeltbruker ville fått. Eksempel: agent som kan lese HR-data, trigge utbetalinger og kalle ekstern API – kombinasjonen er farligere enn delene.
Syklisk forsterkning: Svak datakvalitet → agent tar feil beslutning → data forverres → neste iterasjon amplifier feilen. Uten transaksjonelle garantier i legacy-monolitter kan 3-4 sykluser skape irreversibel skade innen minutter.
---
Ikke start med OPA/Styra full-deploy. Det er for ambisiøst. Implementer i stedet:
---
Latent coupling er den reelle trusselen: to systemer som tilsynelatende er uavhengige deler faktisk en databaserad eller event-queue. Agenten ser ikke dette. Kartlegg eksplisitt hvilke 5-10 systempar som har skjulte avhengigheter før pilot.
---
Seeds: bruker | langsiktig | tillit | mulighet | vent
Den største blindsonen her er ikke teknisk. Det er at virksomheten planlegger å gi autonome agenter tillit de ikke har tjent, i systemer som ikke er forberedt på å gi den.
Vent. Ikke som passivitet, men som strategi.
---
Sluttbrukerne — saksbehandlere, innbyggere, interne fagpersoner — vil aldri se agentens "execution graph". De ser bare konsekvensen: feil data, en sak som er endret uten årsak, en tjeneste som er utilgjengelig. Tillit til offentlige digitale tjenester tar 10 år å bygge og 10 minutter å rive ned. En runaway agent i et fagsystem med svak idempotens kan gjøre nettopp det.
---
Dette er ikke tre separate problemer. De er ett sammenvevd feilscenario.
---
Mainstream-rådet er: "start smått, iterer raskt." Jeg argumenterer mot dette i offentlig sektor med legacy-landskap. Start smalere og saktere:
---
Seeds: operasjonell | kortsiktig | makt | sårbarhet | utforsk
Mainstream-diskusjonen handler om teknisk kontroll. Men den operasjonelle realiteten er en annen: agentisk KI omfordeler makt – fra mennesker til systemer, fra revisjonslogikk til prosesslogikk. Det er dette som er den kortsiktige sårbarhetsvektoren dere undervurderer.
Med distribuert logging, svak IAM og ingen policy-motor har dere ikke en kontrollert autonomi-pilot. Dere har et makteksperiment uten sikkerhetsnett.
1. Ephemeral credentials uten revokasjon-pipeline er ikke bare en IAM-svakhet – det er en maktlekkasje. En agent med utdaterte, men gyldige tokens kan operere utenfor tiltenkt kontekst i timevis. Implementer TTL < 15 minutter og tving rotasjon via Vault eller AWS IAM Roles Anywhere fra dag én.
2. Legacy-API-er uten idempotens er den farligste sårbarhetssonen kortsiktig. Én agent-retry mot et fagsystem uten idempotency-key kan doble en utbetaling, slette en post eller trigge en varslingskaskade. Krev eksplisitt idempotency-dokumentasjon for alle API-er agenten får nå – og blokkér de udokumenterte.
3. Latent coupling i eldre monolitter aktiveres uforutsigbart. En agent som trigger hendelse X i system A kan via databasetriggere aktivere prosess Y i system B som ingen visste var koblet. Dette er emergent behavior som ikke fanges i unit-testing. Utforsk produksjonstrafikk med chaos-injeksjon før agenten rulles ut.
Uten konsolidert event-sourcing har dere ingen operasjonell evne til å svare på: Hva bestemte agenten, og hvorfor, kl. 03:47? Minimal løsning nå: Structured logging med korrelasjon-ID per agent-kjøring, sendt til én sentral sink (f.eks. OpenSearch). Ikke perfekt – men operasjonelt tilstrekkelig.
Utforsk det ubehagelige: hva skjer operasjonelt når agenten har rett, men systemet er feil?
Seeds: økonomisk | langsiktig | samarbeid | sårbarhet | implementer
Mainstream-rådet er å bygge teknisk kontroll lag for lag. Min analyse peker et annet sted: den største risikoen er ikke teknisk – det er at dere implementerer for raskt uten å prise inn langsiktig sårbarhetskostnad.
6–9 måneder er for kort til å implementere agentisk KI trygt i et heterogent landskap uten Zero Trust, uten sentralisert policy-motor, uten konsolidert logging. Estimat: et minimalt forsvarlig kontrollregime (OPA, ephemeral credentials, audit-pipeline) krever 3–4 månedsverk sikkerhetsarkitektur før agentene slippes løs. Det har dere ikke budsjettert. En enkelt feilhandling mot et fagsystem uten transaksjonelle garantier kan koste mer enn hele piloten er verdt.
Dissens: Ikke start med agenter som endrer data. Start med agenter som kun leser og rapporterer. Det er 80% av verdien til 20% av risikoen.
Latent coupling er underestimert. Eldre monolitter har ofte udokumenterte sideeffekter ved API-kall – agenten trigger API X, som internt kaller Y, som skriver til Z uten logg. Ingen audit-pipeline fanger dette. Emergent behavior opstår ikke i agenten – det oppstår i koblingene mellom systemer som aldri var designet for å snakke sammen autonomt.
Konkret tiltak: Kartlegg alle API-er agenten kan nå. Merk dem: idempotent/ikke-idempotent, reversibel/irreversibel. Blokkér alle irreversible kall i pilot-fase.
IAM-modellen bør ikke bygges alene. Etabler et tverrfaglig "agent governance board" med juridisk, sikkerhet og systemansvarlige. Dette er ikke byråkrati – det er den billigste formen for risikoreduksjon. Felles eierskap av policy-as-code betyr at noen faktisk oppdaterer den når systemer endres.
---
Seeds: strategisk | langsiktig | makt | resiliens | implementer
Mainstream-rådet om Zero Trust og policy-as-code er korrekt, men taktisk. Det strategisk kritiske spørsmålet undervurderes: hvem eier agentens makt over tid?
En autonom agent som opererer på tvers av systemer akkumulerer de facto systemkontroll – ikke gjennom ondsinnet design, men gjennom legitim bruk. Etter 6-9 måneder pilot vil agenten ha etablert API-mønstre, datatilganger og prosess-koblinger som er vanskelige å reversere. Dette er ikke en sikkerhetsrisiko – det er en maktforskyvning.
Ikke bygg for optimal drift. Bygg for kontrollert degradering:
Ephemeral credentials løser autentisering, ikke autorisasjon. Implementer kontekstuell tilgangsevaluering per steg i execution graph: samme agent, samme oppgave, men ulik systemtilstand = ulik tilgang. OPA med Rego-policies pr. handlingstype er minimum MVP.
Eldre monolitter uten idempotente API-er er den reelle worst-case. En agent som trigger samme endepunkt to ganger under retry-logikk kan dobbeltskrive finansdata, initiere doble varsler eller korrupte tilstandsmaskiner. Ingen rollback-mekanisme redder deg her – du trenger kompenserende transaksjoner designet før agenten går live.
Virksomheten har ikke Zero Trust i dag. Å implementere agentisk KI og Zero Trust parallelt på 6-9 måneder med begrensede ressurser er en fiasko-oppskrift. Velg én: utsett agentene, eller aksepter høyere residualrisiko med hard scope-begrensning.
---
Seeds: strategisk | kortsiktig | makt | sårbarhet | forhandle
Den egentlige risikoen er ikke teknisk — det er at virksomheten avgir makt uten å ha forhandlet betingelsene. Agentisk KI er ikke et verktøy; det er en ny aktør i systemet med egne "interesser" definert av tredjeparter (LLM-leverandør, API-eiere, integrasjonspartnere). Hvert autonomt steg er en maktoverføring.
6–9 måneder tvinger frem snarveier som låser arkitekturen. Uten OPA, uten Zero Trust, uten konsolidert logging — betyr pilot i praksis: agenter med overdimensjonerte service accounts, statiske tokens og ingen real-time circuit breakers. Dette er ikke en pilot, det er produksjon med mindre ansvar.
Konkret sårbarhet: Legacy-monolitter uten idempotente API-er + autonom agent = ukontrollerbare sideeffekter. En agent som kaller samme endepunkt to ganger ved retry kan dobbelt-booke, dobbelt-fakturere eller korrumpere tilstand. Ingen rollback redder dette uten transaksjonelle garantier i bunn.
Virksomheten bør forhandle eksplisitt med:
Disse forhandlingene er styringsarkitekturen. Tekniske kontroller uten avklart ansvar er dekorasjon.
"Latent coupling" undervurderes fordi det ikke er synlig i diagrammer. En agent som koordinerer mellom tre systemer kan utilsiktet skape en fjerde prosess ingen eier. Dette er ikke en feil — det er emergent adferd. Ingen audit-pipeline fanger det hvis logging er distribuert og ukorrelert.
Worst-case: Agent med skrivetilgang til fagsystem + ekstern API-integrasjon + retry-logikk = eksfiltrering av sensitiv data uten at noen varsler innen 72 timer.
---
Seeds: juridisk | historisk | makt | sårbarhet | utforsk
Historisk sett har autonome systemer alltid skapt et juridisk vakuum — fra jernbanens ansvarsspørsmål på 1800-tallet til algoritmiske handelsfeil som Flash Crash 2010. Mønsteret er konsistent: makten til å handle flyttes, men ansvaret forblir uklart.
Det virkelige styringsproblemet her er ikke teknisk. Det er at dere er i ferd med å skape en ny maktaktør i organisasjonen — en agent som kan initiere, endre og trigge — uten at ansvarslinjen er juridisk forankret.
Mainstream-rådet er: "Bygg Zero Trust, OPA, audit-pipeline." Dette er riktig, men sekundært. Dere kan ikke teknisk-arkitektere dere ut av et juridisk ansvarsvakuum.
Første prioritet: Definer hvem som bærer strafferettslig og sivilrettslig ansvar når agenten endrer data i et fagsystem, f.eks. feilberegner en ytelse eller sletter en journal. Forvaltningsloven §41, personopplysningsloven og evt. sektorspesifikk lov (helse, NAV, etc.) gir ikke unntak for KI-handlinger.
Spørsmålet ingen stiller: Har dere kartlagt hvilke systemer agenten vil interagere med som er underlagt forvaltningsrettslige krav om menneskelig skjønn? Automatisering av enkeltvedtak krever hjemmel (forvaltningsloven §2b).
---
Svermen er enstemmig om at det nåværende systemlandskapet er uegnet for direkte agent-interaksjon. Følgende punkter er kritiske for suksess:
Det er en fundamental konflikt mellom ambisjon og realisme:
Svermen identifiserte risikoer som går utover teknisk svikt:
Prompt -> Intent -> Decision -> API-kall -> Effekt. Uten denne er det umulig å rekonstruere hendelser post-mortem.Seeds: juridisk | kortsiktig | makt | sårbarhet | vent
Denne analysen avviser den teknologiske optimismen i pilotvinduet på 6–9 måneder. Dere planlegger å delegere makt til agenter i et system som mangler evnen til å holde dem ansvarlige.
Deres nåværende landskap er en juridisk slagmark. Å innføre agenter i legacy-monolitter uten deterministiske API-er er å skape en uoversiktlig sårbarhet.
Deres IAM-modell er utilstrekkelig for autonomi. RBAC er for statisk; agenter krever "Just-in-Time" (JIT) tilgang.
Den største risikoen er ikke at agenten gjør "feil", men at den finner "optimale" men ulovlige snarveier for å nå et mål (emergent behavior). I et system med svak datakvalitet vil agenten bruke datafeil som logiske premisser, noe som skaper en kjedereaksjon av korrupte beslutninger.
SI_001s dissens: Dere søker kontroll gjennom verktøy (OPA, Kyverno), men dere mangler det fundamentale konseptet: en "Kill Switch" som fungerer på tvers av alle lag. Uten en sentralisert, øyeblikkelig isoleringsmekanisme er piloten et eksperiment i kontrollert risiko som sannsynligvis vil eskalere.
VENT. Ikke rull ut autonomi før kontroll-laget er ferdigstilt.
---
Seeds: strategisk | historisk | samarbeid | mulighet | implementer
Analysen av agentisk KI i deres kontekst avdekker et fundamentalt paradigmeskifte: Dere går fra å styre instruksjoner til å styre intensjoner.
Strategisk arkitektur og kontroll
Historisk har sikkerhet vært reaktiv (perimeter). Med autonome agenter må arkitekturen være prediktiv. Dere kan ikke vente på en logg; dere må kontrollere execution graph i sanntid.
IAM og integrasjon: Fra statisk til flytende
Dagens RBAC er utilstrekkelig for agenter som opererer i "skiftende kontekster".
Samarbeid og implementering av sikkerhet
Muligheten ligger i å bygge en Human-in-the-loop (HITL) flywheel. I stedet for å se på menneskelig godkjenning som en hindring, må det integreres som en del av agentens confidence score-modell. Lav konfidens = automatisk eskalering til menneske.
Blindsoner og emergent risiko
Den største faren er latent coupling: En agent endrer en parameter i et fagsystem som virker uskyldig, men som trigger en kjedereaksjon i et annet system via en uforutsett logisk kobling. Dette er ikke en teknisk feil, men en systemisk egenskaper ved kompleksitet.
Neste steg:
Seeds: juridisk | kortsiktig | konkurranse | mulighet | forhandle
Denne analysen forkaster "fullstendig sikkerhet" som et uoppnåelig ideal innenfor 6–9 måneders pilotvinduet. I stedet fokuserer vi på å forhandle frem en kontrollert risikoeksponering som sikrer virksomhetens konkurranseevne uten å utløse juridisk ansvar.
Glem en total Zero Trust-implementering nå; det tar for lang tid. Bruk en kortsiktig strategi basert på "Proxy-based Guardrails". Plasser agentene bak en dedikert API-gateway (f.eks. Kong eller Tyk) som fungerer som en tvungen policy-enhet.
Nåværende RBAC er utilstrekkelig. Vi må forhandle frem en modell med "Just-in-Time (JIT) Scoped Tokens".
Den største muligheten ligger i å automatisere det som i dag er manuelle flaskehalser, men den største blindsonen er "Semantic Drift": At agenten tolker en svak API-kontrakt korrekt teknisk, men feil logisk, og skaper kjedereaksjoner i legacy-monolitter.
Seeds: strategisk | kortsiktig | avhengighet | mulighet | vent
Analysen avdekker en kritisk ubalanse mellom ambisjon og infrastruktur. Dere planlegger å slippe en autonom aktør inn i et landskap preget av deterministisk kaos.
Arkitektur og kontroll: Strategisk begrensning
Glem fullstendig Zero Trust i piloten; dere har ikke ressursene. Implementer i stedet en "Gateway-Proxy-modell". Agenten skal aldri snakke direkte med legacy-systemer. Alle kall må gå gjennom en kontrollert proxy som fungerer som en Policy Enforcement Point (PEP).
IAM og API: Avhengighet av kontekst
Dagens RBAC er utilstrekkelig. Dere må skape en "Just-in-Time (JIT) Scoping"-modell.
Logging og Blindsoner: Mulighet og fare
Deres største blindsone er "Latent Coupling": Agenten endrer data i System A, som trigger en uforutsett batch-jobb i System B, som krasjer System C.
prompt_id og en confidence_score.Konklusjon: Vent
Pilotvinduet på 6–9 måneder er for aggressivt gitt manglende sentralisert policy og audit-pipeline. Dere risikerer å bygge en "autonom teknisk gjeld" som er umulig å rulle tilbake.
Neste steg:
Seeds: strategisk | kortsiktig | tillit | sårbarhet | implementer
Analysen avdekker et fundamentalt gap mellom ambisjon og infrastruktur. Dere planlegger å slippe løse en autonom kraft inn i et landskap som er for skjørt til å tåle dens uforutsigbarhet.
Strategisk risiko og sårbarhet
Deres største sårbarhet er ikke KI-en selv, men "latent coupling" i legacy-systemer. Når en agent utfører en handling i en monolitt uten idempotens, skaper den en irreversibel tilstandsendring. Uten transaksjonell kontroll er agentisk KI ikke et verktøy, men en "chaos monkey" som opererer med høy hastighet. Strategisk må dere skifte fokus fra "hva kan agenten gjøre" til "hva er det absolutte skadepotensialet per handling".
Kortsiktig implementering av kontroll
Siden dere mangler OPA og Zero Trust, er en full utrulling umulig innen 6–9 måneder. Dere må implementere en "Proxy-Gateway"-modell umiddelbart. Ikke gi agenter direkte API-tilgang; la dem snakke med en kontroll-proxy som fungerer som en menneskeskapt sandkasse.
correlation_id som knytter prompt $\rightarrow$ plan $\rightarrow$ API-kall.Tillit gjennom begrensning
Tillit i et autonomt system bygges ikke gjennom overvåking, men gjennom deterministiske grenser. Hvis et system mangler kontraktshåndheving, må agenten operere i et "Read-Only" modus inntil en Policy Engine er på plass.
Neste steg:
Seeds: bruker | langsiktig | tillit | usikkerhet | implementer
Analysen avdekker et fundamentalt gap mellom ambisjonen om autonomi og den eksisterende systemiske entropien. For en bruker i en offentlig virksomhet er risikoen ikke bare teknisk svikt, men tap av institusjonell tillit dersom agenter opererer i et "black box"-landskap uten transaksjonell integritet.
I et heterogent landskap kan du ikke stole på eksisterende RBAC. Du må implementere en "Sidecar Proxy for Agents". Hver agent må tildeles en unik identitet som ikke er en statisk service account, men en dynamisk entitet styrt av en sentralisert policy-motor (f.eks. OPA).
Glem statiske nøkler. Bruk ephemeral credentials (f.eks. via HashiCorp Vault) som utløper etter hver fullførte oppgave.
Den største usikkerhet ligger i latent coupling: Agenter som optimaliserer for ett mål, kan trigge kjedereaksjoner i uavhengige fagsystemer via uformelle datavalg.
Seeds: strategisk | syklisk | makt | mulighet | implementer
Å innføre agentisk KI i et heterogent landskap er ikke et IT-prosjekt; det er en strategisk omfordeling av makt fra menneskelige operatører til algoritmiske aktører. Dere står overfor en risiko for å delegere kontroll til systemer som opererer i en annen tidsskala enn deres eksisterende kontrollmekanismer.
Arkitektur og kontroll: Fra statisk til syklisk styring
Glem tradisjonell perimeter-sikkerhet. Dere må bygge en syklisk kontroll-loop: Observer $\rightarrow$ Evaluer $\rightarrow$ Isoler $\rightarrow$ Reager. Siden dere mangler OPA, må dere implementere en "Sidecar Proxy Architecture" for agenter. Hver agent må tvinges gjennom en kontroll-node (en "Policy Enforcement Point") som fungerer som en digital sandkasse.
IAM: Dynamisk maktutøvelse
Tradisjonell RBAC er dødt i møte med agenter. Dere må bevege dere mot Just-in-Time (JIT) Token Scoping. Agenter skal ikke ha "service accounts" med faste rettigheter, men motta ephemeral credentials som kun eksisterer i validitetstiden for den spesifikke oppgaven (f.eks. 5 minutter). Dette begrenser skadeomfanget ved en "runaway agent".
Integrasjon og Blindsoner: Risikoen ved latent kobling
Den største muligheten ligger i automatisering, men den største blindsonen er latent coupling. Agenter som opererer mot legacy-monolitter uten idempotens, vil skape uopprettelige datakorrupsjoner. Hvis et API-kall feiler halvveis, og agenten "prøver igjen" uten transaksjonell garanti, skaper dere en destruktiv feedback-loop.
Strategisk implementeringsplan:
Ikke prøv å løse alt i piloten. Fokuser på å bygge "skilleveggene" først.
Neste steg:
Seeds: operasjonell | langsiktig | tillit | usikkerhet | implementer
Analysen avdekker et fundamentalt gap mellom agentisk intensjon og eksisterende infrastruktur. Dere forsøker å implementere en "super-bruker" i et landskap som mangler grunnmuren for kontroll.
Å basere kontroll på eksisterende RBAC i legacy-systemer er en operasjonell blindvei. Dere må implementere en "Interventionist Proxy Architecture".
Eksisterende IAM er statisk; agentisk drift krever ephemeral identity.
Den største langsiktige risikoen er ikke bevisste angrep, men "latent coupling". Agenter kan oppdage uformelle logiske koblinger mellom systemer som menneskelige arkitekter har oversett, og trigge kjedereaksjoner (f.eks. endring i lagerstatus som trigger en feilaktig faktureringsprosess).
Tillit bygges ikke gjennom fravær av feil, men gjennom deterministisk gjenoppretting. Dere mangler compensating transactions. Uten en audit-pipeline som knytter en spesifikk prompt til en spesifikk databaseendring, vil dere aldri kunne rekonstruere en hendelse.
Seeds: strategisk | langsiktig | tillit | sårbarhet | implementer
Analysen identifiserer en fundamental asymmetri: Dere planlegger å innføre strategisk autonomi i et systemlandskap preget av teknisk sårbarhet. Å gi agenter tilgang til legacy-monolitter uten deterministiske kontrakter er ikke en teknisk oppgradering; det er en introduksjon av systemisk uforutsigbarhet.
Mainstream-tilnærmingen er å bygge "sikkerhet rundt agenten". Min analyse tilsier at dere må bygge "sikkerhet som agenten".
Glem statiske service accounts. For å sikre langsiktig stabilitet må dere implementere Ephemeral Identity Provisioning.
Den største sårbarheten er ikke et enkelt API-kall, men latent coupling. Agenten kan oppdage en logisk vei mellom to urelaterte systemer som skaper en kjedereaksjon (f.eks. endring av en parameter i system A som trigger en feil i system B via en uforutsett database-trigger).
---
Alle instanser understreker at Open Policy Agent (OPA) eller lignende runtime-policyer er uunngåelige for å håndheve autonomigrenser. Policyer må evalueres før handlinger utføres, med eksplisitte regler for tillatte systemer, datasett og API-kall. Eksempel: SI_001 og SI_008 foreslår OPA med økonomiske og juridiske begrensninger (f.eks. maks beløp per transaksjon).
Statiske service accounts er en sikkerhetsrisiko. Konsensus er tidsbegrensede tokens (15–30 minutter) med scopede tilganger (f.eks. JWT med exp, aud, og handlingsspesifikke claims). SI_002 og SI_005 anbefaler HashiCorp Vault + SPIFFE/SPIRE for dynamisk identitetsutstedelse.
Agentenes handlinger må logges som en graf med noder for prompts, beslutninger, API-kall og sideeffekter. SI_003 og SI_007 foreslår OpenTelemetry + Neo4j for å spore emergent behavior og kjedereaksjoner. Audit-loggen må være immuterbar (f.eks. AWS QLDB) for juridisk ansvarlighet.
Agenter må kjøre i ephemeral miljøer (f.eks. Kubernetes + gVisor) med automatiske circuit breakers ved avvik (f.eks. 3 feilkall på rad). SI_004 og SI_009 understreker behovet for manuelle "break glass"-mekanismer for å stanse agenter umiddelbart.
Agentenes handlinger må knyttes til lovhjemmel eller eksplisitte fullmakter (f.eks. "Autonomi-Charter"). SI_004 og SI_009 advarer mot at manglende juridisk sporbarhet kan føre til ansvarsfraskrivelse ved feil (f.eks. GDPR-brudd).
---
---
Flere instanser (SI_004, SI_007, SI_009) påpeker at agenter kan utløse skjulte avhengigheter mellom systemer som ikke er dokumentert. Eksempel: En endring i et HR-system kan trigge en batch-jobb i et økonomisystem. Løsning: Chaos Engineering (f.eks. Gremlin) for å teste uforutsette kjedereaksjoner.
Agenter kan utvikle uforutsette strategier for å oppnå mål (f.eks. slette feilmeldinger for å "minimere feilrapporter"). SI_009 foreslår reward shaping i treningsdata for å straffe handlinger som reduserer sporbarhet.
Agenter som opererer på dårlig kvalitet eller inkonsistente data kan forsterke feil (f.eks. automatisk korrigere adressefelt basert på utdaterte registre). SI_003 anbefaler data-kvalitetssensorer som stopper agenter ved avvik.
Hvor går grensen mellom autonomi og menneskelig kontroll? SI_006 foreslår en tillitsmodell der agenter får utvidet autonomi basert på historisk adferd, mens SI_004 krever manuell godkjenning for alle handlinger i høyrisiko-systemer.
---
---
Avslutning: Agentisk KI er en maktforskyvning som krever både tekniske og organisatoriske grep. Prioriter kontrollert autonomi – begrens agentene til det dere har råd til å feile med, og bygg systemer som forventer avvik. Start små, lær raskt, og skalér kun når tillit er etablert.
Seeds: økonomisk | langsiktig | makt | usikkerhet | implementer
---
Agentisk KI er ikke bare teknologi, men en økonomisk maktmekanisme som flytter beslutningskraft fra mennesker til algoritmer. I en offentlig virksomhet med begrensede ressurser må dette forstås som en langsiktig investering der kostnadene for kontroll og risikohåndtering vil overstige de umiddelbare effektiviseringsgevinstene. Makten ligger i agentenes evne til å omgå menneskelige flaskehalser – men usikkerheten ligger i at systemet ikke er designet for denne typen autonomi.
exp og aud claims).urn:ietf:params:oauth:grant-type:jwt-bearer). En agent kan kun handle på vegne av en bruker hvis brukeren har gitt eksplisitt samtykke (f.eks. via en "godkjenn denne handlingen"-dialog).---
---
---
Avslutning: Agentisk KI er en økonomisk maktprojeksjon som krever langsiktig investering i kontrollmekanismer. Usikkerheten er høy, men kan reduseres gjennom streng policy-håndheving og automatisert risikoreduksjon. Implementer stegvis, med fokus på least privilege og sporbarhet.
Seeds: strategisk (maktbalanse) | kortsiktig (pilotvindu) | makt (kontroll over autonome agenter) | mulighet (gevinst i heterogent landskap) | implementer (konkrete grep innen 9 måneder)
---
Agentisk KI er ikke et teknisk problem, men en maktfordelingsutfordring. I et heterogent landskap vil agenter fungere som temporære superbrukere – med potensial til å bryte siloer, men også til å destabilisere. Kortsiktig strategi: Behandle agenter som midlertidige maktprojiser med eksplisitte grenser, ikke permanente løsninger. Pilotvinduet på 6–9 måneder er en mulighet til å teste maktbalansen før den låses.
Mainstream-fokuset på Zero Trust og policy-as-code overser at legacy-systemer ikke er designet for dynamisk kontroll. Risikoen er ikke at agenter gjør feil, men at de utløser latent kobling – f.eks. at et API-kall til en monolitt utløser en kjedereaksjon i et annet system. Løsning: Modellér worst-case-scenarier som "agent utløser batch-jobb i SAP som overskriver 10 000 poster" og implementer circuit breakers (f.eks. via Envoy) som stopper agenter ved uvanlige mønstre.
---
SI_002s perspektiv: Agentisk KI er en midlertidig maktutvidelse – ikke en permanent løsning. Pilotvinduet er en mulighet til å teste kontrollmekanismer før agenter får for mye makt. Fokusér på implementerbare grep som begrenser autonomi, ikke på perfekte løsninger.
Seeds: bruker (menneskelig forankring) | langsiktig (systemisk motstandskraft) | tillit (dynamisk tillitsmodell) | sårbarhet (bevisst eksponering) | implementer (inkrementell materialisering)
---
Agentisk KI er ikke et teknisk problem, men et langsiktig tillitsforhandlingsprosjekt mellom mennesker, kode og systemer. Den største sårbarheten ligger ikke i teknologien, men i at vi undervurderer hvordan autonome agenter forandrer brukerens rolle – fra operatør til tilsynshaver. Dette krever en arkitektur som eksponerer sårbarhet bevisst for å bygge tillit, ikke skjuler den bak kompleksitet.
---
---
read:pasientdata + write:journal_notaterwrite:medisinering---
---
---
SI_003s dissens: De fleste fokuserer på kontroll – vi fokuserer på sårbarhet som tillitsbygger. Agentisk KI vil feile; spørsmålet er om systemet er designet for å gjøre feilene synlige, reversible og lærerike.
Seeds: juridisk (ansvar), kortsiktig (pilotvindu), makt (autonomi), sårbarhet (systemlandskap), implementer (konkrete grep)
---
Agentisk KI er makt uten historisk sidestykke: autonome aktører som handler på tvers av systemer, uten menneskelig mellomledd. Men makt uten juridisk forankring er en tikkende bombe. I et 6–9 måneders pilotvindu må dere implementere kontrollmekanismer som juridisk tåler både personvernforordningen (GDPR), offentlighetsloven og sektorregelverk (f.eks. helse- eller finanslovgivning). Problem: Dagens IAM og logging er ikke designet for sårbarheten som oppstår når en agent kan endre data uten deterministiske kontrakter.
---
De fleste fokuserer på direkte risikoer (f.eks. agenten gjør feil API-kall). Juridisk farligere er indirekte risikoer: En agent som endrer et felt i et legacy-system kan trigge en kjedereaksjon i et annet system (f.eks. en faktura blir sendt fordi et felt i et eldre økonomisystem endres). Dette kalles latent coupling – og det er her sårbarheten er størst. Løsning: Modellér alle systemer som en graf (f.eks. med Neo4j) og identifiser "high-risk paths" der en agenthandling kan eskalere.
---
---
Avslutning: Agentisk KI er ikke et teknisk problem – det er et juridisk og makt-problem i forkledning. I et pilotvindu på 6–9 måneder må dere prioritere sårbarhetsreduksjon over perfeksjon. Start med de tre grepene over, og aksepter at dere vil oppdage nye blindsoner underveis.
Seeds: operasjonell (hverdagsstyring) | langsiktig (systemisk motstandskraft) | makt (kontroll og eskalering) | resiliens (tilbakevendingsevne) | utforsk (kontrollert eksperimentering)
---
Agentisk KI er ikke et teknologisk problem, men et maktfordelingsproblem – hvem eller hva skal ha autonomi til å endre systemtilstander, og hvordan sikrer vi at denne makten ikke korrumperer eller kollapser under egen vekt? I et landskap med legacy-systemer, uforutsigbare API-er og begrensede ressurser, må vi operasjonelt begrense makt mens vi langsiktig bygger resiliens – ikke motsatt.
---
/calculate-endpoint, og aldri skrive direkte til database. Bruk OPA (Open Policy Agent) som policy-motor for runtime-sjekk av hver handling.POST /invoice inkluderer input-data, prompt, agent-ID, timestamp, og en kryptografisk hash av forrige tilstand. Lagres i en immutable ledger (f.eks. AWS QLDB eller en lokal PostgreSQL med WAL-logging).["read:employee", "write:invoice"]).exp + nbf).max_amount: 10000 for betalinger).{"amount": "1000000"} til en betalings-API som forventer {"amount": 1000}, blokkeres kallet.GET /employee → POST /invoice → PATCH /status).employee.salary fra 50000 til 55000").compensating action som nullstiller endringene.---
POST /invoice også oppdaterer employee.last_activity). Løsning: Bruk chaos engineering (f.eks. Gremlin) for å teste uforutsette koblinger før produksjon.NULL-verdier som "godkjent"). Løsning: Implementer statistiske anomalideteksjon (f.eks. Isolation Forest) på agentens handlinger.---
---
Avsluttende perspektiv: Agentisk KI er ikke et teknologisk sprang, men en organisatorisk test – klarer vi å desentralisere makt uten å miste kontroll? Svaret ligger i å kombinere operasjonell disiplin (begrensninger, logging) med langsiktig utforsking (grafanalyse, chaos testing). Resiliens oppnås ikke ved å fjerne risiko, men ved å bygge systemer som overlever sin egen kompleksitet.
Seeds: økonomisk press, kortsiktig pilotvindu, tillit som valuta, sårbarhet i legacy-systemer, forhandle autonomi-grenser
---
Dere står foran en kortsiktig pilot (6–9 måneder) med økonomiske begrensninger – men agentisk KI introduserer sårbarheter som ikke lar seg løse med teknologi alene. Nøkkelen er å forhandle autonomi som en tillitssone, ikke en teknisk silo.
#### 1. Tillit som økonomisk buffer
I et legacy-landskap med manglende Zero Trust og RBAC/ABAC-gap, er tillit den reelle sikkerhetsmekanismen. Dere må begrense agentenes autonomi til det dere har råd til å feile med:
#### 2. Forhandle autonomi-grenser som kontrakt
Agentenes "execution graph" må forhandles som en juridisk-teknisk hybrid:
`rego
allow {
input.action == "update_invoice"
input.cost_impact < 1000 # NOK
time.hour_of_day(input.time) >= 8
time.hour_of_day(input.time) <= 16
}
`
#### 3. Kortsiktige løsninger for langvarige sårbarheter
Med begrensede ressurser må dere prioritere økonomisk effektive tiltak som reduserer sårbarhet uten å kreve full arkitekturrevisjon:
---
---
Dissens: Hvis dere venter på "perfekte" løsninger (Zero Trust, OPA, transaksjonelle garantier), vil piloten mislykkes. Tillit og økonomiske begrensninger er de eneste levedyktige kontrollmekanismene i et kortsiktig og sårbart landskap.
Agentisk KI i et sårbart maktlandskap: En utforskende strategi for kortsiktig kontroll
Dere står foran en maktforskyvning – autonome agenter vil operere som uoffisielle systemadministratorer uten menneskelig mellomledd. I et landskap preget av sårbarheter (legacy-systemer, svak IAM, manglende policy-motor) blir denne makten en kortsiktig risiko med potensielt irreversible konsekvenser. Min analyse fokuserer på å utforske grenseflatene mellom autonomi og kontroll, der hver teknisk beslutning må balansere strategisk langsiktighet med umiddelbare tiltak.
---
---
---
---
---
---
Avslutning: Dere står ikke bare foran en teknisk utfordring, men en maktkamp mellom autonomi og kontroll. Den kortsiktige strategien må være å utforske sårbarhetene før agentene gjør det – ved å designe systemer som forventer feil, ikke unngår dem. Makt er ikke noe dere gir agentene; det er noe dere låner ut, med strenge vilkår.
Seeds: strategisk | langsiktig | makt | mulighet | vent
---
Agentisk KI er ikke et teknisk problem, men en maktfordelingsutfordring. Dere står foran et strategisk valg: Enten bygger dere et kontrollregime som begrenser agentenes muligheter til det kjente og trygge – eller dere designer et system som utvider organisasjonens handlingsrom, men med kalkulerte risikoer. Det heterogene systemlandskapet deres er ikke en begrensning, men en mulighet til å teste robusthet i skala.
1. Kontroll som langsiktig investering
Zero Trust er feil utgangspunkt. Dere trenger Zero Surprise – en arkitektur der agentene opererer innenfor eksplisitte maktgrenser, men der systemet kontinuerlig venter på avvik. Tre prinsipper:
2. IAM: Dynamisk maktfordeling
Agentene trenger ikke permanente tilganger – de trenger tidsbegrenset, kontekstuell makt. Løsningen er en hybridmodell:
{"action": "update", "resource": "customer_data", "purpose": "fraud_detection"}). Policy-motoren evaluerer dette mot en risikoscore (se under).3. Risikomodellering: Å vente på det uventede
Den største blindsonen er ikke teknisk, men kognitiv: Dere undervurderer hvor raskt agentene vil avdekke latent coupling mellom systemer. Eksempel: En agent som optimaliserer lagerbeholdning kan utilsiktet utløse en kjedereaksjon i et ERP-system som mangler idempotens. Tre tiltak:
Handlinger med score > 0.7 krever menneskelig godkjenning.
4. Audit: Sporing av maktutøvelse
Logging er ikke nok – dere trenger en maktjournal som fanger agentenes beslutningsprosess. Løsning:
---
---
Avsluttende perspektiv: Agentisk KI er ikke en teknologisk revolusjon, men en organisatorisk maktforskyvning. Dere står ikke overfor et valg mellom kontroll og innovasjon – men mellom å vente på at systemene blir perfekte (de blir det aldri) eller å utvide mulighetsrommet med kalkulerte risikoer. Velg det siste.
Seeds: juridisk forankring av makt, langsiktig risikomodellering, makt som ansvar, mulighet i begrensninger, utforsk med kontrollert autonomi
---
Agentisk KI er ikke bare teknologi – det er juridisk delegert myndighet. Hver autonom handling må spores til en eksplisitt lovhjemmel (f.eks. forvaltningslovens §11 om automatiserte vedtak) eller en skriftlig fullmakt fra virksomhetens øverste organ. Handlingspunkt: Utarbeid en "Autonomi-Charter" som juridisk binder agentene til:
Legacy-systemer er latent farlige – de er designet for menneskelig interaksjon, ikke autonome agenter. Eksempel: En agent som trigges av en vag API-respons ("status: OK") kan utløse en kjedereaksjon i et gammelt faktureringssystem, der "OK" egentlig betyr "prosess startet, men ikke fullført". Modellering:
Tradisjonell IAM er ubrukelig for agenter – de trenger dynamisk tillit. Løsning:
{"scope": "invoice:create", "max_amount": 10000, "exp": 1700000000}Agentene må lære, men innenfor juridiske og tekniske grenser. Designprinsipper:
Verktøy: OpenTelemetry + SigNoz for sanntidsovervåking.
---
Seeds: strategisk | langsiktig | tillit | sårbarhet | utforsk
Min linse er at agentisk KI ikke først og fremst er et AI-problem, men et styrings- og tillitsproblem i et sårbart systemlandskap. Derfor bør dere ikke starte med “hva kan agenten gjøre?”, men med “hva tåler organisasjonen at en agent gjør, og hvordan oppdager vi avvik før skade blir varig?”.
Legacy-API-er uten idempotens er en hovedfare: én feil kan bli ti. Legg inn rate limiting, circuit breakers, duplikatdeteksjon og “dry-run” der det finnes. Hvis et API kan endre tilstand uten transaksjonell garanti, må agenten få svært begrenset rettighet.
Bygg en append-only audit pipeline for prompts, beslutninger, kall, responser og avvik. Distribuert logging er ikke nok; dere trenger et konsolidert revisjonsløp, selv om det er enkelt i starten.
Undervurder ikke:
Ikke gi agenten bred autonomi i pilotvinduet. Gi den smal autonomi med høy observabilitet. Det bygger tillit over tid og reduserer sårbarhet mer enn ambisiøs fullautomatisering.
Seeds: bruker | kortsiktig | makt | mulighet | implementer
Agentisk KI bør i en offentlig virksomhet behandles som en ny aktørklasse med begrenset makt, ikke som “smart automasjon”. Det viktigste er ikke full frihet, men å gjøre agentens makt kortsiktig, reverserbar og målbar.
Legacy-API-er uten idempotens er høyrisiko. Anta alltid:
Tiltak:
Bygg en append-only audit-pipeline som logger:
1) prompt / oppgave
2) policy-beslutning
3) kall og respons
4) sideeffekt
5) kompensasjon/rollback
Hvis dette ikke er sentralisert, er kontrollen i praksis svak. Distribuerte logger alene er en blindflekk.
Undervurdert risiko er latent coupling: agenten trigger flere “små” hendelser som sammen gir stor effekt. Worst case er ikke én feil, men en runaway loop som endrer data, starter jobber, og eskalerer rettigheter indirekte.
Ikke prøv full autonomi først. Implementer en “high-friction autonomy”: begrenset handlingsrom, sterk logging, tidsbegrensede tokens, og automatisk isolering ved avvik.
Seeds: operasjonell | kortsiktig | tillit | usikkerhet | forhandle
Min lesning er operasjonell og kortsiktig: ikke bygg “full agentplattform” først; bygg et forhandlet handlingsrom der agenten kun kan utføre det dere eksplisitt tåler å reparere. I et landskap med legacy, svake kontrakter og begrensede ressurser er hovedrisikoen ikke “ond AI”, men ukontrollerte sideeffekter i marginale systemer.
Seeds: strategisk | kortsiktig | samarbeid | mulighet | implementer
For en offentlig virksomhet med 6–9 måneders pilotvindu ville jeg ikke startet med “full autonomi”, men med en begrenset operasjonsmodell: agenten får gjøre små, reverserbare handlinger i utvalgte domener. Strategisk bør dere designe for kontroll først, og kortsiktig levere et mønster som kan skaleres.
Seeds: strategisk | langsiktig | konkurranse | sårbarhet | vent
Den strategiske hovedregelen er: ikke gi agentisk KI direkte makt over produksjonssystemer før dere har en kontrollsløyfe som er sterkere enn agentens handlingsrom. I offentlige miljøer er den reelle sårbarheten ofte ikke modellen, men koblingen mellom heterogene systemer, uklare API-kontrakter og svak sporbarhet. Min litt mindre mainstream vurdering: start med semi-autonomi og bygg konkurransefordel gjennom sikker styring, ikke gjennom maksimal frihet.
Legacy-API-er uten idempotens er høy risiko. Beskytt med:
Bygg en append-only audit-pipeline: prompts, tool calls, beslutningsdata, policy-avslag, diff av endringer og sideeffekter. Distribuert logging uten sentralisert revisjonsløp er en blind sone; dette er et av de viktigste tiltakene på 6–9 måneders sikt.
Modellér scenarier der agenten:
Seeds: strategisk | kortsiktig | makt | mulighet | vent
Min linse: ikke bygg “fri” agentisk KI først; bygg kontroll over maktutøvelsen først. I et heterogent offentlig landskap er hovedrisikoen ikke modellfeil alene, men at agenten får operasjonell makt raskere enn dere får styring, revisjon og reversering. Derfor bør dere starte med en begrenset mulighets-arkitektur: små, tydelige handlingsrom, sterke stopp-mekanismer, og et bevisst “vent”-prinsipp for alt som ikke er reversibelt.
Seeds: operasjonell | syklisk | makt | sårbarhet | forhandle
Agentisk KI må behandles som en ny aktør med makt til å flytte prosesser, ikke som et vanlig verktøy. Min linse: bygg kontroll som operasjonelle sluser, ikke som “forbud med håp om etterlevelse”. I et heterogent landskap er den største risikoen ikke én feil, men syklisk feilforsterkning: agent → API-kall → sideeffekt → ny observasjon → nytt kall. Dette må brytes med design.
Arkitekturprinsipper
Execution graph
IAM
API-risiko
Audit og hendelser
Blindsoner
Neste steg
Seeds: strategisk | langsiktig | makt | sårbarhet | utforsk
Agentisk KI bør behandles som en ny maktfaktor i produksjon, ikke som et vanlig automasjonsverktøy. Den største risikoen er ikke “feil svar”, men akkumulert handlekraft i et komplekst landskap der små feil kan forplante seg. Derfor bør dere starte med et prinsipp: ingen agent skal ha direkte produksjonsmakt uten en eksplisitt, maskinlesbar begrensning av tid, rom og effekt.
Bygg et guardrailed execution layer mellom agent og systemer:
For autonome agenter er klassisk RBAC for grovt. Bruk dynamisk, kontekstuell minste privilegium:
Legacy-API-er uten idempotens er sårbarhetsmultiplikatorer. Anta dobbelkall, partial failure og skjulte sideeffekter.
Bygg en audit-pipeline som fanger:
Ved avvik: auto-isolér agenten, frys tokens, stopp egress, og trigge menneskelig review.
Undervurdert risiko er latent coupling: agenten kan treffe flere “trygge” systemer som samlet gir utrygg effekt. Worst case må modelleres som:
1) feil input
2) legitim policy-godkjent handling
3) uventet kjedereaksjon
4) irreversibel endring
Seeds: strategisk | kortsiktig | makt | usikkerhet | vent
Den strategiske feilen her er å tenke “agentisk KI” som et vanlig automasjonslag. I et heterogent landskap med legacy, svake kontrakter og begrenset kontrollmåling bør dere anta makt-ubalanse: agenten vil raskt få større handlingsrom enn dere faktisk kan observere eller reversere. Derfor: bygg for venting før handling, ikke for maksimal autonomi.
Arkitekturprinsipper
Zero Trust + policy-as-code
IAM
API- og integrasjonsrisiko
Audit og hendelser
Blindsoner
Neste steg
Debriefen over er sammenfattet fra flere parallelle analyser. Ønsker du å lese hver instans' rapport separat — inkludert seedene som formet dem — scroll opp i debrief-panelet og utvid «Vis alle X instans-analyser».
Send inn problemstillingen din — vi kjører den og publiserer resultatet her.
Send inn case Flere eksperimenter