Key takeaways
- Ten concrete choices, not company size, decide whether an AI readiness audit is small or large: workflows in scope, interviews, systems and data reviewed, security depth, and what gets delivered at the end.
- A useful audit produces a current-state map, a prioritized and valued opportunity list, a recommended approach and a roadmap, not a maturity score.
- A good proposal names the workflows, systems and interviewees in scope, states what happens to the findings, and says plainly whether you own them.
- A narrow, well-defined software brief can often skip a separate audit and go straight to a proposal.
- Compare proposals against what each one actually covers before comparing the number at the bottom.
A board member reads that AI projects should start with a readiness assessment, asks finance to collect three quotes, and the quotes land an order of magnitude apart with no explanation of the gap. That gap is almost never padding or a negotiating opener. It is scope: concrete choices about how many workflows to review, how many people to interview, how deep to go on data and security, and what gets handed back at the end. Once you can see those choices, a proposal stops being a mystery number and becomes something you can question, compare and negotiate.
Why doesn't an AI readiness audit have a fixed price?
An AI readiness audit is not a product with a list price. It is scoped consulting work, closer to an engagement letter from an accountant or a statement of work from a law firm than to a software subscription. Two audits called the same thing can differ by a factor of three or four in effort, because one reviews a single workflow with clean data and one accountable owner, and the other reviews five workflows across three departments with data scattered across email, spreadsheets and a system with no documented API.
This piece assumes you already know roughly what an assessment covers. If you have not read What happens in an AI readiness assessment, start there: it explains the areas a reviewer examines and the steps a credible assessment follows. This piece is about what makes one assessment bigger than another, and how to read a proposal so the price makes sense before you sign it.
One fact holds regardless of provider: an audit is separately scoped and billed work, distinct from an initial conversation. A discovery call that simply establishes fit and scope should not cost anything. If a provider wants to charge you before they will even discuss scope, that is worth asking about.
What actually drives the size and cost of an AI readiness audit?
Ten factors explain almost all of the variation between a small, focused audit and a large, expensive one. None of them is about how good the provider is. All of them are about how much ground the engagement covers.
| Driver | What raises the effort | What lowers the effort |
|---|---|---|
| Workflows and teams in scope | Several workflows across multiple departments, each with its own exceptions | One workflow, one department, one accountable owner |
| Interviews and workshops | Frontline staff, managers and system administrators, in separate sessions for each | A handful of people who can speak to the whole process together |
| Systems and data sources to review | Many systems, some with no documented API, access that needs IT and security sign off | A few systems already integrated, with read access granted before the audit starts |
| Data sampling and quality checks | Records spread across inboxes, spreadsheets and personal drives that must be gathered by hand | Clean, centralized records a reviewer can sample directly |
| Security and governance review depth | Regulated or sensitive data, a formal review against a framework such as the NIST AI Risk Management Framework, legal input required | Public or low-sensitivity data, with a usage policy already in place |
| Whether a technical proof of concept is included | A working prototype built and tested against real data before the proposal is finalized | A written recommendation only, no code built |
| Deliverables produced | A current-state map, a prioritized opportunity list with value estimates, architecture options, a full roadmap and a business case | A short opportunity list and a directional recommendation |
| Stakeholder availability | Interviews stretched over weeks because people are hard to schedule | Leadership blocks out time upfront and turns around requests quickly |
| Travel | Multiple sites, in-person workshops, several trips | Everything done remotely, one location |
| How findings are presented | A live workshop with leadership plus follow-up sessions to prioritize together | A written report with no in-person session |
Notice that company size is not on this list. A 400-person company that wants one workflow reviewed, with clean data in a single ERP and one available manager, is a smaller audit than a 60-person company that wants three workflows reviewed across finance, service and operations, with data in six systems and a request to test extraction from scanned documents before anyone commits to a build. Ask what is actually in scope before you compare price to headcount.
Illustrative example: Consider two companies asking for what they each call an AI readiness audit. The first wants a single workflow reviewed, purchase order intake, with data already in one ERP and one manager available for two interviews. The second wants three workflows across finance, customer service and operations, spanning five systems including one with no documented API, plus a working prototype to test whether scanned invoices can be extracted reliably. Both requests are reasonable. The second will take longer, involve more people and cost more, not because the work is priced differently, but because it is a larger piece of work.
What deliverables should the audit fee cover?
A useful audit ends with four things, tied to the workflows you actually asked about, not to AI in the abstract: a current-state assessment of how the work runs today, a prioritized list of opportunities with a rough value estimate for each, a recommended approach for each priority, which can include buying a product, integrating existing systems, or leaving something alone, and an implementation roadmap. What happens in an AI readiness assessment sets these out in detail.
For a finance audience specifically, ask whether the fee includes a business case: the value estimate behind each priority, the assumptions used to get there, and what would have to be true for the number to hold. A proposal that skips this usually means the case gets built later, at extra cost, once you have already committed to a direction.
What should a good AI readiness audit proposal state?
- The specific workflows, teams and systems in scope, named, not "a review of your AI opportunities."
- The deliverables you will receive, matching the four outputs above.
- Who will be interviewed, including frontline staff and system administrators, not only leadership.
- What access is needed: which systems, which records, and who has to approve it before the audit can start.
- A timeline, and what would change it, such as delayed access or unavailable stakeholders.
- What happens to the findings: whether you receive documents you can hand to another team, or a presentation only.
- Whether the audit fee is credited toward a build if you decide to go ahead, and under what conditions.
- A clear statement that you own the outputs, regardless of who you choose to build with.
The AI readiness checklist that pairs with this guide covers the preparation side from your end: what to have ready before an audit starts, so the scope in the proposal reflects the real size of the work rather than a guess. Before that conversation, the free AI readiness self-assessment is a quick way to see roughly where you stand and to sharpen which workflows you would ask a paid audit to look at.
When is an AI readiness audit not worth paying for?
An audit earns its cost when there is real uncertainty to resolve: which of several candidate workflows to start with, whether the data behind them is usable, which systems can be connected, and what a defensible business case looks like. It earns its cost less when that uncertainty does not exist.
A narrow, well-defined software brief, one workflow, one system, requirements you can already state clearly, can often go straight to a proposal without a separate audit. That is not a shortcut unique to one provider; it reflects how a scoped engagement works generally, AI or not. Switching on an AI feature inside software you already license is a similar case: there is no separate workflow to assess, so an audit adds cost without adding much you did not already know.
If you are not sure which situation you are in, how to choose an AI implementation partner covers the wider set of questions to ask any provider, including how they decide whether you need an audit at all.
How do you compare two audit proposals with different price tags?
Line up each proposal against the driver table above before you compare the number at the bottom. A lower price that reviews fewer workflows, skips the technical proof of concept, or names no specific interviewees is not automatically the better deal. It may simply be a smaller piece of work, or it may be a vaguer one.
Watch for two patterns in particular. A very precise price attached to a vague scope, "a comprehensive AI audit" with no named workflows, usually means the scope gets defined after you sign, on the provider's terms. A very detailed scope attached to a price that does not move when you narrow it is a sign nobody actually built the estimate from the scope in front of them. Ask each provider to walk through why their price reflects their proposed scope, using the drivers above as the shared language.
How Kastling scopes and prices an audit
Kastling's audit is separately scoped and paid, distinct from the initial conversation. A discovery call comes first, is free and commits you to nothing: we use it to understand the workflows you are looking at and whether an audit is even the right next step. For a well-defined software brief, we can move straight from that call to a proposal.
When an audit follows, we scope it against real workflows, not a template. Interviewees, systems, data sources and deliverables get named in the proposal before you agree to anything, following how we work. The outputs are yours regardless of who builds the resulting project.
For a number specific to your situation, the discovery call is the place to start. Read more about AI Integration & Automation.
AI readiness self-assessment
Twelve questions across workflows, data, systems, governance and people. See your readiness by area and what to work on first.
AI readiness checklist
A practical AI readiness checklist covering workflow, data, systems, security, people and measurement, so you can see what to fix before an AI project starts.
Questions
Does a bigger company always mean a bigger audit?
No. The number of workflows, systems and interviews in scope drives the size of an audit far more than headcount does. A 300-person company asking about one well-documented process can be a smaller engagement than a 40-person company asking about three processes spread across systems with no API. Ask what is in scope before assuming size follows employee count.
Should the audit fee be credited toward the build if we go ahead?
Ask, because practice varies and it is a fair question to raise before you sign. Some providers credit some or all of the audit fee against a later build; others treat the audit as a separate, standalone engagement regardless of what follows. Either approach can be reasonable. What matters is that the proposal states the policy plainly rather than leaving it to be negotiated after the findings are already in hand.
Can we run a readiness check ourselves before paying for an audit?
Yes. A free AI readiness self-assessment is a reasonable way to see roughly where you stand and to sharpen the workflows you would ask a paid audit to look at. It will not replace the interviews, system checks and data sampling a real audit does, but it can make the scoping conversation faster and more specific.
Does including a technical proof of concept always add significant cost?
It adds some cost, because building and testing a working prototype takes more time than writing a recommendation, but the increase should be proportional to what the prototype actually tests. A narrow proof of concept, extracting fields from one document type, for example, costs less than one spanning multiple systems and data formats. Ask what question the proof of concept is meant to answer before agreeing to add one.