AI Readiness Assessment
Find out what will actually survive contact with production
An inspection of the things that decide whether an AI project works: your data, the access an implementation would need, who owns the workflow, and what happens when the system is wrong. It ends in a prioritised build plan, not a score out of ten.
- Inspection, not a questionnaire
- No production access needed to start
- A plan, not a score
- Who it is for
- Teams about to commit budget to AI who want to know what they are walking into
- What it produces
- A prioritised build plan with dependencies, risks and operating-cost assumptions
- What it is not
- A maturity score, a vendor comparison, or a readiness badge
- Access needed
- Data samples and interviews. Production access is not required to start
What it inspects
The four things that decide whether an AI project lands
Most stalled AI work fails on one of these, and almost always on one that nobody checked before the budget was committed.
The data
Not whether you have a lot of it – whether the specific fields a workflow needs are present, consistent, current, and permitted to be used for this. Samples get inspected, not described.
The access
What systems an implementation would have to reach, whether their interfaces support it, who can grant that access, and how long that decision actually takes in your organisation.
The ownership
Who owns the workflow today, who would own the system, and who decides when the output is wrong. Projects without a named owner do not survive their first disagreement.
The failure modes
What it costs when the system is confidently wrong, who notices, how quickly, and what the recovery is. This is what determines how much review the design needs.
What you get
A document you can make a budget decision from
Written to be taken into a room where money is allocated – which means the assumptions are visible and the recommendations against building are in there too.
- 01
A prioritised build plan
Candidate workflows in the order the dependencies and risks suggest.
- 02
Findings against your data
What the samples support, what they do not, and what would close the gap.
- 03
An access and dependency map
What an implementation touches and whose approval each part needs.
- 04
Risk and failure analysis
What a wrong answer costs per workflow, and the review each needs.
- 05
Operating-cost assumptions
The inputs behind any estimate, so you can test them against your numbers.
- 06
What not to build
The candidates we recommend against, with the reasoning written down.
Scope
What the assessment covers
An assessment is an inspection and a plan. It is deliberately separate from building anything, so its conclusions are not shaped by who would do the build.
Included
- Inspection of data samples for the candidate workflows
- System access and dependency mapping
- Interviews with the people who run the process today
- Failure-mode and review-requirement analysis per candidate
- A prioritised build plan with dependencies and risks
- Operating-cost assumptions written out and testable
- A walkthrough session and one round of clarifications
Scoped separately
- Building anything, including a prototype
- A code audit of your existing systems
- Formal regulatory, legal or security certification opinions
- Vendor selection or procurement negotiation
- Data cleanup or migration work the plan may recommend
- Ongoing advisory after the plan is delivered
Anything on this side is scoped and priced on its own, once the shape of it is clear. Request a scope →
How it runs
Inspection, not a questionnaire
The assessment looks at real artefacts. A survey of opinions about readiness produces a report about opinions.
- 01
Scope call
Which workflows are candidates, what you are hoping to commit to, and what a useful answer would change. This produces a written scope before any invoice.
- 02
Collect the inputs
Data samples – redacted is fine – system documentation, and time with the people who actually run the process today. Named and agreed in the scope, so nothing is a surprise.
- 03
Inspect the data
The specific fields a candidate workflow needs: present, consistent, current, permitted. Where they are not, what it would take to get there.
- 04
Map access and dependencies
What an implementation would need to reach, whose approval that requires, and which dependencies sit outside your team's control.
- 05
Test the failure modes
For each candidate workflow, what a wrong answer costs and who catches it – which decides how much review a design has to carry.
- 06
Deliver the plan
A prioritised sequence with dependencies, risks and operating-cost assumptions written out, plus the candidates we recommend not doing and why.
Against the alternatives
A readiness score tells you nothing. An inspection tells you what will survive production.
The data, the access an implementation would need, who owns the workflow, and what happens when the system is wrong – inspected rather than described, and written up as a plan you can make a budget decision from.
| A free readiness quiz | A vendor's assessment | This assessment | |
|---|---|---|---|
| Based on | Your answers about yourself | Their product's fit | Your data samples, access, ownership and failure modes |
| What you get | A score | A proposal | A prioritised build plan with dependencies, risks and operating costs |
| Who builds afterwards | Nobody | Usually them | Kept separate, so the conclusions are not shaped by who would build |
| What not to build | Not covered | Rarely | Written down, with the reasoning |
Evidence
Ask to see the shape of the output before you commit
No client assessments are published here, and none will be without the client's written approval and their name on it. What you can ask for on a scope call is a walkthrough of the structure the report takes and the kinds of findings each section carries, using an example built from a workflow shape rather than from anyone's confidential material. If the format is not what you need to make your decision, better to establish that before the engagement than after it.
Daniel Rondeau
The person on the call, and the person making the decisions.
Daniel on LinkedIn →Ask on the fit call how a decision like yours has been approached before.
What it costs
No price list. A written scope, agreed before any invoice.
How many candidate workflows are in scope, how many systems and teams they touch, how much of the data can be inspected from redacted samples, and how many people need interviewing. A scope call produces a written scope with a figure attached, agreed before any invoice.
Before you book
The questions that usually come first
How is this different from the free readiness quizzes?
A quiz asks what you think. This inspects what you have – the actual fields in actual samples, the actual interfaces, the actual owner. A score out of ten does not tell you which project to fund; a prioritised plan with dependencies does.
Do we have to give you production access?
No. The assessment is designed to work from redacted samples and interviews. Where deeper access would materially improve a finding, we say so and you decide – it is never assumed.
What if the answer is that we are not ready?
That is a legitimate and common finding, and it is cheaper to hear now. The plan then says what would have to change, in what order, and what could proceed in the meantime – which is more useful than a yes that does not survive delivery.
Are you just going to recommend that we hire you to build it?
The assessment is priced and delivered separately from any build for exactly that reason, and "use an existing tool", "automate this conventionally" and "do not do this yet" are all normal conclusions. You are free to take the plan to anyone.
How long does it take?
It depends on how many workflows are in scope and how quickly the inputs arrive – the scope call sizes it, and the timeline goes in the written scope. The part that usually slips is collecting samples and access on your side, so that gets named as a dependency.
Who needs to be involved from our team?
Whoever actually runs the candidate workflow today, and whoever can speak to system access. Executive sponsorship helps, but the findings come from the people doing the work.
Not the right engagement? The others
Start with a conversation
Find out what you are walking into before you commit the budget
A scope call establishes which workflows are worth assessing and what a useful answer would change. It produces a written scope, not an invoice.
Pick a time that suits you. Or write to daniel@gotai.com