Foundation-first AI starts with a different question than most teams ask. Most teams start AI conversations with platform selection. Fabric, Databricks, Snowflake, “which LLM,” “which vendor.” That is a signal that the organization is looking for certainty in a tool decision.
The organizations that ship useful AI do the opposite. They decide what must be true before automation touches a live workflow. They treat AI as applied execution on top of a credible foundation.
Here is the order of operations we see in environments that produce results.
AI only matters when it changes a decision or a workflow. “We want AI” is not a requirement. “We want to reduce expedite cost” is.
What good looks like:
Before models, identify the authoritative source for each key input. If inputs come from three systems and two spreadsheets, the model will learn inconsistency.
What good looks like:
If definitions drift, AI outputs drift. Ownership is the mechanism that prevents drift.
What good looks like:
AI is not a prototype environment problem. It is production operations.
What good looks like:
Once the first four steps are complete, platform selection becomes straightforward: you choose based on fit, existing stack, cost profile, and team capability.
The reverse order creates the most common failure pattern: a platform decision is made, a pilot is built, outputs are challenged, and the program stalls.
If your AI initiative hasn’t produced results, the foundation is the first place to look, not the platform. A data readiness assessment identifies which of these five steps is missing before you commit to another pilot.
Author: Bill Turosky
Foundation-first AI means settling the decision, data source, ownership, and operational readiness before choosing a platform or model. Platform selection becomes the last step, not the first.
Choosing a platform before the foundation is settled locks in assumptions about data and ownership that usually turn out wrong. Teams then rebuild the pilot instead of scaling it, because the platform choice masked problems that were never fixed.
Four things: a defined decision the AI is meant to support, an authoritative source for each key input, documented metric definitions with clear ownership, and an operational environment with observability and rollback paths. Skipping any of these shows up later as AI outputs nobody trusts.
Readiness means the decision is defined, data sources are authoritative, definitions are owned, and the environment can support production operations, not just a prototype. Once those four are in place, platform choice becomes a fit-and-cost decision, not a bet.
They overlap heavily but aren’t identical. Data readiness covers sources, definitions, and ownership. AI readiness adds the operational layer on top, observability, change management, and rollback paths, since AI in production fails differently than a dashboard does.
Yes, as long as the pilot’s scope matches what the current foundation actually supports. Problems show up when a pilot’s success creates pressure to scale before the underlying data and ownership issues get fixed.
