AI Readiness Checklist: 25 Questions Before You Build

An AI readiness checklist is a short list of yes or no questions about one specific AI use case. It tells you whether your data, process, systems and people can carry that use case today. The version below has 25 AI readiness questions in five areas, a scoring method, and an honest reading of each score band. It is not behind a form. Copy it, print it, run it in a meeting.

It is the same ground we cover at the start of an assessment. Most AI projects that fail never had a model problem. They had a data problem nobody looked at, a process that changed every quarter, or no agreed definition of a correct answer. All three show up in this list. They are much cheaper to find in an hour than in month five of a build.

Four rules make the answers worth something:

• Pick one use case. The question 'is my company ready for AI' has no useful answer in the abstract. Answered for AI in general, the checklist scores everyone in the middle.
• Answer as a group. Bring the process owner, someone who knows the data, someone from IT, and whoever handles data protection. Each of them will mark a different question as no.
• Unsure counts as no. If nobody in the room knows the answer, that is the finding.
• Answer from evidence, not documentation. 'The data is in the CRM' is a yes only if someone has opened the CRM recently and looked.

Use case and value

This area decides whether there is anything worth building at all. Many of the stalled pilots we are asked to review would have stopped here, had anyone asked these five questions first.

1. 01Can you describe the use case in one sentence that names the input, the output, and who acts on the output? 'Draft replies to inbound support tickets for an agent to approve' passes. 'Use AI in customer service' does not.
2. 02Do you know what the task costs today, in hours, errors or lost revenue, from a measurement rather than an estimate?
3. 03Is there one number that will tell you, three months after launch, whether it worked? Handling time per ticket, share of invoices processed without correction, hours per week returned to a team.
4. 04Can someone in the business define a correct output, and would two of your experts usually agree on it? Knockout question.
5. 05Have you ruled out the cheaper answers? A rule, a database query, or an off-the-shelf product that already does this for a monthly fee.

The last question is the one people skip. If a deterministic rule produces the right answer, a model only adds cost, latency and doubt. If a vendor sells it for a few hundred euros a month, building it yourself is rarely a good use of budget.

Data readiness

Data is where most readiness scores fall apart, because it is the area people answer from memory.

1. 01Does the data the use case needs exist today in a system you control, not in inboxes, laptops or people's heads? Knockout question.
2. 02Has someone looked at a real sample in the last month? A few hundred actual records, not the schema and not the documentation.
3. 03Does that sample look like production, including the scanned PDFs, the second language and the half-filled forms?
4. 04Does the data have an owner who keeps it current, so the system is not answering from last year's price list?
5. 05Do you have, or could you assemble within two weeks, around 100 real examples with known correct answers to test against?

The fifth question matters more than it looks. Those examples become the evaluation set, the thing that tells you whether the system works before your customers find out. If you cannot assemble them, you usually cannot define correct either, and the use case section was answered too generously.

Process readiness

A model automates the process you have, not the one in the slide deck. If the process is unstable, the AI inherits the instability and gets blamed for it.

1. 01Does the process run the same way most of the time, with exceptions that are actually exceptional?
2. 02Is there a named process owner who wants this change and has the authority to adjust the process around it?
3. 03Will the process stay stable for the next twelve months, rather than being reorganized, outsourced or moved to a new system?
4. 04Is it clear what happens when the AI is wrong or unsure: who reviews it, who corrects it, and how quickly?
5. 05Does the task run often enough that saving a few minutes per case adds up to real money each month?

The fourth question separates a demo from a system. Every AI feature produces wrong outputs at some rate. A process with a place for them absorbs that. A process that assumes the model is always right finds out in production, usually in front of a customer.

Systems and integration

An AI feature that cannot read from your systems and write back into them becomes a separate tool. Staff end up copying and pasting into it, and in our experience those tools quietly stop being used.

1. 01Do the systems holding the input data have an API or a supported export, not just a screen to scrape?
2. 02Do you know where the output has to land, whether CRM, ERP or ticketing system, and can you write to it?
3. 03Has IT agreed where a model may run: a provider API on an EU region endpoint, a private cloud deployment, or open weights on your own hardware?
4. 04Can you log inputs, outputs, and the model and prompt version behind each one, and keep those logs for months?
5. 05Is there a named owner and a budget for running it after launch? That covers model usage, hosting, monitoring and the occasional prompt fix.

Logging looks like an engineering detail. It is also the record you need when someone asks what the system told a customer last March. You cannot create it after the fact. The running budget is the other item teams miss. The build is a one-off cost. The model bill, the monitoring and the maintenance are not.

People and governance, including GDPR and the EU AI Act

This is where GDPR and the EU AI Act come in. For most business software both are manageable, provided somebody checked before the build rather than after it.

1. 01Is there a sponsor with budget who will decide on the results, including the decision to stop?
2. 02Do you have a lawful basis under GDPR to use this data for this new purpose? Has your data protection lead seen the use case, and is there a processing agreement with any model provider involved? Knockout question.
3. 03Have you checked the use case against the EU AI Act? You need to know that it is not prohibited, and whether it is high risk. Knockout question.
4. 04If people interact with the system or receive generated content, is there a plan to tell them it is AI?
5. 05Have the people whose work changes been involved early, and is there a plan to help them use the system well?

A few dates help here. Prohibited practices have been banned since 2 February 2025. The Article 50 transparency duties, telling people they are talking to an AI and labeling deepfakes, have applied since 2 August 2026. The Digital Omnibus entered into force on 27 July 2026. It moved the high-risk obligations for Annex III areas, such as employment, credit scoring and education, to 2 December 2027.

Classification follows the use case, not the model or where it is hosted. Most internal copilots, document search tools and support assistants end up limited or minimal risk. Checking takes an afternoon. Not checking is what makes the third question a knockout. The Omnibus also softened the AI literacy duty in Article 4: companies must now support AI literacy among staff rather than guarantee a level of it. The last question covers that, and it is good practice regardless of the law.

How to score it, and what each score means

Score one point for every yes. Unsure is a no. Then read the total against the table, and apply the two adjustments below it.

First adjustment: the four knockout questions override the total. A use case with 24 points and no lawful basis for its data is not a 24. It is a stop.

Second adjustment: if any single area scores two or fewer, read your result one band lower. A strong total can hide a weak area, and the weak area is where the project will stall.

AI maturity models, and why a checklist is more useful here

Analyst firms such as Gartner publish AI maturity models, usually with five levels. They run from early experiments, through a first system in production, to AI built into how the whole organization works. An AI maturity assessment against one of them gives a board a shared vocabulary for where the company stands. That has its uses.

For a mid-sized company deciding whether to spend €40,000 on one project, the maturity level is mostly the wrong question. Maturity is an average across the organization. Readiness is specific to a use case. A company can sit at level two overall and be fully ready to automate invoice extraction. That data is clean and that process is stable. The same company can sit at level four and be nowhere near ready for an agent that touches credit decisions.

So use an AI maturity framework for the strategy conversation, if you want one. Use an AI readiness framework like this one for the decision in front of you. If what you need is governance structure rather than a score, the NIST AI Risk Management Framework is free and sensible. It is organized around four functions: govern, map, measure and manage.

A word on online AI readiness assessment tools. Many of them are a form, a score and a sales call. That is fine as far as it goes. But any self-assessment, this one included, can only score what you believe about your company. It cannot open the database.

From checklist to assessment

The weakness of any checklist is that it records what the people in the room believe. 'We have the data' stays a yes until someone opens the table. Then a required field turns out empty in a third of the records.

Our two week AI readiness assessment is this checklist done against the real data. We read a sample of the actual records and sit with the process owner. We check the systems anything would have to integrate with. Then we write down the GDPR and EU AI Act position for each use case. It ends in a written document: a shortlist with expected return, build or buy per use case, an architecture recommendation, and one costed first build.

The fee is fixed at €9,500 to €14,000. If we build what it recommends within six months, on a project above €50,000, the fee comes off the first invoice. If you take the document to another supplier, that is a fair outcome too. And if you scored 21 or more on your own, you probably do not need it. Go straight to a scoped build.