The new PMI AI standard, chapter by chapter
PMI released its first AI standard, ANSI-approved. Here it is chapter by chapter in plain English, and the one part that needs a product. A PMI standard is not theory; it is tailorable checklists built by practitioners. The rule: never do all of it, keep what fits your project.
By Konstantin Trunin, founder and CEO of Swiftward, a PMP who contributed to international PMI standards as a global expert, and who now builds AI infrastructure.
What is in each chapter
First decide how AI shows up in your project: as a tool (it runs the project: schedules, status, risk forecasts) or as a deliverable (AI is the product you ship, with its own life cycle). Takeaway: keep a human in the loop on consequential decisions.
Eight questions to ask before you touch AI: strategic value, risk, governance and compliance, people and culture, ethics, stakeholder engagement, optimization, and data quality. The governance one is blunt: who owns the decision, and can you prove it was compliant?
The five domains of actual work: managing stakeholder expectations, defining the AI scope, designing for quality and reliability, executing strategic goals, and managing AI risks and uncertainties. Each domain ends with a "checking results" step.
AI has phases your project plan is missing: data collection, model development, deployment, monitoring, optimization, and decommissioning. Pick a mode first (predictive, adaptive, hybrid), then tailor the phases into your own life cycle.
What AI changes at three altitudes: portfolio (which use cases first), program (benefits, risk, change across projects), and project (estimates, schedules, automatic status, early risk flags). It also pins who owns what, from data scientist to sponsor to PM.
How to pick and justify an AI tool: a business case, six selection criteria (alignment, integration, scalability, usability, cost-benefit, managing system data), and risk tracked with real KPIs (risks identified, percent mitigated, speed of recovery).
The part most teams underestimate: 14 ethics considerations and 9 legal ones, from bias and explainability to accountability, audits, and IP. The question that decides a dispute: can you prove what your AI did?
Two kinds of work run through it
Read end to end, the standard asks for two distinct things. Organizational work (principles, scope, stakeholders, life cycle) is people and process, the manager's job. Technical work (prove and control what the AI does) surfaces in the governance principle, the risk domains, and the legal chapter: version every policy, log every decision, keep an audit trail, answer a disputed decision from the record, prove compliance. The catch: you cannot close the technical side in a meeting. It needs a product.
What the standard asks of the technical layer, and how Swiftward answers
| The standard asks | Swiftward does |
|---|---|
| Keep a human in the loop | Built-in human review queue |
| Version every policy | Versioning (draft, candidate, frozen, archived) + rollback by naming the previous version |
| Log every decision | Append-only audit trail + the decision record |
| Answer a disputed decision | The record, plus a backtest against the version that was live |
| Prove the decision | The record names the rule that decided and the frozen version it ran on |
| Continuous compliance testing | Shadow mode on live traffic + A/B |
All of it on an enterprise foundation you run yourself: on-prem, RBAC/ABAC/SSO, multi-tenancy, secrets, SIEM forwarding, and gateways for LLM, MCP, network, FIX, SCM, and blockchain.
The honest question
The technical side is where most teams have a gap. The standard now names it. How are you closing it? Read the full standard, then bring us the decisions you need to control.