Lad os være ærlige. Det meste “AI i virksomheden” i dag er en tynd glasur. En copilot i IDE’en, en chatbot i supporten. Små gevinster, ja. Men arkitekturen under er stadig menneske-lag-på-lag. Derfor føles Blomfields vinkel (genfortalt i en Towards AI-artikel opdateret 3. juni 2026) som et knæk, ikke en finesse: design virksomheden som rekursive, selvforbedrende AI-loops, ikke som et hierarki med AI på toppen.
Hvorfor betyder det noget? Fordi flaskehalsen flytter sig fra headcount til tokens. Fra “hvor mange mellemledere kan vi ansætte” til “hvor mange beslutninger kan vi automatisere sikkert pr. krone”. Vores korteste anbefaling til ledelsen: 1) Gør data læsbar for maskiner og log alt fra dag 1. 2) Byg ét loop i produktion, ikke fem pilotprojekter. 3) Få styr på governance fra starten: versionsstyring, eval-metrics og en fail-safe menneskelig kontrol for risikofyldte handlinger.
Hvad Blomfield sagde — kort og fokuseret
Kernen i Blomfields budskab, som Towards AI-teksten opsummerer, er enkel: De fleste bygger AI ovenpå gamle strukturer. Det nye er at tænke virksomheden som et sæt rekursive, selvforbedrende loops. Artiklen peger på fem skift: optag alt, gør virksomheden læsbar for AI, brænd tokens før headcount, skær i mellemledelse, og placér mennesker ved kanten (der hvor risici og undtagelser er).
Modellen beskrives i fem lag: sensorer, ingestion og politik, værktøjer, kvalitetsport og læring\/feedback. På slide ser det let ud. I praksis kræver det en anden data- og driftsdisciplin, end de fleste har i dag.
Hvorfor det faktisk er nyt (og hvad der er gammelt)
Copilot-tilgangen lover 10–20 procent produktivitetsløft i eksisterende workflows. Fint. Men arkitekturen er stadig menneskecentreret med AI som hjælper. I en loop-arkitektur flytter tyngdepunktet: data skal indsamles, etiketteres implicit og måles løbende; pipelines skal være versionerede; og beslutninger går fra møder til eval-gates og politikker, der eksekverer automatisk.
Vi ser forskellen i hverdagen. Når nogen beder os “implementere en chatbot”, spørger vi i stedet: hvor lander samtalerne som træningsdata, hvilken eval måler, om botten faktisk løser problemet, og hvordan sikrer vi, at næste release lærer af fejl i går. Banalt på papiret. Ikke i drift.
De fem lag i praksis
Sensorlaget: Alle input, der peger på virkelige hændelser. Support-mails, klikstrømme, produkttelemetri, annulleringer, ændringer i kode eller konfiguration. Krav: strukturerede skemaer, tidsstempler, brugerkontekst. Ingen PDF-kælder med 2019_finals_v3_endelig.pdf. Vi har set det for tit.
Ingestion og politik: Rens, berig, standardiser. Beskriv med skemaer, taksonomier og feltbeskrivelser, så modellen kan “læse” virksomheden. Indfør politikker for, hvad der må automatiseres, og hvornår et menneske skal kigge med. Tænk det som et simpelt flow: hvis risk_score < tærskel, så automatisk; ellers til supervisor.
Værktøjslaget: Det deterministiske lag. API’er, databaser, CRM, e-mail, fakturering. Agenten må kun handle via dokumenterede værktøjer med klare kontrakter. Ingen skjulte sideeffekter. Her bor også rolle- og adgangsstyring.
Kvalitetsporten: Eval-sæt, automatiske tests, sikkerhedsfiltre og i højrisiko-sager et hurtigt menneske-check. Tænk “pre-commit hook” for beslutninger. Et simpelt billede: input → beslutning → kvalitetstjek → handling.
Læring og feedback: Hver beslutning gemmes med kontekst, resultat og eval-score. Den strøm fodrer både prompts, værktøjskald og finetuning. Uden denne sløjfe dør selvforbedringen. Med den bliver fejl dyre én gang, billige næste gang.
Tre konkrete implementationsspor
1) Support-loop. Datakilder: chatlogs, tickets, makroer, knowledge base, CRM. Pipeline: rens sprogligt, de-duplikation, map til intents og resolution codes. Metrics: first-contact resolution, eskalationsrate, tid til løsning, hallucinationsklager. Governance: alle nye svar-typer gennemgår eval-sæt; højrisiko emner kræver menneskelig godkendelse. Gevinst: hurtigere svar og færre eskalationer (estimat: 20–40 procent kortere TTR afhængigt af domæne). Faldgruber: manglende versionering af prompts og svarskabeloner; skjulte datafelter der bryder konteksten. Vi blev ramt af det sidste hos en kunde — ét internt flag manglede i konteksten, og botten tilbød refusion på sager, der faktisk var svindel. Ikke fedt.
2) Produkt-loop. Instrumenter features med klare succes-signaler: aktivering, opgaver fuldført, frafald efter release. Pipeline: event-logging med stærk skemadisciplin, automatisk clustering af fritekst-feedback, kobling til feature-flags. Metrics: brugersucces pr. feature, NPS på berørte flows, regressions i funnel. Governance: A\/B-kontroller og automatisk rollback hvis kvalimål falder under tærskel. Gevinst: hurtigere iteration på det, brugere faktisk gør — ikke det vi gætter. Faldgrube: hvis feedback-samling er for løs, lærer modellen at optimere på støj.
3) Operations-loop. Incident-telemetri, alarmer og runbooks. Pipeline: klassificer hændelser, generér foreslåede handlinger, simulér virkninger i sandkasse, udfør via værktøjslaget. Metrics: MTTA, MTTR, gentagelseshyppighed, antal menneskelige håndgreb pr. incident. Governance: change management-regler, pligt til post mortem, obligatorisk menneskelig godkendelse for produktionstiltag over en vis risiko. Gevinst: kortere driftstop og mindre nattearbejde. Faldgrube: for brede agent-tilladelser. Hold værktøjsadgange snævre.
MLOps, SFT og DPO — hvor teknisk skal du blive
Det vigtige her: AWS viser i en teknisk blog, hvordan SFT og DPO i kombination kan løfte en agents evne til at vælge og kalde de rigtige værktøjer. De illustrerer også, hvad fejl koster i drift: langsommere opgaveafslutning, højere supportomkostninger og dårligere brugeroplevelse. Det matcher det, vi ser i produktion.
Hvornår er finetuning det rigtige greb? Når fejlmønstret er stabilt og specifikt for jeres værktøjsøkosystem, og prompt-justering ikke længere flytter sig. DPO er nyttig, når du vil straffe dårlige værktøjskald og belønne ønskede handlinger i selve træningssløjfen. AWS-eksemplet bruger SageMaker-jobs, så teamet kan fokusere på træningskode frem for infrastruktur. En genvej, der kan betale sig.
Målepunkter for tool-calling accuracy: værktøjsvalg-præcision (top-1), korrekt parameterformat, andel succesfulde kæder uden manuel indgriben og efterfølgende opgavefuldførelse. Vi lagrer også “wrong-tool but safe” vs. “wrong-tool and harmful” for at styre risikoprofilen.
Organisatoriske konsekvenser
Jobprofiler flytter sig. Fra udførende til superviserende. Roller vi ser virke: AI-supervisorer, der tager kant-sager; data-curators, der sikrer semantisk orden i events og tekster; og ML-observability-ejere, der holder øje med drift — hele tiden. KPI’er bør pege på loopets performance: tid til forbedring, andel automatiserede beslutninger inden for kvalitetsmål, tokenforbrug pr. løst opgave.
Anonymiserede erfaringer fra Snilld: Hos en kundesupport-løsning reducerede finetuning af værktøjsvalg fejl i parameterformatering med omkring 35 procent og sænkede eskalationsraten et pænt stykke. Vi målte også task completion time før\/efter; gevinsten kom især på gentagne sager. En anden gang valgte vi for bred modeladgang i et ops-loop. Det gav en uventet ændring i et alert-threshold-script. Heldigvis fangede kvalitetsporten det.
Og den politiske vinkel: Modstanden kommer ofte fra mellemled, ikke fordi folk er imod teknologi, men fordi rapporteringslinjer og ansvar ændrer sig. I flere workshops hørte vi bekymringen sagt i pauserne mere end i plenum.
Risici, governance og hvornår mennesker stadig skal være i loopet
Risici, kort: værktøjskald, der rammer forkert; driftssikkerhed; bias og forstærkning af fejl i rekursive loops; og budgetter der brænder på tokens. Governance-svar: versionsstyr alt (data, prompts, værktøjer, eval-sæt), kør A\/B og shadow-mode før brede udrulninger, og behold menneskelig godkendelse der, hvor konsekvensen er høj eller uigenkaldelig.
Token-økonomi er ikke et flueben. Vi har set budgetter tippe i produktion, når kallene eksploderer. Vores afhjælpning har været en hybrid strategi: lokal caching af hyppige svar, rate-limiting, aggressiv prompt-komprimering og selektiv finetuning for at reducere gennemsnitlig tokencount pr. opgave. Effekten er målbar over uger, ikke dage.
Praktisk, trinvis roadmap 30\/90\/180 dage
30 dage: Lav en data-audit. Hvor logger I allerede? Hvor mangler skema og kontekst? Leverabler: kortlagte events og datastrømme, et skema for support eller produkttelemetri, baseline-metrics for kvalitet og svartid samt en pipeline-skitse fra sensor til læring. Vælg også ét loop at starte med. Ikke tre.
90 dage: Byg en MVP-agent i produktion med smal scope. Implementer eval-sæt og kvalitetsport. Leverabler: versionerede prompts, værktøjskatalog med testbare kontrakter, dashboard for tool-calling accuracy og loop-KPI’er samt en simpel governance playbook for release og rollback.
180 dage: Udvid loopets dækning, begynd selektiv finetuning (SFT og evt. DPO), hvis fejlmønstre er stabile, og indfør token-økonomi som fast styringsparameter. Leverabler: træningsdatasæt med klar lineage, SageMaker- eller tilsvarende træningsjobs, cost-dashboard med tokens pr. succesfuld opgave og en change management-plan for berørte teams.
Hvad skeptikerne vil sige — og vores svar
“Det koster for meget.” Måske på kort sigt. På lang sigt er spørgsmålet: hvor mange beslutninger kan automatiseres inden for jeres kvalitetsmål pr. 1.000 kroner? Lav et simpelt regnestykke: estimer kaldsfrekvens pr. opgave, gennemsnitligt tokencount, pris pr. 1.000 tokens, og sammenlign med nuværende FTE-tid. Markér alle tal som estimat og justér med reelle målinger månedligt.
“Vi kan ikke stole på modeller.” Stol ikke blindt. Indfør kvalitetsporte, eval-sæt og start i lavrisiko-områder. Brug shadow-mode og gradueret frigivelse. AWS-posten om SFT+DPO viser, at værktøjskald kan forbedres systematisk. Det er ikke magi. Det er træning og disciplin.
“Det fjerner jobs.” Nogle opgaver flytter, ja. Vores erfaring er, at roller bliver mere superviserende, og at de teams, der får nye KPI’er og opkvalificering tidligt, bliver mere tilfredse. Vi mangler dog stadig uafhængige studier af langtidseffekten på trivsel. Sig det højt internt, og mål det.
Hvor lander ansvaret i praksis
CTO og produktchefer ejer arkitekturen og de første loops. MLOps driver versionskontrol, observabilitet og udrulning. HR og ledelse gentænker roller og KPI’er: fra “løs 40 sager dagligt” til “supervisér 200 automatiserede sager med fejlrate under X og dokumentér forbedringsforslag”. Finans følger tokens lige så tæt som licenser. Compliance får data lineage og rollback-planer skrevet ned, ikke bare sagt.
Til implementering: start altid med et kort proof-of-value i produktion, ikke en ren PoC i sandkassen. Et rigtigt loop, lille men ægte, med rigtige brugere og rigtige konsekvenser. Man opdager først hullerne, når man tænder for trafikken.
Hvad vi gjorde anderledes efter at have prøvet det selv
To praktiske ting vi ændrede i vores standard: 1) Vi indfører nu et “tool health check” som en del af hver release. Et lille script, der kører hver time og sikrer, at værktøjskontrakterne opfører sig. 2) Vi logger altid forkastede handlinger som førsteprioritet. De er guld til næste træningsrunde. Overraskelsen var, hvor meget værdi der lå i de afviste forslag.
Og en lille detalje fra en workshop i Aarhus: rummet lugtede af kaffe og tavleklistermærker. Halvdelen af energien kom i pausen, hvor den mest skeptiske mellemleder indrømmede, at hans team allerede manuelt gjorde det, som agenten nu foreslog. Bare langsommere.
Konklusion
Hvis vi kun skulle sige én ting: byg virksomheden som loops, ikke som slideware med en copilot. Start småt, men med arkitekturen rigtigt. Tokens bliver et styringsmål på linje med headcount, og værktøjskald bliver jeres nye kvalitetsmål. Resten er håndværk: data, versioner, målinger — og et par beslutninger, der gør ondt i begyndelsen. Det er prisen for at få en virksomhed, der bliver bedre, mens I sover.
