Your Lake Can Feed Dashboards. It Still Can't Feed Production AI.

Your lakehouse demo never fails. Dashboards light up. Executives see yesterday's sales by region. Someone says the platform is "AI ready" because the same tables sit behind a notebook. Then a production model asks for yesterday's features with a freshness SLA, a PII class, an owner, and a contract that does not drift when a BI engineer renames a column. The lake goes quiet.

BI-ready data and AI-ready data are not the same product. One feeds charts. The other feeds decisions that touch customers, credit, claims, and agents that can write. Confusing them is how Australian enterprises burn a year of platform spend and still cannot promote a model without a war room.

This piece is about the gap: freshness, feature and table contracts, lineage, PII classes, and named owners. Not another catalogue slide. A checklist you can run in ninety days.

What "BI ready" actually bought you

A solid lake for analytics usually means:

• Batch pipelines that land overnight for morning dashboards
• Wide tables tuned for Tableau, Power BI, or Looker
• A semantic layer that forgives a late load if the chart catches up by 9am
• Access models built for analysts, not for low latency inference identities

That is useful. It is not enough for production AI. A dashboard can be wrong for an hour and still be a meeting topic. A scoring job that prices risk, ranks claims, or feeds an agent tool with stale joins becomes an incident. Same lake. Different blast radius.

If your architecture already creaks under shared platforms nobody owns, this gap will make it worse. We wrote about that failure mode in When Your AI Architecture Becomes a Liability.

What production AI needs from the lake

Treat AI consumers like production APIs, not like curious notebooks.

1. Freshness SLAs. Not "usually by morning". A stated max lag for each feature set or table slice the model depends on, with a monitor and an owner when it breaches.
2. Feature and table contracts. Stable names, types, null rules, allowed value ranges, and change notices. Renames and silent casts are breaking changes, not tidy-ups.
3. Lineage you can query under pressure. Which upstream job produced this row set, which transform version, which source system cut-off. If you cannot answer in minutes, you cannot roll back a bad train or a bad score batch.
4. PII classes on columns, not vibes. Labels that drive masking, join rules, and which identities may materialise features. GenAI and RAG paths that pull prose make this sharper, not softer.
5. Named owners. A human or team for each contract. "Data platform" is not an owner. Neither is a Slack channel that goes quiet at 6pm.

Retrieval stacks inherit the same pain. If the corpus behind RAG is still a swamp of conflicting PDFs, production answers will keep guessing. See Your RAG Demo Worked. Your Production Retrieval Is Still Guessing.

The false comfort of "we have a lake"

Teams point at object storage and bronze/silver/gold layers and call it foundation. Layers are filing cabinets. Contracts are the product.

• Gold for BI can still be unusable for features if grain, keys, and late arriving facts are undefined for model windows.
• Feature stores bolted on without table contracts just move the chaos closer to the model.
• Catalogues that list tables without freshness, PII, or owners become a search UI over hope.

Shadow notebooks will keep pulling wide extracts because the official path is slow or unclear. That is the same dynamic as unmanaged GenAI: convenience beats policy when the approved lane is painful. Bring the lane up to scratch rather than banning curiosity. The shadow AI pattern is familiar territory: Shadow AI Is Already in Your Business.

Contracts before more pipes

Before you buy another ingestion tool, write the contract for the first production AI consumer.

• Identity of the dataset: name, grain, primary keys, partition or time column
• Freshness: target lag, breach alert, who gets paged
• Schema: column list with types, nullability, enums where they exist
• Quality gates: row count bands, null rate caps, referential checks the model cannot survive without
• PII and purpose: class per column, allowed joins, retention
• Change process: how a breaking change is proposed, tested against the model golden set, and announced
• Owner and backup: names, not roles alone

Put the contract in the same change discipline as application APIs. If MLOps still lives as a ritual in someone's head, data contracts will be ignored the first time a dashboard deadline lands. Fix the release path too: Your Model Is Ready. Your Release Path Is Still a Ritual.

Agents make weak data louder

Agents that can call tools turn a stale join into a write. If the allowlist is loose and the features are wrong, you get automated wrongness with audit logs. Constrain tools and treat data inputs as part of the same control story. Start with Your Agents Need an Allowlist, Not a Blank Cheque.

Practically: every agent tool that reads customer or risk state should declare which contract it depends on, and fail closed when freshness or schema gates fail. Do not let the model "improvise" from a warm BI extract.

A ninety day path to AI-ready slices

You do not boil the lake. You productise the slices production AI actually calls.

Days 1 to 14. Pick one live or near-live model path. List every table and feature it reads. For each, write current freshness (honest), current owner (honest), and whether a silent schema change would be noticed before customers feel it. That inventory is the backlog.

Days 15 to 45. Publish contracts for those slices only. Add freshness monitors and a schema diff check in the promote path. Label PII classes on the columns in play. Wire lineage links from the scoring job back to the last successful load. Block model promotion when a depended-on contract is red.

Days 46 to 90. Practise a contract breach drill: late load, column type change, unexpected null spike. Confirm alerts hit a rota and the model path fails safe. Only then expand to a second use case that shares the same foundation pain. Resist a multi-year "enterprise data for AI" programme until two consumers share the same contract gaps.

By day 90 you should answer without archaeology: which slices feed production AI, how fresh they must be, who owns a breach, and whether the model can see a red contract before it scores.

Frequently asked questions

Is a feature store mandatory? No. A feature store helps when multiple models share curated features with serving needs. Contracts, freshness, lineage, PII, and owners come first. Buying a store on top of undefined tables just relocates the mess.

Can BI gold tables be reused for AI? Sometimes, if grain and keys match the model window and you add SLAs and change control. Often you need a thinner, purpose-built slice. Reuse the lake storage. Do not reuse BI tolerance for lag and drift.

Who should own the contracts? A joint ownership model works: domain data owner for meaning and PII, platform owner for pipeline reliability, model owner for consumer requirements. One name on the pager for freshness. One name for schema change approval.

How does this relate to RAG corpora? Same idea in document form: authoritative versions, owners, effective dates, and a refresh contract. Prose without those controls is just another swamp with embeddings on top.