Project Management Leadership with AI · AI-enabled project management with governance · lesson 19 of 21 · 13 min
Governing AI use in project delivery
Why PMs need AI governance
Project managers now use AI tools themselves and often deliver projects that include AI features. Both require governance: rules that keep AI use lawful, safe, accurate and accountable.
Principles for AI use in project work
- Accountability: a named person owns every AI-assisted output and decision.
- Proportionate review: the higher the impact, the more rigorous the human check.
- Transparency: stakeholders know when content is AI-assisted, according to policy.
- Data protection and confidentiality: only approved tools; minimum necessary data; respect for personal data laws.
- Traceability: record inputs, tool versions, outputs, edits and approvals for significant outputs.
- Fairness and bias awareness: watch for biased suggestions (e.g., in resource allocation or vendor evaluation).
- Continuous learning: track errors and improve prompts, tools and training.
Risk-tiered review for PM outputs
| Tier | Examples | Review | |---|---|---| | Low | Brainstorming ideas, formatting, internal notes | Author check | | Medium | Status reports, RAID updates, meeting summaries, draft user stories | Author verifies facts against sources before sharing | | High | Business case figures, contractual correspondence, vendor evaluations, HR-related decisions | Independent review, documented approval | | Prohibited | Automated decisions about people (hiring, performance) or contracts without human decision | Not allowed |
Governing AI features inside your project
If your project builds or buys AI capabilities (e.g., a chatbot, a forecasting model, document automation), add governance to the plan:
- Use-case risk assessment: what could go wrong, for whom? Is it a high-risk use under applicable law?
- Data governance: source, quality, consent, retention, residency.
- Testing: accuracy, robustness, bias, security (including prompt injection for language-model features), and human fallback.
- Human oversight design: when and how humans review or override.
- Monitoring after go-live: performance drift, incidents, user feedback.
- Documentation: model or system cards describing purpose, limitations and evaluation results.
Frameworks that can help include the NIST AI Risk Management Framework (US), ISO/IEC 42001 for AI management systems, the EU AI Act's risk-based obligations where applicable, the UK's principles-based regulatory approach, and national AI principles and guidance published in the UAE, Saudi Arabia (e.g., SDAIA guidance) and Pakistan. Always follow your organisation's legal advice; requirements change and depend on context.
Worked example: vendor evaluation with AI
Illustrative. A fictional public agency in the UK used an AI tool to summarise vendor proposals. A reviewer noticed that the summaries consistently described one bidder's proposal more favourably; investigation showed that bidder's document used language closely matching the evaluation criteria, which the AI echoed. The agency changed its process: AI summaries could be used for navigation only, evaluators scored directly from the proposals, and the procurement record noted how AI had been used. This protected fairness and the defensibility of the award.
AI use register
Use ID | Description | Tool (approved?) | Data used | Tier | Reviewer role | Records kept
U-01 | Weekly status drafting | Enterprise AI (Y) | Project data only | Medium | PM | Draft + final
U-02 | Test case generation | Dev assistant (Y) | Requirements | Medium | QA lead | Test repo
U-03 | Vendor proposal summaries | Enterprise AI (Y) | Proposals | High | Procurement lead| Evaluation file
Common mistakes
- No policy, so each person makes their own rules.
- Treating AI features as ordinary software without bias, robustness or oversight testing.
- Ignoring data residency and cross-border transfer rules.
- No record of how AI influenced important decisions.
Quick self-check
Could you, today, list every way your project uses AI and who reviews each output? If not, start an AI use register this week.
Working with specialists
Project managers do not need to be AI experts, but they must involve the right specialists: data protection officers, security teams, legal and compliance, and data scientists who can evaluate models. Build their reviews into the plan with dates and entry criteria, just like any other quality gate. Late involvement is a frequent reason AI features are delayed or blocked before launch.
Communicating with users about AI
Tell users when they are interacting with an AI system, what it can and cannot do, and how to reach a human. Clear communication builds trust, reduces misuse and is required by some regulations and policies.
Template: AI use register
| ID | Use | Tool (approved) | Data used | Personal/confidential data? | Tier | Reviewer | Disclosure | Added | Review date | |---|---|---|---|---|---|---|---|---|---| | AI-01 | Weekly status draft | Enterprise assistant | Metrics table, RAID export | No | Medium | PM | Footer note | | | | AI-02 | Vendor proposal navigation | Enterprise assistant | Proposals | Commercial: yes (approved tool) | High | Evaluation lead | Procurement record | | |
Template: AI-feature governance workstream
Task Owner Gate it blocks
Use-case risk assessment Product owner + legal Design approval
Data review (source, consent, Data protection Build start
retention, residency)
Testing: accuracy, robustness, QA + data science Pilot
bias by group, prompt injection
Human oversight design Product + operations Pilot
Monitoring plan (drift, incidents,
feedback, override rates) Operations Rollout
System/model card Product owner Rollout
Hands-on: a simple bias check on pilot results (Python)
import pandas as pd
pilot = pd.read_csv("triage_pilot.csv") # case_id, group, model_priority, reviewer_priority
pilot["agree"] = pilot.model_priority == pilot.reviewer_priority
by_group = pilot.groupby("group").agg(cases=("case_id", "count"), agreement=("agree", "mean"))
gap = by_group.agreement.max() - by_group.agreement.min()
print(by_group.round(3))
print(f"Largest agreement gap between groups: {gap:.1%}")
if gap > 0.05: # illustrative threshold; agree yours with compliance before the pilot
print("Investigate before extending the pilot; record the decision.")
Group definitions must be lawful and agreed with data protection; small groups need care before drawing conclusions.
How to measure success
- Every AI use on the project listed in the register with a tier and reviewer.
- AI-feature governance tasks complete before the gates they block.
- No high-tier output released without documented independent review.
Video lecture: Governing AI use in project delivery
Lecture coming soon · 10 chapters · about 9 minutes. Read the full transcript below.
- Two jobs: governing AI use, and governing AI features
- Why it matters
- The concept: principles and tiers
- Governing AI features inside your project
- Worked example one: an AI use register entry
- Worked example two: vendor evaluation in the UK
- Watch me do it: adding AI-feature governance to a plan
- Communicating with users about AI features
- Common mistakes and working with specialists
- Recap and try this now
Lecture transcript
Two jobs: governing AI use, and governing AI features
Project leaders now face AI governance from two directions. First, your own use of AI: drafting reports, summarising proposals, analysing data. Second, the AI features your project delivers: a chatbot, a claims triage model, document automation. Both can go wrong in ways that hurt people, and both need governance that's proportionate and practical. In this lecture you'll learn principles for AI use in project work, a risk-tiered review model for project outputs, how to run an AI use register, what governance an AI feature needs from design to monitoring, and the frameworks that can help. By the end, you'll be able to create an AI use register for your project and add AI-feature governance to a project plan.
Why it matters
Why does this matter? Because AI outputs increasingly influence decisions that affect people: which vendor wins a contract, how a customer's claim is prioritised, what the board believes about a project's status. If those outputs are biased, wrong or opaque, the harm is real, and so is the accountability. Procurement is a particularly sensitive area, because fairness and defensibility are legal requirements for public bodies and expected by everyone else. Regulation is evolving in many jurisdictions. And customer trust, once lost through a poorly governed AI feature, is very hard to rebuild. Governance is how you capture the benefits while keeping these risks visible and managed.
The concept: principles and tiers
Here are the principles for AI use in project work. People remain accountable: AI assists; it doesn't sign. Use only approved tools, and protect personal and confidential data. Review proportionally to impact. And be transparent: record where AI was used in significant outputs, and disclose it according to policy. Now the tiers. Low: internal notes and first drafts for your own use, spot-checked. Medium: team-facing documents such as minutes, status drafts and backlog items, fully reviewed by the owner. High: anything affecting decisions about money, contracts or people, such as board reports, vendor evaluations, business case figures or regulator correspondence, which need independent review and documented approval. And prohibited: automated decisions about people or contracts without human oversight.
Governing AI features inside your project
If your project builds or buys an AI capability, add governance to the plan, not as an afterthought. Start with a use-case risk assessment: what could go wrong, for whom, and is this a high-risk use under applicable law? Then data governance: where the data comes from, its quality, consent, retention and residency. Testing: accuracy, robustness, bias across the groups affected, and security, including prompt injection for features built on language models. Design human oversight: when and how people review or override outputs. Plan monitoring after go-live for drift, incidents and user feedback. And document it, in a model or system card describing purpose, limitations and evaluation results. Frameworks such as the NIST AI Risk Management Framework and ISO slash IEC forty-two thousand and one help structure this, alongside regulations like the EU AI Act where they apply, and national guidance in the UK, the UAE, Saudi Arabia and Pakistan.
Worked example one: an AI use register entry
Let's write one entry in an AI use register, which is simply a list of the ways your project uses AI. Use: drafting the weekly status report. Tool: the organisation's approved enterprise assistant. Data: the metrics table and the RAID export, with no personal data and no commercial terms. Tier: medium, because the report goes to the team and sponsor. Reviewer: the project manager, who checks every number against the source. Disclosure: a footer note, in line with company policy, saying the draft was AI-assisted and reviewed. Date added and review date. Five minutes of work. And now, if anyone asks how AI is being used on your project, you have a clear, honest answer rather than a vague reassurance.
Worked example two: vendor evaluation in the UK
Now a realistic example from the lesson. A fictional public agency in the UK used an AI tool to summarise vendor proposals, to help evaluators navigate hundreds of pages. A reviewer noticed that the summaries consistently described one bidder's proposal more favourably. The investigation showed why: that bidder's document used language closely matching the evaluation criteria, and the AI echoed it back. The underlying substance wasn't necessarily better. The agency changed its process. AI summaries could be used for navigation only; evaluators scored directly from the proposals; and the procurement record noted exactly how AI had been used. That protected the fairness of the competition and the defensibility of the award. It's a perfect example of a subtle bias that only human attention caught.
Watch me do it: adding AI-feature governance to a plan
Let me show you how I build AI-feature governance into a plan so it actually happens. I add a workstream called AI governance, with real tasks: use-case risk assessment, data review, testing for accuracy, bias and robustness, including prompt injection for language-model features, human oversight design, a monitoring plan and a system card. Each task gets an owner: data protection, security, the product owner, compliance. Then I link them to gates. No pilot without test results reviewed and signed off. No rollout without a monitoring plan and an agreed human override process. Now governance isn't a document someone writes at the end. It's work with owners and dates, visible on the same plan as everything else, and it can block a gate if it's not done.
Communicating with users about AI features
A final practical point on AI features: tell the people affected. Users and customers should know, in plain language, what the AI does and doesn't do, and how a person can review or challenge an outcome. For a claims triage feature, that might be three sentences: we use AI to help prioritise claims; a claims handler reviews every recommendation; and you can ask for a review by contacting us. Keep these messages consistent with the system card and with what the product actually does, because a mismatch between the promise and the reality is a trust problem and, in some jurisdictions, a regulatory one. The project leader doesn't write the legal wording, but should make sure this communication is on the plan, owned and tested with real users.
Common mistakes and working with specialists
The common mistakes: using unapproved tools because they're convenient; reviewing the wording of AI outputs but not the numbers or sources; launching AI features without bias testing or a monitoring plan; and treating AI governance as someone else's job. Project leaders don't need to be lawyers or data scientists, but they do need to bring those specialists in early, at design reviews rather than just before go-live. And communicate honestly with users about AI features: what the AI does, what it doesn't, and how a person can review or challenge an outcome. Clear communication builds trust, and it's increasingly expected by regulators too.
Recap and try this now
Let's recap. Project leaders govern AI in two ways. For your own use: people stay accountable, only approved tools, review proportional to impact, and transparent records in an AI use register. For AI features your project delivers: a risk assessment, data governance, testing for accuracy, bias, robustness and security, designed human oversight, monitoring after go-live and a system card, all as real tasks on the plan, linked to gates. Use frameworks like NIST's and ISO slash IEC forty-two thousand and one, follow applicable regulation, and involve specialists early. Your try-this-now: create an AI use register for your project or team with at least three entries, and assign a review tier to each.
Key takeaways
- Govern AI use with accountability, proportionate review, transparency, data protection and traceability.
- Tier AI-assisted outputs by impact; prohibit automated decisions about people or contracts.
- Projects delivering AI features need risk assessment, data governance, bias and security testing, oversight and monitoring.
- Keep an AI use register and follow applicable frameworks and legal advice.
Try it
Create an AI use register for your project or team with at least three entries and assign a review tier to each.