AI Governance for Project Managers
Very few project teams sit down and decide to start using AI. Someone drafts a risk summary with it on a Tuesday afternoon, finds the result useful, and mentions it to two colleagues. A month later three people are using three different tools, one of them has pasted a supplier's commercial terms into a prompt, and nobody has a shared view of what went in or what came out. By the time the matter reaches the project manager, it is no longer a question of permission. Something is already circulating, and a decision may already be resting on it.
The useful governance questions at that point are ordinary ones. What activity is this meant to improve, what information does it consume, what happens when the output is wrong, who checks it before anyone relies on it, who carries the consequence, and what needs to be recorded. None of those require an understanding of how a model works. They are the same questions a competent project manager would ask about any new source of information entering the project, and the answers determine whether an AI-assisted output is an aid to judgement or an unexamined input to a decision.
What a project manager is actually governing
Organisational policy sets the outer boundary. Which tools are permitted, what data classifications may be used with them, what the procurement and legal position is, and what the organisation has committed to its own customers and regulators. A project manager rarely sets any of that and should find out what already exists before writing local rules, because a project-level instruction that contradicts an organisational data policy creates a compliance problem on top of the original one.
Inside that boundary, the project decides where AI enters its own work. Which tasks it supports, what project information it is allowed to touch, which outputs need a named reviewer before they go anywhere, how decisions informed by those outputs are recorded, and what happens when someone's use of a tool falls outside what was agreed. This is consistent with Appendix X3 of the PMBOK® Guide Eighth Edition, which treats artificial intelligence as a modern project-management consideration requiring human oversight and clear accountability, not as something that replaces the project manager's judgement.
Getting the level right saves a surprising amount of time. Escalating a question about how the team drafts its meeting notes wastes a governance forum's attention. Deciding locally that it is acceptable to put an unpublished design specification into a public tool is a different order of mistake, and one that a project manager cannot make good afterwards.
The questions worth asking before an output is used
Start with the activity being improved. If someone can name it, the conversation becomes concrete: first-pass identification of risks that a human will then challenge, summarising forty pages of supplier response so a reviewer knows where to read properly, drafting a status narrative from figures that already exist. If nobody can name a decision or activity that gets better, what is happening is experimentation, which is legitimate, but it should be labelled as such and kept away from anything committed.
The second question concerns what goes in, and it is the one most often skipped. Personal data, security-classified material, a partner's confidential design information, unpublished financials, contract terms under negotiation: the harm in these cases has nothing to do with whether the output was any good. It happened at the moment the information left the environment it was supposed to stay in. Ask what the prompt will contain before asking what the answer will look like.
Then ask what happens if the output is wrong, and whether anyone would notice. A wrong first draft of an internal update is corrected in ten minutes by the person who wrote it. A wrong figure inside a supplier evaluation, a cost forecast presented to a steering group, or a document that forms part of a regulatory submission may not be corrected at all, because plausible errors survive review in a way that obvious ones do not. Detectability matters as much as likelihood here, and it is the difference between a low-consequence use and one that needs a control.
The fourth question is who reviews it, and whether that person is genuinely able to. A reviewer needs access to the source material, the competence to judge it, and enough time to do more than skim. Someone confirming a summary they cannot compare against anything has provided a signature rather than a review, and the project is then relying on a check that does not exist.
Accountability is the question that closes the set. It does not move to the tool, to the vendor, or to the team member who ran the prompt. Whoever owns the decision still owns it, which is why an accountable project leader has a legitimate interest in how an input to that decision was produced. Where the work is contractual, regulated or auditable, that interest extends to a proportionate record: which parts of a document were AI-assisted, what they drew on, who reviewed them and when. A light note in a decision log is often enough, and it is far easier to write at the time than to reconstruct nine months later when someone asks how a conclusion was reached.
Where the check usually breaks down
A payments migration programme received responses from eleven suppliers, each running to several hundred pages. An analyst used an approved AI assistant to build a comparison table of how each supplier proposed to handle transaction reconciliation during cutover, and the evaluation panel worked from that table. The summary was accurate for nine of the eleven. For the other two it recorded a commitment that the supplier had in fact qualified heavily in a later section, in language that the summary had condensed away.
The organisational policy had been followed. The tool was permitted, no confidential data had gone anywhere it should not, and the analyst had done nothing careless. What was missing was smaller and more specific: no member of the panel had read the two source passages that the scoring actually turned on. When the project manager set the rule that each scored criterion had to be traceable to a named paragraph in the original submission, checked by the panel member who owned that criterion, the AI output changed role. It became an index that told people where to read, rather than evidence in its own right, and the panel's time went to the parts of the submissions that mattered.
An analyst summarising eleven submissions by hand under time pressure could have made exactly the same error. What changes with AI is the speed and the fluency of the output, which makes the error less likely to look like one. That is an argument for designing the check in, not for treating the tool as untrustworthy.
Keeping the control proportionate
None of this justifies an approval queue for every use. Tiering by consequence is usually enough. Work that stays internal, gets corrected by its own author and commits nobody needs no ceremony at all. Output that enters a decision, a commitment, an external document or a regulated artefact needs a named reviewer, traceable sources and a note of what was checked. Tailoring applies here exactly as it does to any other control: heavier where the consequence of being wrong is real and difficult to reverse, lighter where it is not, and reviewed as the project learns what its people are actually doing.
Candidates preparing for the current exam should be precise about where AI sits. The 2026 Examination Content Outline names artificial intelligence as an emerging trend used as an input when the underlying job task analysis was validated. No task or enabler names AI, and technology appears as an example of the external business environment changes a project manager is expected to survey and assess. The practical implication is that AI questions arrive dressed as governance, compliance, risk or change questions, which is how they arrive on real projects too. Much of the difficulty is judgement under uncertainty rather than recall, and it firms up through practice against varied situations, which is a large part of what structured PMP® exam preparation is for.
On a live project the benefit is simpler. Teams that can answer these questions move faster with AI, because they know which uses need a second pair of eyes and which do not, and they stop relitigating the same argument every time a new tool appears. The record that matters a year later is not which assistant produced a document. It is who read the source, what they checked, and on what basis the decision was made.
Interested in going further?
Governance questions about AI rarely announce themselves as governance questions, which makes them easy to answer at the wrong level or not at all. Structured preparation gives you repeated practice at spotting where a decision sits, who holds the authority for it, and what evidence a responsible answer requires.
Appendix X3 of the PMBOK® Guide Eighth Edition sets out how artificial intelligence is treated as a project-management consideration, alongside the oversight and accountability expectations that go with it.
Ad · Amazon affiliate link.
References
A049: Artificial Intelligence in Project Management: Practical Uses, Risks and Limits
A090: Project Governance Explained: Who Decides What, and Why
A091: Project Governance vs Organisational Governance: What's the Difference?
A096: How to Recognise a Governance Question on the PMP Exam
A050: AI and the PMP Exam: What Project Managers Need to Know
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
