Dina bästa AI-piloter cementerar processen du menade att döda

McKinsey publicerade en artikel den 4 augusti 2026 om att bygga en HR-funktion kring agenter, och gömd i inställningen är den mest användbara meningen som någon har skrivit om företags-AI den här kvartalet. När det beskrivs vad som händer när team bygger agenter utan en plan, skriver författarna att “varje ostyrd agent förstärker en bit av den gamla driftsmodellen i kod.”

De kallar resultatet för pilotfällan: hastighet på uppgiftsnivå, drift på designnivå.

Den meningen är värd mer än ramverket den introducerar, och den gäller långt utanför HR, för många företag som just nu kör agentpiloter som inte kan se utfallet, eftersom piloterna fungerar.

Fällan är piloten som lyckas

Här är mekanismen. En lönespecialist eller en rekryterare, noterar artikeln, kan nu konfigurera en fungerande agent på en eftermiddag med hjälp av lågkodverktyg, bygg-vid-konfiguration-plattformar som lägger mest arbete i att klicka och skriva instruktioner snarare än att skriva kod. Inte en prototyp. En fungerande, inkopplad i en riktig arbetsflöde, producerar riktigt utdata.

Det betyder att sekvensen som alla lärde sig, börja smått sedan lära sedan expandera, inte längre är den försiktiga optionen. McKinsey uttrycker det rakt: instinkten att “börja smått och lära” är inte längre konservativ. När någon specialist kan ställa upp en agent på en eftermiddag, sker starten av det små oavsett om ledningen sanktionerar det eller inte.

Värt att vara exakt om var artikeln slutar och extrapoleringen börjar. McKinseys pilotfälla är främst ett argument om bortslösad ansträngning — team som perfekterar steg som en ordentlig omkonstruktion skulle radera. Versionen nedan är den svårare, och den är min: den bortslösade ansträngningen är återvinningsbar, och låsningen är inte.

De misslyckade piloterna är okej. En pilot som misslyckas stängs av och glöms och kostar några veckor. De farliga är de som fungerar, eftersom en fungerande agent omedelbart blir belastande. Någons tisdag beror på det. Det försvaras i budgetmötet. Och vilken process det automatiserade, inklusive alla steg som bara existerar på grund av ett system som ersattes för fyra år sedan eller en policy som ingen har läst sedan, är nu inkodat, körs och är mycket svårare att argumentera mot än det var när det levde i ett dokument.

Det är fällan. Du automatiserade inte ett arbetsflöde. Du ratificerade ett. Vilket är den obekväma versionen av den alltmer vanliga upptäckten att AI-resultat beror mer på arbetsflödets form än på verktygen riktade mot det. Om arbetsflödet är den variabel som är viktig, då är att förstärka ett dåligt ett det dyraste en lyckad pilot kan göra.

Det nummer de begravde

Rubriksiffran i artikeln är att ungefär två tredjedelar av dagens HR-aktiviteter kan fullständigt automatiseras eller fullständigt automatiseras i leverans till 2030. Det numret kommer att citeras överallt den här veckan och det är det minst intressanta i artikeln.

Det intressanta numret är i tidsallokeringsdiagrammet. I den destinationstillstånd som McKinsey beskriver, går ungefär 20 procent av mänsklig tid till vad de kallar agenskapacitetsförvaltning: konfigurera agenter, skriva och granska den logik som agenterna följer, testa dem före utgivning, övervaka deras prestanda och drift, och pensionera dem när arbetsflödet ändras. Artikeln definierar inte drift; läs det som den långsamma glidningen där en agents utdata förblir trovärdig medan den tystnar och slutar vara rätt.

En femtedel av en funktionens mänskliga timmar ägnas åt att sköta maskinerna. Artikeln är explicit med att detta “inte är en avrundningskategori”, och det är rätt. Det är samma tillsynskostnad som fortsätter att dyka upp som den största dolda kostnaden i företags-AI, nu given en procentsats. Men artikeln säger inte om den 20 procenten är en övergångskostnad som faller när praxis mognar, eller den faktiska steady-state-priset för att köra agenter i stor skala. Det är det numret som bestämmer om ett agentprogram är en kostnadsreducering eller en kostnadsbyte, och det saknas. Om du modellerar besparingar från automatisering och du inte har lagt till en rad i modellen för de personer som underhåller automatiseringen, är din modell felaktig med ungefär en femtedel av den berörda teamen.

Samma lucka dyker upp i fallet. En organisation i artikeln implementerade 50 användningsfall och “identifierade betydande årliga kostnadsbesparingar tillsammans med meningsfulla förbättringar av HR-service nivåer.” Betydande gör mycket arbete där. Mer till punkten: artikeln varnar, i paragrafen rakt efter, att i vissa fall förbättrar organisationer effektiviteten i processer som senare eliminerar eller absorberar i helt olika arbetsflöden. Så hur många av de 50 överlevde? Det enskilda numret skulle avgöra om den bottom-up-routen är en genväg eller en dyr omväg, och det är inte där.

Den halva rådet som ett vanligt företag faktiskt kan använda

McKinseys recept är att definiera din 2030-mänsklig-agent-driftsmodell först och arbeta bakåt från den. Definiera destinationen, sedan sekvensen för implementeringen, kapacitetsinvesteringarna, styrningen.

Artikeln är ärlig om vem som kan göra det. Dess egen destination-organisationsdiagram, säger det, kräver “produktledningsmusklerna som de flesta HR-funktioner inte har idag, en datagrund som är tillräckligt stark för att köra en färdighetsgraf, och en CHRO med ett riktigt företagsarbetsstyrningsmandat.” Sedan: “färre organisationer kan börja här.”

För alla andra, inklusive många företag som redan har agenter som körs, är den nordliga stjärnan inte den handlingsbara halvan. Diagnosen är. Om ostyrda agenter kodar den gamla processen, då är exponeringen du har idag proportionell mot hur många agenter som redan existerar som ingen godkände, och du vet nästan säkert inte det numret.

Så det första draget är inte en 2030-ritning. Det är en räkning.

Hitta vad som faktiskt körs. Inte vad som godkändes. Vad existerar. Varje automatisering någon byggde i ett lågkodverktyg, varje schemalagd uppgift inkopplad i en delad inkorg, varje assistent konfigurerad mot ett riktigt system av register. För var och en, tre fakta: vem byggde det, vad det kan röra, och vad bryter om det slutar. Den inventeringen tar en eftermiddag per avdelning och det är den enda versionen av “styrning” som ett företag utan en transformationskontor kan utföra på måndag.

Artikelns egen femte CHRO-fråga är den att stjäla, och det är den skarpare av de fem: vilka tidiga val är grundläggande, vilka ackumuleras över tiden, och vilka kan säkert göras ogjorda. Sortera din inventering på det sättet. Agenterna som kan göras ogjorda är dina experiment och du bör köra fler av dem. De som inte kan är din arkitektur, oavsett om någon bestämde det eller inte. Det är också en användbar korrektur till instinkten som driver de flesta första piloterna, som är att rikta agenter mot den mest synliga processen snarare än en tystare inre.

Vem det faktiskt kostar

Partiet som förlorar här är inte företaget som aldrig började. Det är det som är två år in med en sund piloträkning och en bild som visar antagande som stiger.

Piloträkning är den mätning som känns som framsteg och mäter motsatsen. Varje ytterligare pilot byggd mot den nuvarande processen höjer kostnaden för att ändra den processen senare, eftersom det nu finns verktyg på vägen och en person som äger det och ett nummer i en bild som säger att det fungerar. Företaget med dussintals fungerande agenter är inte före företaget med tre. Det är mer engagerat.

Det är den omformulering som är värd att ta med sig från den här artikeln. Frågan att ställa om ditt agentprogram är inte hur många som körs eller hur precisa de är. Det är hur mycket av din nuvarande driftsmodell du skulle behöva avveckla för att ändra ditt sinne — och om någon kunde säga det till dig idag.