AI procurement often begins with a product demonstration and ends with an operating problem the product cannot resolve. A platform may be capable, secure in general and easy to buy while still being wrong for the organisation’s current workflow, information or authority model.
Readiness is therefore not a score for the whole business. It is a decision about one proposed initiative: proceed within bounds, strengthen conditions first, or do not build yet.
Define the procurement decision
Replace “We need an AI platform” with a bounded statement:
> We are considering a capability that performs or supports this specific job, for these users, with this information, inside this workflow, under these approval and recovery conditions.
That statement lets procurement compare products against an operating requirement rather than a feature list.
Decision 1: What business consequence matters?
Name the outcome and affected parties. Is the organisation reducing response time, improving decision quality, preventing missed handoffs or expanding service capacity? Define what must not become worse.
If the benefit remains “increase productivity”, procurement cannot distinguish a useful capability from an attractive demonstration.
Decision 2: Who owns the outcome?
Assign one accountable business owner. Technology, procurement and risk functions may each own part of the process, but somebody must decide whether the capability is producing the intended result and whether it should continue.
A supplier cannot own the organisation’s consequence.
Decision 3: Which information is permitted and dependable?
List the sources the capability may use. Check permission, provenance, quality, freshness and conflict handling. Ask whether sensitive or regulated information can enter the system and which contractual or technical controls apply.
Do not upload representative data to a trial simply because the interface permits it.
Decision 4: Where does it operate in the workflow?
Map the trigger, input, current state, intended state change, handoff and exception. Decide whether the system prepares work, recommends action or executes a change.
This prevents the organisation from buying a general capability and discovering later that no dependable workflow exists around it.
Decision 5: What authority may it receive?
Separate actions that are allowed, reviewable, escalated and prohibited. Specify approval thresholds and revocation. The authority boundary should be narrower than the product’s technical capability.
An agent that can access a tool should not automatically be authorised to use every action that tool exposes.
Decision 6: Can the organisation detect and recover from failure?
Identify how failures appear, who intervenes and how state is restored or reconciled. Recovery may mean reversing a change, correcting a record, contacting an affected person or suspending the capability.
If a consequential side effect cannot be detected or treated, the initiative is not ready for that level of autonomy.
Decision 7: What evidence will justify the purchase and expansion?
Define the baseline, outcome, guardrails, intervention rate, cost and review date. Separate evidence that a tool was used from evidence that the business condition improved.
Expansion should require observed evidence, not the exhaustion of a pilot budget.
Turn answers into a procurement disposition
Use three outcomes:
- PROCEED — BOUNDED: critical conditions are evidenced for a limited scope.
- STRENGTHEN CONDITIONS FIRST: the use case is valuable, but a repairable operating condition is missing.
- DO NOT BUILD YET: a hard constraint, absent owner, prohibited information use or unrecoverable consequence blocks the initiative.
Do not average the decisions into one score. A serious authority or recovery failure cannot be cancelled by a polished workflow or strong vendor feature.
Use standards as context, not a procurement badge
NIST AI RMF provides voluntary risk-management guidance through Govern, Map, Measure and Manage. Its Playbook offers suggested actions that organisations apply contextually. ISO/IEC 42001 describes requirements for an AI management system and continual improvement.
These sources can strengthen evaluation, but citing them does not prove that a product or deployment fits a specific organisation. Procurement still needs traceable requirements, evidence and accountable acceptance.
The next step
Document the seven decisions before issuing a request for proposal, approving a platform trial or granting an agent access to production systems.
The detailed [readiness decision framework](/blog/ai-for-business/ai-readiness-assessment-decisions/) explains the evidence behind proceed, strengthen and stop outcomes. If the problem crosses multiple workflows, information systems and authority boundaries, request an [Architecture Assessment](/request-an-architecture-assessment/) before procurement commits the organisation to a solution.
Sources and scope
NIST and ISO material provides governance context. The procurement application and recommendations are original netlinkE analysis. This is not legal, procurement or certification advice.
