How to Assess Team Capability Before Buying an AI Platform

Platform features can dominate the discussion while the real decision stays elsewhere. The team has not agreed what the workflow must do, how quality will be judged, or who will own the result after the vendor leaves.

What did the worksheet decide?

For a constructed 42-person support-company scenario, the worksheet scored current capability at 7 out of 21. Workflow integration was usable, but evaluation, governance, and operating ownership were not ready for a full platform contract.

Decision	Result
Current capability score	7/21
Platform-only recommendation	Buy now because connectors and orchestration appear to solve the technical problem
Capability-transfer recommendation	Train, partner, assign ownership, then defer the full contract
Documented veto	No full purchase while evaluation, governance, or operating ownership remains at 0, or while data access is 0

The choice is conditional. Buy the platform when it removes a demonstrated technical bottleneck after the team can define, evaluate, govern, and operate the workflow. Otherwise, the next spend should target the lowest capability score.

The external evidence points in the same direction, but it does not prove this worksheet's result. The OECD describes internal capability, training, governance, and process change as part of AI adoption, while a 2026 paper frames readiness as organizational learning across people, operations, data, infrastructure, and governance. (OECD, McClure and Gerdau)

How does the capability worksheet score a team?

Score the team's present ability, not the vendor's feature list. A platform feature can improve a score only when the team can configure it, test it, govern it, and keep it working.

Score	Meaning
0	Absent. No named practice, evidence, access, or owner exists.
1	Ad hoc. One person or an informal workaround exists, but it is not repeatable.
2	Repeatable. A documented practice or working control can support a bounded pilot.
3	Owned. The practice is measured, maintained, and transferable across workflows.

Use these seven dimensions:

1. Use-case definition: Can the team name the user, trigger, action, boundary, success measure, and definition of done?
2. Data access: Can the team identify the data, permissions, freshness, and safe test set the workflow needs?
3. Workflow integration: Can it connect the workflow to existing systems, including exception handling and write-back where needed?
4. Evaluation: Can the team create representative cases, apply a rubric, record failures, and decide whether a change is better?
5. Governance: Can it set allowed data, approvals, escalation, audit, and risk ownership?
6. Operating ownership: Is a person or team responsible for incidents, changes, cost, user feedback, and retirement?
7. Enablement: Can more than one person perform the work, use the runbook, and teach the next operator?

These dimensions adapt a recurring pattern in the primary sources. NIST's AI RMF Playbook uses Govern, Map, Measure, and Manage. Microsoft's adoption model spans business process transformation, governance and security, technology and data, and organization and culture. Google Cloud's framework treats people, process, technology, and data as interacting parts of capability. (NIST, Microsoft Learn, Google Cloud)

The worksheet's decision bands are practical heuristics, not an industry standard:

• 0-7: Defer a full platform contract. Run capability work and, if safe, a low-risk sandbox exercise.
• 8-13: Consider a narrow platform pilot only when every critical dimension is at least 2, data access is at least 1, and a named owner has weekly capacity.
• 14-21: Proceed to platform commercial diligence if the platform closes a documented technical gap and the team keeps evaluation and governance ownership.

The critical-dimension rule matters more than the total. A team can score well on data and integration while still being unable to tell whether the system works.

What did the filled example score?

The constructed scenario is deliberately ordinary: a support company wants to classify inbound implementation requests, draft the next action, and route exceptions to a human. It has a ticket API, unlabelled historical examples, unresolved document permissions, two interested champions, and one operations lead who is expected to own the pilot alongside existing work.

Capability	Score	What the score means here	First response
Use-case definition	1	“Reduce triage time” is not an acceptance criterion or definition of done.	Train the team to write a bounded workflow brief and acceptance criteria.
Data access	1	The API exists, but data labelling and permissions are unresolved.	Partner on data mapping and permission review.
Workflow integration	2	The API and human exception path exist, but write-back is untested.	Buy only a narrow connector or platform capability if the pilot proves it.
Evaluation	0	There is no labelled evaluation set, rubric, threshold, or owner.	Train and partner to create a reviewable evaluation set and release gate.
Governance	1	Data classification and approval rules are incomplete.	Partner with security or compliance before production data.
Operating ownership	1	A nominal owner exists, but the role has no protected capacity.	Hire, reassign, or fund an owner.
Enablement	1	Two champions exist, but no runbook or transfer check exists.	Train through a live workflow and verify independent operation.
Total	7/21	Capability is the binding constraint.	Train + partner + assign ownership, then defer.

This is the sourceable result of the artifact. It is not a benchmark and not a client case. The scenario is constructed so a buyer can replace its assumptions with their own evidence.

Why does the platform-only answer change?

A platform-only review asks, “Does the product have connectors, orchestration, model access, and governance features?” The capability-transfer review asks, “Can our team turn those features into a working, judged, governed process?” Those questions can produce opposite recommendations.

Decision lens	Platform-only answer	Capability-transfer answer
Main diagnosis	The platform has the missing features, so buy now.	Integration is not the binding constraint. Evaluation, governance, ownership, and enablement are.
Next spend	Enterprise platform contract plus implementation services.	Definition-of-done training, data and permission review, evaluation setup, protected ownership, then a narrow pilot.
What the purchase may remove	Connector and orchestration friction.	The same technical friction, but only after the team can operate the result.
What it cannot create automatically	A workflow that the team can judge and own.	A transfer plan that leaves the team with those capabilities.
Decision in the example	Buy now.	Veto the full purchase at 7/21. Reconsider a bounded pilot after critical gates reach 2.

The OECD identifies outsourcing, hiring, training, and partnerships as different levers for capability building. It also notes that building internal capability can improve alignment and reduce dependency on providers. That does not mean every company should hire or build everything itself. It means the procurement decision should include the capability transfer, not only the license. (OECD)

What can an AI platform remove, and what can it not create?

An AI platform can be the right purchase when the team already has the surrounding practices and the friction is genuinely technical.

A platform may remove	A platform does not automatically create
Repeated connector and orchestration work	A precise use case and definition of done
Environment setup and shared access patterns	Representative evaluation cases and a release decision
Some monitoring, logging, or model-routing work	Permission decisions and acceptable risk
Reusable components for several workflows	A named operator with time to respond to failures
Infrastructure work that is expensive to maintain alone	The workflow redesign and enablement needed for adoption

Treat vendor claims about these capabilities as features to verify, not capability you can mark as present. Ask for the configuration effort, export path, audit behavior, failure handling, evaluation workflow, and operator handoff. Then score your team again after a proof exercise.

Microsoft's maturity model is useful here because it separates initial experimentation from repeatable, defined, capable, and efficient states. Its early-stage description includes unclear roles, limited process redesign, and no operational model. That is close to the scenario's failure mode, even if the platform itself is sophisticated. (Microsoft Learn)

What is the veto condition before signing?

Veto a full AI platform purchase if any of these conditions is true:

1. No one can state the workflow's definition of done.
2. No one can produce representative evaluation cases and a decision rubric.
3. No one owns governance decisions, approvals, and escalation.
4. No one accepts operational ownership for incidents, changes, cost, and retirement.
5. The required data cannot be accessed lawfully and safely, or its permissions are unknown.

This veto is about capability risk, not vendor quality. A good platform can still be the wrong next investment when nobody can tell it what success means or what to do when it fails.

NIST's framework gives a useful external check: trustworthy AI work needs activities across Govern, Map, Measure, and Manage, not only deployment. Its playbook is voluntary, so use it as a structure for questions and add any legal or internal controls that apply to your organization. (NIST)

What did I observe with product managers?

This is the bounded firsthand part, not a claim about the external studies. When I taught product managers who went from writing specs to building and shipping the product, the recurring problem was often a missing definition of done and shipping capability rather than a missing tool. That observation is why use-case definition and operating ownership appear before platform selection in this worksheet. It is qualitative teaching experience, not a measured rate or a substitute for buyer research.

It also changes the training recommendation. “Run a workshop” is too weak. The team should leave with a workflow brief, a small evaluation set, an approval rule, a runbook, and one person who can operate the workflow without the teacher. If the artifact cannot transfer, the capability score has not really moved.

What should the buyer do next?

Use the worksheet before a platform demo becomes a procurement process:

1. Score the current state. Require evidence for every score. A feature on a roadmap is not a 2.
2. Name the binding constraint. Choose the lowest score that blocks the workflow, then map it to buy, train, hire, partner, or defer.
3. Run a bounded transfer exercise. Produce a definition of done, safe test data, evaluation cases, governance decisions, and a runbook. Check whether a second operator can use them.
4. Re-score before buying. Buy a narrow platform capability when it removes the remaining technical bottleneck. Keep the veto if a critical dimension is still 0 or no owner exists.

For the cost side of the decision, use the existing AI platform total-cost worksheet after this capability screen. For the people side, compare it with how to assess whether AI training made a team capable. The parent decision context is whether to choose an AI consultant, agency, or internal team.

The recommendation is simple, but not universal: buy the platform when it removes a proven technical constraint and your team can own the surrounding work. If the team cannot define, evaluate, govern, or operate the workflow, buy capability first and keep the full-purchase veto in writing.