It looks like a data-quality problem. It isn’t.
That misdiagnosis is the most expensive one in enterprise AI.
When a pilot stalls, the instinct is to clean the data: run a quality initiative, buy a catalog, stand up a lakehouse. Those things help. But they treat quality as an input you can fix once.
Quality is closer to an output. It’s what a well-orchestrated, well-governed system produces, and what an ungoverned one quietly stops producing. Each tool cleans its own layer and hands the problem downstream, so the failure ends up in the seams between them, right where AI touches the data at runtime.
It rarely feels like a crisis while it’s happening:
- A promising pilot loses steam and never reaches the rest of the organization.
- A team makes a call on numbers that were already out of date.
- A system ends up with access to information it had no reason to see.
Governance has the same shape of problem. Access rules written for databases and dashboards don’t automatically carry over when a model retrieves a document, embeds it, and generates an answer from it. Nearly all AI-related breaches on record involved improper access controls.
The pattern is well documented. Close to 90% of companies are experimenting with AI, but only about 7% have scaled it, and about 7% say their data is fully ready for production use. Gartner predicted that 60% of AI projects built without AI-ready data would be abandoned through 2026.
Five patterns show up in almost every stalled pilot.
Tick the ones that sound familiar. Nothing is stored or sent anywhere.
Tick whatever sounds familiar. There’s no wrong answer.
See what a first step looks likeThe bill tends to arrive twice.
Once for the pilot that stalled, and again for the cleanup nobody scoped.
Fixing access, pipelines, and schemas up front costs a fraction of a post-incident cleanup or a rebuild. Three places that shows up:
Penalties and breaches
Under the EU AI Act, fines for the most serious violations reach €35M or 7% of global turnover, and data governance obligations carry their own tiers of penalty. The average data breach costs about $4.4M, with shadow AI adding roughly $670K.
Reuse
In one financial services engagement, a reusable data foundation avoided an estimated $10M–$20M as use cases grew from 1 to 15. Built ad hoc, costs would have nearly tripled.
Decisions
87% of practitioners say decision speed would improve most with faster, more reliable access to good data, and 78% say the same of decision confidence.
“Ready” depends on what you’re asking AI to do.
A marketing copilot and a loan-approval agent need very different foundations. Treat them the same and you either over-build the easy case or under-govern the dangerous one.
Tier 1: Internal efficiency and assisted BI
Think internal search bots, executive dashboards, and drafting tools.
The bar to clear:
- Basic schema clean-up
- Standard read permissions
- Periodic batch ingestion is fine
Building this to Tier 4 standards is the over-built case: real money spent on controls a drafting tool doesn’t need.
Tier 2: Customer-facing operational AI
Think support copilots, automated ticket routing, and web recommendations.
The bar to clear:
- Strict role-based access
- Real-time pipeline monitoring
- High data accuracy
Once customers see the output, mistakes are public. Access control and monitoring stop being optional.
Tier 3: Autonomous and high-risk decisioning
Think automated loan approvals, medical triage, and fraud detection.
The bar to clear:
- Full master data management
- Strict lineage tracing
- Continuous audit trails
Running this on Tier 1 controls is the under-governed case, and it’s the one that tends to show up in incident reports.
Tier 4: Enterprise semantic ecosystem
Think cross-department agent swarms and dynamic multi-cloud query engines.
The bar to clear:
- A fully unified semantic layer
- Automated schema reconciliation
- Self-healing pipelines
Few organizations need this everywhere. It’s a destination for specific ecosystems, not a default.
Where the work actually happens.
Five areas of your data estate decide whether a use case holds up in production. A domain is ready when it clears all five at the tier its use cases require. That’s the whole bar: nothing more, nothing less.
Find out where your data actually lives
Estate discovery and atlas mapping
Catalog the critical assets across warehouses, lakehouses, and the unstructured content legacy systems were never built to hold. Name an owner for each, inventory shadow data and the AI applications already running, and map the full supply chain from source through extraction, chunking, embedding, and indexing.
Make data move reliably
Ingestion and pipeline industrialization
Replace brittle batch exports with near-real-time access where the decision demands it. Pipelines become versioned, tested, and observable, and unit cost is instrumented so you see spend before the invoice arrives.
Make governance travel with the data
Runtime governance and guardrails
Extend controls past storage to the moment AI retrieves, embeds, and generates. That means access tied to identity, automated detection and masking of PII and PHI, an AI application register with risk ratings, defenses against prompt injection and data poisoning, and alignment with regulation such as the EU AI Act and GDPR.
Make trust engineered, not assumed
Quality orchestration and data product cataloging
Data contracts with automatic tests, quarantine gates that isolate bad data before it reaches a model, and certified data products with owners and SLAs. The same business term should return the same answer whether it’s asked through SQL, search, vector retrieval, or an agent.
Structure data so AI can actually use it
AI activation and feature integration
Feature stores that serve training and inference from one source of truth, governed vector indexes with defined chunking and freshness SLAs, retrieval quality that’s measured and acted on, and traceability from every AI answer back to its source.
How we think about this work.
Start from the use case, not the data
We don’t begin by cleaning anything. We ask what the AI is for, then work backward to the readiness that use case needs. A fix that unblocks a high-stakes system outranks one that only helps a low-stakes tool, even when the low-stakes fix is cheaper.
Own the seams
Platforms like Snowflake, Databricks, Starburst, and Microsoft do their jobs well, but they depend on normalized, governed data underneath. That upstream work, and the connections between tools, is where we spend our time. We stay vendor-neutral on the approach.
Follow the data to where AI uses it
Governance that stops at storage doesn’t hold once models start retrieving and generating. We treat identity, policy, and audit as one model from the source to the prompt to the output.
Leave the capability behind
We use AI to move faster through the diagnostic and the build, and we leave working capability inside your stack, so your team can tier, baseline, and assess the next AI idea without calling anyone back in.
A good first step is a short assessment.
It’s the one step every engagement shares. After it, the work is modular: take only the pieces that close your gaps, in any order, in series or in parallel. Governance-only or pipeline-only is a perfectly good place to begin.
Name the use cases in scope, each with a business owner.
Assign each a tier based on what’s at stake if it goes wrong.
Score where you stand today across the five areas, and set the target.
Baseline a handful of metrics (reuse, reliability, governance, scalability) so progress is measurable later.
You finish with:
- A scored readiness grid showing where each domain stands against the tier its use cases require.
- A prioritized gap register, with every finding tied to a specific use case and its stakes.
- A clear order of operations you can act on yourselves, or with us.
If two or more of the five patterns above sounded familiar, it’s worth a conversation.
Questions people ask before they start.
Is this a multi-year commitment?
No. It starts with the assessment, and everything after it is modular. Each block is designed to leave something useful behind on its own, so you can stop after any of them.
We’re already evaluating Snowflake, Databricks, Starburst, or Microsoft. Where does this fit?
Underneath. Those platforms give you a semantic layer and a catalog, and they work as well as the data and governance beneath them. The upstream work (normalizing schemas, fixing pipelines, setting access controls) is what lets that investment pay off.
We just want a quick proof of concept. Can’t governance wait?
It can, and plenty of teams do it that way. The risk is that “later” tends not to arrive, and the pilot that impressed everyone isn’t the one production gets. A lighter approach is to decide which tier the pilot sits in and what it needs now. For a low-stakes internal tool, that may be very little.
We acquired a company and our schemas don’t line up. Is that the same problem?
Often, yes. Acquisitions leave data spread across incompatible schemas and systems, and AI pipelines can’t work with that until it’s normalized. It’s one of the most common places this work starts.
Do we need to bring everything up to the highest standard?
No, and we’d advise against it. Readiness is relative to the use case. Building every system to the top tier is how readiness programs turn into multi-year platform projects nobody can defend.
What happens after the work is done?
Your team can tier, baseline, and assess future AI initiatives on its own. If you’d rather not carry the ongoing monitoring yet, an optional managed layer covers drift detection, output-quality audits, and cost reviews, with a defined path to hand it back as your internal capability matures.
Related reading: AI Team Enablement
Data is half of the readiness problem. The other half is whether your people can use what you’ve built. See how we approach it.