What does an AI readiness assessment actually check?

A serious AI readiness assessment checks five domains: data, infrastructure, governance, people and evidence. It establishes where your data lives and whether you can lawfully use it, where inference can physically run, who approves models and owns decisions, which workflows will change, and whether you can prove afterwards what the AI did. Anything narrower is a use-case workshop, not an assessment.

The question matters in 2026 because the EU AI Act's high-risk obligations now bite on 2 December 2027 after the Digital Omnibus deferral, DORA has applied to financial entities since 17 January 2025, and boards are being asked to show diligence before deployment rather than after an incident.

What should an assessment check about our data?

Three things, in order. Where the data physically lives, including the copies nobody owns: exports, shared drives, vendor backups. Whether its quality supports the intended use, because a model retrieving from a contradictory document store produces confident nonsense. And whether there is a lawful basis to process it for the new purpose, because adopting AI often amounts to processing for a new purpose, and purpose limitation under GDPR applies to inference as much as to storage.

The output of this domain is a data map with named owners, not a slide listing data sources nobody has inspected.

What should it check about our infrastructure?

Where inference can physically run. That means an honest audit of compute, including whether existing CPUs can carry drafting, extraction and retrieval workloads, because inference should be selectable between CPU and GPU rather than assumed to need accelerators. It means network segmentation: whether a zero-egress enclave is possible, which routes lead out of the building, and who can open new ones. And it means placement: which sites can host hardware, and which workloads must never leave a given jurisdiction.

What does the governance domain actually cover?

Decision rights. Who approves a model for use, who signs off a version change, who owns the output of an AI-assisted decision, and what gets logged when each of these happens. An organisation with strong model governance can answer in names, not committees. The assessment also checks the escalation path: what happens when the AI is wrong, who is empowered to say so, and whether that event leaves a record. ISO/IEC 42001 offers a usable management-system frame, though certification is not the same thing as control.

Why do people and workflows belong in a technical assessment?

Because AI fails at the handover points. The assessment maps which roles will consume AI output, whether they can evaluate it, and which workflows change shape rather than merely speed. It looks for the competence a reviewer needs to overrule a system, since human oversight without competence is theatre. It also looks for the quiet risk: staff already pasting regulated data into public cloud services such as ChatGPT, Claude or Gemini because no sanctioned alternative exists. An assessment that has not surfaced shadow use has not looked.

What is the evidence domain, and why start there?

Evidence is the ability to prove afterwards what the AI did: which model version ran, on which inputs, producing which output, reviewed by whom. Most assessments treat this as a compliance footnote. A regulated-sector assessment starts here and works backwards, because the evidence requirement determines the architecture. If logs must be tamper-evident and reviewable for years, that constrains where inference runs, how versions are pinned and how records are sealed. We apply a named test here, the year-two test: pick any AI output your organisation produced this week and ask whether the full decision record for it could be produced two years from now to a regulator, a court or an auditor. If the answer depends on a vendor's goodwill, the answer is no.

“An organisation is ready for AI when it can prove afterwards what the AI did, and not before.”

How is this different from the assessments most vendors sell?

Most AI readiness engagements are use-case brainstorming: a workshop, a heat map of opportunities, a maturity score. These have a place, but they test appetite, not readiness. They rarely touch lawful basis, seldom inspect network egress, and treat evidence as someone else's problem. The regulated-sector version inverts the order: it begins with what the organisation must be able to prove, then asks what data, infrastructure, governance and skills make that proof possible. The use cases fall out of that analysis with their risks already understood.

What should the output look like?

Five artefacts, one per domain: a data map with owners and lawful bases; an infrastructure plan showing where inference runs and what egress exists; a governance charter written in names; a workforce and workflow plan; and an evidence architecture stating how every AI decision will be logged, sealed and verified. We run structured AI readiness assessments on exactly this five-domain model, and we hold the evidence domain to the standard we build to ourselves: Mickai is a Sovereign Intelligence Operating System that runs offline on operator-owned hardware, with every action sealed to a post-quantum signed audit ledger.

How the wider system fits together is set out at /sovereign-ai, and the film at /film shows the interface in operation.

Frequently asked questions

How long does an AI readiness assessment take?

It scales with organisational complexity rather than headcount. The data and evidence domains dominate the timeline because they require inspection rather than interviews. A focused engagement on a single regulated workflow moves faster than an enterprise-wide review, and we scope each assessment to the decision the buyer actually needs to make.

Do I need an AI readiness assessment before buying any AI system?

Before anything intended to touch regulated data or consequential decisions, yes. An assessment done first prevents the common failure, where a system is chosen for capability and then blocked by lawful basis, egress or evidence problems that were knowable in advance. For low-stakes internal experimentation, a lighter review of the data domain may be proportionate.

What questions should I ask a vendor offering an AI readiness assessment?

Ask which domains it inspects, whether it examines network egress, whether it tests lawful basis for each data source, and what evidence architecture it recommends. Ask to see the artefact list before signing. If the deliverable is a maturity score and a use-case heat map, it is a workshop, whatever the engagement is called.

Can we run the assessment ourselves?

Partly. An internal team can build the data map and the governance charter with honest effort. The infrastructure and evidence domains benefit from an external eye, because egress routes and log integrity are exactly where familiarity breeds blind spots. The named tests travel well: any organisation can apply the year-two test today without outside help.