- 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.
- 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 system 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 systems be subject to data governance practices 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 require taking the system offline.
- NIST AI RMF MAP 1.1 requires that the intended use of an AI system be well-specified and finite, and that the system be analysed for whether it provides 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 the standard the MAP function sets.
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 that are unique to AI — before the architecture is set, before the data is collected, before a team is ramped and sunk costs make an honest assessment politically difficult. The charter is the place to answer questions that would never appear on a conventional software project: Why AI rather than a simpler approach? What decisions will this system make, and which should never be fully automated? Who might be harmed if the system is wrong? What data is this project permitted to use?
These are not compliance exercises. They are the questions that, left unanswered at chartering, will surface as expensive problems during development or as governance failures after deployment. The charter exists to surface them 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, addressed with the same rigour as any project: business case and objectives; scope and boundaries; stakeholders; authority (including who can order the system taken offline); constraints; and assumptions and risks. Standard charter elements apply unchanged.
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. NIST AI RMF MAP 1.1 requires that the intended purpose be well-specified, and that the system be analysed for whether it provides net benefit accounting for both benefits and potential costs. Three questions must be answered:
- Why AI or ML for this specific problem? What makes this suitable for machine learning 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 human oversight. These must be explicit in the charter — 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. The charter should include a realistic assessment of what happens when the system is wrong, who bears the cost of errors, and whether the benefit of automation justifies the harm profile.
Many AI projects fail not because the technology fails but because the problem was not suitable for an AI approach, or because the trade-offs were never honestly examined. A charter that cannot answer these questions clearly is a signal to slow down before building.
2. Human Oversight: Architecture Decisions Made at the Start
EU AI Act Article 14(4) specifies five capabilities that human oversight must enable: understanding the system’s capacities and limitations; awareness of automation bias; correctly interpreting outputs; deciding to override or reverse an output; and halting the system. These are design requirements. They cannot be retrofitted after the architecture is set. Article 26(2) requires that oversight be assigned to named natural persons with necessary competence, training, and authority. The charter must answer:
| 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. Getting to the right answer after architecture is set is expensive. |
| Who is assigned oversight, and 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 it exists in the organisation. |
| What decisions should never be fully automated, regardless of system confidence? | Decisions 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 automation. |
| What are the override conditions and mechanisms? | Article 14(4)(d) and (e) require that oversight persons can override outputs and halt the system. Both require technical mechanisms designed in from the start. |
| How will automation bias be managed? | Article 14(4)(b) requires awareness of the tendency to over-rely on AI outputs. This is a training, interface design, and process requirement the charter must address. |
3. Data Strategy: Surface the Data Problems Before Development Starts
EU AI Act Article 10(2) requires governance practices covering: design choices underlying data selection; collection processes and origin; preprocessing operations; assumptions about what the data represents; availability and suitability assessment; examination for biases; and identification of data gaps. The charter’s data strategy section must address:
- What data will train the system? Source, volume, the time period it covers, and the population it represents. Is the data representative of the deployment population?
- Is this data appropriate for this use? Data collected for one purpose may not be suitable for training an AI system serving a different purpose — because of consent limitations, or because it does not represent the deployment context.
- Who owns the data, and under what terms? Licensing, IP, and privacy rights must be established before training begins, not discovered during a compliance review after the model is trained.
- What bias examination has been done or is planned? Article 10(2)(f) requires examination for biases likely to affect health, safety, or fundamental rights. The charter should document the methodology and ownership.
- How will data lineage be maintained? Without lineage tracking established from the start, tracing a production decision back to the training data that shaped it becomes structurally impossible to reconstruct later.
4. Affected Parties: Extend Beyond the Stakeholder Register
NIST AI RMF MAP 1.2 requires engagement with people external to the team, including end users and potentially impacted communities. EU AI Act Article 27 requires a Fundamental Rights Impact Assessment prior to deployment. The charter should address: who is subject to the system’s decisions (often not the system’s users but the people decisions are made about); who might be disproportionately affected; and what the feedback and contestation mechanism is. NIST MEASURE 3.3 requires that these feedback processes be established and integrated into AI system evaluation metrics.
5. Regulatory and Compliance Context
What regulations apply? What is the system’s risk classification? What compliance activities are required and when? Who owns regulatory monitoring? The answer “we will check this later” is not acceptable — regulatory applicability must be determined before scope, budget, and timeline are established, because compliance activities have cost and schedule implications.
For high-risk AI under the EU AI Act, compliance activities include: risk management system (Article 9); data governance (Article 10); technical documentation (Article 11); record-keeping (Article 12); transparency (Article 13); human oversight (Article 14); accuracy and robustness (Article 15); conformity assessment (Article 43); registration (Article 49); and post-market monitoring (Article 72). Each is a project deliverable that must appear in scope, schedule, and budget.
6. Success Criteria: Beyond “Does It Work?”
AI projects require a broader definition of success. The charter should define acceptance criteria across all the following dimensions:
| Success Dimension | What the Charter Should Specify |
|---|---|
| Technical performance | Accuracy, precision, recall, F1 score, latency, and throughput targets specified 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. A system that achieves aggregate accuracy targets but performs significantly worse for a specific population is not meeting its fairness criteria. |
| Robustness | Performance under edge cases, distribution shift, and adversarial conditions. EU AI Act Article 15 requires high-risk AI systems be resilient to errors, faults, and inconsistencies. |
| Explainability | Can decisions be understood by those who need to understand them? The level required should be specified based on the use case and regulatory context. |
| Operational viability | Can the system be monitored, maintained, and updated? Is there a plan for detecting performance degradation in production? What is the process for taking the system offline if a serious incident occurs? |
7. AI Governance: Who Reviews, Who Approves, Who Escalates
The governance section should specify: who reviews AI-specific milestone decisions (go/no-go, training data approval, deployment approval, retraining decisions, suspension); what the escalation path is for ethical concerns; and what external reviews or conformity assessments are required under EU AI Act Article 43.
The Charter as a Go/No-Go Gate
The charter is not just documentation. It is a decision. NIST AI RMF is explicit: after completing the MAP function, organisations should have sufficient contextual knowledge to inform an initial go/no-go decision. The following conditions warrant stopping or fundamentally revising before proceeding:
| Condition | Governance Implication |
|---|---|
| No clear justification for why AI is the right approach, or the justification does not account for trade-offs and alternatives | Proceed only if the AI justification can be made complete. Starting without a defensible answer to “why AI?” is a governance failure. |
| Training data is unavailable, legally constrained, or insufficiently representative for the intended deployment population | 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 known affected parties 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 the 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 fundamental conflict must be resolved before development begins. If the business case requires automation that the regulatory framework prohibits, either the business case or the project must change. |
| The team cannot articulate measurable success criteria that include fairness, robustness, and explainability | Proceed only after success criteria are defined across all relevant dimensions. |
Better to discover these during chartering than during development. The cost of a no-go at charter is a planning exercise. The cost of 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 organisation’s AI governance, and the regulatory context. But all AI projects benefit from working through these questions at the start.
For PMs without formal AI governance. A one-page charter extension covering the seven AI-specific sections at the level of detail appropriate for lower-risk systems. A simplified go/no-go checklist. Designed to add governance without adding bureaucracy.
For PMs building repeatable processes. A full charter template with guidance on each AI-specific section, including the EU AI Act regulatory classification framework and NIST AI RMF MAP function mapping. Includes a structured go/no-go gate with documented decision criteria and a data strategy section aligned to Article 10 requirements.
For PMs in organisations with formal AI governance. How to align the AI project charter with existing organisational AI policies, ethics review boards, and regulatory approval gates. Covers conformity assessment planning for high-risk AI systems, Fundamental Rights Impact Assessment initiation at chartering, and integration with enterprise risk management frameworks.
The AI Governance Advisor can help you work through each section of your AI project charter, including risk classification, human oversight design, and regulatory compliance planning.
AIPMO’s AI Project Charter template covers each AI-specific section described in this article — including the EU AI Act regulatory classification framework, NIST AI RMF MAP function mapping, a structured go/no-go gate with documented decision criteria, and a data strategy section aligned to Article 10 requirements. Download free and adapt to your project, or use the AI Governance Advisor to generate a version pre-populated for your system type, methodology, and risk level.
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: five specific capabilities required under Article 14(4)); Article 26(2) (deployers shall assign human oversight to natural persons with necessary competence, training, and authority); Article 27(1) (Fundamental Rights Impact Assessment prior to deployment); Article 43 (conformity assessment before high-risk AI system is placed on the market).
NIST AI RMF 1.0 (NIST AI 100-1, 2023) — MAP 1.1 (intended purpose well-specified and finite; net benefit analysis accounting for both benefits and costs; consideration of non-AI and non-technology alternatives); MAP 1.2 (engagement with diverse internal team and external collaborators including end users and potentially impacted communities); MAP 1.5 (go/no-go decision as explicit outcome of the MAP function); 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 to report problems and appeal system outcomes).
This article is part of AIPMO’s PM Practice series. See also: AI Risk Classification | The PM’s Guide to NIST AI RMF | The AI Project Charter for Agile Teams
To err is AI; to govern, human.