- The AI project charter serves the same purpose as any project charter — authorise the work, define scope and governance, establish accountability. What makes it different is the questions it must answer that conventional charters never ask: Why AI rather than an alternative? Who might be harmed? What decisions will never be fully automated? What data is this system permitted to learn from?
- NIST AI RMF MAP 1.5 identifies the go/no-go decision as an explicit outcome of the mapping function: after understanding the context, intended use, and risk profile of a proposed AI system, organisations should have sufficient information to make an initial decision about whether to design, develop, or deploy it. The charter captures that decision and the reasoning behind it. A charter that cannot answer the go/no-go questions is not ready.
- EU AI Act Article 14 requires that human oversight for high-risk AI systems be designed into the system — including technical measures enabling oversight persons to understand limitations, detect anomalies, interpret outputs, and override or halt the system. These are architecture requirements that must be resolved during chartering. A human oversight section that says only “there will be human review” is not sufficient.
- EU AI Act Article 10 requires that training, validation, and testing data for high-risk AI be subject to data governance covering origin, collection processes, preprocessing operations, and bias assessment. The charter’s data strategy section must address these before the project begins — a data problem discovered post-deployment may be irreversible.
- NIST AI RMF MAP 1.1 requires that the intended use of an AI system be well-specified and that the system be analysed for net benefit accounting for both benefits and costs. An AI justification that addresses only benefits and not trade-offs, costs, and alternatives does not meet this standard.
If you have chartered projects before, you know the mechanics: document the purpose, define what success looks like, establish scope, assign accountability, and get the sponsor to sign it. None of that changes for AI projects. What changes is the set of questions the charter must answer before it can be considered complete.
The AI project charter is your first and best opportunity to surface the considerations unique to AI — before the architecture is set, before the data is collected, before sunk costs make an honest assessment politically difficult. The charter exists to surface these questions at the cheapest possible moment.
The Fundamentals Don’t Change
Before covering what’s different, it’s worth being explicit about what isn’t. If you have a charter template that works for you, do not throw it out. Extend it.
Your AI project charter still needs all of the following: business case and objectives; scope (AI projects have a particular tendency toward scope creep into additional use cases — a clear boundary at chartering limits this); stakeholders; authority, including who can order the system taken offline in a production incident; constraints; and assumptions and risks.
What the AI Project Charter Adds
1. AI Justification: Why This Approach for This Problem
Traditional projects do not require justification for the technology choice. AI projects do — and the justification must be substantive, not assumed. NIST AI RMF MAP 1.1 requires analysis of net benefit including discussion of non-AI and non-technology alternatives.
Why AI or ML for this specific problem? What makes this problem suitable for a machine learning approach rather than rules-based logic, expert systems, or human judgment? Is there a clear signal in the training data? Is the performance ceiling of a non-AI approach inadequate?
What trade-offs are being accepted? Every AI system involves trade-offs that do not arise in deterministic software: accuracy versus interpretability, performance versus fairness, speed versus oversight. Implicit trade-offs become hidden assumptions that cause problems later.
What is the cost-benefit including potential harms? NIST MAP 3.1 and 3.2 require analysis of both benefits and costs. A charter that presents only business benefits and does not acknowledge the harm side of the ledger is not a complete analysis.
Many AI projects fail not because the technology fails but because the problem was not suitable for an AI approach, or the trade-offs were never honestly examined. A charter that cannot answer these questions is a signal to slow down before building.
2. Human Oversight: Architecture Decisions Made at the Start
EU AI Act Article 14(1) requires that high-risk AI systems be designed so they can be effectively overseen by natural persons. Article 14(4) specifies five capabilities oversight must enable: understanding system capacities and limitations; remaining aware of automation bias risk; correctly interpreting outputs; deciding to disregard, override, or reverse an output; and halting the system. These are design requirements that cannot be retrofitted after the architecture is set.
Article 26(2) requires deployers to assign oversight to named persons with necessary competence, training, and authority. “Human review will be in place” is not a specification.
| Charter Question | Why It Must Be Answered at Chartering |
|---|---|
| What level of human involvement? (Fully automated, human-in-the-loop, human-on-the-loop, human-in-command) | This determines the system’s architecture. Human-in-the-loop review changes the workflow, timing, and technical interface requirements. Getting to the right answer after the architecture is set is expensive. |
| Who is assigned oversight, with what competence and authority? | EU AI Act Article 26(2) requires oversight assigned to persons with necessary competence, training, and authority. The charter must name the role and confirm the required competence actually exists. |
| What decisions should never be fully automated? | Some decisions — those affecting fundamental rights, liberty, safety, or significant financial consequences — require human judgment as a matter of principle. These must be identified before the system is designed around the assumption of automation. |
| What are the override conditions and mechanisms? | Article 14(4)(d) and (e) require oversight persons be able to override outputs and halt the system. Both require technical mechanisms that must be designed in from the start. |
| How will automation bias be managed? | Article 14(4)(b) requires oversight persons remain aware of the tendency to over-rely on AI outputs. This is a training requirement, an interface design requirement, and a process requirement simultaneously. |
3. Data Strategy: Surface the Data Problems Before Development Starts
Data problems in AI do not manifest as build errors or test failures. They manifest as systematic performance disparities, embedded bias, or post-deployment incidents traceable to decisions made during data collection that were never documented. EU AI Act Article 10(2) requires data governance covering design choices, collection processes and origin, preprocessing operations, assumptions about what the data represents, suitability assessment, bias examination, and identification of data gaps.
The charter’s data strategy section must address: what data trains the system and whether it represents the deployment population; whether the data is appropriate for this use and whether there are consent or licensing limitations; who owns the data and under what terms; what bias examination methodology will be used and who is responsible; and how data lineage will be maintained so a production decision can be traced back to the training data that shaped it.
4. Affected Parties: Extend Beyond the Stakeholder Register
AI projects affect people who may have no involvement with the project team. In a credit scoring deployment, the affected party is the loan applicant, not the loan officer. In a recruitment screening system, it is the candidate, not the hiring manager.
NIST AI RMF MAP 1.2 requires engagement with end users and potentially impacted communities. EU AI Act Article 27 requires a Fundamental Rights Impact Assessment identifying categories of persons likely to be affected. NIST MEASURE 3.3 requires feedback processes for affected communities to report problems and appeal outcomes to be established and integrated into evaluation metrics.
If the team cannot identify affected parties at chartering, the project is not ready to proceed. Affected party identification shapes scope, design, and testing in ways that cannot be retrofitted.
5. Regulatory and Compliance Context
The regulatory section must document: what regulations apply; what the system’s risk classification is and the reasoning supporting it; what compliance activities are required and when; and who owns regulatory monitoring. For high-risk AI systems, each of Articles 9–15, 43, 49, and 72 represents a project deliverable that must appear in scope, schedule, and budget. A high-risk AI project without a compliance plan is not a viable project.
6. Success Criteria: Beyond “Does It Work?”
A system that is accurate but unexplainable, performant but unfair, or technically compliant but unmonitorable is not a successful AI project.
| Success Dimension | What the Charter Should Specify |
|---|---|
| Technical performance | Accuracy, precision, recall, F1, latency, and throughput targets at the use-case level. What performance is required for the system to be operationally viable? |
| Fairness | Performance disaggregated by relevant demographic and contextual subgroups identified in the affected party mapping. |
| Robustness | Performance under edge cases, distribution shift, and adversarial conditions. EU AI Act Article 15 requires resilience to errors, faults, and inconsistencies. |
| Explainability | Can decisions be understood by oversight persons, affected parties, and regulators? The level required should be specified based on the use case and regulatory context. |
| Operational viability | Can the system be monitored, maintained, and updated? What is the process for detecting degradation and taking the system offline if a serious incident occurs? |
7. AI Governance: Who Reviews, Who Approves, Who Escalates
The questions that must be escalated — was this training data appropriate? is this system performing fairly? should this system be suspended? — require judgment combining technical, ethical, legal, and operational expertise. The governance section should specify: which decisions require AI-specific review (go/no-go, training data approval, deployment approval, retraining after drift, suspension after incident); the escalation path for ethical concerns; and what external reviews or conformity assessments are required. EU AI Act Article 43 requires conformity assessment before a high-risk system is placed on the market.
The Charter as a Go/No-Go Gate
The charter is not just documentation. It is a decision. NIST AI RMF MAP 1.5 is explicit: after completing the MAP function, organisations should have sufficient contextual knowledge to inform an initial go/no-go decision.
| Condition | Governance Implication |
|---|---|
| No clear justification for why AI is the right approach | Proceed only if the AI justification can be made complete. Starting an AI project without a defensible answer to “why AI?” is a governance failure. |
| Training data is unavailable, legally constrained, or insufficiently representative | Proceed only if the data problem can be resolved before training begins. EU AI Act Article 10 requirements cannot be met retroactively. |
| Affected parties cannot be identified, or have no mechanism to raise concerns | Proceed only after affected party mapping is complete and a feedback mechanism is designed. |
| Regulatory requirements have not been assessed, or compliance scope exceeds available resources | Proceed only after the regulatory classification is confirmed and compliance activities are scoped, resourced, and scheduled. |
| Human oversight needs are incompatible with operational requirements or business objectives | This is a fundamental conflict that must be resolved before development begins. Either the business case or the project must change. |
| The team cannot articulate measurable success criteria including fairness, robustness, and explainability | Proceed only after success criteria are defined. A project without acceptance criteria for what matters in AI cannot determine whether it has succeeded. |
The cost of a no-go at charter is a planning exercise. The cost of a no-go at deployment, or a governance failure after deployment, is substantially higher.
AI Charter Additions: Quick Reference
| Section | Key Questions to Answer |
|---|---|
| AI Justification | Why AI rather than rules-based or manual alternatives? What trade-offs are being accepted? What is the cost-benefit including potential harms? |
| Human Oversight | What level of human involvement? Who is assigned oversight with what competence and authority? What decisions are never fully automated? What are the override conditions and mechanisms? |
| Data Strategy | What data trains the system? Is it appropriate for this use? Who owns it under what terms? What bias examination is required? How is data lineage maintained? |
| Affected Parties | Who is subject to the system’s outputs (not only who uses the system)? Who might be disproportionately affected? What is the feedback and contestation mechanism? |
| Regulatory Context | What regulations apply? What is the risk classification and supporting rationale? What compliance activities are required, with what schedule and budget? |
| Success Criteria | Technical performance targets; fairness criteria by subgroup; robustness under edge cases; explainability requirements; operational viability and monitoring plan. |
| Governance | Who reviews AI-specific milestone decisions? What is the escalation path for ethical concerns? What external reviews or conformity assessments are required, and when? |
Right-Sizing for Your Situation
How formally you address these additions depends on the risk level of the system, the maturity of your AI governance, and the regulatory context. A low-risk internal tool needs a lighter-weight charter than a high-risk AI system making consequential decisions about individuals. But all AI projects benefit from working through these questions at the start — the value is not the documentation, it is the thinking.
You don’t have formal AI governance yet. Work through the seven AI-specific sections as a structured conversation: Why AI? Who is affected? What does success look like beyond accuracy? Document what you decided and why — even informally. That’s your minimum viable AI charter.
You’re building repeatable processes. Use the full charter template with the EU AI Act regulatory classification framework and NIST AI RMF MAP function mapping. Formalize the go/no-go gate with documented decision criteria. Make the data strategy section a required project input rather than an afterthought.
Align the AI project charter with existing organisational AI policies, ethics review boards, and regulatory approval gates. For high-risk systems, initiate the Fundamental Rights Impact Assessment at chartering and build conformity assessment planning into the project schedule from day one.
The AI Governance Advisor can help you work through each charter section, identify your EU AI Act risk classification, and generate a draft charter aligned to your specific deployment context and methodology.
AIPMO’s AI Project Charter template covers all seven AI-specific sections described in this article — AI justification, human oversight, data strategy, affected parties, regulatory context, success criteria, and governance — alongside the standard project charter elements. It includes a go/no-go checklist mapped to EU AI Act Articles 9, 10, 14, and 27 and NIST AI RMF MAP 1.1, 1.2, 1.5, 3.1, and 3.2. Download free and adapt to your project, or use the AI Governance Advisor to generate a version pre-populated for your system type, risk level, and methodology.
Framework References
EU AI Act (2024) — Article 9 (risk management system throughout the lifecycle); Article 10(2) (data governance requirements for training, validation, and testing data); Article 14 (human oversight requirements and five specific capabilities under 14(4)); Article 26(2) (deployers assign oversight to named persons with necessary competence, training, and authority); Article 27(1) (Fundamental Rights Impact Assessment); Article 43 (conformity assessment before high-risk AI is placed on the market).
NIST AI RMF 1.0 (NIST AI 100-1, 2023) — MAP 1.1 (intended purpose well-specified; net benefit analysis including non-AI alternatives); MAP 1.2 (engagement with diverse team and affected communities); MAP 1.5 (go/no-go decision as explicit MAP outcome); MAP 3.1 and MAP 3.2 (analysis of benefits and costs including potential harms); MEASURE 3.3 (feedback processes for end users and impacted communities integrated into evaluation metrics).
PMI CPMAI Guide (2025) — Phase I (project charter and governance framework as foundation for all subsequent CPMAI phases); Phase II (data strategy alignment to charter data governance commitments).
This article is part of AIPMO’s PM Practice series. See also: AI Risk Classification | The PM’s Guide to NIST AI RMF