Long feature lists make products look similar and reward confident terminology. Outcome-led requirements expose meaningful differences: what decision must improve, which control must operate and what evidence must remain afterwards. If the starting point is unclear, run the AI governance maturity assessment before drafting requirements.
Write the outcome first
Replace “the system shall provide an AI inventory” with a result such as: “the organisation can identify approved and undeclared AI, assign ownership, understand connected identities and tools, and escalate unowned systems.” The second statement can be demonstrated and scored.
Turn each outcome into a scenario
- Describe the operating context and starting state.
- Introduce a realistic risk or material change.
- Ask the supplier to show detection, decision and action.
- Inspect integrations and manual steps.
- Review the evidence available to operators and assurance teams.
Build a requirements matrix
One row should connect a governance outcome to a realistic scenario, a clear priority, the proof requested and an observable pass condition. This keeps business, technical and assurance reviewers focused on the same result.
| Governance outcome | Test scenario | Priority | Requirement | Evidence requested | Pass condition | Owner |
|---|---|---|---|---|---|---|
| Find and govern undeclared agents | Introduce an unregistered agent connected to a business tool | Must | Discover the agent, assign an owner, assess risk and preserve the decision | Live demonstration plus exported record | Source, owner, status, control and evidence remain linked | AI governance lead |
| Control material change | Broaden tool access after approval | Must | Trigger reassessment and prevent silent inheritance of approval | Change event, workflow and updated decision | Old approval is visibly superseded | Business owner |
| Support executive oversight | Review high-risk exceptions | Should | Show current exceptions, owners, expiry and remediation | Dashboard linked to source records | Every metric is traceable to evidence | Risk owner |
Separate must, should and could
A “must” protects a necessary outcome, obligation or architecture constraint. A “should” materially improves operation but has an acceptable workaround. A “could” is a differentiator. Do not classify roadmap features as current coverage, and do not let a large number of optional features compensate for a failed mandatory scenario.
Measure fit, not theoretical breadth
A broad platform may offer a strong operating model but shallow technical enforcement. A specialist may provide deep agent or runtime controls while depending on another system for inventory and workflow. The right choice depends on existing stack, risk profile, region, skills and control gaps.
Ask for proof at the right level
Evidence can include a live demonstration, architecture documentation, supported integration, exported decision record, independent assessment or customer reference. Match proof strength to requirement importance. The evidence and metrics guide explains what a portable governance record should contain.
Score the demonstrated end-to-end outcome separately from roadmap promises, configured integrations and descriptive claims.
Score evidence and implementation fit
Score capability, confidence and implementation dependency separately. A requirement may be supported in principle but still depend on custom integration, manual enrichment or a separate enforcement product. Record data residency, services, operating ownership, retention and export constraints beside functional fit.
Run a controlled proof-of-value
Use the same scenarios and representative identities, data, tools and approval roles for every finalist. Include a normal path, a change event and a failure path. Ask the supplier to discover an unregistered agent, assign an owner, apply a risk decision, enforce or route a control and export the evidence record.
Record gaps, assumptions and clarifications
The decision record should state what was demonstrated, what relied on documentation, which integration was configured, what remains a supplier claim and which gap is accepted. This prevents a qualified shortlist from becoming an unqualified product endorsement when stakeholders revisit it later.