Most companies skip the AI readiness audit. They pick a use case, sign a contract, and start building. Six months later the project is shelved: the data wasn’t usable, the team didn’t have the skills to maintain what got built, and nobody could agree on who was responsible when the outputs went wrong. A readiness audit would have taken three weeks and caught all of it.
What a readiness audit actually is
An AI readiness audit is a structured review of whether your organization can support a specific AI initiative. It covers four areas: data, people, infrastructure, and governance.
A vendor assessment won’t tell you this. Neither will a product demo or an AI strategy session. Those have their uses, but none of them answer the question you need answered before committing to a project: can your organization build this, deploy it, and keep it working?
The audit produces a picture of where you stand, what the gaps are, and which gaps would actually block the initiative versus which ones you can manage. No organization is fully ready for AI. The question is whether your specific gaps will sink the specific project you’re planning.
Start with your data
Data is where most AI projects get into trouble, so start there. You’re looking at three things: what data you have, whether it’s good enough for the use case you’re planning, and whether you can actually get to it when you need it.
Start with an inventory. Many organizations have data scattered across a CRM, an ERP, a warehouse, spreadsheets, and shadow systems IT doesn’t fully control. Before you can assess quality, you need a map: where the relevant data lives, who owns it, and how it gets updated. This step alone surfaces problems that would otherwise appear mid-project.
Quality has four components: accuracy (is the data correct?), completeness (are there gaps that would affect model performance?), consistency (does the same field mean the same thing across systems?), and freshness (is it current enough for your use case?). The bar varies. A customer service chatbot can tolerate noise in historical ticket data. A fraud detection model cannot tolerate inconsistently labeled transactions. Know what your use case requires and measure against that.
Even clean, well-cataloged data is useless if you can’t get to it reliably. Check whether the data you need is accessible via a stable API or pipeline, or whether it requires manual exports. Also check for legal or contractual restrictions: customer data often has consent or licensing constraints that affect how it can be used for training or inference.
Trace the full path from raw data to usable model input for your planned use case. More than two manual steps in that path is a gap that needs closing before you build anything.
Assess your people
Technical problems get the most attention in AI post-mortems. People problems kill just as many projects. The audit should give you an honest picture of whether your team can build, deploy, and maintain what you’re proposing.
Start with what your team can actually do. There’s a wide range of capability that gets labeled “AI experience.” Engineers who can call an LLM API and engineers who can evaluate model outputs, manage fine-tuning, build feedback loops, and debug production failures are doing very different things. Be specific about what your project requires, and whether those skills exist in-house.
Domain expertise matters as much as technical skill. A system that flags anomalies in purchasing data is only useful if someone can tell which anomalies matter and which are noise. That person needs to be in the loop, especially during early deployment when the model is still being calibrated against real conditions. Without domain expertise close to the system, you end up with something that’s technically functional but operationally useless.
The question most teams skip: in 12 months, who owns this? Many AI projects are launched by a consultant or a borrowed engineer. When they move on, the system is left without anyone who understands it well enough to maintain or improve it. If you can’t name a long-term owner now, that’s a gap.
Check your infrastructure
You don’t need cutting-edge infrastructure to do useful AI work. But you do need to know what you have.
Most LLM-based applications run fine against cloud APIs. You don’t need your own GPU cluster unless you’re planning to fine-tune models, run inference at real scale, or keep data on-premises for compliance reasons. Know which of those applies before you budget for infrastructure you may not need.
Integration is where more projects quietly break down than most teams expect. If the goal is automating a step in a procurement workflow, you need to know whether your ERP exposes a usable API, whether your data team has built reliable connectors, and whether ERP upgrades will break the integration on a predictable schedule. These are solvable problems when you find them in planning. They’re expensive when you find them mid-build.
Once an AI system is in production, you need to know whether it’s still working. That means logging that captures inputs and outputs, alerting that fires when something looks wrong, and a way to measure model performance over time. Without it, you won’t know the model has degraded until a human catches it by hand, often months after the problem started. Observability needs to be a project requirement from day one.
Governance and risk
Governance sounds like compliance theater. It’s actually a practical question: who is accountable for what this system does, and what happens when it’s wrong?
If your AI system makes or influences real decisions, there should be a named person who has reviewed the system and is accountable for its outputs. Hiring screens, loan approvals, procurement decisions, medical triage: all of these require a human who can be asked to defend the system’s behavior. If no one in your organization can answer that question, you have more legal and reputational exposure than you probably realize.
Regulatory exposure is worth mapping before you build. Financial services, healthcare, and HR are the obvious sectors, but supply chain automation, marketing personalization, and customer-facing chatbots each carry their own requirements. Those requirements are also changing faster than most legal teams can track.
Many organizations also don’t have a formal AI use policy. That leaves employees making their own calls about what data to put into third-party AI systems, whether to share AI-generated content externally, and how much weight to give to AI recommendations. Those calls are inconsistent. A policy doesn’t need to be long, but it needs to exist.
What audits tend to find
A few things come up in almost every engagement.
Data ownership is murkier than people expect. The person who should own a dataset either doesn’t know they own it, has left the company, or is maintaining it in a way that doesn’t match how it’s documented. You can’t improve data quality without a clear owner.
Skill gaps tend to be specific rather than general. Organizations often have engineers who can build an integration but not evaluate model quality, or data scientists who can train a model but not deploy it reliably. The gap isn’t “we have no AI skills.” It’s “we have the right skills for two of the three steps.”
Governance is almost always underdeveloped relative to the ambition of the planned use case. Most organizations have thought hard about what they want to build. Very few have thought about who would be accountable if it went wrong. That conversation is much easier to have before the system is live.
How to run the audit
A focused readiness audit can be done in two to four weeks without a large external engagement.
Start by scoping it to a specific use case. “Are we ready for AI?” isn’t auditable. “Are we ready to build an AI system that routes customer support tickets to the right team?” is. Specificity is what makes the audit useful.
If you want a quick baseline before you start, our free AI readiness assessment covers the same four areas and takes about 10 minutes. It won’t replace the full audit, but it surfaces the most obvious gaps fast.
Before interviewing anyone, gather what already exists: data catalogs, system architecture diagrams, org charts, any previous analytics or data projects. A factual baseline keeps conversations grounded. Without it, you end up evaluating what people hope is true rather than what’s actually there.
Talk to the right people: whoever owns the data, the engineers who would build the system, the business owner who would use it, and whoever would be accountable for its decisions. Ask each of them what they think the biggest risk is. The gaps that come up in every conversation are the ones worth taking seriously.
For each area, sort your findings into three buckets: ready, needs work before launch, and blocks the project entirely. A blocking gap doesn’t mean abandon the project. It means fix the gap first, or narrow the scope so the gap no longer applies.
The output should be a short document: where you stand, what the blocking issues are, what’s manageable, and a recommended path forward. A decision-maker should be able to read it in 20 minutes and know what to do next. Not a 60-slide deck.
The bottom line
A readiness audit is a diagnostic, not a test you pass or fail. The goal is an honest picture of where you are before you commit budget and people to a project that isn’t set up to succeed.
Most AI initiatives that fail were reasonable ideas that got launched too early, before the organization had the data, the people, or the infrastructure to make them work. The audit tells you which gaps you have and what it would take to close them. That’s worth three weeks before you build.
If you’re planning an AI initiative and haven’t done this work, start there. Borah AI’s AI strategy services include structured readiness evaluations built around your specific use cases, designed to surface what needs to change before you build, not after.