Byg videre på den stack, du har: rollout-mønstret der får AI til at skabe compound-effekt

Den hurtigste måde at spilde et år med AI på er at behandle det som en samling smarte værktøjer, som medarbejdere kan “prøve af.” Du får et energiboost, nogle imponerende prompts – og et stille rod: spredt dataadgang, inkonsistente svar og et security-team, der opdager det bagefter.

Udtrykket “build on the stack you have” dukker op igen og igen, fordi det er det stik modsatte. Det er en constraint, der tvinger fokus: brug de systemer, folk allerede lever i, og lad forbedringen føles som en workflow-opgradering – ikke et nyt job.

Det stod tydeligt i SaaStrs writeup om en fælles playbook på tværs af meget forskellige profiler fra Atlassian, Anthropic og Scale, som alle konvergerer på at bygge AI ind i de værktøjer og processer, virksomheder allerede kører på. Jeg er enig i retningen. Men jeg mener, at de fleste teams fejler i oversættelsen.

Så her er oversættelsen: “build on the stack you have” er et rollout-mønster for operators. Det fortæller dig, hvad der skal standardiseres, hvad der skal lukkes ned, og hvordan du sætter en lille gruppe op, der gør pilots til workflow-assets, der kan compounde.

Spændingen: pilots føles billige, men rodet er dyrt

Pilots er forførende, fordi de er lette at starte. Nogen tilføjer en copilot-extension, opretter et LLM-workspace, smider et par dokumenter ind og erklærer sejr. Ingen budgetrunde. Ingen integration. Ingen svære samtaler.

Så kommer regningen – i en anden valuta: rework, mistillid og skjult risiko.

• Rework: man kan ikke reproducere hinandens resultater, så hver “sejr” bliver personligt håndværk – ikke en gentagelig capability.

• Mistillid: når to assistants svarer forskelligt på samme spørgsmål, lærer organisationen den forkerte lektie: AI er tilfældigt, så lad os ignorere det.

• Skjult risiko: adgangsveje bliver flere. Data flyder gennem uforvaltede tools. Ingen kan forklare, hvad der er brugt hvor.

Løsningen er ikke “mere governance” som stemning. Løsningen er et lille sæt standarder, der skaber en fælles control plane – og viljen til at fjerne alternativer, der går udenom den.

Standardisér fire ting tidligt (eller betal for evigt)

Hvis du vil have AI til at compounde, skal du standardisere det, der gør det styrbart. Teams kan godt variere på prompts og UI-eksperimenter. Men de må ikke variere på identity, permissions, dokumentation og evaluering.

1) Identity: én bruger, ét spor

Alle interaktioner, der betyder noget, skal kunne tilskrives nogen. Ikke for at kontrollere – for at lære. Hvis du ikke kan koble et resultat til bruger og kontekst, kan du hverken debugge fejl eller sprede det, der virker.

Identity er også sådan, du holder AI inde i din stack. Single sign-on er ikke et checkbox-krav. Det er forskellen på “det her er vores tool” og “det her er noget, folk gør ved siden af.”

2) Permissions: least privilege, workflow-aware

De fleste permission-modeller er bygget til mennesker, der klikker i skærmbilleder. AI ændrer adgangens form, fordi det kan bevæge sig på tværs af systemer og opsummere.

Så spørgsmålet er ikke “kan assistant læse mappen?” Det er: “kan assistant udføre denne handling i dette workflow – med dette audit trail?” Hvis permission-modellen ikke afspejler workflow-grænser, ender du med enten at blokere alt eller lække alt.

Praktisk regel: start restriktivt, og åbn derefter baseret på observeret værdi og kontrollerede pathways. Det er langt nemmere at give adgang end at rulle den tilbage, når indhold allerede er spredt i prompts, noter og exports.

3) Dokumentation: behandl prompts og workflows som product

Dokumentation er der, pilots dør – netop derfor skal den standardiseres.

Du har brug for et sted, hvor en workflow-forbedring bliver forståelig for det næste team. Ikke “her er min prompt”, men “her er jobbet der skal løses, her er input contract, her er det forventede output, her er failure mode.”

Gør den genbrugelige enhed til et workflow card:

• Trigger: hvornår bruger man det?

• Inputs: hvilke systemer og felter bygger det på?

• Output: hvordan ser “godt” ud?

• Escalation: hvornår skal et menneske tage over?

• Owner: hvem opdaterer det, når processen ændrer sig?

Det er den samme muskel som at shippe features: klare contracts slår tribal knowledge.

4) Evals: et simpelt test-harness slår diskussioner

Uden evals bliver enhver debat til smag og behag. Med evals kan du forbedre workflowet på samme måde, som du forbedrer software: mål, ændr, mål igen.

Hold det simpelt i starten:

• Golden set: 20–50 reelle eksempler fra workflowet.

• Scoring rubric: hvad “korrekt” betyder (og hvad der er uacceptabelt).

• Regression checks: når prompts, retrieval eller modeller ændrer sig, så kør testen igen.

Hvis I allerede shipper software, bør det her føles velkendt. Faktisk har den hurtigste adoption, jeg har set, været, når teams stoppede med at tale om “AI quality” og begyndte at behandle det som et system, man kan teste.

Luk to ting ned konsekvent: shadow copilots og private videnslagre

Standardisering er kun halvdelen. Den anden halvdel er subtraktion. Hvis du vil have en fælles AI-capability, kan du ikke samtidig beholde parallelle tools, der undergraver den.

Shadow copilots: den stille forgrening af organisationen

En shadow copilot er enhver assistant, der ligger udenfor jeres identity- og permission-model. Den kan være velment. Den kan endda være “godkendt for nu.” Men den skaber tre forks:

• En fork i data paths (hvad blev indsat hvor).

• En fork i user behavior (teams lærer forskellige vaner).

• En fork i truth (svarene varierer, og ingen ved hvorfor).

Vær eksplicit: hvilke assistants er sanctioned, i hvilke kontekster – og hvilke er ikke. Hvis du ikke trækker linjen, bygger dine bedste folk udenom dig, og dine mest forsigtige folk melder sig helt ud.

Private videnslagre: stop med at belønne “prompt whisperers”

Alle organisationer får nogle power users, der skaber stærke resultater. Den klassiske fejl er at hylde dem uden at udtrække aktivet.

Hvis en prompt eller et workflow-trick er værdifuldt, hører det hjemme i det fælles bibliotek – med en owner og en opdateringskadence. Ellers har du skabt en ny type key-person dependency, forklædt som innovation.

Det er også her, incitamenter betyder noget. Hvis du roser heroics, får du flere heroics. Hvis du roser genbrugelige workflow cards, som andre adopterer, får du compound-effekt.

Org-designet, der gør pilots til aktiver, der compounding

De fleste “AI task forces” fejler af én enkel grund: de er bemandet til at udforske, ikke til at integrere. Udforskning er nødvendig. Integration er det, der ændrer forretningen.

Du vil have en lille enabling-gruppe med et snævert mandat: at gøre dokumenterede pilots til genbrugelige workflow-assets inde i den stack, I allerede kører. Tænk på det som at produktificere interne workflows.

Her er en struktur, der holder under pres:

• Workflow owner (fra forretningen): definerer hvad “godt” er, vælger de første use cases, ejer adoption.

• Platform integrator (fra engineering eller IT): identity, permissions, connectors, audit.

• Evaluation lead (kan være QA-minded): golden sets, rubrics, regression checks, incident review.

• Change lead: træning, docs, rollout-kommunikation, feedback loops.

Ikke et stort team. Et klart interface. Og én regel: Gruppen bygger ikke tilfældige demoer. Den shipper kun workflow-upgrades, der lever i de tools, folk åbner hver dag.

Det er også her, du kan låne fra transformationsmekanismer, der forhindrer silo-theater. Hvis du vil have et strammere sæt steering tools, har jeg skrevet et separat indlæg om fem mekanismer, der forhindrer silo-theater. Samme logik gælder her: klarhed om ejerskab, kadence og beslutninger slår entusiasme.

Et eksempel fra virkeligheden: når du indser, at “pilot” er et governance-valg

Jeg har set en R&D-organisation shippe flere “assistants” parallelt, hver bygget af dygtige teams, der ville hjælpe. De virkede. Hver for sig. Så ændrede en release en fælles dependency, og ingen kunne blive enige om, hvorvidt kvaliteten blev bedre eller dårligere – fordi hvert tool brugte forskellige prompts, forskellige context sources og forskellige acceptance criteria.

Vi løste det ikke ved at vælge den “bedste” assistant. Vi løste det ved at standardisere evals og dokumentation og derefter samle tools i én sanctioned path med klare access rules. Den synlige effekt var færre diskussioner. Den reelle effekt var hastighed: forbedringer stoppede med at blive nulstillet, hver gang en model eller prompt ændrede sig.

Pointen er lidt ubehagelig, men nyttig: pilots bliver permanente, når man undgår det hårde standardiseringsarbejde. “Midlertidigt” betyder ofte bare “uden owner.”

Rollout-mønstret, du kan køre dette kvartal

Hvis du vil have en konkret sekvens, så brug denne:

1. Vælg to workflows hvor output er let at vurdere, og hvor handoff-friktionen er reel (support triage, salgsopkald-summaries til CRM, incident writeups, PRD-drafting med en fast template).

2. Definér input contract: hvilke systemer er tilladte sources, hvilke felter betyder noget, og hvad er out of scope.

3. Installér control plane: SSO, permission boundaries, audit trail. Ingen undtagelser for “bare dette team.”

4. Lav et golden set fra reelle cases og skriv en rubric. Start småt. Gør det eksekverbart.

5. Ship et workflow card i det primære tool (ticketing, CRM, docs, chat). Hold friktionen lav.

6. Kør en ugentlig review: adoption, failure modes, regressions – og én forbedring shipped.

7. Luk alternativer ned der går udenom standarderne. Vær høflig, vær konsekvent, vær hurtig.

Hvis jeres organisation allerede tænker i “control plane”-termer for AI, vil du måske også kunne lide AI architecture isn’t a diagram. It’s an operator’s checklist. Den røde tråd er den samme: reliability er designet – ikke noget man håber på.

Min holdning: “build on the stack you have” er en disciplin, ikke en præference

At bygge videre på den stack, du har, handler ikke om at være konservativ. Det handler om compound-effekt. Når AI lever inde i jeres eksisterende identity, permissions, docs og evals, bliver hver forbedring genbrugelig. Den spreder sig gennem workflow cards, ikke gennem snakke på gangen. Den overlever udskiftning i medarbejderstaben. Den bliver mere sikker, i takt med at den bliver mere nyttig.

Når AI lever udenfor stacken, kan du bevæge dig hurtigt i en måned. Derefter bruger du de næste seks på at rydde op i konsekvenserne og forsøge at genopbygge tillid.

Hvis du vil have én sætning, der kan styre beslutninger: standardisér control plane – og skaler først derefter kreativiteten.

Og hvis du er fristet til at måle succes i sparede timer, vil jeg udfordre den refleks. Det reelle mål er throughput med høj confidence. Jeg folder den spænding ud i Stop Measuring AI by Hours Saved.

Det bedste rollout er det, der gør næste kvartal lettere end dette kvartal. Det er sådan compound-effekt ser ud.