AI data readiness: is the data there, accessible, clean and legal to use?

The most common reason an AI project stalls in month two is not the model but the discovery that its data lives in a spreadsheet on one laptop, behind a system with no API, or under a contract that forbids the use. This is for anyone about to approve a build without having asked those questions first.

Why projects stall on data, not on models

A use case that scores well on value and feasibility still has to be fed. "Feasible" in the scoring session means a model can do the task in principle; ready means this company can get the right records to the model, in time, with permission. Those are different questions, and the second one is where estimates go wrong by a factor of three.

The failure is rarely dramatic. The CRM export exists but is refreshed monthly. The ticket history is there, but 60% of tickets carry the category "other". Each is solvable, and each adds weeks that nobody budgeted because nobody looked.

The four readiness questions

We ask four questions about every data source a use case touches, in this order, because a "no" on an earlier one makes the later ones irrelevant.

1. Does it exist?

Not "does the company have this information" but "is there a record, with a field, that holds it". An urgency level that lives in a support agent's head does not exist for this purpose. If the record has to be created before the automation can read it, the project has a data-entry phase, and that phase belongs on the plan.

2. Can the system reach it?

Existence in a database and availability to an n8n workflow are different things. Ask for the concrete path: an API with credentials, a database user with read access, a Microsoft 365 or Google Workspace connector with the right scopes, a Notion integration with the pages shared. If the honest answer is "someone exports a CSV", the automation has a human in its input path, and its uptime is that person's uptime.

3. Is it clean enough?

Clean enough is relative to the task. A classifier that routes emails tolerates typos in the sender name; a reconciliation step that matches invoice references does not tolerate three formats of the same reference. Pull 50 recent records and look at them with the person who uses them daily. Count blanks, duplicates, free-text fields that should be codes, and dates in more than one format. Ten minutes of looking beats a week of theorizing.

4. May we use it this way?

Personal data under GDPR needs a lawful basis for the new processing, not only for the original collection. Data bought under license often forbids feeding it to a third-party model. Customer contracts sometimes require that data stays inside the EU, which decides which model endpoints are allowed before any technical discussion starts. This question needs a name from legal or compliance attached to the answer, not a shrug.

The constraints that shape the architecture

Readiness says whether the data can be used. Constraints say how, and they usually decide the architecture sketch more than any preference does.

None of these is exotic, until it is found in week six of the build. Rate limits are the favorite: a workflow that runs perfectly on 20 test emails and then hits a 429 on the first real Monday morning.

A worked example: claim emails at an insurance broker

A regional insurance broker with around 80 staff wanted to triage incoming claim emails, pull out the policy number, claim type and incident date, and pre-fill a case in the claims system so a handler starts with a draft instead of a blank form. The readiness check took one afternoon:

• Emails: exist in a Microsoft 365 shared mailbox; reachable through the Graph API once IT granted a mailbox-scoped permission, which took four working days. Clean enough: the model reads free text, so noise is expected.
• Policy records: exist in the policy system, which has a REST API. Reachable with a read-only key. After checking 50 records: policy numbers consistent, customer names in two formats.
• Claims system: on-premise, no API, and the vendor quoted three months for one. Not reachable for writes in any useful timeframe.
• Legal: claim emails contain health and financial details. Processing was covered by the existing claims-handling basis, but company policy required EU-only processing, which ruled out two model providers on day one.

The unreachable claims system changed the design rather than killing the project. Instead of writing a case, the workflow produced a structured summary and a pre-filled form link for the handler, and the "create case via API" step moved to the day-90 column of the roadmap, pending the vendor. That is the normal outcome: readiness rarely says no, it says "not like that".

The readiness scorecard

For each data source, score each of the four questions from 0 to 2 and record who answered. In Hilluter's workshops this is a one-page sheet filled in during the session, and it becomes the first section of the build plan.

• Exists: 0 = not recorded anywhere, 1 = recorded inconsistently or in free text, 2 = a field in a system.
• Reachable: 0 = manual export only, 1 = access possible but not yet granted, 2 = credentials in hand and tested.
• Clean enough: 0 = unusable without a cleanup project, 1 = usable with validation rules, 2 = usable as-is for this task.
• Permitted: 0 = unclear or forbidden, 1 = permitted with conditions (residency, retention, consent), 2 = permitted and confirmed by a named person.
• For every score below 2, one line: what would move it to 2, who owns that, and by when.

A source that totals 8 is ready. A source at 5 or 6 goes ahead with the fix on the plan. Anything under 5 is a data project in disguise, and it is cheaper to call it that now. If you want a second pair of eyes on a use case, describe the data it needs and we will send back the questions we would ask first.