AI Readiness Audit
We review the proposal, not the technology.
What is AI readiness audit?
An AI readiness audit is an independent review of a proposed AI project, testing whether the data, systems and staff capacity it assumes actually exist, and producing a written verdict a board can act on.
Every proposal rests on three assumptions it rarely states. The data exists and is usable, the systems can be connected, and somebody will have time to run the thing once it is built. Proposals are written as though all three are settled.
The data assumption fails most visibly. Data usually does exist somewhere, in a form nobody has tried to use, with gaps that only appear when somebody actually tries, which is normally three months into a project.
The capacity assumption fails most expensively. The person who would run this already has a full job, and a system that needs an hour a day from somebody who does not have an hour a day quietly stops being used.
The proposals we will not review
Duara carries out independent readiness audits in Kenya for organisations weighing an AI proposal.
We will not audit a proposal we wrote. Reviewing our own work and calling it independent would make the report worthless, and a board is entitled to a reviewer with nothing riding on the answer.
Who this is for
- A supplier proposal is on the table
- A board wants review before funding
- A previous project failed for unclear reasons
- Internal opinion is divided about whether to proceed
Industries we serve
- Banking and financial services
- Manufacturing
- Insurance
- Public sector
- Large retail
- Any organisation funding an AI project
Problems this solves
These are the assumptions proposals make silently and that audits exist to test.
- The data is assumed usable. It usually exists somewhere in a state nobody has tested, and the gaps surface months into a build rather than before it.
- Integration assumed possible. Whether your systems can be connected at all is treated as a detail, and it occasionally decides the entire approach.
- Capacity assumed available. The person who would run this already has a full job, which is how systems get built and then quietly abandoned.
- No independent view. The only people who have assessed the proposal are the ones who wrote it and the ones who want it approved.
What we deliver
An independent test of each assumption against what actually exists, with a plain verdict on whether the proposal is supportable and what would have to change first.
A verdict on whether the proposal is supportable
The assumptions that do not hold
The real state of the data it depends on
What would need fixing first, with effort estimated
A written report a board can read
A clear recommendation, including not to proceed
Features
- Assumptions tested, not accepted. Each one checked against what exists rather than against what the proposal says about it.
- Data examined in its actual state. Not whether it exists but whether it is usable, which is a question nobody asks until a build is underway.
- Capacity treated as a constraint. Whether anybody has time to run this, since that is what determines survival after launch rather than at it.
- Written for a board. A report readable by people who will not open a technical annex, because they are the ones deciding.
- Independence protected. We decline audits of proposals we wrote, since a review with something riding on the answer is not a review.
Benefits
- Money committed with eyes open. The assumptions are visible before funding rather than after, which is the only point at which they are cheap to address.
- Failures explained. Where a previous project failed, the audit usually finds the assumption that broke rather than the technology that was blamed.
- Boards can decide. A plain verdict lets a board approve or decline on the facts rather than on which internal party argued more confidently.
- Fixable problems get fixed first. Knowing what has to change before starting turns a doomed project into a delayed one.
What the audit examines
- Data state. What exists, in what condition, with what gaps, tested rather than described.
- System connectivity. Whether the systems involved can actually exchange data, and what it would take.
- Operating capacity. Who would run this and whether their week contains the time it requires.
- Skills available. Whether the organisation can maintain what is proposed, or would depend on the supplier indefinitely.
- Process fit. Whether the work actually happens the way the proposal describes it happening.
- Cost realism. Whether the running cost has been estimated at all, since proposals frequently price the build alone.
The capacity question is the one boards find most uncomfortable and the one that predicts outcomes best. A system nobody has time to operate is not a technology problem and cannot be fixed by better technology.
How the process works, step by step
A readiness audit usually takes two to four weeks, which is short compared with what it is reviewing.
-
Step 1
Scoping
We agree what is being reviewed and what a useful answer would look like for the people deciding.
-
Step 2
Evidence gathered
Systems, records and how work is really done, rather than how it is documented as being done.
-
Step 3
Assumptions tested
Each one checked against what exists, particularly data state and available capacity.
-
Step 4
Verdict formed
Supportable, supportable after specific changes, or not supportable, said plainly.
-
Step 5
Report delivered
Written for the board, with the effort of any prerequisite work estimated.
Quality assurance and how we work
The commitments attached to a report somebody will use to spend money.
- We will not audit our own proposal. A review with something riding on the answer is not a review, and a board deserves better than that.
- We will recommend against proceeding. An audit that always concludes proceed with modifications is not an audit, and that answer has to be genuinely available.
- We report on assumptions, not on motives. We can tell you which assumptions do not hold. We cannot tell you what a supplier knew when they wrote it.
- A clean result is a real result. Sometimes the proposal holds up, and paying to establish that is not a wasted fee.
- We write for the people deciding. A report only a technical reader can follow has failed, because the decision is being taken by somebody else.
Frequently asked questions about AI readiness audit
What does a readiness audit actually check?
Whether the organisation can support what is being proposed. That is a different question from whether the technology works, and the one proposals skip.
Which assumption fails most often?
Data state. It usually exists somewhere in a condition nobody has tested, and the gaps appear three months into a build.
Which failure is most expensive?
Capacity. The person who would run it already has a full job, and a system nobody has time to operate is quietly abandoned.
Can the audit conclude we should not proceed?
Yes, and that answer has to be genuinely available. An audit that always says proceed with modifications is not an audit.
Would you audit a proposal you wrote?
No. Reviewing our own work and calling it independent would make the report worthless to whoever relies on it.
Can you tell us if a supplier is overselling?
We can tell you which assumptions do not hold. What the supplier knew when they wrote it is not something an audit can establish.
What if the proposal turns out to be sound?
Then you have confidence you did not have, which is a legitimate outcome rather than a wasted fee.
How is this different from your readiness assessment?
That is the first step of a project we would run. This is independent review of somebody else proposal, with no involvement in what follows.
Who is the report written for?
The people deciding. A report only a technical reader can follow has failed, whatever it contains.
How long does the audit take?
Two to four weeks, which is short compared with the commitment it is reviewing.
How much system access does an audit need?
Enough to test the assumptions, which usually means configuration, data samples and conversations rather than full access.
Will staff be interviewed?
Yes, because how work actually happens differs from how it is documented, and that gap is frequently where a proposal breaks.
Can it explain why a past project failed?
Often. The failed assumption is usually still visible, and it is rarely the technology that was blamed at the time.
Does it estimate what fixing things costs?
Yes, in effort terms, since a board needs to weigh the prerequisite work against the project itself.
Is running cost part of the review?
Yes. Proposals frequently price the build alone, and the running cost is what determines whether the thing survives.
Do you check whether we could maintain it?
Yes. Depending on a supplier indefinitely is a legitimate choice, and it should be a choice rather than a discovery.
Can this run before we select a supplier?
Yes, and it is arguably better placed there, since the findings then shape the requirement rather than judge a response to it.
What if internal opinion is divided?
That is a common reason to commission one. A plain verdict on the facts settles arguments that seniority otherwise decides.
Who sees the report?
Whoever you decide. It contains an assessment of your own weaknesses, so distribution is usually kept narrow.
What does a readiness audit cost?
Scope and the number of systems involved determine it, quoted after scoping and before any work begins.
Glossary of terms
Audit terms in plain language.
- Readiness
- Whether the organisation can support a system, as distinct from whether the system can be built.
- Assumption
- Something a proposal treats as settled without testing, of which most contain several.
- Data state
- The actual condition of data, including gaps that only appear when somebody tries to use it.
- Operating capacity
- Whether anybody has the hours a system requires once it is live.
- Independent review
- An assessment by somebody with nothing riding on the outcome.
- Prerequisite work
- What has to be fixed before a proposal becomes viable, which is often the real deliverable.
Related services in AI Audit Services
Talk to us about AI readiness audit
Take the proposal on your desk and find the sentence that assumes the data is ready. Then ask who has tested that.
Start your project