Ask ten suppliers what makes an organization ready for AI and you will get ten lists. Most of them are the same list with different headings, and the differences matter less than the discipline of having one and applying it consistently.
This is ours. Seven dimensions, used in the same order every time, in our assessments, in our reports and in the self-assessment on this site. The value of a framework is not that it is uniquely correct. It is that it is exhaustive enough that nothing important gets skipped, and stable enough that a score means the same thing next year as it does today.
What follows is what each dimension covers, why it is separate from the others, and what a weak result in it actually costs you.
1. Strategy and leadership
What the organization is trying to achieve, who owns that objective, and whether there is money and a decision maker attached to it.
This is first because it changes every other answer. Without an agreed objective there is no basis for choosing between candidate use cases, no way to say whether a pilot succeeded, and no defensible account of the purchase afterwards. Without a named owner who can stop work as well as start it, pilots drift into production by default.
Weakness here is cheap to fix and expensive to leave. It usually takes a page of writing and one meeting, and organizations routinely spend six figures rather than hold that meeting. If you are at this stage, how to build an AI strategy covers what that page should contain.
2. AI use cases
Specific candidate processes, tested for business value, mission impact, feasibility, risk and expected return.
A use case is not a capability. "Document summarization" is a capability; "producing first drafts of the responses our records team sends to routine requests" is a use case, because it names a process, a team and a volume. Only the second can be assessed, scoped or measured.
This dimension is separate from strategy because organizations frequently have one without the other. A body with a clear objective and no candidate processes will buy a platform and then look for something to do with it. A body with a long list of ideas and no objective will do the most enthusiastic one rather than the most valuable.
Weakness here shows up as a pilot that works technically and changes nothing.
3. Data readiness
Quality, accessibility, ownership, classification, governance and integration, across structured records and the knowledge repositories staff actually rely on.
This is the dimension that most often decides the outcome, and the one organizations most often assume is fine. The questions are ordinary: does the information exist somewhere a machine can read, is it current, is there a single authoritative version, who owns it, who may grant access to it, and is it labelled well enough to be found.
The unstructured side matters as much as the structured side. Policies, procedures, prior correspondence and institutional knowledge are exactly what a knowledge assistant would draw on, and they are usually scattered across drives with no owner and no review date.
Weakness here is the most expensive kind, because it is invisible until the tool is producing answers and nobody can tell whether they are right.
4. Technology and infrastructure
Cloud and on-premises environments, network capacity, APIs, application integration, identity systems, content platforms, and the ERP, student information or CRM systems holding the records in scope.
Two questions dominate. Can the systems holding the relevant information be read through a documented interface or a supported export, and can identity be managed centrally so access is granted and revoked in one place. A line of business application with neither is a hard constraint, and discovering it after a platform has been selected is the most common avoidable cost in this work.
The third question is running cost at realistic volumes. Pilots are cheap because usage is low; the figure that matters is the one after the tool becomes useful.
5. Cybersecurity and privacy
Identity and access controls, sensitive data exposure, data loss risk, AI-specific attack surface, privacy obligations, logging, monitoring, third-party AI services and shadow AI.
An AI service inherits the permissions of whoever runs it, so broad access becomes broad exposure the moment one is introduced. This dimension asks whether access is already scoped to what each role needs, whether you can see what is being sent to and returned from AI services, and whether you know which services staff are already using.
It also covers the risks that are specific to these systems rather than inherited from ordinary IT. The National Institute of Standards and Technology maintains a taxonomy of adversarial machine learning attacks that is a reasonable place to start on what is genuinely new here, and its AI Risk Management Framework is the reference most public bodies will be asked about. We cover the practical version in AI cybersecurity risks to assess before deployment.
This is a readiness dimension, not a security audit. A low score here means the exposure has not been examined, not that a breach has occurred.
6. Governance and compliance
AI policy, acceptable use, oversight, procurement procedures, vendor risk, records retention, data governance, compliance obligations and human oversight.
Governance is the dimension organizations score lowest on and are most surprised to learn matters this early. The instinct is to establish it after a tool is chosen, which is exactly backwards: the point of a governance position is to inform the choice.
It does not need to be heavy. A named approver, a written acceptable-use position staff have actually seen, AI questions added to the supplier review you already run, and a decision about which outputs require a human before they take effect. That is a proportionate starting set for most organizations, and it is far more than most have.
Weakness here is what turns an individual mistake into an institutional one, because there is no record of who decided what.
7. Workforce and adoption
AI literacy, training, adoption, skills gaps, change management, role impact and user support.
This is the dimension most often left out of a plan and the one that decides whether the deployment is still in use in a year. A tool whose output nobody is competent to check is either trusted blindly or quietly abandoned, and the second failure is expensive precisely because nothing announces it.
The useful questions are whether the people who would rely on the output could recognize a wrong answer, whether training has been aimed at their actual work rather than delivered as general awareness, whether affected staff have been talked to before launch rather than after, and whether there is somewhere to raise a problem.
Why seven, and what happened to the eight
Earlier LABUSA writing on this subject used an eight dimension model that separated process readiness and application readiness. We have consolidated deliberately, and the substance did not change.
Process readiness, which asked whether a candidate process was documented and consistent enough to automate, is now assessed inside use cases, because in practice it is a feasibility test on a specific candidate rather than an independent property of the organization. Application readiness, which asked whether the systems holding the data could be integrated, is now assessed inside technology and infrastructure, where it always belonged: the question is the same question, and splitting it produced two scores that moved together.
The reason for consolidating is that a framework people can hold in their heads gets used, and one that cannot does not. Seven is at the edge of that. Nothing that was assessed before is unassessed now.
How the dimensions are scored
Each dimension is scored on its own, from zero to one hundred, and the overall figure is the unweighted mean of the seven.
Unweighted is a deliberate choice. Which dimension binds depends entirely on the organization: a district with excellent data and no governance and a county with clear governance and unreachable data are both blocked, and neither is more blocked than the other. Weighting the average would encode an assumption about which of them matters more, and that assumption would be wrong roughly half the time.
The consequence worth understanding is that a middling overall score can hide a severe gap. An organization scoring seventy overall with one dimension at fifteen is not seventy percent ready; it is blocked, and the seventy is misleading. That is why every report we produce leads with the per-dimension scores and treats the overall figure as a summary rather than a finding.
Using the framework
You can apply this yourself. The AI readiness checklist for public-sector organizations turns the seven dimensions into questions you can work through with your own team, and ten questions to ask is the shorter diagnostic version for a first conversation.
The AI Readiness Self-Assessment scores you across all seven in about eight minutes and returns recommendations for wherever you scored lowest. It is an informational benchmark based on your own answers, not a verified assessment, and the results page says so.
Where the answers matter enough to be checked rather than self-reported, the seven dimensions LABUSA assesses are examined against the evidence: your systems, your records, your policies and the people who would use the output. That produces a written report and a roadmap. If you want to see what comes after one, what happens after an AI readiness assessment follows the thread.