Framework · Version 1.0
The Practical AI Adoption Framework
What the framework is
The Practical AI Adoption Framework moves a single workflow from observation to a measured result in five ordered stages: observe and map, prioritize, integrate and deploy, train and govern, measure and improve. Each stage has an exit criterion that must hold before the next begins. Its purpose is to stop capable pilots from stalling before they become operations.
58-word direct answer
Key takeaways
- The unit of work is one workflow, not an organization-wide program.
- The exit criteria are the framework. Without them it is just a list of verbs.
- The baseline is captured in stage two, before anything changes. It cannot be reconstructed later.
- A deliberate retirement at stage five is a success. An abandoned pilot is not.
The problem it solves
Organizations run an AI pilot, it works, and nothing changes. Six months later the capability is in occasional use by the person who championed it and absent from the operation. This is the most common outcome of AI enthusiasm, and it is not caused by the technology.
It is caused by stage confusion. A pilot answers “can this capability do the task?” Implementation answers “can this organization operate, oversee, measure, and maintain it?” Teams answer the first question, treat it as evidence for the second, and skip the work the second actually requires.
The framework exists to make that skipping visible. Each stage has a condition that either holds or does not. If it does not, moving on is a decision being made rather than a step being missed.
The five stages and their exit criteria
The Practical AI Adoption Framework v1.0. Five stages in order, each with the condition that must hold before the next begins. The dashed return path shows the two legitimate endings: extend the pattern to an adjacent workflow, or retire the workflow deliberately. Original diagram; reuse with attribution to martinzialcita.com.
Definitions
Terms the framework depends on, defined as used here.
- Workflow
- A repeating sequence of steps with a trigger and a completion condition, performed by identifiable people, at a countable frequency. Not a capability, a tool, or an ambition.
- Baseline
- A measurement of the workflow taken before anything changes: cycle time, volume, error or rework rate, or cost per unit. It cannot be captured retrospectively, which is why it sits in stage two.
- Exit criterion
- An observable condition that must hold before the next stage begins. Stated so that a disinterested person could confirm it.
- Review point
- The place in the workflow where a person inspects output before it takes effect, sized to the consequence of the output being wrong.
- Operator
- A person who runs the workflow as part of their normal job, distinct from the person who built it.
- Deliberate retirement
- A documented decision to stop a workflow, with the reason recorded. Distinct from abandonment, which leaves no record and teaches nobody anything.
The stages in detail
Order matters. Each stage produces the input the next one needs.
Observe and map
Sit with the people doing the work. Document the real process: the workarounds, the informal spreadsheet, the steps that exist only because a system cannot do something. Exit criterion: the team recognizes the map as accurate, including the parts that are slightly embarrassing. If they correct it, the map was wrong and the stage is not finished.
Prioritize
Score candidates on value, feasibility, and risk. Select one. Capture its baseline now. Exit criterion: a single named workflow, a named process owner, and a recorded baseline. High value with low feasibility is a research project; deploying it first is the most common sequencing error.
Integrate and deploy
Connect the capability to the systems already in use, with real permissions and real data paths. Exit criterion: output reaches the system of record without a person copying it. If a human still shuttles the result between windows, the integration has been moved onto a person rather than completed.
Train and govern
Set the review point, the logging, and what happens when the system is wrong. Train operators on their own cases. Exit criterion: a second person (not the builder) can run it, and the review requirement is written down with its risk tier.
Measure and improve
Instrument against the stage-two baseline. Report honestly, including underperformance. Exit criterion: a result reported against the baseline, and a decision made: extend to an adjacent workflow, or retire this one with the reason recorded.
Principle
An AI pilot proves that a capability can work. Implementation proves that the organization can operate, govern, measure, and improve it.
When to use it, and when not to
The second column matters more. A framework that applies to everything constrains nothing.
Use it when
- You are implementing a specific, repeating workflow
- The organization has existing business systems to integrate with
- A person could perform the task, given enough time
- You can capture a baseline before changing anything
- Someone can be made accountable for the process outcome
- Previous AI attempts stalled after a successful demo
Do NOT use it when
- You are building a product feature rather than an internal workflow; use ordinary product development
- The task is genuinely novel research with no known-good output to compare against
- A named regulatory regime dictates the design; that governs, not this
- The work is one-off rather than repeating; a framework is overhead
- You are training or fine-tuning models; this covers deployment, not model development
- Adoption has already failed for trust reasons; address that first, or stage four will fail again
The stage that gets skipped
Stage two's baseline is skipped more than any other element, because it feels like administrative delay when everyone is keen to build.
The cost arrives at stage five, when leadership asks what the work achieved and the only available answer is anecdote. That is how projects with genuine benefits lose funding to projects with better storytelling. A baseline takes hours; its absence is unrecoverable.
Evidence and its limits
This framework is a description of practice, not a validated instrument. It has not been tested in a controlled study, no effect size is claimed, and none should be inferred from this page.
What can be said: it is the model used in consulting engagements and taught in workshops, and it was arrived at by observing which stages, when skipped, produced the failure modes described above. That is practitioner evidence, useful and weaker than a study.
The one client engagement documented to this site's standard is on the case studies page. It predates the framework being written down and does not include a captured baseline, which is itself an illustration of the stage-two problem and is stated plainly there.
If you apply this and it fails, that is genuinely useful information and the contact route is open.
Relationship to other frameworks
This overlaps substantially with established implementation and change-management practice, and does not claim otherwise. Process mapping, staged gating, and measurement against baseline all long predate it.
Its two distinguishing properties are the observable exit criteria attached to each stage, and the insistence that the baseline is captured at stage two rather than assembled at stage five.
Shuhari for AI Adoption operates at a different scale. This framework governs one workflow; shuhari describes the organization's capability across many. A team in shu should follow these stages exactly; a team in ri may legitimately compress them, because they know what each stage protects against.
For governance specifically, stage four connects to responsible AI governance, which covers risk tiers and oversight in far more depth than a single stage can.
How to cite this framework
Zialcita, M. (2026). The Practical AI Adoption Framework, version 1.0. martinzialcita.com. https://martinzialcita.com/frameworks/practical-ai-adoption/
Cite the version number. The framework will be revised, and a citation without a version becomes ambiguous once it is.
The diagram may be reproduced with attribution to martinzialcita.com. This page prints cleanly to PDF if you need it away from the site; interface elements drop away, leaving the model, diagram, and citation.
Version history
| Version | Date | Change |
|---|---|---|
| 1.0 | 2026-07-31 | First published. Five stages with exit criteria, boundaries, and citation format. |
Material revisions will be recorded here rather than applied silently, per the editorial policy.
Frequently asked questions
How long does one pass through the five stages take?
For a single well-scoped workflow with existing system access, commonly four to twelve weeks. Stage one is often days; stage three is usually the longest.
What extends it is rarely the build. It is unresolved permissions, data that is less structured than assumed, or no decision-maker on the review point. Those surface in stage one if you are looking for them.
Can stages run in parallel?
Partly. Stage four's governance thinking can begin during stage three, and often should. But the exit criteria are sequential for a reason: you cannot set a meaningful review point before you know what the integration produces, and you cannot measure without the baseline captured in stage two.
A team in ri, in shuhari terms, will legitimately overlap them. A team running its first implementation should not.
What if we fail an exit criterion?
Stop and resolve it, or make an explicit decision to proceed without it and record why. Both are legitimate; drifting past it unnoticed is not.
The most common one to fail is stage three: output that still needs a person to move it. Teams frequently declare that stage complete because the hard part felt finished.
Is this specific to AI?
Not especially, and that is a fair criticism. Most of it would apply to any workflow automation project.
The AI-specific parts are stage four's emphasis on review points sized to consequence (because AI failure modes are fluent and plausible rather than obviously broken) and stage three's attention to what data reaches a model provider.