Styra AI-beslut i ditt team
Problemet är inte PM:en som använder Claude slarvigt. Den PM:en finns i varje team och skapar risk på individnivå.
Det svårare problemet är teamet där varje PM har en annan standard. En PM granskar varje kundriktat utkast noggrant. En annan genererar och skickar. En tredje undviker AI-verktyg helt och producerar långsammare arbete av pålitlig kvalitet. En fjärde använder AI entusiastiskt och granskar inkonsekvent beroende på deadlinetryck.
Kunden ser en organisation. Inkonsistensen är osynlig för teamet och synlig för kunder över tid — i inkonsekvent kvalitet, i enstaka fel som når dem, i trovärdighetsklyftan mellan vad teamet levererar en bra vecka kontra en pressad.
En team-AI-process stänger det gapet. Inte ett policydokument. En fungerande process.
Hur ett AI-inkonsekvent team ser ut utifrån
En kund som arbetar med ett PM-team under flera månader ser mönster. Vissa projektuppdateringar är ovanligt välstrukturerade och specifika. Andra är tydligt sammanslagna snabbt och saknar kontexten kunden behöver. Vissa riskbedömningar är substantiella. Andra är generiska checklistor.
Kunden kan inte se vem som producerade vilket dokument eller hur. De kan se variationen. Kvalitetsvariation från ett professionellt team är en förtroendesignal — i fel riktning.
AI-inkonsistens gör ofta det här värre snarare än bättre. Klyftan vidgas mellan PM:en som använder AI väl (mer output, bättre formaterat) och PM:en som använder det slarvigt (snabbare output, lägre pålitlighet). Variationen blir mer synlig, inte mindre.
De tre saker en teamprocess behöver definiera
Vilka outputtyper som kräver obligatorisk granskning. Allt AI-assisterat arbete bär inte samma konsekvens. En snabb intern uppdatering som går till en kollega: individuellt omdöme räcker. Ett förslag som går till en kund och kommer att användas i ett upphandlingsbeslut: obligatorisk granskning av en andra person innan det går ut.
Definiera det efter konsekvens, inte efter om AI användes. Triggern för obligatorisk granskning är outputens ansvarsnivå, inte produktionsmetoden.
Vem som äger granskningen. För varje kategori av output som kräver obligatorisk granskning bör det finnas en namngiven roll (inte nödvändigtvis en namngiven person). Senior PM på kontot. Engagemangsledaren. Teamledaren för den här kunden. Ägarskapet definieras innan deadline — inte beslutas under press.
Vad som händer när något går fel. Om ett AI-assisterat dokument når en kund med ett betydande fel, vad är vägen framåt? Vem meddelas, hur snabbt, vad är korrigeringsprocessen, vem kommunicerar med kunden? Den frågan bör besvaras i lugn innan den behöver besvaras i kris.
Vad processen inte behöver inkludera
Den behöver inte täcka varje AI-interaktion. Interna anteckningar, personlig forskning, utforskande utkast — dessa är individuellt ansvar.
Den behöver inte ha en heltäckande verktygslista. Vilka specifika verktyg som är godkända eller inte är en separat fråga från hur granskning och ansvar fungerar. Processen täcker ansvar, inte verktyg.
Den behöver inte vara lång. En en-sidig process som en PM kan minnas under deadlinetryck är mer värdefull än ett tio-sidigt policydokument som ingen läser efter den första veckan.
Att bygga det utan att göra det till byråkrati
Det snabbaste sättet att bygga en teamprocess som fungerar är att göra det till en ärlig beskrivning av hur de bästa PM:arna i teamet redan arbetar — och sedan tillämpa det konsekvent.
Steg 1. Ta de senaste fem kundriktade dokumenten teamet producerade. För varje: vilken granskning skedde innan det skickades? Var det tillräckligt? Vad skulle ha fångats av en mer noggrann granskning?
Steg 2. Definiera de outputkategorier som spelar roll: de typer av dokument som går till kunder eller informerar viktiga beslut. För varje kategori, skriv en mening om den krävda granskningen: "Förslag över en viss storlek kräver en andra PM-läsning innan de skickas. Kundrika statusrapporter kräver att PM:en verifierar nyckelspåstenden mot sin egen kunskap innan de skickas."
Steg 3. Namnge ägaren för varje kategori. Vem är ansvarig för att granskningen sker?
Steg 4. Sätt en kvartalsvis kontrollpunkt. Inte för att revidera hela processen — för att fråga: är det här fortfarande korrekt? Har teamets AI-användning förändrats? Har en ny typ av arbete uppstått som behöver läggas till?
Steg 5. Testa det under press. Processen som fungerar i lugn kanske inte fungerar i en deadlinesprint. Kör det första kvartalet med uppmärksamhet på om granskningsstegen faktiskt händer när projekten är tajta. Justera baserat på vad du hittar.
Den enda fråga som berättar om processen fungerar
Fråga en teammedlem: "Vilken granskning krävs innan ett kundförslag går ut?"
Om de kan svara utan att slå upp något fungerar processen.
Om de säger "jag tror det finns ett dokument någonstans" eller "jag skulle behöva kolla", är processen ett dokument, inte en process.
Målet är internaliserad tydlighet. Rätt granskningsstandard bör vara lika automatisk som rätt dokumentformat. Det är en del av hur teamet arbetar, inte ett efterlevnadssteg som lagts till ovanpå.
Koppling till bredare styrning
Den här processen på teamnivå är PM-lagret i en större styrningsstruktur. Det tekniska lagret — vilka AI-verktyg som har tillgång till vilken data, hur MCP-kopplingar är avgränsade, vem som äger autentiseringsuppgifterna — täcks i Spår 4:s styrningsaterial.
En team-AI-process ersätter inte det lagret. Den fungerar tillsammans med det. PM-teamet definierar vilken granskning som sker innan outputs når kunder. Den tekniska styrningen definierar vad Claude kan komma åt och på vilka villkor. Båda är nödvändiga. Vardera är ofullständig utan den andra.
Det här är den sista guiden i serien PM & Operations Fundamentals.
Se även: Ansvarsnivåer i AI-assisterat arbete och Från individuell AI till organisatorisk AI