We run a one-to-two-week AI readiness assessment for companies deciding where AI pays off in their operation. Most of what it checks is not technical. It is whether a handful of things are true about the workflow, the data, the rules and the people before anyone builds. This is that checklist, so you can run the first pass yourself. It is a working guide, not legal advice; the privacy section in particular deserves your own counsel.
The workflow
- Which decisions would the system make or influence? Name them. “Customer support” is not a decision; “choose which refund policy applies and draft the reply” is.
- What does a wrong answer cost? In money, in a customer, in a regulator’s attention. If nobody can answer this, the project has no way to set its guardrails.
- Who approves what? Which actions may the system take on its own, which need a person, and who is that person? Reversible actions and irreversible ones need different answers.
- How is the work done today, step by step, by the people who do it? Not the process document. The real steps, with the exceptions. Most of the value, and most of the risk, lives in the exceptions.
- How will you know it is working? A measure you already track, or one you can start tracking before the build.
The data
- Where does the data the system needs actually live? Systems, spreadsheets, inboxes, people’s heads. Count the sources.
- Can a program read it today? An API, a database, an export. If the answer is “someone copies it out”, that is the first project.
- Is it what it says it is? Fields used for things they were not designed for, “null” written as a word, dates in three formats. Public and internal data alike arrive this way; we have built pipelines for both.
- How current does it need to be, and how current is it? A nightly export may be fine for forecasting and useless for an agent that books appointments.
- Who owns it? The person who can answer “is this field still used?” has to be in the room.
Privacy and compliance
- What personal information will the system see, and does it need to? The federal Personal Information Protection and Electronic Documents Act (PIPEDA) applies to most commercial activity in Canada, and its principles of consent, limiting collection and use to the stated purpose, and safeguarding the information apply to an AI system exactly as they apply to a database. Minimise what the model sees.
- Where will the data be processed? Model providers and cloud regions matter. Azure, for example, has Canadian regions; many model endpoints do not. Decide what may leave the country and what may not, and write it down.
- If you operate in Québec, provincial privacy law adds obligations of its own, including around automated decisions about individuals. Check them before design, not after.
- Can you explain a decision? If the system influences a decision about a person, a credit, a claim, a hire, you will be asked why. Keep the inputs, the retrieved evidence and the output for every decision.
- Who is accountable? A name, not a department.
Guardrails
- Approval gates. Anything irreversible waits for a person, and the system makes that easy rather than possible to skip.
- Grounding. The system shows only what its tools returned, never what the model composed. Our pattern for this is in keeping AI agents honest.
- Injection. Anything the model reads, a document, a web page, a tool result, can carry instructions. The design has to assume it will.
- Audit log. Every action, every tool call, every model call, with who asked and what came back.
- Cost and latency budgets. Per request and per month, with an alert before the bill arrives.
The platform
- Where will it run? Inside your own cloud subscription is usually right: the keys, the data and the logs stay yours.
- Who can change the prompts, the tools and the model? Treat them like code: versioned, reviewed, deployed.
- What happens when the model provider changes the model? They will. An evaluation set with known answers, run before and after, is the only way to know whether you got better or worse.
The people
- Who owns the system after launch? Someone has to read the traces, review the queued approvals and run the evaluations.
- What do the people doing the work today think? They know the exceptions. They also know whether the system is helping, long before the metrics do.
- What will you stop doing? If the system takes on work and nothing changes for the people who did it, the project has no benefit to measure.
Scoring it
Count the questions you cannot answer. Fewer than five: start with a prototype on real data. Five to ten: a short assessment will save you the cost of finding out mid-build. More than ten: the first project is the data, and it is a good project.
The assessment we run produces an opportunity map, the data and guardrail requirements, two or three architecture options with their running costs, a prioritised build plan, and a prototype scope you could hand to any team. It is described at AI strategy and readiness.