The AI Data Supply Chain: Why It Should Start With Your Systems of Record
Craig Mullins highlights the importance of understanding what's happening to AI data at every step of the journey, from source to application
Artificial intelligence has changed the way organizations think about data. Or, at least, it should have.
For a long time now enterprise data strategies primarily involved collecting, storing and moving data. Build a warehouse or build a data lake. Then move it to the cloud. Stream it somewhere else. Make another copy for analytics. And then make another copy because somebody needs a slightly different version.
AI changes the equation because collecting data is no longer enough. AI requires data that can be trusted, understood, governed and delivered with sufficient context to produce useful results. That means organizations need to start building their AI data supply chain.
Just as a manufacturing supply chain traces raw materials through processing, assembly and delivery, an AI data supply chain traces information from where it originates through the various stages that prepare and deliver it to an AI application.
And that supply chain should begin with the enterprise system of record.
Where Does Business Truth Begin?
Consider the typical enterprise AI architecture. The business concerns itself with large language models, vector databases, embeddings, retrieval-augmented generation (RAG), agents and prompt engineering. And yes, all of those technologies are indeed important. But they are downstream components.
Before asking which model to use, organizations should be asking a more fundamental question, namely, “Where does the information that the model needs originate?”
For most large enterprises, the answer is operational systems. Customer accounts, financial transactions, insurance policies, inventory levels, airline reservations, payments, orders and other critical business information originate in systems designed to process the business.
And for many larger organizations, those systems run on IBM Z using Db2 for z/OS, IMS, VSAM, CICS and other mainframe technologies.
These are systems of record for a reason. They were engineered to maintain transaction integrity, enforce business rules, protect information and reliably process enormous volumes of work.
AI does not eliminate the importance of these characteristics. It only makes them more important.
Think Supply Chain, Not Data Pipeline
We tend to talk about data pipelines when discussing AI. But I prefer the term data supply chain because a pipeline implies that the primary challenge is transportation. You know, “let’s move data from Point A to Point B.” And yes, that is certainly part of the problem, but it is not the whole problem.
An AI data supply chain might look something like this:
At every step, something can happen to the data. It may be copied, transformed, summarized or combined with other data. Its name may change. Its definition may change. Its freshness may deteriorate. Metadata may disappear. Lineage may become difficult to trace.
By the time information reaches the AI model, it may bear only a passing resemblance to the authoritative information from which it originated. And therein lies the problem.
The objective of an AI data supply chain should be to deliver trusted business information while preserving meaning, lineage, governance and currency along the way. All too often the goal is minimized to merely delivering data to AI.
Distance From the Source Creates Risk
There is a useful principle to keep in mind when designing AI architectures: The farther enterprise data travels from its authoritative source, the greater the opportunity for context and trust to decay.
Let’s consider an example. Suppose a customer’s account balance resides in Db2 for z/OS. Within the operational application, that value has a specific meaning. Business rules govern how it is calculated. Transactions determine when it changes. Security controls determine who can access it. Recovery procedures protect it. Audit mechanisms document what happened to it.
Now extract that balance into another platform. Then transform it. Combine it with data from several other sources. Load it into a data lakehouse. Copy part of it into another analytical environment. Convert associated information into embeddings. Store those embeddings in a vector database.
Finally, we retrieve fragments of the information through RAG and provide them to an AI model. At that point, you should have several questions.
- How current is the information?
- What transformations were applied?
- Which source supplied it?
- What business definition was used?
- Is the original security classification still being enforced?
- Can the result be traced back to the authoritative record?
These are not theoretical governance questions. They determine whether an enterprise can trust the AI system.
Data Movement Has a Cost
There is another issue that architects sometimes underestimate: enterprise operational data resists movement. That is not because mainframe professionals are stubborn or because somebody forgot to modernize. Operational data tends to remain where it is because moving it can be difficult and expensive.
Scale is one reason. Large organizations may have decades of transactional history encompassing enormous volumes of data. Operational dependencies are another. Applications, transactions, batch processes, reporting systems and downstream interfaces may all depend on the same data.
Then there are governance and compliance requirements. Moving regulated or sensitive information to additional platforms increases the number of environments that must be secured, monitored, audited and governed.
And finally, there is business continuity. The system of record exists to run the business. Any architecture that jeopardizes its availability in pursuit of an analytical or AI workload has its priorities backward.
The resistance of data to move off platform for all of these reasons is sometimes referred to as data gravity.
Of course, this should not mean that data can never move. Sometimes replication, streaming and transformation are exactly what is required. At any rate, data movement should be an architectural decision, not an automatic assumption.
Bring AI to the Data When It Makes Sense
The dominant analytical pattern we see is to move operational data to wherever the analytical processing occurred. But AI gives us an opportunity to reconsider that assumption.
Increasingly, some analytical and AI processing can occur closer to the system of record. IBM, for example, continues to develop capabilities for accessing, analyzing and applying AI to IBM Z data without requiring every workload to extract all of that data to another platform.
That does not mean everything should run on the mainframe, either.
The future enterprise is hybrid. Some AI capabilities will run on IBM Z. Others will run in private clouds, public clouds or specialized AI infrastructure. Data may be streamed or replicated where doing so provides legitimate business value.
The architectural goal should therefore not be “keep everything on the mainframe” any more than it should be “move everything to the cloud.”
The better question is, “Where should processing occur to maximize business value while minimizing unnecessary data movement, latency, cost and governance risk?”
That is a much more useful modernization question.
Don’t Forget the Meaning
There is another component of the AI data supply chain that deserves more attention: metadata.
An AI system needs more than values. It needs context, and that is provided by metadata.
Consider a database column named BALANCE. Is that the customer’s current balance? Available balance? Ledger balance? Outstanding loan balance? Balance before pending transactions? Balance at the end of the previous business day?
A human who has worked with the application for 20 years may know immediately, but an AI model does not.
Metadata, data definitions, relationships, lineage, business rules and semantic context therefore must become essential parts of the AI supply chain.
This is where decades of accumulated enterprise knowledge become extremely valuable. The schema, constraints, application logic, data definitions and operational procedures surrounding systems of record represent institutional knowledge.
Throwing away that context while extracting the raw values is like shipping a machine without the instruction manual and expecting somebody else to operate it correctly.
Distributed Architecture Doesn’t Make the Problem Disappear
Modern architectures are frequently distributed by design. Data may reside on many platforms across the mainframe, cloud platforms, SaaS applications, data lakehouses and specialized databases. Distribution delivers tremendous flexibility, but it also introduces three persistent challenges: latency, consistency and synchronization.
Every additional copy of operational data creates another version that must remain synchronized with the authoritative source. Every network boundary introduces latency. Every transformation introduces another opportunity for differences in meaning or interpretation.
AI magnifies these problems because AI applications increasingly expect fresh information.
An AI agent making a decision based on yesterday’s customer balance may be worse than having no AI at all, because the organization may mistakenly assume that the answer is current.
Real-time AI requires real-time data discipline.
Protect the Chain
As enterprises build production AI systems, DBAs, data architects and governance professionals should begin treating the AI data supply chain as critical infrastructure.
That means being able to answer some basic questions.
- Where did this data originate?
- Who owns it?
- What transformations occurred?
- How current is it?
- Which business definition applies?
- What security classification does it carry?
- What applications depend on it?
- And can we trace an AI result back to the information that influenced it?
If those questions cannot be answered, the organization does not have a trustworthy AI data supply chain. It merely has data flowing into an AI model. There is a big difference!
Start Where the Truth Lives
There is an understandable tendency to spend a lot of time discussing AI models. Models are new, exciting, and advancing rapidly, so they naturally attract attention. But over time, models will increasingly become interchangeable components of the enterprise technology stack. Organizations will be able to choose among models, replace them, or use multiple models for different purposes. The model itself, therefore, does not provide a sustainable competitive advantage.
The more valuable and differentiated asset is the organization’s data. Proprietary enterprise data, especially trusted operational data accumulated through years of business activity, contains the unique knowledge, history, relationships and context that competitors cannot easily reproduce.
An organization’s trusted, contextualized, proprietary operational data already exists. And it is unique to each organization. This data represents the customers you serve, the products you sell, the transactions you process, the policies you administer, the inventory you manage and the money flowing through the organization.
And for many of the world’s largest enterprises, much of that information resides on IBM Z. This is why the mainframe continues to be an important asset for large enterprises.
So, as organizations build their AI strategies, it will be wise for them to resist the temptation to begin at the end of the supply chain. That is, don’t start with the model or the vector database or even with RAG. Start with the question that database professionals have been asking for decades: “Where is the authoritative data?”
Find the system of record. Understand the data. Preserve its context and governance. Then determine the most appropriate way to deliver that information to AI.
Because the AI data supply chain does not begin with AI itself, it begins with business truth. And that is your operational data.