AI Readiness Audit

An AI readiness audit is a structured assessment of where AI can create measurable value in an organisation, where it is constrained by data, risk or regulation, and whether the workforce and culture are ready to adopt it. Tenhaw's version examines four domains rather than one: the external product a customer touches, the internal processes that run the business, operations, and the software development process itself. It runs 4 weeks at a fixed price of £44,000 and produces a sequenced, costed plan rather than a maturity score.

Four domains, in this order. The external product your customers touch, and whether AI belongs in it or only behind it. The internal processes that run the business, traced end to end rather than taken from a process map. Operations, including the run cost of anything already live. And your own software development process, which is usually the domain with the shortest path from a decision to a measurable result, because it is the one place an organisation already instruments itself. Each is ranked against the others as well as within itself, because the first question a board asks is which one to fund.

Tenhaw prices the AI Readiness Audit at £44,000 as a fixed fee, whatever the size of the organisation. Large consultancies typically price equivalent assessments between £150,000 and £500,000, our estimate rather than a published figure. The fixed price means the scope is agreed before the work starts and does not expand mid-engagement, and the number does not move once it is in writing.

Start with the audit if the question is where to invest across the organisation and you need a board-ready case. Start with a proof of concept if you already know which workflow you want to attack and the question is whether it can actually be done. Some clients run the proof of concept first because a working thing persuades internal sceptics that a plan does not.

James Rooney leads every audit personally. Where specialist input is needed, it comes from an associate he has already delivered alongside, screened to BS7858 standard before any client access, and every person on your engagement is senior. Tenhaw does not sell work that someone else then delivers, and there is no pyramid of junior consultants.

A permanent Head of AI search runs six to nine months, and the specification usually gets written from market narrative. The audit takes four weeks at £44,000 and gives whoever you hire a sequenced, costed plan to arrive into rather than a blank page. If you have already made the hire, the audit is the fastest way to give them a defensible first hundred days. It is not a substitute for the permanent role.

Everything the four weeks produce. Two or three candidate workflows built as working prototypes against your real data, inside your own tenancy, with the code yours to keep. A heat map across all four domains, the constraints that would block you, an estimated run cost per candidate workflow, and a costed plan in three-month increments capped at twelve months, presented to your board at the end. The number is fixed in writing before the engagement starts and does not move with scope.

It can tell you which of them are earning their keep. Weeks one and two inventory what is actually in use across the business, sanctioned or not, map each tool to the workflows it touches, and show where two or three of them cover the same job. That overlap, and what each costs to run, then sits in the sequenced plan alongside everything else, and consolidation decisions usually land on the do-not-do list. Nothing on the ladder involves us selling you a licence, so this is an assessment rather than a procurement exercise.

Working prototypes and a costed plan, not a slide pack. Two or three candidate workflows are built against your real data inside your own tenancy, each with a measured accuracy and confidence read and an estimated run cost per unit of work. Alongside them you get a heat map of where AI will and will not pay across product, internal process, operations and your own software delivery, the constraints that would block you, and a sequenced plan in three-month increments capped at twelve months.

By building on it rather than surveying it. We trace real workflows end to end, pull your delivery data instead of relying on what the org chart claims happens, and then prototype two or three candidates directly against your data. Readiness shows up fast that way: retrieval quality, how much of the context an agent actually needs is reachable, where provenance breaks, and which workflows quietly depend on a system nobody in the centre knows about.

The same way we work out where it will, which is why it comes out of the same four weeks. A workflow fails the test when the data is not there, when the risk appetite will not carry an automated decision, when the volume is too low for the run cost to make sense, or when the real constraint is a process problem that agents would simply do faster. Those land on a do-not-do list, with the reason attached, so the plan is defensible in both directions.

Fewer than you would expect, and less of their time than a survey-based assessment. The method works by sitting with the people who actually do the work, so it needs access to those teams rather than to a data room. Beyond that: an executive sponsor who can make decisions inside the agreed scope, someone from risk or the second line to agree a risk classification before anything is built, and whoever owns the platform the prototypes run on.

In currency, per workflow, before anything is built. Volume, elapsed time, people involved and rework, measured on the workflow as it runs today rather than as it is documented. That baseline is what the prototypes are then measured against, and it is what makes a later claim of saving checkable rather than asserted. It also sets the run cost side, an estimated cost per unit of work, so the operating cost is known before you commit to it.

Where the data can go, who can reach it, and what an agent is allowed to touch. Prototypes are built inside your own tenancy on your own contracts, so the constraints examined are the real ones: identity and access, least-privilege scoping for agent permissions, where model inference is allowed to run, what your data-handling requirements mean for retrieval corpora, and what the second line needs to see before a risk classification is agreed.

Yes, and it is one of the four domains rather than an afterthought. We measure how your organisation ships today, against its own delivery data rather than against a vendor benchmark, and the prototypes are pair-programmed with your engineers, which is the most direct test there is. Software delivery is usually the domain with the shortest path from a decision to a measurable result, because it is the one place an organisation already instruments itself.

Ours ends in working code and a fixed £44,000. An equivalent large-firm assessment is an estimated £150,000 to £500,000 and typically ends in a document. The difference is the shape of the team rather than the day rate, and ours is a partner, a senior operator and a build engineer for four weeks, with no pyramid to fund. Every figure we publish is on the pricing page with the competitors' own published framework rates beside it.

The engineering starts inside the audit itself. By the end of week three, two or three workflows are running against your data and the code is in your repositories. The plan that follows is written against things that already exist, with sequencing grounded in what the prototypes measured rather than in what a workshop guessed. If you stop after the audit, you still keep the prototypes.

It is the cheapest way to find out that a workflow does not work. The alternative is discovering it inside a six or twelve month build, where the same finding costs the whole run rate rather than four weeks. The audit produces a measured accuracy read per candidate workflow, an estimated run cost, and a baseline in currency to measure against later. It is priced to be approved without a committee for exactly that reason.

Yes, scoped to the target or to the business unit under review, at the same fixed price over the same four weeks. The method works by sitting with the people doing the work, so it needs access to them rather than to a data room alone, and four weeks now fits inside most exclusivity periods, where six to eight did not. Both are worth raising on the first call. It is an operational read on what is real, not legal, financial or regulatory due diligence, and it replaces none of those.

Same engagement, wider scope. This started life as an agent readiness audit. Agents turned out to be one answer rather than the question, so the rename was a widening rather than a relabel, and the four weeks now cover the product your customers touch, the internal processes that run the business, operations, and your own software development process. The agent-specific part is a decision inventory in the board readout: which decisions in the workflows we examine could move to an agent, which must stay with a person, and the consequence and reversibility test behind each call. Two or three candidates are then built as working prototypes against your real data, at a fixed £44,000.

Yes, and it is one of the reasons the audit gets bought. A seven-figure programme is on the table and someone wants the scope sanity-checked before it is signed. Nothing needs to pause while it runs, because the method is sitting with the teams doing the work and tracing real workflows end to end rather than reviewing a data room. What comes back is evidence rather than an opinion: two or three of the candidate workflows built against your real data, each with a measured accuracy read and an estimated run cost, a heat map ranked by return and feasibility, and a do-not-do list. We sell no licences, so nothing in that recommendation is a sale.

Nothing by default, and that is deliberate. The engagement ends on the date it said it would, nothing rolls on, and the prototype code has been in your repositories since it was written, so there is no handover to wait for. The costed plan is yours to keep even where the recommendation is to stop. It comes in three-month increments capped at twelve months, with decision points marked where it should be re-tested against what you learn, so your own team can start the first increment without us. If you want us for part of it, that is a separate contract: a proof of concept at £20,000 to £55,000, a design team, or programme and delivery management.

Most of it lands on the engineers pairing in weeks two and three, and Tenhaw shapes the rest of the four weeks to sit inside normal work rather than in workshops. Week one is observation, spent sitting with the teams doing the work and tracing real workflows end to end, so the time goes on being watched rather than on preparing material for us. Weeks two and three are the heaviest, because the two or three candidate workflows are pair-programmed with your engineers against your real data. Week four needs your leadership for the readout. How heavy those two weeks get depends on how many of your own engineers you want in the pairing.

Both, and Tenhaw runs the session rather than sending a pack over. The week four readout is presented to your leadership with the prototypes running behind it, so the board watches the two or three workflows work rather than reads about them, and the written deliverable runs to seven sections in a fixed order, from the heat map through the constraint register and the decision inventory to the do-not-do list. The prototype code has been in your repositories since it was written, so nothing is handed over on the day. Who needs to be in that session depends on which of the four domains your board is closest to funding.

Evidence, named against each placement. Tenhaw ranks the candidate workflows by expected return against feasibility and writes what sits behind each placement into the readout rather than scoring it out of five, because a maturity model is not something a board can fund from. The same rule keeps sample findings off this page. A worked heat map with plausible rows in it would be an invented result for an organisation nobody has audited. The two or three workflows built as prototypes each carry a measured accuracy and confidence read, which is the hardest evidence in the pack. Which placements get argued over depends on how much of your delivery data is already instrumented.

Yes, because the scope is bounded before the clock starts rather than stretched to fit. Tenhaw agrees how many workflows get built in writing before the engagement starts, and scoping settles which parts of the business the four domains are examined across, so the four weeks go deep on those instead of shallow everywhere. Two or three candidates are then built as working prototypes against your real data, and that depth is the test a timebox has to pass. What four weeks cannot do is cover every operating company in a large group at once, so where to point the four domains is the first conversation rather than a detail settled later.

Then they can rework them in the room. Tenhaw states the value in currency with the assumptions exposed, a confidence level attached to each figure and the arithmetic laid out, so your finance function can run its own numbers through it rather than take a benefit figure on trust. James Rooney leads every audit personally, so the person answering the challenge is the person who did the work, and the two or three prototypes are running behind the readout with a measured accuracy read on each rather than screenshotted into a slide. Which figures get pushed on hardest usually turns on how your finance team already values the time a workflow consumes.

Yes, and a recommendation to stop is one of the outcomes Tenhaw builds the four weeks to produce rather than a failure of them. The £44,000 buys four weeks of work, and the finding is the work. You keep the do-not-do list with the reason attached to each entry, the measured accuracy read on each prototype, the constraint register and the costed plan, whether or not you act on any of it. Clients tell us the do-not-do list is usually the most valuable page. More often a stop recommendation reorders which of the four domains to fund and which to leave alone this year, rather than meaning stop everything.

Parts of it do, and Tenhaw writes it to show you which. The plan comes in three-month increments capped at twelve months, with decision points marked where it should be re-tested, so a pause leaves you at a marked point rather than at the top of a document nobody trusts. The estimated run cost per workflow ages fastest, because model pricing moves under it. The constraint register, the operating-cost baseline in currency and the do-not-do list hold longer, because they describe your organisation rather than the market. How much has actually moved depends on what changed in your estate while you waited.

Only what your own tenancy charges, because that is where they were built. Tenhaw builds the two or three candidate workflows against your real data inside your own infrastructure on your own contracts, so inference and compute sit on your bill during the four weeks and after them, and you can switch them off the day the engagement ends without asking us. An estimated run cost per unit of work for each candidate is part of the deliverable precisely so that number is known before anything is committed. What it would cost at production volume depends on the volumes you would actually put through it.

No, and Tenhaw calls them prototypes for that reason. The two or three candidate workflows built in weeks two and three run against your real data inside your own tenancy and produce a measured accuracy and confidence read, which is what grounds the week four sequencing, but four weeks buys evidence rather than a hardened system. The code sits in your own repositories either way, so your engineers can take it forward without us, and the costed plan carries the build cost and the dependencies for doing that properly. What hardening actually costs turns on the volumes and the error tolerance the workflow has to hold.