[Medium Article] The Database and AI Revolutions: A Useful Parallel
date posted: 2026-Aug-29, last edit date: 2026-Aug-29
Originally published on Medium, August 29, 2026.
TL;DR
Databases became infrastructure through abstraction, then trust. The relational model replaced imperative record-walking with a declarative interface: state the what, let the database work out the how. Then organisations built the controls, roles, and discipline needed to depend on this new technology.
AI is in the same transition, with two differences. It has no broadly adopted abstraction yet, and it is probabilistic rather than deterministic. In a database, the path to the answer only affects speed. In AI, the path to the answer can change the answer.
The missing layer is not better models, or even better AI engineering. For AI, stating the intent is the easy half. The hard half is meaning, verification, governance, and the people accountable for them.
1. What Databases Taught Us About Abstraction
Early applications stored their data in files, and each one was welded to how its files were organised. Change the layout, and the application broke. The first database systems improved on this less than people assume: the hierarchical and network databases of the 1960s and 70s were navigational, meaning the programmer still wrote code that walked the structure record by record. The database managed the storage; the programmer still managed the path.
Then, in 1970, Edgar Codd proposed the relational model, built on the idea of data independence: an application should not need to know how data is physically stored in order to use it. SQL made the idea practical:
SELECT customer_id, name FROM customers WHERE balance > 10000;Whoever writes this does not say where the data sits, which records to read first, or whether to use an index. That is what makes SQL declarative, and it is the whole point. The shift was not from files to databases. It was from tell the system how to find the data to tell the system what data you want.
2. AI Is Heading Toward Execution Independence
AI is moving toward a similar separation. It looks declarative: summarise this contract, investigate this transaction. However, that is declarative in a weaker sense than SQL: SQL has formal semantics; AI does not yet.
For a while, that declarative surface sat on hand-written procedural code. The application chose the model, retrieved documents for context, built the prompt, parsed the result, called other systems, checked, and looped. The developer was writing the execution plan by hand. That is changing: modern platforms increasingly own the loop themselves, allow an agent to be defined through instructions, knowledge, and constraints rather than coded, and separate what a task is from how it is executed.
However, the AI declarative layer is fragmented: every platform defines agents, tools, knowledge, and constraints in its own way, and none provides what the relational model provided for data — a broadly accepted model everyone builds on. Which is why the usual question is the wrong one:
Not “what is the SQL of AI?”
But “what is the relational model of AI?”
To see what that abstraction could look like in practice, imagine a bank application expressing this:
Review this customer’s situation and determine whether a credit-limit increase is appropriate, using approved customer information and the bank’s current credit policy. Escalate any case where the evidence is insufficient for a reliable decision.
It states intent, boundaries, and expected outcome, and says nothing about how. Something underneath works out execution: which model reasons, how many agents, in what sequence. Call this execution independence — the AI analogue of data independence. A better model appears next year: the application does not change. The credit policy changes: it changes in one place. An auditor asks why a customer was declined: the platform produces the record.
That is the destination. With one caveat — and it is the important one.
3. Where the Analogy Breaks: The How Can Change the What
A database may execute a query in several ways: scan the table, use an index, reorder the work. Many plans are possible, and every valid one is expected to preserve the meaning of the query. With a database, the how only affects speed and cost.
AI cannot promise that. An agent that reviews 6 months of credit history and one that reviews 24 months may reach different conclusions. Two systems given the same objective may interpret it differently, consult different information, and reach different results; the same system may answer differently tomorrow. In AI, some of the how changes the what.
This is the turning point, and it defines what an AI abstraction has to be. Anything that can change the answer cannot be hidden behind the abstraction; it must move out of execution and into the declared intent. That is why the example above names its objective, its evidence, its policy, and its boundary. Independence from the model is achievable. Independence from the evidence is not — the intent has to own it.
This is the core argument of this article: AI needs an abstraction that separates declared intent from execution, but unlike the relational model, that abstraction must carry meaning, evidence, policy, and accountability, because in AI the execution can affect the answer.
And because AI’s answers are not guaranteed to repeat, trust cannot come from system guarantees alone, the way it does with database transactions — it has to be built around the decision itself.
Banks already govern decisions that cannot be replayed. Consider a credit committee approving a corporate facility. The decision is not reproducible — convene a different committee, or the same one a month later, and the outcome might differ. It is trusted anyway, because everything that matters is on record:
evidence considered → policy applied → reasoning given → conditions attached → who signed
AI infrastructure may end up looking less like database administration and more like that.
4. What Dependable AI Infrastructure Requires
If execution is independent and the how can change the what, three things have to live above the execution layer: meaning, verification, and ownership. And they are not three separate ideas but three consequences of the same one.
Meaning
If applications no longer encode the execution logic themselves, something else has to anchor what their requests mean. A business user asks: which customers are showing signs of increased risk? What is a customer — an individual, a household, a legal entity? What is risk — credit, fraud, money laundering, attrition? Which source is authoritative? Models are very good at interpreting language; that does not mean they understand the meaning this organisation assigns to its data, policies, and decisions.
Natural language removes the need for users to know the schema. It does not remove the need for a schema to exist.
Two established ideas from data management point toward that schema. The semantic layer, familiar from business intelligence tools, translates business vocabulary into physical data so that “active customer” means one thing everywhere. The ontology models what the business is made of and how it relates — a customer holds accounts, a policy applies to a product, a decision references a policy and is approved by a role. Neither is new. What changes with AI is their importance: shared semantics becomes a prerequisite for trust, not a reporting convenience.
And this applies to unstructured content as much as to tables — arguably more. Most of what an enterprise AI reads is documents: policies, contracts, correspondence. The point is not to force structure onto that content; it is to govern its meaning: which document is the authoritative version of the credit policy, what concepts it defines, who owns it, and how current it is. The content stays unstructured. The map of what it means cannot. And one difference from database schemas must be accepted from the start. A database schema can formally define every structure the system operates over; AI must also interpret concepts and questions that were never fully specified in advance. So this schema is never complete. It has to remain a living, owned artefact — someone’s job is to keep extending it.
Verification
Shared meaning solves interpretation. It does not solve correctness: even with the same intent, evidence, and policy, an AI system can still produce a wrong answer that looks right. AI tooling is already good at execution tracing — recording model calls, retrieved information, tool use, intermediate steps. But a trace is not the same as decision lineage.
A trace says: model → retrieval → tool → model → result.
Decision lineage, for a hypothetical flagged transaction, says: intent → authorised evidence → applicable policy → reasoning and confidence → controls applied → action → accountable owner.
An execution trace tells us what the system did. Decision lineage tells us why the organisation allowed the decision to happen.
The distinction matters because a model’s explanation of itself is not evidence; it can be fluent and wrong. Lineage has to be anchored in things that can be checked independently of the model: which records were authorised, which policy version applied, which threshold triggered review, who confirmed the action. A lineage does not prove the decision was right. It makes the decision contestable, which is what accountability actually requires. Execution tracing is increasingly mature. Decision lineage is much less so.
Ownership
As database infrastructure matured, informal responsibilities became formal roles — administrators, modellers, stewards, security, audit — because organisations learned the hard way that a capability without ownership is a liability. AI is at the same point: the capability exists, the ownership mostly does not. Which function holds each responsibility will vary by organisation; the point is that someone must own it.
The organisational functions largely exist — a bank already has data architects, information security, model validation, and internal audit. Their AI mandate and capability often do not, and extending the mandate without building the capability produces sign-off without scrutiny.
If I had to pick one role as the highest priority, it would be the first. The semantics role is the most important and the furthest from the technology.
Organisations that skipped data modelling in the database era paid for it for decades. There is no reason to expect AI to be more forgiving. The ontology and semantic layer are the same debt; AI only compounds the interest.
Closing Thought
Databases did not become infrastructure because computers learned to store data. They became infrastructure because an abstraction emerged — applications declaring what they wanted, the system owning how — and because organisations built the meaning, controls, and roles needed to trust it. AI is partway through the same transition, with the one difference that changes everything downstream: its execution can change its answers, so its abstraction must carry meaning, evidence, policy, and accountability, not just intent.
The models will keep improving without any help from us. The abstraction, the semantics, and the accountability will not. Those have to be built, and the organisations that build them will be the ones that get to depend on AI rather than merely experiment with it.
Further reading: Anthropic’s account of building self-service analytics with Claude is the practitioner’s version of this article’s argument — semantic layer first, definitions owned by humans, provenance on every answer: How Anthropic enables self-service data analytics with Claude.