AI Readiness Audit
An AI readiness audit is a fixed-scope assessment that determines whether your organisation can actually deploy AI, and where it would pay off first. Over three to four weeks we examine your real data under NDA, test the assumptions the shortlist depends on, then hand back a ranked list of use cases — each with an estimated cost, effort, and expected return — plus a candid list of the things blocking you. It ends in a decision, not a strategy deck.
The problem
Eleven ideas and one budget
Every function has brought a proposal, and none of them are comparable
Marketing wants content generation, support wants an assistant, finance wants invoice processing. Each is plausible, each has a senior sponsor, and there is no shared basis on which to say no to any of them — so the decision defaults to whoever is most persuasive in the room.
The pilot that has been nearly ready for five months
Something got built. It demoed well. It is still not in production, and the reason changes depending on who you ask: the data team says access, the vendor says scope, the business owner says it never quite did what was described. Nobody has established which of those is actually true.
You are comparing quotes for work nobody has scoped
Three vendors have priced a build having never seen your data. The proposals use different assumptions, cover different amounts of the problem, and none of them states what it costs to keep running once it is live. Choosing between them is currently a matter of taste.
What a real fix takes
The blocker is almost never the model. It is a customer identifier that means two different things in two systems, a process whose exceptions outnumber its rules, or a system of record that will not accept a write from anything but its own interface. An assessment that only reads documents and interviews people misses all three, because everyone describes the process as it is documented rather than as it runs. The work has to touch the actual data, and it has to include at least one conversation with the person doing the job.
Outcomes
What changes by week four
You stop guessing which use case to fund first
Scoring the handful of AI ideas circulating in your organisation against one framework ranks them, and disagreement about priorities usually dissolves once everyone is looking at the same scoring rather than at competing pitches.
You find out what is actually blocking you, early
Data sitting in three systems that disagree, a process nobody has documented, an integration everyone assumed was possible. Finding these in week two costs a fraction of finding them in month five.
You get a defensible business case
Each recommended use case comes with a build estimate, a run cost, an expected effect on a metric you already track, and the assumptions behind that estimate written down. That is what a CFO needs, and it is what most AI proposals do not have.
You can compare vendor proposals on the same basis
With a scoped architecture and a stated run cost in hand, three quotes become comparable — including ours, which you are under no obligation to accept.
What we build
The assessment itself
Most assessments in this category are interviews written up. This one is hands-on: the two items below are where the verdict actually gets decided, and they are the reason the engagement takes weeks rather than days.
Hands-on examination of your real data
Not a questionnaire. We work with representative samples under NDA and look at what is actually in them — field completeness, definitional consistency between systems, volume, history depth, and whether outcomes were recorded in a way anything could learn from. Most readiness verdicts are settled here, and this is routinely the point at which a use case everyone was confident about stops being viable.
Feasibility tests on load-bearing assumptions
Where a use case depends on something uncertain, we test it during the audit rather than assume it and discover it later: a retrieval test against a sample of your documents, a classification baseline on historical records, an API call against the system that supposedly accepts writes. A small number of tests, each chosen because the answer changes the recommendation rather than because it is interesting.
Structured discovery across three levels
Process owners, technical leads, and at least one person who does the work daily. That last group is non-negotiable; the gap between how a process is documented and how it runs is where AI projects die.
Consistent scoring and cost modelling
Every candidate through the same framework, with build and run costed separately and the assumptions written down so they can be challenged.
A challenge session before the ranking hardens
Your team argues with the emerging conclusions mid-engagement, while there is still time for that to change them.
What you receive
Four artifacts, all yours to keep
Everything is written to be read by executives and engineers alike, and deliberately written so another firm could execute from it. An audit that only makes sense if you hire the auditor is not an audit.
Feasibility test results
Where a use case depends on an assumption nobody can confirm, we test it rather than assume it, and you get the results either way: a retrieval test against a sample of your documents, a classification baseline on your historical records, an API call against the system that supposedly accepts writes. Each test is written up with what was run, what came back, and what it means for the recommendation. Where something failed, that is reported as plainly as where it worked.
Assessment and findings
What data you hold, where it lives, its quality and completeness, who owns it, and specifically what would need to change for each recommended use case to be feasible — lineage gaps, contradictory definitions between systems, history depth, and whether outcomes were actually recorded. Alongside it, the systems picture: integration points any AI system would need and the constraints they impose, including API limits, latency, authentication, and whether the system of record can accept a write at all. This is where "we'll integrate with the CRM" turns out to mean six weeks of work or two days.
Use case register
Every candidate identified during discovery, scored and ranked against a consistent framework — data availability, technical feasibility, process fit, measurable value, change cost. The ones we recommend against are included with the reasoning stated. The rejected list is often the most useful page in the document, because it is the one that settles arguments.
Recommended approach and roadmap
For the top-ranked use cases: a concrete recommended technical approach with the services and model types it would use, a build-versus-buy call, and an indicative run cost at your projected volume — indicative because real run cost depends on usage patterns that only production reveals, and any figure presented as precise before a build is a guess wearing a suit. With it, a sequenced 6–12 month plan and a scoped first engagement, enough to start without a second discovery.
How it works
Four weeks, checkpointed
- Week 1
Discovery
Structured interviews with process owners, technical leads and the people doing the work. We also inventory systems and request data samples under NDA.
- Week 2
Technical assessment
Hands-on examination of data quality and volume, integration feasibility, and existing infrastructure. Feasibility spikes run here.
- Week 3
Analysis and modelling
Scoring, cost modelling, and the recommended technical approach. A mid-week checkpoint with your team to challenge the emerging ranking before it hardens.
- Week 4
Delivery
Written report, a working session with your leadership, and the scoped first engagement. We walk through the recommendations we rejected as carefully as the ones we made.
Four weeks is typical. Two to three is achievable for a single department with clean systems. Enterprises with many disconnected systems or several business units run longer, and we say so before starting rather than discovering it midway. The phase that most often surprises clients is week two, because the data usually turns out to be in worse condition than the people responsible for it believe — not through negligence, but because nobody has had reason to look at it this way before.
Technology
Technology we assess against
The landscape we assess against, not a stack we sell. Naming a platform here means we evaluate it on its merits for your case — not that we hold a partnership, certification or reseller arrangement with its vendor.
Model providers: OpenAI, Anthropic, Google, plus open-weight options including Llama, Mistral and Qwen where data residency, cost at volume, or fine-tuning control favour self-hosting.
Infrastructure: AWS Bedrock and SageMaker, Google Vertex AI, Azure AI Foundry, and self-hosted inference where economics justify it.
Data and retrieval: Postgres with pgvector, Pinecone, Weaviate, Qdrant; Snowflake, BigQuery, Databricks; dbt and Airflow for pipelines.
Orchestration and evaluation: LangGraph, LlamaIndex, and the emerging agent frameworks — assessed sceptically, since this layer moves fast and much of it is not production-ready.
We are not a reseller for any of these and hold no incentive to recommend one over another. Where the honest answer is that a spreadsheet, a rules engine, or better process design beats a model, we say that.
Where this applies
Useful when the choice is real
Most valuable for organisations with meaningful operational data, repetitive knowledge work, and more candidate use cases than budget — which is the situation that makes the ranking worth paying for.
Least valuable for companies with a single obvious, well-understood use case and clean data. If you already know exactly what you want built and why, skip the audit and start building. We will tell you that on the intro call rather than sell you an assessment you do not need.
Commonly run in fintech, healthcare, manufacturing and legal and professional services, where operational data is rich, several functions want the same budget, and funding the wrong use case first is expensive to unwind.
Why us
One team, not three vendors
The usual way
- A strategy consultant, a development shop and a marketing agency, each scoped separately.
- Months spent getting three vendors to agree, and blame to allocate when something breaks.
- The model ships and adoption becomes somebody else's problem.
With Nexiour
- One team across strategy, engineering and growth. You skip the coordination tax entirely.
- We own the whole outcome — from the first audit to the system that is running.
- Delivery across the UK, UAE, Germany and India, with overlapping hours in four markets.
What it costs
Fixed price, fixed scope
The audit is a separate engagement with its own fixed fee, quoted after a short scoping call and agreed before any work starts. It is priced and delivered on its own terms, not as a stage of a larger build. Three things move the figure.
Organisational breadth
One department with three systems is a different engagement from four business units with overlapping platforms and no shared data model.
Number and condition of the data sources
Several systems with inconsistent definitions and shallow history take substantially longer to examine than one well-maintained source, and the examination is where most of the engagement's effort sits.
How much has to be tested rather than asked
Where feasibility rests on assumptions nobody can confirm, we run spikes. Where documentation and data are in good order, fewer are needed.
If the audit concludes you should not proceed with AI right now, that is a legitimate outcome and the fee is unchanged — a recommendation against committing a build budget to the wrong thing is worth more than the audit cost.
FAQ
Frequently asked questions
Three to four weeks for most organisations. Two to three weeks for a single department with clean, accessible systems. Six weeks or more for enterprises with many disconnected systems or several business units in scope, which we scope and state up front.
A separate fixed fee, quoted after a short scoping call and agreed before any work starts. What moves it is organisational breadth, the number and condition of your data sources, and how much has to be tested rather than asked. We do not run audits on time and materials, so the figure you agree is the figure you pay.
When you have one use case, you understand it well, the data sits in one system you control, and the build is small enough that the assessment would cost a meaningful fraction of it. In that situation an audit is a delay with a fee attached. Go and build it, learn from the real thing, and assess later if a programme develops. We will say this on the first call if it applies to you.
Access to the people who own the relevant processes, roughly six to ten hours of their time across the engagement, read access to representative data samples under NDA, and documentation of your current architecture if it exists. If it does not exist, we produce it as part of the audit.
No. Representative samples under NDA are sufficient, and can be anonymised or synthetic where the data is sensitive. We do not require production write access at any point during an audit.
That is a valid and reasonably common result. The report then focuses on what would need to change — usually data foundations, process documentation, or ownership — and sequences that work. It costs the same. Knowing this before committing a build budget is the point.
A consultation gives you an opinion. An audit gives you evidence: examined data, tested assumptions, costed architecture, and a written business case you can take to a board. Free assessments are typically sales instruments designed to arrive at a predetermined recommendation.
The audit is technical and bottom-up — what your data and systems can actually support. Strategy is organisational and top-down — what the business should pursue, who owns it, and how new use cases get approved. If you can only run one, start with the audit; it is cheaper and it grounds everything else in what is real.
Yes, and you are under no obligation to use us. The report is deliberately written so another firm could execute from it.
Yes. A common engagement is assessing why an existing deployment underperforms — usually evaluation gaps, retrieval quality, or a process that was never redesigned around the system rather than the model itself.
Related