ETE Oversight / Practical guide

AI agent readiness checklist.

Questions to ask before an AI agent receives access to organizational data, tools, or actions. Use them to define a review, not to replace testing.

By ETE Oversight · Published October 18, 2026

An AI agent readiness assessment examines a system in its intended operating context: what it can access, what it can do, how well it performs, and whether people can supervise and recover the workflow. Readiness is specific to a configuration and use case; a model’s general benchmark score is not enough.

1. Define the workflow and decision.

Document the intended users, tasks, data, integrations, and accountable decision-maker. Specify whether the agent recommends actions, prepares them for approval, or executes them. Agree acceptance criteria and the evidence required before deployment.

2. Establish performance evidence.

Test representative tasks, including incomplete inputs, ambiguous requests, unsupported questions, and relevant failure scenarios. Record useful completion, consequential errors, repeated-run variation, and human review effort. Retain enough context to reproduce and interpret the result.

For a knowledge assistant, check whether its answer is supported by an approved source and whether that source actually answers the user’s question. A citation is something to verify, not proof by itself.

3. Map data and permission boundaries.

List the agent’s tools, accounts, credentials, and allowed operations. Confirm who approved each permission and how it can be revoked. Test the intended boundary between users and documents. Include relevant attempts to redirect the agent through untrusted inputs within an authorized test scope.

Ask what information goes to each vendor, how retention is configured, and what supporting documentation is available. Record unverified vendor claims separately from observed behavior.

4. Make human approval operational.

Identify which actions require approval, who receives the request, what they can see, and what happens if they do not respond. A policy that says “human in the loop” is incomplete unless a person has the time, information, and authority to make the decision.

Test whether the workflow waits for approval and whether rejection prevents the action. Define escalation for unfamiliar or high-impact requests. Do not assume an approval screen proves the control works end to end.

5. Test intervention and recovery.

Agree how to stop further actions, revoke access, preserve evidence, and return to a manual process. Where feasible within the authorized scope, exercise recovery rather than relying only on a written description. Record any actions that cannot be undone and how their consequences are handled.

6. Examine operating value and dependencies.

Account for review, correction, escalation, licensing, usage, and maintenance. Identify model providers, integrations, service availability dependencies, and what happens if a supplier changes a model or feature. Review findings alongside the business case rather than treating controls and value as unrelated decisions.

7. Record findings and reassessment triggers.

Create a versioned record of the configuration tested, methods, evidence, unresolved issues, and proposed conditions for proceeding. Assign owners to the follow-up work. Material changes to models, data, tools, permissions, or intended use should trigger a decision about retesting.

A useful evidence record distinguishes these categories
Evidence typeHow to describe it
ObservedWhat the evaluator tested and saw under stated conditions.
DocumentedWhat policies, configurations, or supplied records show.
AssertedWhat a supplier or stakeholder claims without supporting evidence examined.
UnavailableWhat could not be accessed or tested and how that limits the conclusion.

Is a readiness review the same as certification?

No. A scoped review informs an accountable deployment decision. It does not establish that a system is safe in every context or confer government authorization. The report should state what was examined and what remains unknown.

Who should perform an independent review?

Review responsibilities require suitable technical expertise and disclosure of relevant relationships. Implementation testing and independent assurance serve different purposes. ETE does not describe its own implementation testing as independent assurance; a separate qualified reviewer is needed for an independent conclusion about ETE-delivered work.

Further reading and next steps

The NIST AI Risk Management Framework provides a public reference for AI risk management. This checklist is ETE’s practical scoping guide, not a NIST certification checklist or a claim of endorsement.

Planning a new workflow? Start with the AI workflow pilot guide. Evaluating a supplier? Explore third-party AI assurance.

Put the guide into practice.

ETE Assurance’s Workflow Readiness Review examines performance, business value, human control, and recovery within an agreed testing scope.

Explore the service

Practical AI resources

Make the next decision clearer.

All guides ↗

Planning & business value

AI Workflow Pilot Guide

Choose a useful AI workflow, establish a baseline, prepare approved knowledge, and measure quality, review effort, and cost before expanding.

Read the guide ↗