How to Choose an AI Capability Milestone That Predicts Workplace Use

The most convincing AI demo is often the least useful evidence. It shows what the tool can produce when the path is prepared. It does not show what a person can do when the task changes, the output is wrong, or the decision crosses a risk boundary.

I’ve seen the same distinction while teaching product managers who moved from writing specifications to building and shipping products: the hard question is usually not whether the model can produce something. It is what counts as done, and who is allowed to accept the result. That is a teaching observation, not a measured result.

What should count as an AI capability milestone?

Count a milestone only when the person can complete a bounded task, find and repair a material error, verify the result, repeat the capability on a changed task, and stop or escalate when authority is unclear. Tool fluency is exposure. Transfer is evidence.

That definition matches the useful direction of broader adoption research. SEI describes adoption as a managed process with measurable capabilities and clearly defined intermediary objectives, rather than a single maturity label. Microsoft’s readiness model likewise describes observable behaviors such as decision rights, accountability, human judgment, and escalation paths. (SEI’s AI Adoption Maturity Model, Microsoft’s readiness model)

The test used here turns those ideas into a smaller product-team decision. It asks five questions:

1. Can the person produce the requested artifact at the stated scope?
2. Can they name the first material error or missing condition?
3. Can they verify the result with a source or reviewer?
4. Can they do the same kind of work on a changed task without copying the answer?
5. Can they name the stop condition and the next owner?

The fifth question matters because workplace use is not only a skill decision. It is an authority decision. AI-CAM makes a similar broader point by separating business, data, technology, organisation, AI skills, risks, and ethics across capability levels. (AI-CAM)

Which milestone justifies which workplace use?

Use the narrowest workplace permission that the evidence supports. The matrix below is the sourceable artifact from the bounded rehearsal recorded with this post.

Observed evidence	Workplace use it can justify	Conditions	Veto
Tool fluency or a polished demo	No workplace use yet	Repeat the task with an inspectable artifact.	Veto if there is no independent reconstruction.
Independent artifact and first-error diagnosis	Low-risk supervised drafting	A reviewer can inspect the artifact and correction.	Veto if the operator cannot identify an evidence gap.
Evidence checking and changed-task transfer	Repeatable preparation or read-only analysis	Name the owner and make verification visible.	Veto if transfer works only on the practice wording.
Safe escalation at the risk boundary	A bounded workflow proposal with human approval	Write the action, owner, stop condition, and review path.	Veto autonomous action when authority, privacy, security, or reversibility is unclear.

This matrix is deliberately conservative. A passed milestone does not grant a person permission to take the next action. It just tells you the smallest use worth trying. The permission still depends on the work, the data, the reviewer, and the consequence of an error.

OpenAI’s 2025 enterprise report describes AI moving into repeatable, multi-step workflows and says Custom GPTs and Projects can support repeatable tasks. That is useful context for the direction of travel, but it is not a readiness test for your team. (OpenAI’s enterprise report)

How do you run the capability-transfer test?

Run one normal task and one changed task for every milestone you want to use as a decision gate. Keep the inputs bounded, save the artifacts, and write the correction before moving on.

1. Choose a real product-team task with a visible output. Remove secrets and personal data, but keep the ambiguity that makes the task representative.
2. Define the acceptance boundary before using AI. Include what must be present, what must be checked, and what must remain out of scope.
3. Let the person use AI to make the first artifact. Record the first correction, not just the final polish.
4. Close the assisted answer. Rebuild the core artifact without copying the earlier output.
5. Change one meaningful condition. Use a different format, audience, policy, data shape, or risk boundary.
6. Ask for the verification source or reviewer. If there is no source or reviewer, record an evidence gap.
7. Record the escalation decision. A safe “stop and ask” is a pass when the task crosses the person’s authority.
8. Choose the narrowest next use from the matrix. Do not jump from a passed exercise to autonomous action.

NIST’s AI Risk Management Framework gives the risk side a useful external anchor: govern, map, measure, and manage are continuous functions, and context and human oversight inform an initial decision about whether an AI use is appropriate. (NIST AI RMF Core)

If the capability is still being learned, How to Use AI to Learn a Technical Skill gives the learner-side practice loop. If the work is shared across a small team, How to Make AI Training Stick in a Small Team covers the follow-up habit that makes the transfer check repeatable.

What did the product-team rehearsal show?

The three-task rehearsal produced a correction before it produced a recommendation. That is the part worth carrying into your own test pack.

Task	First failure	Transfer result	Decision
Turn an analytics CSV-export request into a release brief	The first pass omitted a maximum-row condition.	The acceptance structure transferred to a PDF-export request with different constraints.	Allow supervised preparation of a bounded brief.
Review a claim that AI onboarding lifted activation by 42%	The first pass treated positive feedback as evidence for the number.	The same evidence-gap test transferred to a retention claim.	Allow evidence-request preparation, not a roadmap decision.
Draft a reply to a data-deletion request	The first pass assumed eligibility and implied deletion could proceed.	The boundary transferred to a suspected security-incident notification.	Keep triage and drafting supervised; escalate to privacy or security.

The result is qualitative. It comes from one operator, three tasks, and one changed task per milestone. It does not estimate how often people pass, and it does not prove a team can perform the same work. It does show why the matrix needs corrections and transfer, not just a polished first output.

How should a product team choose its next AI use?

Choose the first use that is both supported by the transfer evidence and cheap to review. For the CSV-export example, the next use is a read-only preparation workflow: AI turns a bounded request into a draft brief, lists missing acceptance conditions, and points to the reviewer. It does not publish the brief, change permissions, or export customer data.

That choice is narrower than “use AI for product development,” but it is actionable. The team can name the input, output, reviewer, evidence source, and stop condition. It can also run the same test again when the task changes.

Microsoft warns that adoption can become dependent on a few champions and that a technology-project mentality can leave technically successful work unused. The practical implication is simple: make the evidence and escalation path reusable by the team, rather than leaving the judgment inside one enthusiastic operator. (Microsoft’s observable readiness behaviors and anti-patterns)

When should you reject the next workplace use?

Reject the next use when any of these conditions holds:

• The person can prompt well but cannot reconstruct the result without the tool.
• The first error is invisible because nobody defined what good means.
• The changed task exposes a new policy, data shape, or audience and the method does not transfer.
• The only verification is “it looks right.”
• No one owns the decision or the escalation.
• The action is irreversible, privacy-sensitive, security-sensitive, or externally consequential.

These are vetoes, not reasons to abandon learning. Move the learner back to a smaller task, define the reviewer, or keep the AI at drafting and read-only preparation. The goal is not to prove that someone is ready for everything. It is to choose one next use that the evidence can actually support.

If you want help designing that test around your team’s own work, Marius Manolachi’s AI capability programme starts from the work people need to do and the evidence they need to produce. You can also use the assigned parent guide, What to Learn Before Building AI Agents, to connect this decision to the wider capability cluster.