Before You Build Anything, Map What You Have
Vasily Grigorovsky
Most organizations don't think they have a data problem. Some might have existing dashboards and pipelines. Others have an AI initiative or a new data-focused project on the roadmap. But ask a pointed question ('Could you train a model on this tomorrow?') and the answer usually isn't obvious.
A data audit is a structured look at what data you have, what shape it’s in, and whether it can support what you're trying to do next. Like getting an honest inventory before you build anything on top of it.
Why Now
The push to "do something with AI" has made this more urgent. Every AI initiative starts with assumptions about data availability, and most of those assumptions turn out to be at least partially incorrect, or at least untested. Teams tend to discover this three months into a build, when the model underperforms and the root cause is an upstream quality issue that was there from the start.
An audit catches that before you commit people and budget. It closes the gap between what people believe about their data and what the data actually shows.
Beyond AI readiness, there are more basic things an audit reveals. How fast can the organization go from question to insight? What kinds of metrics are possible? What type of data is missing? Where are the bottlenecks, and what would it take to clear them? Some of these are technical, while others are not.
Most audits end up being about one (or more) of three things: data quality (is what you have trustworthy), AI readiness (can you build on it), and data potential (what else becomes possible, and what would it take).
Data Audit Spectrum: Three Examples
Data audits look very different depending on where the organization is. Here are three engagements that show the range.
Company A: Lots of Data, Specific Goal
Company A wanted to build a model to predict legal case outcomes. They were working from a database of five million-plus cases over two decades: linked tables for case details, hearings, personnel, and outcomes. Plenty of data, but the question was how much of it was usable.
Less than expected. A key input feature (gender) was almost entirely missing for the first decade of records, cutting the usable training window roughly in half. Decision codes joined to descriptions through a multi-key lookup, and some combinations just weren't in the reference table. Location data had a long tail: too many individual locations with too few records to be useful as features. The raw outcome data had dozens of granular categories. These needed collapsing into a workable taxonomy. The next step, mapping the data, required judgment, since getting it wrong would mean the model optimizes for the wrong thing.
What came out was a data map: what time window to train on, how to handle missing data, solutions to overcome data-join mismatches, and which features are likely to have a high impact. Having that information before modelling started, provided clear guidance on the next steps and saved weeks of back and forth on data-issue discovery.
Company B: No Data Yet
Company B was pre-launch, building an AI analytics platform for a regulated industry: peer benchmarking, financial forecasting, a conversational assistant.
Data would come from clients during onboarding, in different formats from different systems: structured exports, semi-structured PDFs, some of it needing OCR. So the audit focused on what the data landscape should look like: expected sources, likely fields and formats, and where public benchmarking data could fill the gap before enough clients onboarded.
The risk analysis ended up being the most useful part. Peer benchmarking depended on clustering, which needs a critical mass of client data. But prospective clients would be hesitant to share sensitive data before the platform proved its value, which it couldn't do without their data. We recommended prioritizing integration on the one or two dominant systems by market share, and identified potential public data sources to bootstrap initial clustering.
This data audit was more of a roadmap - what kind of data would be required (with different priorities), how to structure it, and what becomes possible at each stage of onboarding.
Company C: Data That Looks Representative and Ready (But Isn't)
This is the scenario we see most. Company C had an educational platform, looking to better track progress and outcomes for underserved students. As this is potentially sensitive data, we were working with a sample dataset of roughly 50 active users across five locations; close to 50 database tables in total.
Test data contamination ran up to 34% in key tables. The platform had two user populations nobody had distinguished (twelve linked to an external LMS, forty-odd on the native platform), and combining both without accounting for this would silently undercount most students. Since this was test data, some test entries were expected. But the audit showed that the test data wasn't representative of what actual usage would look like, and the organization's assumptions about user behaviour didn't match what the data showed. They had defined engagement tiers for a planned impact framework: High (200+ hours), Medium (50-199), Low (under 50). Maximum observed engagement was under 30 hours, and over half of users had less than one hour. Whether that reflected the testing phase or how the platform actually gets used, the gap between expectations and data was worth flagging early.
Some of the consequential findings were mundane: a date column stored as VARCHAR (quietly breaking time-based filtering), or multiple users sharing activity timestamps, suggesting batch-generated system events rather than genuine user activity.
The bigger value was in mapping what was possible. Of 25 metrics in a planned well-being assessment framework, only five were available from existing data. Things like demographics and long-term outcomes were not available and would need to be sourced. The audit did more than name the gaps. It showed where and how to fill each one: several metrics were derivable from existing fields without schema changes, public datasets could cover some gaps short-term, and partnering with the sites' administration to source anonymized records could unlock most of the rest.
The deliverable was a path forward: here's what you can measure now, here's what you need, and here's where to get it.
These are different scopes of the same work. Company A's audit was tied to a specific model build. Company B's was a forward-looking health check for a product that didn't exist yet. Company C's was somewhere in between: existing data that needed honest assessment, plus a roadmap for what to collect next. The framing changes, but the core is the same: map what you have, figure out what's usable, and get a clear picture of what it would take to get where you want to go.