PMI-CPMAI — PMI Certified Professional in Managing AI Cheat Sheet

This Cheat Sheet is for candidates preparing for the PMI Certified Professional in Managing AI (PMI-CPMAI) exam from PMI, exam code PMI-CPMAI. Use it to connect project management judgment with AI-specific lifecycle, data, model, governance, and operational risks.

Use the tables for a quick pre-exam check. Expand a topic’s notes for explanations, examples, and additional distinctions.

Scope and study context

The exam is best approached as a management-of-AI-initiatives exam, not as a pure data science, coding, or machine learning engineering exam. You should understand the technical vocabulary well enough to make sound project, governance, risk, stakeholder, and delivery decisions.

Item	Detail
Vendor/provider	PMI
Official exam title	PMI Certified Professional in Managing AI (PMI-CPMAI)
Official exam code	PMI-CPMAI
Review focus	Managing AI projects, AI lifecycle, business value, data readiness, governance, risk, responsible AI, deployment, and operational monitoring
Practice approach	Use PM Mastery practice with original practice questions, topic drills, mock exams, and detailed explanations

After this Cheat Sheet, move into original practice questions rather than rereading notes passively. For PMI Certified Professional in Managing AI (PMI-CPMAI) preparation, effective PM Mastery practice should include:

• Topic drills on AI lifecycle, data readiness, responsible AI, MLOps, and generative AI.
• Scenario questions that force tradeoffs between value, risk, governance, and delivery.
• Mock exams to practice pacing and decision-making.
• Detailed explanations that explain why the best answer is best and why distractors are weaker.
• Review of missed questions by concept, not just by answer choice.

Practice Sequence

1. Do a short mixed quiz to identify weak areas.
2. Review the relevant Cheat Sheet section.
3. Complete focused topic drills.
4. Read detailed explanations for every missed or guessed item.
5. Build a short error log of recurring traps.
6. Take a mock exam only after topic weaknesses are improving.
7. Re-drill missed domains until your reasoning is consistent.

AI Project Lifecycle at a Glance

AI initiatives are not managed like ordinary software delivery. The project manager must handle uncertainty in data, model performance, experimentation, governance, stakeholder trust, and production monitoring.

Core PMI-CPMAI Distinctions

AI Use-Case Pattern Reference

PMI-CPMAI candidates should be able to classify AI opportunities and connect the pattern to data, risks, and success metrics.

Role and Responsibility Matrix

Business Case and Use-Case Selection

High-Yield Evaluation Criteria

Notes and examples

Practical Prioritization Formula

Use scoring to compare candidate AI use cases. The exam may not require a specific formula, but it often rewards risk-aware prioritization.

\[ \text{Priority Score} = \frac{\text{Business Value} + \text{Strategic Alignment} + \text{Learning Value}} {\text{Complexity} + \text{Data Risk} + \text{Operational Risk}} \]

Interpretation: higher value and learning increase priority; high complexity and risk reduce priority unless justified by strategic importance.

AI Use Case Selection

A strong AI use case has:

• A clear business problem or opportunity.
• A measurable success criterion.
• Available and usable data.
• Stakeholder ownership.
• A realistic path to deployment.
• Acceptable risk and governance controls.
• A feedback loop for improvement.

Use Case Screening Table

Question	Why It Matters
What decision, workflow, or outcome will improve?	Prevents vague “AI transformation” goals
Who will use or be affected by the AI system?	Identifies adoption, training, fairness, and human oversight needs
What data is required and who owns it?	Surfaces access, quality, privacy, and governance constraints
What happens if the AI is wrong?	Determines risk level, controls, and human review requirements
How will performance be measured?	Connects technical metrics to business value
Can the solution be integrated into operations?	Avoids successful prototypes that never create value

Data Management Cheat Sheet

Notes and examples

Data Split Decision Table

Scenario	Prefer	Why
Randomly distributed independent records	Random train/validation/test split	Simple and usually sufficient
Time-series or forecasting	Time-based split	Prevents future data from leaking into training
Rare positive cases	Stratified split	Preserves class balance in each set
Same customer/patient/device appears multiple times	Grouped split	Prevents the same entity from appearing in both train and test
Small dataset	Cross-validation, with caution	Improves estimate stability but does not solve poor data quality
Production data differs from historical data	Back-testing and pilot monitoring	Tests real-world stability

Data Readiness Review

AI outcomes depend heavily on data. If a scenario has unclear data ownership, poor quality, incomplete labels, privacy restrictions, or biased samples, those issues must be addressed before relying on model results.

Data Quality Dimensions

Dimension	Review Point
Accuracy	Does the data correctly represent reality?
Completeness	Are required fields and records present?
Consistency	Are formats, definitions, and values aligned across sources?
Timeliness	Is the data current enough for the use case?
Representativeness	Does it reflect the population or operating environment?
Lineage	Can the source, transformation, and use of data be traced?
Label quality	Are labels correct, consistent, and relevant?
Accessibility	Can the team lawfully and practically access the data?
Privacy	Is sensitive data protected and used appropriately?

Common Data Traps

• Training data does not represent future production conditions.
• Historical data contains past bias.
• Labels are inconsistent across teams or regions.
• Sensitive information is used without proper controls.
• Data is available for prototyping but not for production.
• Data definitions differ between business units.
• Duplicate records inflate model performance.
• Data leakage makes evaluation look better than real-world performance.

Data Leakage

Data leakage occurs when information unavailable at prediction time is used during training or evaluation. It produces misleadingly high performance.

Leakage Example	Why It Is a Problem
Including a field that is created after the target event	The model learns future information
Randomly splitting time-series data	Future patterns may leak into training
Duplicate customers in both train and test sets	Test performance is inflated
Preprocessing before splitting data	Test data influences training transformations
Using target-derived features	The answer is indirectly encoded

Decision rule: if the model would not have access to the information at the time of real-world prediction, it should not be used as a feature.

Model Approach Selection

Notes and examples

Build, Buy, or Adapt Decision

Option	Choose when	Advantages	Risks
Build custom model	Need differentiated capability, control, special data, or integration	Tailored performance and ownership	Higher cost, skills, support burden
Buy vendor AI solution	Common use case, faster time to value, vendor support acceptable	Speed, packaged features	Lock-in, opaque model, data sharing risk
Adapt/fine-tune foundation model	Need language or multimodal capability with domain adaptation	Strong baseline, faster than building from scratch	Evaluation, hallucination, privacy, model updates
Use API/prompting only	Low customization, rapid experimentation, moderate risk	Fastest start	Less control, variable behavior
Do not use AI	Rules or reporting solve the problem adequately	Lower risk and complexity	May not capture complex patterns

Evaluation Metrics Reference

Classification Metrics

Notes and examples

Regression, Forecasting, and Ranking Metrics

Metric	Use when	Lower or higher is better	Trap
MAE	Average absolute error is understandable	Lower	Treats all errors linearly
RMSE	Larger errors should be penalized more	Lower	Sensitive to outliers
MAPE	Percentage error is meaningful	Lower	Fails or distorts near zero values
R-squared	Explaining variance in target	Higher	Does not prove business usefulness
Lift / gain	Ranking improves targeting vs baseline	Higher	Needs baseline comparison
Business KPI	Model affects revenue, cost, cycle time, risk, service	Depends	Must be measured after deployment

Generative AI Evaluation

Evaluation area	Ask	Example evidence
Factuality	Are outputs correct and grounded?	Human review, retrieval grounding tests, citation checks
Relevance	Does output answer the user’s task?	Rubric scoring, task completion
Safety	Does it avoid harmful, prohibited, or sensitive output?	Red-team tests, policy checks
Hallucination	Does it invent unsupported facts?	Grounded evaluation, refusal tests
Toxicity and bias	Are outputs discriminatory or harmful?	Bias test suites, reviewer audits
Robustness	Does it resist prompt injection and adversarial inputs?	Attack simulations, guardrail tests
Consistency	Are similar prompts handled consistently?	Regression test set
Cost and latency	Can it meet operational constraints?	Token cost, response time, throughput tests

Classification Metrics

Metric	Plain-Language Meaning	Best Used When
Accuracy	Share of total predictions that are correct	Classes are balanced and errors have similar cost
Precision	Of predicted positives, how many were truly positive	False positives are costly
Recall / sensitivity	Of actual positives, how many were found	False negatives are costly
Specificity	Of actual negatives, how many were correctly rejected	Correctly excluding negatives matters
F1 score	Balance of precision and recall	Need one metric for uneven classes
ROC-AUC	Ability to rank positives above negatives	Comparing classifiers across thresholds
Confusion matrix	Counts true positives, false positives, true negatives, false negatives	Understanding error types

Regression Metrics

Metric	Plain-Language Meaning	Watch For
MAE	Average absolute error	Easier to explain to stakeholders
MSE	Average squared error	Penalizes large errors heavily
RMSE	Square root of MSE	Same unit as target; sensitive to outliers
MAPE	Percentage error	Can fail when actual values are near zero

Generative AI Evaluation

Generative AI evaluation often requires multiple measures because outputs can be fluent but wrong.

Evaluation Area	What to Check
Factuality	Is the answer true?
Groundedness	Is the answer supported by approved sources?
Relevance	Does it answer the actual user request?
Completeness	Does it include required information?
Safety	Does it avoid harmful, toxic, or prohibited content?
Privacy	Does it avoid exposing sensitive data?
Consistency	Does it produce reliable results across similar prompts?
Human review	Are high-risk outputs reviewed by qualified people?

Generative AI Management Review

Generative AI introduces specific risks because outputs may be plausible, variable, and difficult to verify.

Generative AI Decision Table

Need	Likely Approach	Watch For
General drafting or brainstorming	Prompting a foundation model	Review and accuracy controls
Answering from internal documents	Retrieval-augmented generation	Source quality, grounding, permissions
Domain-specific style or task adaptation	Fine-tuning or prompt engineering	Data quality, overfitting, cost
High-risk factual responses	RAG plus human review	Hallucination, outdated sources
Structured extraction	Model plus validation rules	Inconsistent outputs
Customer-facing chatbot	Guardrails, escalation, monitoring	Safety, privacy, brand risk

Generative AI Risks

Risk	Mitigation
Hallucination	Grounding, retrieval, citations, human review
Prompt injection	Input filtering, tool restrictions, security testing
Sensitive data exposure	Data loss prevention, access control, redaction
Copyright / IP concern	Approved content sources, legal review
Toxic or unsafe output	Safety filters, evaluation, escalation
Overreliance	User training, confidence limits, review workflows
Inconsistent output	Templates, structured prompts, deterministic settings where possible
Unauthorized action	Tool permissions, approval gates, audit logs

RAG vs. Fine-Tuning

Approach	Use When	Not Best For
RAG	Need answers grounded in current or proprietary documents	Teaching the model broad new behavior by itself
Fine-tuning	Need model behavior, tone, format, or task adaptation	Keeping rapidly changing knowledge current
Prompt engineering	Need low-cost, flexible task guidance	Complex governance or high-risk reliability needs alone
Rules / workflow automation	Need deterministic behavior	Open-ended language understanding or generation

Risk, Governance, and Responsible AI Controls

Risk exposure is often summarized as:

\[ \text{Risk Exposure} = \text{Probability} \times \text{Impact} \]

For AI projects, include both project delivery risk and model behavior risk.

Governance Artifacts to Recognize

Notes and examples

AI Governance Artifacts

You may see scenario questions where the best answer is to add governance, documentation, or monitoring rather than to tune the model again.

Artifact	Purpose
AI use case inventory	Tracks where AI is being used
Risk assessment	Identifies severity, likelihood, controls, and owners
Data sheet / data documentation	Describes data source, quality, limits, and permitted uses
Model card	Summarizes model purpose, performance, limitations, and intended use
Evaluation report	Records test design, results, assumptions, and acceptance criteria
Human oversight plan	Defines review, override, escalation, and accountability
Monitoring plan	Defines metrics, thresholds, alerts, drift checks, and retraining triggers
Incident response plan	Defines response to harmful, incorrect, or unexpected AI behavior
Change log	Tracks model, data, prompt, feature, and configuration changes

Project Management Decision Tables

What Should the Manager Do Next?

Notes and examples

Predictive, Agile, or Hybrid Delivery

Delivery approach	Best fit	AI-specific tailoring
Predictive	Stable compliance, procurement, infrastructure, or deployment constraints	Still allow experimentation within planned stages
Agile	Uncertain model approach, evolving requirements, iterative discovery	Use spikes, experiments, model backlog, frequent stakeholder review
Hybrid	Most AI initiatives: governed phases plus iterative modeling	Stage gates for data/model/governance; agile iterations inside phases
Kanban/flow	Operational model monitoring, incident handling, labeling queues	Manage WIP, service levels, and continuous improvement
Experimental POC	Feasibility unknown	Timebox, define learning goals, avoid production promises

Change Control in AI Projects

MLOps and Operationalization Workflow

    flowchart LR
	    A[Business objective] --> B[Data access and profiling]
	    B --> C[Data preparation and feature pipeline]
	    C --> D[Model training and experiments]
	    D --> E[Validation and risk review]
	    E --> F{Go / no-go}
	    F -- No --> B
	    F -- Yes --> G[Deploy to pilot or production]
	    G --> H[Monitor performance, drift, cost, safety]
	    H --> I{Trigger?}
	    I -- Drift or incident --> J[Rollback, retrain, or remediate]
	    J --> E
	    I -- Stable --> H

Notes and examples

Production Readiness Checklist

Area	Must be true before go-live
Ownership	Sponsor, product owner, model owner, support owner identified
Data	Source permissions, quality checks, lineage, and versioning established
Model	Performance, limitations, bias, explainability, and thresholds documented
Integration	Interfaces, latency, reliability, and fallback paths tested
Security	Access controls, endpoint protection, secrets management, and testing complete
Monitoring	Metrics, alerts, drift checks, cost tracking, and review cadence defined
Human process	Review, override, escalation, and feedback loops designed
Change control	Retraining, model updates, and rollback procedures defined
Auditability	Decisions, versions, approvals, and evidence retained as required by the organization
Adoption	Training, communications, and user readiness completed

Thresholds, Tradeoffs, and Human-in-the-Loop

Quality and Acceptance Criteria

AI Quality Dimensions

Notes and examples

Definition of Done for AI Work

Work item	Done means…
Data source onboarded	Approved, documented, profiled, secured, and accessible
Labeling completed	Guide followed, quality checked, conflicts resolved
Model candidate trained	Reproducible run with dataset/model version and metrics
Model selected	Compared to baseline and alternatives; tradeoffs documented
Risk review completed	Material risks assessed, mitigations accepted or required
Pilot completed	Real users/workflow tested; feedback and metrics reviewed
Production release completed	Monitoring, support, rollback, and ownership active

Common Exam Traps

Rapid Review Checklist

Before the exam, be able to answer these quickly:

• What business decision or process does the AI system improve?
• Which AI pattern fits the use case?
• What data is needed, who owns it, and is it fit for purpose?
• What could make the model unfair, unsafe, insecure, or noncompliant?
• Which metric matches the business cost of errors?
• What is the baseline, and how does the model improve on it?
• How will stakeholders validate, accept, and adopt the solution?
• What governance artifacts are needed before deployment?
• Who owns the model after project closure?
• How will production performance, drift, incidents, and retraining be managed?

Notes and examples

Final Pre-Practice Checklist

Before starting a mock exam, make sure you can quickly answer:

• When is AI appropriate, and when is a simpler solution better?
• What makes data ready or not ready for AI?
• How do you connect model metrics to business outcomes?
• What are the main risks of deploying AI into production?
• How do fairness, explainability, privacy, and accountability affect project decisions?
• What is the difference between a prototype and an operational AI system?
• How should generative AI be evaluated and controlled?
• What does monitoring need to detect after deployment?
• Who must be involved in AI governance and delivery?

Core Mental Model for the Exam

AI projects are not just software projects with a model added. The key difference is that project outcomes depend on data quality, model behavior, uncertainty, continuous evaluation, and responsible use.

A practical AI initiative usually moves through this logic:

    flowchart LR
	    A[Business problem] --> B[Use case and value hypothesis]
	    B --> C[Data availability and readiness]
	    C --> D[Model or AI solution approach]
	    D --> E[Evaluation against success criteria]
	    E --> F[Deployment and integration]
	    F --> G[Monitoring, governance, and improvement]
	    G --> C

High-yield exam principle:

A good AI manager does not start with the algorithm. A good AI manager starts with the business problem, validates that AI is appropriate, confirms data readiness, manages uncertainty, governs risk, and measures value after deployment.

High-Yield Review Map

AI Project Management: The Big Differences

Traditional Software vs. AI Initiatives

Key Decision Rule

If the problem can be solved with simple rules, workflow automation, or conventional analytics, do not assume AI is the best answer. AI is most appropriate when the task involves prediction, classification, pattern detection, natural language, perception, recommendation, or generation and when sufficient data and governance are available.

Notes and examples

Common Scenario Decision Rules

If the Scenario Says…	Prefer This Type of Answer
“The model performs well in testing but poorly in production”	Investigate drift, data mismatch, monitoring, and deployment conditions
“Stakeholders disagree about success”	Clarify business objectives and acceptance criteria
“Data quality is unknown”	Conduct data assessment before full development
“The AI output may affect people significantly”	Add risk review, human oversight, explainability, and appeal path
“A vendor model is high-performing but opaque”	Evaluate explainability, risk, contractual rights, and monitoring
“A team wants to automate immediately”	Confirm risk level, human review needs, and operational readiness
“A prototype works in a lab”	Validate production data, integration, scalability, and support
“Accuracy is high but minority group errors are high”	Investigate fairness and subgroup performance
“Generative AI gives confident wrong answers”	Add grounding, evaluation, guardrails, and human review
“Model performance is declining”	Check data drift, concept drift, upstream changes, and retraining criteria

Business Value and Success Metrics

AI projects should link technical performance to business value. The exam may present scenarios where a technically impressive model is not the best project choice.

Common Value Measures

Notes and examples

Candidate Trap

Do not select a model metric without understanding business consequences. A medical screening, fraud detection, or safety use case may require high recall even if precision falls. A customer-facing recommendation system may care about conversion, relevance, and user trust more than raw model accuracy.

Common Candidate Mistakes

1. Starting with the technology instead of the business problem. The exam often rewards defining value, feasibility, and governance before selecting a tool.

2. Confusing prototype success with production readiness. A proof of concept does not prove operational scalability, monitoring, security, or adoption.

3. Choosing accuracy as the default metric. Match metrics to the cost of errors and business objective.

4. Ignoring data governance. Data access, privacy, lineage, and quality are core AI management issues.

5. Treating bias as only a technical issue. Bias can originate in history, process, measurement, labels, sampling, and deployment.

6. Assuming more data always improves the model. More low-quality, biased, irrelevant, or unauthorized data can make the system worse.

7. Assuming a complex model is best. Simpler models may be more explainable, cheaper, safer, and easier to govern.

8. Forgetting monitoring after deployment. AI performance can degrade without code changes.

9. Overlooking human adoption. AI initiatives fail when users do not trust, understand, or integrate the system into work.

10. Confusing generative fluency with correctness. Generative AI can sound authoritative while being inaccurate or unsupported.

AI, Machine Learning, and Generative AI Basics

Core Terms

Notes and examples

Algorithm-Level Awareness

You generally need to recognize which technique fits which problem.

Problem Type	Typical Approach
Predict a number	Regression
Predict a category	Classification
Group similar records	Clustering
Detect unusual behavior	Anomaly detection
Recommend items	Recommendation systems
Extract meaning from text	Natural language processing
Identify objects in images	Computer vision
Generate text or summaries	Generative AI / LLM
Optimize sequential decisions	Reinforcement learning

Overfitting, Underfitting, and Generalization

Candidate trap: the best model is not automatically the most complex model. Simpler, explainable, stable, and governable models may be preferable, especially in regulated, safety-critical, or stakeholder-sensitive contexts.

Bias, Fairness, and Responsible AI

Responsible AI should be built into the lifecycle, not added at the end.

Responsible AI Principles

Notes and examples

Bias Sources

Source	Example
Historical bias	Past decisions reflect unfair treatment
Sampling bias	Training data excludes certain groups
Measurement bias	Variables measure outcomes differently across populations
Label bias	Labels reflect subjective or inconsistent judgments
Deployment bias	Users apply the AI system differently than intended
Feedback-loop bias	Model outputs influence future data in a self-reinforcing way

Fairness Trap

Removing protected attributes from data does not automatically remove bias. Proxy variables such as location, income, education, language, or device type may still encode sensitive patterns.

AI Risk Management

AI risk depends on both likelihood and impact. High-risk use cases need stronger controls, documentation, testing, monitoring, and escalation.

Risk Review Table

Notes and examples

Risk-Based Decision Rule

The higher the impact of a wrong AI output, the more the project needs:

• Human review.
• Explainability.
• Traceability.
• Testing across edge cases.
• Monitoring after deployment.
• Formal approval and escalation paths.
• Clear accountability.

AI Lifecycle Review

A practical AI lifecycle includes both management and technical work.

Project Roles and Stakeholders

AI initiatives are cross-functional. A common exam trap is choosing a technically correct answer that ignores stakeholder ownership, governance, or operational adoption.

Scope, Schedule, and Estimation in AI Projects

AI project estimates are uncertain because feasibility depends on data and model performance. Manage this with discovery, proof of concept, staged decisions, and explicit assumptions.

Good Practices

• Separate discovery from full-scale delivery.
• Use timeboxed experiments.
• Define minimum acceptable model and business performance.
• Keep a baseline comparison.
• Document assumptions about data, access, quality, and integration.
• Use go/no-go checkpoints.
• Avoid promising exact model performance before data assessment.

Poor Practices

• Committing to production dates before data is accessible.
• Treating proof of concept success as production readiness.
• Ignoring model monitoring work in the schedule.
• Excluding legal, security, data owners, or operations until late.
• Defining “done” as model training rather than operational value.

Agile, Iterative, and Stage-Gate Thinking

AI work benefits from iteration, but not uncontrolled experimentation. Strong AI management combines learning cycles with governance checkpoints.

MLOps and Operational Monitoring

MLOps is the discipline of reliably deploying, monitoring, updating, and governing models in production.

MLOps Capabilities

Notes and examples

Drift Types

Drift Type	Meaning
Data drift	Input data distribution changes
Concept drift	Relationship between inputs and target changes
Prediction drift	Output distribution changes
Performance drift	Business or model metrics degrade

Candidate trap: retraining is not always the first answer. First determine whether the issue is data quality, upstream system change, user behavior change, model drift, integration failure, or metric definition change.

Deployment and Change Management

A model that works in a notebook may fail in operations. Deployment planning should address workflow, people, systems, risk, and support.

Deployment Checklist

• Integration with existing systems.
• User training and communication.
• Defined human review steps.
• Access controls and security testing.
• Monitoring dashboard and alert thresholds.
• Rollback or fallback process.
• Support ownership.
• Incident escalation.
• Documentation for users and operators.
• Post-deployment review.

Adoption Trap

Users may reject an AI system if they do not trust it, understand it, or see how it improves their work. Change management is part of AI delivery, not an optional extra.

Build vs. Buy vs. Partner

AI solutions may be built internally, purchased from vendors, or delivered through partners. The best option depends on strategic value, data sensitivity, expertise, time, cost, control, and risk.

Vendor Evaluation Questions

• What data is sent to the vendor?
• Who owns inputs, outputs, derived data, and model improvements?
• Can the vendor explain model limitations?
• How is performance validated?
• What security and privacy controls exist?
• Are logs retained, and who can access them?
• What happens if the vendor changes the model?
• Is there an exit or migration plan?
• Can the organization audit or review relevant controls?

Security Review for AI Projects

AI systems introduce conventional cybersecurity issues plus AI-specific threats.

Candidate trap: security is not only an IT issue after deployment. It should be considered during data acquisition, model design, vendor selection, testing, deployment, and monitoring.

Explainability and Transparency

Explainability needs depend on the use case. A low-risk recommendation may need less explanation than a model used for credit, employment, healthcare, safety, or disciplinary decisions.

Decision rule: when decisions significantly affect people, increase explainability, documentation, review, appeal, and accountability.

Human-in-the-Loop Design

Human involvement should be purposeful. It is not enough to say “a human is involved” if the human lacks time, expertise, authority, or information to intervene.

Human Oversight Trap

A human review step can become ineffective if reviewers rubber-stamp outputs due to automation bias, time pressure, poor explanations, or unclear accountability.

Rapid Review Tables

AI Project “Go / No-Go” Signals

Notes and examples

Technical vs. Management Response

Problem	Technical Response	Management Response
Poor model performance	Improve features, data, model, tuning	Revisit feasibility, timeline, success criteria
Biased outcomes	Test subgroups, adjust data/model	Define fairness goals, governance, review process
Hallucinations	RAG, prompts, evaluation	Limit use case, add human review, communicate risks
Drift	Monitor, retrain, recalibrate	Define thresholds, ownership, incident process
Poor adoption	Improve UX, workflow integration	Change management, training, stakeholder alignment
Vendor opacity	Model documentation request	Risk assessment, contract terms, exit plan

Put the review into practice