Why Your Next AI Failure Will Be a Storage Failure

Most enterprise AI failures are data failures. In a September 2026 EY survey of senior AI leaders at billion-dollar companies, 72% said they worry about being unable to trace or audit the data lineage and inputs feeding critical AI decisions, and their AI assurance reviews found data quality problems (57%) more often than model drift (48%). In a Cloudera study fielded the same summer, 95% of enterprises had delayed or cancelled AI initiatives over data governance, compliance or regulatory challenges, and 72% said their data architecture needs a significant overhaul.

We build data infrastructure for regulatory and financial reporting, where every number has to be traceable. In our experience the problem is rarely the model. It is whether each layer of the data platform overwrites data or keeps its history.

Three storage design patterns, and only one is auditable

Let's take an example. A bank runs an AI agent that drafts its quarter-end credit risk summary. For the quarter ending 30 June, it reported exposure of $12.4 million to the borrower with identifier B-1042: the amount outstanding on the borrower's loans, minus the collateral held against them. The figure came from a report generated automatically from the data layer. A risk controller approved it, and it was submitted to the regulator.

On 28 July, an analyst finds that a collateral revaluation on the borrower's loan L-2041, from $4.1 million to $4.6 million, was never loaded. The source system sends a new file, the collateral record is corrected, and exposure drops to $11.9 million.

In October, the supervisor's data quality review asks: "Your June return says $12.4 million. Your systems say $11.9 million. Explain the difference." The same correction plays out very differently depending on how each layer stores data.

SELECT l.borrower_id,
       SUM(l.outstanding - c.value) AS exposure
FROM   core.loans l
JOIN   core.collateral c ON c.loan_id = l.loan_id
WHERE  l.borrower_id = 'B-1042'
GROUP  BY l.borrower_id;          -- 12,400,000

-- staging: truncated and reloaded
TRUNCATE stg.collateral;

-- hub: corrected in place
UPDATE core.collateral
SET    value = 4600000             -- was 4,100,000
WHERE  loan_id = 'L-2041';

-- mart: rebuilt from the hub
TRUNCATE mart.borrower_exposure;
-- the same query now returns 11,900,000

-- Bronze keeps both extracts:
--   collateral_0630  L-2041  4,100,000
--   collateral_0728  L-2041  4,600,000

-- Silver: corrected in place
MERGE INTO silver.collateral t
USING bronze.collateral_0728 s ON t.loan_id = s.loan_id
WHEN MATCHED THEN UPDATE SET t.value = s.value;

-- Gold: rebuilt by joining loans to collateral
INSERT OVERWRITE gold.borrower_exposure
SELECT l.borrower_id, SUM(l.outstanding - c.value)
FROM   silver.loans l JOIN silver.collateral c USING (loan_id)
GROUP  BY l.borrower_id;          -- B-1042: 11,900,000

-- a week later, routine clean-up
VACUUM gold.borrower_exposure;

seq layer  op      file ver reason                 by           from
41  gold   ADD     g07  v14 Q2 aggregation         pipeline     s12,s13
42  gold   APPROVE -    v14 Q2 sign-off; filed     risk/ctrl-02 -
56  bronze ADD     b30  v8  L-2041 valuation 4.6M  source-sys   -
57  silver REMOVE  s12  v6  fix: reval not loaded  analyst-07   -
58  silver ADD     s19  v6  L-2041 4.1M -> 4.6M    analyst-07   s12+b30
59  silver APPROVE -    v6  correction sign-off    risk/ctrl-02 -
60  gold   REMOVE  g07  v15 restate from silver v6 pipeline     -
61  gold   ADD     g09  v15 restate from silver v6 pipeline     g07+s19
62  gold   APPROVE -    v15 restatement sign-off   risk/ctrl-02 -

-- snapshot_files(table, v): the files the log had added,
-- and not removed, as of version v
SELECT 14 AS ver, SUM(exposure) AS exposure
FROM   read_parquet(snapshot_files('gold.borrower_exposure', 14))
WHERE  borrower_id = 'B-1042'
UNION ALL
SELECT 15, SUM(exposure)
FROM   read_parquet(snapshot_files('gold.borrower_exposure', 15))
WHERE  borrower_id = 'B-1042';

-- ver  exposure
-- v14  12,400,000   what was reported and filed
-- v15  11,900,000   after the approved correction

Data auditability vs data governance

The two terms are often used interchangeably. The example shows they are different jobs, done at different points in the storage layer.

In Design C, auditability is rebuilding Gold v14 (the $12.4M June figure) and showing the log entries, rows 56–62, that turned it into v15 ($11.9M). It is a property of how data is kept and read back.

In Design C, governance is refusing any change without an author and a reason, and requiring a manual correction to be signed off before its version is certified for reporting. It is a property of how data is allowed to be written.

Every approved version, traceable across layers

What makes Design C auditable is not that it has Bronze, Silver and Gold layers; Design B has those too. It is that every version of every layer stays available, each one records exactly which versions of the layer below it was built from, and the versions certified for reporting are marked as approved.

Read across a row and you have the full lineage of a reported number: Gold v15 was built from Silver v6, which was built from Bronze v8. This linkage moves the usual audit requests from rerunning pipelines or hunting for files to simple queries:

1. Reproduce history.
   • Open the approved Gold version, v14, and query the records behind the $12.4M figure.
   • Check each file against the checksum recorded when it was written.
2. Trace its lineage.
   • Follow the version from step 1 through its recorded links down to the raw layer: Gold v14 to Silver v5 to Bronze v7, the collateral_0630 file.
3. Explain the changes.
   • Compare two approved versions at each layer, such as Gold v14 and v15, or Silver v5 and v6.
   • List the changes between them, each with its author and reason.

Because nothing is ever overwritten, auditability is stored with the data itself. Whether a change was made by an AI agent or a person, the previous version is still there for the auditor.

AI agents now change data, not just read it

People and pipelines used to be the only writers to enterprise data. Now AI agents are too, and most controls have not caught up:

• 49% of organizations using AI agents say their governance rules do not cover them yet (EY).
• 87% of IT and security leaders have seen or suspected an AI agent reaching data it did not need for its task (Delinea).
• In July 2025, an AI agent wiped records from a live production database, then filled it with about 4,000 made-up ones (eWeek).
• In 2026, researchers at Cyera reviewed real enterprise AI agent failures and found 23 cases of hidden integrity damage: fabricated records, silently reverted human edits and corrupted data.

The fix: treat an agent like any other writer. It cannot edit or delete data directly. It hands over a new file, the file goes through the same checks as any other load, and the log records which agent made the change, for whom, and why.

Because nothing is overwritten, an agent that gets it wrong cannot destroy anything. The previous version is still there.

A business context: BCBS 239 is still elusive

Banks have been asked to solve this problem for more than a decade. In 2013, the Basel Committee published BCBS 239, its principles for how banks should gather and report risk data. The core idea is simple: a bank should be able to show where every risk number came from.

Ten years later, most still cannot. According to Deloitte's summary of the Basel Committee's 2023 progress report, only 2 of the 31 large banks assessed were fully compliant. The reasons were familiar: data spread across many systems, old technology, and too much manual work. Since 2024, the European Central Bank has gone further and expects banks to trace each reported figure all the way back to its source, field by field.

From where I sit, the lesson is direct. A bank that cannot show this lineage to its regulator cannot show it for an AI model either, because both read from the same storage. Fix the storage once, and you answer both.

Four questions to ask before your next AI pilot

Pick one table your AI will use, and ask your data team to answer these. Each should take a query, not a project.

1. What did the AI see? Take an answer it gave last month. Can you show the exact version of the data it used?
2. Who changed it, and why? Take one value that was corrected. Can you show who changed it, when, why, and what it was before?
3. Can you rebuild it? Can you show the reporting data exactly as it stood three months ago, without restoring a backup or rerunning a pipeline?
4. Was it approved? Can you show that the version the AI used was the approved one?

If any answer is "not easily", the risk in your AI initiative is not the model. It is the storage underneath it, and it will show up the first time someone asks your AI to explain a number.

Frequently asked questions