Governing AI decisions across your team
The problem is not the PM who uses Claude carelessly. That PM exists in every team and creates individual-level risk.
The harder problem is the team where each PM has a different standard. One PM reviews every client-facing draft carefully. Another generates and sends. A third avoids AI tools entirely and produces slower work of reliable quality. A fourth uses AI enthusiastically and reviews inconsistently depending on deadline pressure.
The client sees one organisation. The inconsistency is invisible to the team and visible to clients over time — in inconsistent quality, in occasional errors that reach them, in the credibility gap between what the team delivers on a good week versus a pressured one.
A team AI process closes that gap. Not a policy document. A working process.
What an AI-inconsistent team looks like from the outside
A client working with a PM team over several months sees patterns. Some project updates are unusually well-structured and specific. Others are clearly assembled quickly and lack the context the client needs. Some risk assessments are substantive. Others are generic checklists.
The client cannot see who produced which document or how. They can see the variation. Variation in quality from a professional team is a trust signal — in the wrong direction.
AI inconsistency often makes this worse rather than better. The gap widens between the PM who uses AI well (more output, better formatted) and the PM who uses it carelessly (faster output, lower reliability). The variation becomes more visible, not less.
The three things a team process needs to define
What output types require mandatory review. Not all AI-assisted work carries the same consequence. A quick internal update that goes to one colleague: individual judgment is sufficient. A proposal that goes to a client and will be used in a procurement decision: mandatory review by a second person before it goes out.
Define this by consequence, not by whether AI was used. The trigger for mandatory review is the accountability level of the output, not the production method.
Who owns the review. For each category of output that requires mandatory review, there should be a named role (not necessarily a named person). The senior PM on the account. The engagement lead. The team lead for this client. The ownership is defined before the deadline — not decided under pressure.
What happens when something goes wrong. If an AI-assisted document reaches a client with a significant error, what is the path? Who is notified, how quickly, what is the correction process, who communicates with the client? This question should be answered in calm before it needs to be answered in crisis.
What the process does not need to include
It does not need to cover every AI interaction. Internal notes, personal research, exploratory drafts — these are individual responsibility.
It does not need a comprehensive tool list. Which specific tools are approved or not approved is a separate question from how review and accountability work. The process covers accountability, not tools.
It does not need to be long. A one-page process that a PM can recall under deadline pressure is more valuable than a ten-page policy that no one reads after the first week.
Building it without making it bureaucracy
The fastest way to build a team process that works is to make it an honest description of how the best PMs on the team already work — then apply it consistently.
Step 1. Take the last five client-facing documents the team produced. For each one: what review happened before it was sent? Was it adequate? What would have been caught by a more rigorous review?
Step 2. Define the output categories that matter: the types of documents that go to clients or inform significant decisions. For each category, write one sentence on the required review: "Proposals above a certain size require a second PM read before sending. Client-facing status reports require the PM to verify key claims against their own knowledge before sending."
Step 3. Name the owner for each category. Who is responsible for ensuring the review happens?
Step 4. Set a quarterly checkpoint. Not to revise the entire process — to ask: is this still accurate? Has the team's AI usage changed? Has a new type of work appeared that needs to be added?
Step 5. Test it under pressure. The process that works in calm may not work in a deadline sprint. Run the first quarter with attention to whether the review steps are actually happening when projects are tight. Adjust based on what you find.
The one question that tells you if the process is working
Ask any team member: "What review is required before a client proposal goes out?"
If they can answer without looking anything up, the process is working.
If they say "I think there's a document somewhere" or "I'd have to check," the process is a document, not a process.
The goal is internalised clarity. The right review standard should be as automatic as the right document format. It is part of how the team works, not a compliance step added on top.
Connecting to broader governance
This team-level process is the PM layer of a larger governance structure. The technical layer — what AI tools have access to what data, how MCP connections are scoped, who owns the credentials — is covered in the Track 4 governance material.
A team AI process does not replace that layer. It works alongside it. The PM team defines what review happens before outputs reach clients. The technical governance defines what Claude can access and on what terms. Both are necessary. Each is incomplete without the other.
This is the final guide in the PM & Operations Fundamentals series.
See also: Accountability levels in AI-assisted work and From individual AI to organisational AI