In short

AI readiness is not a perfect data warehouse, a completed digital transformation, or a company-wide AI policy. It is the practical ability to test one agent safely: real examples, a workflow owner, access rules, source material, evaluation criteria, and a path from output to human review.

Microsoft Work Trend Index 2025 describes a move toward teams where people supervise AI agents. That idea is useful, but it has an unglamorous prerequisite: the company must know which human owns the agent’s work.

Use this checklist before vendor selection, discovery, or a 30-day pilot. It is written for teams that want to start without pretending the whole organization is already clean.

1. Choose one workflow

Do not prepare for “AI in the company”. Prepare for one workflow.

A workflow has an input, a decision or output, a user, a source of truth, and a business reason. Examples: support answer drafting, candidate intake, sales follow-up, invoice checking, internal policy search, clinic reception, warehouse exception triage.

If you cannot draw the workflow in ten boxes, it is too broad for the first implementation.

2. Name the owner

Every AI implementation needs a business owner. This is not the project manager. It is the person who can say whether the agent’s output is acceptable.

The owner defines examples, approves escalation rules, chooses the metric, and protects the rollout from vague stakeholder expansion. Without this person, the project will drift toward a demo.

Also name a source owner. If the agent uses documents, someone must keep them current. If it uses CRM fields, someone must care about field quality. If it uses templates, someone must approve changes.

3. Collect real examples

For a first pilot, collect 100-300 examples. More is useful later, but early quality comes from diversity.

Include normal cases, messy cases, edge cases, and cases where the agent should refuse or hand off. For each example, add the expected behavior. Not always the perfect answer. Sometimes the expected behavior is “ask for missing order number” or “do not answer; send to legal”.

Real examples prevent the team from designing for imaginary users.

4. Map sources

Create a source map: documents, CRM or ticket records, spreadsheets, knowledge base articles, message histories, product data, approval rules, pricing or contract templates, internal policies.

For each source, answer four questions: is it current, who owns it, who may see it, and how often it changes?

This source map is the foundation for RAG beyond vector search if the agent answers from documents. It is also the foundation for safe tool use if the agent acts in systems.

5. Decide access and permissions

AI access should follow the work, not enthusiasm.

Separate read, draft, recommend, write, and irreversible action. A support assistant may read policy and draft an answer. A sales assistant may summarize a deal and suggest a next step. A finance assistant may extract fields and flag mismatches. Write access can come later.

For sensitive workflows, write down the human approval points. Human-in-the-loop is not a lack of automation. It is how the system earns more authority over time.

6. Define the evaluation

Before the pilot starts, decide how quality will be judged.

A useful evaluation includes expected behavior, failure labels, and a repeatable test set. OpenAI’s evaluation guidance emphasizes production scenarios and edge cases; in implementation terms, that means your eval set should contain the cases users actually bring, not just happy-path prompts.

For most workflows, evaluate correctness, source use, escalation, tone, extraction accuracy, permission behavior, refusal behavior, and time saved.

The article why AI projects need evals goes deeper, but the readiness version is simple: if you cannot judge output consistently, you are not ready to scale.

7. Baseline the process

You do not need a perfect BI dashboard. You need a baseline that prevents fantasy ROI.

Measure current volume, time, error rate, escalation rate, response time, missed follow-ups, or manual review load. Choose the metric that belongs to the workflow.

If the team cannot baseline anything, start with qualitative review during the pilot. But do not pretend the project has a financial case until the unit of value is visible.

8. Prepare the rollout boundary

Who will use the first version? One team, one shift, one region, one ticket category, one document type?

A small rollout boundary makes feedback legible. If twenty teams use the agent on day one, failure analysis becomes noise.

Also decide where feedback goes. A bad answer should not disappear in a chat complaint. It should become a labeled case for improvement.

9. Security and privacy pass

Before integration, list the sensitive data the agent may see: personal data, HR data, customer records, medical information, contracts, pricing, payment status, internal financials.

Then decide retention, logging, masking, role access, and vendor access. You do not need to overbuild governance for a small pilot, but you do need to know what you are exposing.

If this step blocks the pilot, narrow the scope. Use exports, synthetic samples, or read-only access until the rules are clear.

10. The readiness scorecard

You are ready for a pilot if you have one workflow, one owner, real examples, a source map, access rules, human review points, a baseline metric, a small eval set, a rollout group, and a decision gate.

You are not ready for broad production if you have only a sponsor, a model preference, and a list of departments that want AI.

What to do if readiness is weak

Do not pause for a six-month data cleanup unless the workflow truly requires it.

If examples are missing, run a two-week collection sprint. If sources are messy, choose one source category. If permissions are unclear, start with draft-only mode. If the owner is absent, stop until one is assigned. If the metric is fuzzy, run a small AI pilot in 30 days to discover the right metric.

Readiness is not a gate for perfection. It is a way to avoid expensive confusion.

FAQ

Do we need a data warehouse before AI?

Usually no. A narrow pilot can start with controlled exports, documents, and read-only access. A warehouse helps later when you scale across workflows.

Who should join the first workshop?

The workflow owner, one power user, IT or security, and the person who owns the source material. Keep it small.

What is the most common missing item?

Expected behavior. Companies bring data, but not examples of what a good answer or action should look like.

When should we talk to a vendor?

After you can name the workflow and show sample cases. If you need help choosing the workflow, use how to choose an AI implementation vendor as the interview guide.