PMI-CPMAI Drafting the High-Level AI Solution

A high-level AI solution should be specific enough to support scope, cost, and governance decisions, but not so detailed that the team hard-codes assumptions before the data and evaluation work justify them. PMI-CPMAI usually favors a solution draft that clarifies the major components, data movement, user touchpoints, and control boundaries without pretending the project already knows every technical answer.

The Solution Draft Should Describe The System Shape

At this stage, the project does not need a full technical design. It does need a shared picture of what the solution is likely to include. That usually means:

• the business workflow where the AI output will appear
• the major data inputs
• the kind of model or logic being considered
• the human review or override path
• the operational systems it must interact with
• the main governance boundaries

This helps the team reason about delivery and risk without locking every implementation detail.

Good Solution Drafts Are Concrete, Not Overbuilt

A weak high-level solution is vague. It says the project will “use AI to improve decisions” without identifying what the AI will actually do in the operating process. Another weak solution goes too far the other way and starts prescribing exact technical components before readiness is known.

The stronger answer sits between those extremes. It should clarify the intended function and system shape while leaving room for refinement as the data, evaluation, and risk picture improves.

    flowchart LR
	    A["Business workflow and user decision"] --> B["High-level AI solution concept"]
	    B --> C["Data, system, and governance boundaries"]
	    C --> D["Scope, value, and resource decisions"]

The point of the high-level solution is to support later project decisions, not to prove that detailed design is already complete.

Architecture Choices Already Signal Tradeoffs

Even at a high level, solution choices imply tradeoffs. A batch scoring workflow differs from an interactive assistant. A tightly integrated operational tool differs from a stand-alone analyst support system. A hosted model service differs from a controlled internal deployment. Those choices change:

• latency expectations
• security and privacy exposure
• support burden
• explainability needs
• human oversight design

That is why early solution framing should remain connected to the use case and control environment rather than drifting into generic architecture language.

Governance Boundaries Belong In The Solution Draft

The project should not treat governance as a later overlay. At high level, the solution draft should already clarify:

• where sensitive data is likely to move
• where human approval remains necessary
• what systems or vendors are in scope
• which outputs are advisory versus decision-driving
• where monitoring or audit evidence will likely come from

This does not require final control design, but it does help the project avoid business cases built on impossible assumptions.

Solution Options Should Be Framed For Multiple Audiences

Executives, product leaders, risk stakeholders, and delivery teams all need to understand the solution draft, though not at the same technical depth. The strongest framing usually combines plain-language purpose with a simple structural description. If only engineers can understand the solution concept, governance and investment decisions will be weaker. If only executives can understand it, delivery decisions will be vague.

Example

A bank wants AI assistance for complaints triage. A strong high-level solution might describe the system as: ingest complaint records, classify likely issue type, rank probable urgency, present recommendations to a review team inside the current case tool, log overrides, and monitor post-deployment drift and fairness signals. That is specific enough to support planning without pretending every design detail is settled.

Common Pitfalls

• Writing a solution concept so vaguely that it cannot support scope or cost decisions.
• Turning the solution draft into a detailed design before key evidence exists.
• Ignoring governance or human-review boundaries at the solution-framing stage.
• Framing the solution in language only one stakeholder group can interpret.
• Treating the high-level solution as a marketing summary instead of a project-control artifact.

Check Your Understanding

Sample Exam Question

Scenario: A healthcare organization has validated an AI-assisted intake prioritization use case. The sponsor now wants a business case immediately, but the technical team says it is too early because the detailed architecture is not final.

Question: What is the strongest next planning move?

• A. Create a high-level solution view showing the intended workflow role, major data inputs, output type, human-review path, and key system or governance boundaries so planning can proceed responsibly
• B. Wait until every architecture decision is finalized before drafting any solution description
• C. Skip the solution draft and move directly to value estimation because the use case has already been approved
• D. Ask the model team to select a final algorithm first so the rest of the system can be inferred from that choice

Best answer: A

Explanation: A is best because the project needs a practical high-level solution concept to support scope, cost, and governance decisions, even if detailed design is not yet final. The stronger answer avoids both overdesign and vagueness.

Why the other options are weaker:

• B: Waiting for full design makes early business-case work unnecessarily late.
• C: Value and scope decisions are weaker without a usable solution concept.
• D: Final algorithm choice is not the only or even the first thing that should define the solution.