Free assessment

AI Readiness & Delivery Assessment

Most AI projects do not fail on the model. They fail because nobody could name the decision it was meant to change, because the data had no owner, or because the team needed three weeks to ship a one-line prompt fix. This asks the 23 questions that separate those outcomes — and tells you where you actually stand.

  • 23 questions, 5 domains
  • About 8 minutes
  • No sign-up, no email to see your report
  • Scored in your browser

Start the assessment

23 questions across five domains, roughly eight minutes. No account, no email, and nothing is submitted — the scoring runs in your browser, so your report appears without a single request reaching us. Your answers are saved locally, so a refresh will not lose them.

What the assessment asks, and why

Every question is printed below before you answer anything. None of them ask whether a policy or an intention exists, because every organisation answers yes to that. They ask what happened last time, how long it took, or where the thing physically is — questions with an answer the respondent knows and cannot easily fudge.

1. AI use-case readiness

The single most reliable predictor of an AI project that never ships is that nobody can name the decision it changes. This domain tests whether there is a specific, recurring, measurable job to be done — and whether anyone has thought about what happens when the model is confidently wrong.

  • Name the decision the AI would make or inform. Which is closest?

    Why it matters: This is the strongest single disqualifier in the whole assessment. A project that cannot name the decision has no boundary, so it cannot be scoped, estimated or finished.

  • How is that job done today, before any AI is involved?

    Why it matters: Without a baseline there is nothing to compare the system against, so 'better' becomes a matter of opinion and the project can never be declared successful.

  • What number would tell you this worked, six months after launch?

    Why it matters: A success measure agreed after launch is negotiated against whatever was actually built. Agreed before, it is a specification.

  • When the model is confidently wrong, who is affected and what happens next?

    Why it matters: What a system does when it does not know is a product decision, and one of the few that cannot be deferred: the default behaviour of a language model is to answer anyway.

2. Data readiness

Most stalled AI projects die here rather than on the model. The data turns out to live in four systems and two spreadsheets, nobody owns its quality, there are no labelled examples of a correct answer, and the question of whether it can lawfully be used for this new purpose has never been asked.

  • The data this system would need — where is it right now?

    Why it matters: Data spread across spreadsheets, PDFs and inboxes is not an integration problem, it is a project of its own, and it is routinely priced as if it were a week's work.

  • Who owns that data — meaning whose job it is to fix it when it is wrong?

    Why it matters: Unowned data does not get fixed, so its quality problems arrive as model problems and get debugged in the most expensive possible place.

  • For the outcome you want the system to produce, how many correct examples could you assemble this month?

    Why it matters: The evaluation set is the deliverable — the retrieval pipeline is just code around it. Without correct examples you can demonstrate a system but you cannot measure one.

  • Has anyone checked that this data may lawfully be used for this new purpose?

    Why it matters: This question is cheap to answer at the start and extremely expensive to answer late, because the answer can invalidate the architecture rather than just the paperwork.

  • If a record went to a third-party model provider today, what would go with it?

    Why it matters: Whole records get sent because sending the whole record is easier than choosing fields. That is how personal and confidential data ends up in a prompt nobody reviewed.

3. EU AI Act exposure

The Act is not one rule, it is a set of duties that attach differently depending on whether you are a provider or a deployer and which risk tier the system falls into. Most teams building ordinary internal tools land in limited or minimal risk — which is not the same as no obligations. The transparency duties in Article 50 apply to a great deal of ordinary software, and the record-keeping needed to answer 'what did the system do last Tuesday' has to be designed in, not retrofitted.

  • For the system you have in mind, are you the provider or the deployer?

    Why it matters: The two roles carry different obligations, and the line moves — fine-tuning a model or putting your name on the output can turn a deployer into a provider without anyone deciding to.

  • Which risk category does the intended system fall into?

    Why it matters: Almost everything else follows from the tier. It is also the question an enterprise procurement form asks first, and 'we assume minimal because it is internal' is not an answer that survives review.

  • Where a user sees AI-generated or AI-assisted output, what tells them so?

    Why it matters: Article 50 transparency duties reach a lot of ordinary software, and they are cheap to satisfy while the interface is being designed and awkward to retrofit afterwards.

  • A customer complains about a harmful or plainly wrong output from last Tuesday. Could you reconstruct what happened?

    Why it matters: Reconstruction has to be designed in. The records that make an incident explainable — inputs, model version, prompt version, output — are exactly the ones nobody retains by default.

4. Engineering delivery

AI features are ordinary software with an unusually high change rate. Prompts, model versions and retrieval settings all move, and every one of those movements is a deploy. A team that takes three weeks to ship a change cannot iterate on a model that changes underneath them — so delivery maturity sets the ceiling on how good the AI work can get.

  • How long from a merged pull request to that code running in production?

    Why it matters: This one number predicts more about a team's ability to build an AI feature than any statement about methodology. Prompt and model changes need many small corrections; each one costs a deploy.

  • Who can deploy to production, and what do they have to do?

    Why it matters: A deploy that only two people can perform is an availability risk and a security one — manual steps are where production credentials end up on someone's laptop.

  • When a change breaks something a customer relies on, what usually catches it first?

    Why it matters: Where the safety net sits determines the cost of a mistake. Caught in CI it costs minutes; caught by a customer it costs the relationship as well as the fix.

  • A release goes out at four in the afternoon and it is wrong. What happens?

    Why it matters: A rollback nobody has rehearsed is a belief, not a capability. The teams that ship fastest are the ones that can undo a change cheaply, not the ones that are most careful.

  • The last time production broke, how did the team find out?

    Why it matters: AI features fail by degrading rather than by throwing exceptions, so a system that only watches for errors reports green while the output quietly gets worse.

5. Security in the build

A light touch on purpose — this is not a full security assessment. It asks the four or five things that reliably predict how a build will fail: where the secrets are, how fast you could rotate one, how quickly a dependency patch reaches production, where the authorisation rule lives, and what happens when a language model reads text somebody else wrote.

  • Where are your production credentials and API keys right now?

    Why it matters: Model provider keys are billable, so a leaked one is a direct financial loss as well as a data one, and they are the newest keys in the estate with the least established handling.

  • If one of those keys leaked this afternoon, how long to rotate it everywhere it is used?

    Why it matters: The incident is not the leak, it is the rotation you cannot perform. Teams that cannot rotate quickly end up choosing between an outage and leaving an exposed credential live.

  • A critical vulnerability lands in a dependency you use. How long until the patched version is in production?

    Why it matters: Dependency updates only count as a security practice if you can ship them the same week — which makes this a delivery question wearing a security hat.

  • Where is the rule that decides whether this user may see this record?

    Why it matters: Authorisation repeated per endpoint drifts, and the endpoint written in a hurry is the one that omits the check. Centralised, it can be tested; scattered, it can only be reviewed.

  • If your AI feature reads content a user or third party controls, what stops that content from issuing instructions?

    Why it matters: Prompt injection is an authorisation bug: untrusted text becomes instructions and the model calls a tool with the application's privileges instead of the user's. Filters at the prompt layer do not fix a privilege problem.

How the score is calculated

A score a reader cannot interrogate is a magic number. Here is the whole method, including the judgement calls, so you can disagree with it knowingly.

Every answer is worth 0 to 3
Each of the 23 questions has four answers on a fixed scale: 0 when the practice is absent, 1 when it happens but depends on someone remembering, 2 when it is done deliberately with a known weak spot, and 3 when it is engineered and would survive its author leaving. The same scale is used everywhere, which is what makes the domains comparable.
A domain score is a simple percentage
Points earned in that domain, divided by the points available, expressed as a percentage. No weighting between questions: we could not defend a claim that one of these questions is 1.4 times more predictive than another, so we do not make one.
The overall score is the average of the five domains, not the total
The domains hold four or five questions each, purely because of how many good questions we found to ask. Adding raw points would weight the five-question domains higher for no reason worth defending. Averaging the percentages makes each domain worth exactly one fifth. If you disagree with that choice, your domain scores are all shown separately and you can weight them yourself.
The bands are thresholds, not a curve
Below 30% is At risk, 30-54% is Early, 55-79% is Developing, 80% and above is Strong. These are not percentiles against other companies — we would need a benchmark sample to claim that, and inventing one would be exactly the sort of unfalsifiable number this report exists to avoid.
The questions are behavioural on purpose
No question here asks whether a policy or an intention exists, because every organisation answers yes. They ask what happened last time, how long it took, or where the thing physically is. Those have answers the respondent knows and cannot easily fudge — which also means an honest low score here is more useful to you than a flattering high one.
What this is not
It is a structured conversation, not an audit. It relies entirely on your own answers, it cannot see your codebase, and it is not legal advice — the EU AI Act section will tell you which questions to get answered properly, not what the answers are.
The four score bands, their ranges and what each one means
BandRangeWhat it means
At risk029%The practice this measures does not meaningfully exist yet.
Early3054%It happens, but it depends on specific people remembering.
Developing5579%Done deliberately, with weak spots you could name.
Strong80100%Engineered, and it would survive the person who built it leaving.

What happens to your answers

While you take the assessment, nothing leaves your browser. The questions and the scoring both run client-side, your answers are kept in this browser’s local storage so a refresh does not lose them, and your report is produced without a single request reaching us. If you close the tab now, we never knew you were here.

If you afterwards ask for the report by email, we store the address you gave, an optional name and company, your five domain scores and the multiple-choice answers that produced them — because the emailed report and any conversation about it are about those specific answers. We do not store your IP address, your user-agent, your referrer or any tracking parameters, and there is no free-text field anywhere in the assessment for anything else to hide in.

Giving us an address is consent to send you that report, and to arrange the review if you asked for one. It is not consent to marketing. That is a separate, unticked box with its own wording, and if you leave it alone you will hear from us once.

Records held with no follow-up requested are deleted after twelve months. You can ask for yours sooner.

Questions about the assessment

Do I have to give my email address to see the results?
No. The report is scored in your browser and shown in full the moment you finish. There is an email form underneath it, but it exists to send you a copy of what you have already read — not to unlock it.
How long does the assessment take?
About eight minutes for 23 questions across five domains. Your answers are saved in your browser, so you can close the tab and come back.
How is the score calculated?
Every answer is worth 0 to 3 points. A domain score is the points earned divided by the points available, as a percentage. The overall score is the average of the five domain percentages rather than a points total, so each domain counts equally regardless of how many questions it holds. The full method is published on the page.
Is this a compliance audit or legal advice?
No. It relies entirely on your own answers and cannot see your systems. The EU AI Act section tells you which questions you need answered properly and by whom; it does not tell you what the answers are.
What do you do with my answers?
Nothing at all unless you ask for the report by email. If you do, we store the address, your scores and your multiple-choice answers so we can send it and talk about it. No IP address, no user-agent, no tracking parameters, and there are no free-text questions.

Privacy and cookie preferences

We use strictly necessary cookies to run the site. Analytics, marketing, and AI assistant telemetry are optional and disabled until you choose. You can update consent any time in Cookie Settings.

Some infrastructure cookies, such as load balancer routing cookies, are essential for service delivery. Details: Cookie Policy