Before AI, the Data Platform Has to Hold

Personal content — not employer-related. This article is published in a personal capacity and shares thoughts and experiences based on public industry patterns — not a description of employer or client systems, and not professional instructions. It does not reflect the views, systems, projects, or policies of any current or past employer, client, or financial institution. See the full site disclaimer.

Most AI projects fail before the model is the problem. They fail because the platform underneath cannot answer freshness, ownership, lineage, or trust. This is the scorecard I keep coming back to when serious AI or agent work is on the table.

Context: By autumn 2025 enterprise AI had moved from “build a demo” toward “run in production”. Agents and RAG stacks were no longer exotic. In programs I touched, the bottleneck was rarely the model. It was whether the platform could feed, govern, and measure AI reliably.

When nobody could say when a table was last updated, who owned it, or whether yesterday’s numbers reconciled with finance, adding a vector database or an agent framework did not fix that. It amplified the mess.

Notes from migration work, batch scoring pipelines, and personal lab experiments on public cloud - not from any employer context.

The pattern I kept seeing

Leadership asks for a copilot, recommender, or agent that “uses our data”
Team spins up Vertex AI, OpenAI, or an internal gateway quickly
Demo works on a curated sample
Production breaks on freshness, permissions, definitions, lineage, cost, or silent pipeline failures from three weeks ago

The model was never the first failure. The platform was. AI exposes weak data platforms faster than BI ever did.

What “AI-ready” meant in practice

AI-ready data platform layers

Not “we bought a lakehouse” or “we deployed an LLM”.

It meant the platform could consistently provide:

Capability	Why it mattered
Trusted inputs	Models amplify bad data
Known freshness	Retrieval and features need “as of when?”
Clear ownership	Someone must fix breaks
Lineage and audit	Incidents and compliance need provenance
Predictable cost	AI multiplies reads and enrichment
Safe access boundaries	Agents need least privilege, not warehouse admin

If you cannot do this for a batch report, you will not do it for production AI.

Five foundations that had to move first

1. Layered architecture. Landing -> curated -> serving -> feature/context. Red flag: every AI project rebuilds “customer 360” from scratch. Publish serving tables and contracts for entities AI will touch.

2. Quality with teeth. Freshness SLAs, reconciliation, schema drift detection, quarantine - not a dashboard that says 98% complete while the missing 2% is revenue or consent.

3. Orchestration you can explain. One source of truth per domain, explicit dependencies, idempotent partitions, run metadata. Honest freshness tiers: seconds / minutes / daily - not fake real-time everywhere.

4. Ownership, lineage, access. Business owner, technical owner, access class. Least privilege for humans, services, and agents. An agent with broad warehouse access and no approval flow is an exfiltration pattern waiting for a prompt.

5. Cost as design. Partition for real filters. Materialize heavy joins. Budgets and kill switches. AI makes expensive mistakes show up weekly, not quarterly.

Scorecard I still use

Architecture: layered paths · serving matches access patterns · versioned feature/context
Quality: freshness · reconciliation · drift/quarantine
Operations: real dependency graph · idempotent partitions · runbooks with owners
Governance: named owners · lineage to model input · least privilege
Economics: cost-reviewed patterns · freshness tied to schedules · budgets and kill switches

12-15 -> production-ready. 8-11 -> bounded pilots. Below 8 -> fix the platform first.

I kept a rough score sheet as YAML for intake reviews (personal notes / lab style):

use_case: support_case_summary
datasets:
  - name: curated.cases
    freshness_sla_min: 60
    owner_business: support-ops
    owner_technical: data-platform
    score_architecture: 2   # 0-3
    score_quality: 2
    score_ops: 1
    score_governance: 2
    score_economics: 2
total: 9   # bounded pilot only until ops improves

First 90 days when recovery was possible

Weeks 1-4: Inventory AI-critical datasets; freshness and ownership metadata; draw the real pipeline graph; reconcile top revenue/compliance tables.

Weeks 5-8: Kill duplicate pipelines; publish serving tables; drift checks; access classes.

Weeks 9-12: Version feature tables; audit automated retrieval; cost ceilings; contracts for agent entities.

From the leadership seat

When leadership asked to “do AI” this quarter:

I would not approve model spend before a platform scorecard on the datasets in scope. Below 8 -> bounded pilot only, with a named platform track in parallel.

I tried to split capacity: a real share of the initiative for ownership, contracts, freshness, access - packaged as part of the AI work so it did not get deprioritized as “platform”.

Kill criteria upfront - time saved, override rate, cost ceiling, reversibility.

One executive for definitions when marketing, finance, and product disagree on “customer” or “revenue”. That is not an LLM problem.

Protect the best engineer from hero mode. If one person is the only one who understands the graph, you are person-dependent, not AI-ready.

Closing

Production AI needs a platform that can answer: what data was used, how fresh, who owns it, what happens when it breaks, what it cost. Those answers had to come first.