Enterprise AI Audit: The 5-Pillar Framework

More than 80% of enterprise AI programs fail to deliver intended value. Ashish Garg's Intelligent PDLC framework, presented at TechEx North America in May 2026, diagnoses why: not bad models, but missing accountability infrastructure. The framework maps five trust gaps: evidence, explainability, inputs, human control, and audit, that must be built before AI-assisted decisions can be defended in a regulatory review, a legal challenge, or an internal post-mortem.

Stefaan Vervaet

July 28, 2026

Ashish Garg, Principal Product Manager and an independent researcher in AI governance and enterprise product delivery, gave a session at TechEx North America in May 2026 titled "The Intelligent PDLC: Engineering Trust Into AI-Assisted Product Delivery." Unusually clear-eyed for a conference stage: a precise diagnosis of why enterprise AI programs break down, and a framework for closing those gaps at the process level.

His central claim: most enterprise AI doesn't fail because the models are bad. It fails because the infrastructure around the models, the ownership, the documentation, the evidence chain, was never built. What follows is a writeup of his framework, his data, and the cases he grounded it with.

For teams whose audit architecture sits at the storage layer, the AI and ML workloads page maps the specific pipeline components Garg's Pillar 5 points to.

‍

The Intelligent PDLC: Five Trust Pillars

The Intelligent Product Development Lifecycle maps five gaps that, independently, kill enterprise AI programs. Teams ship AI into product workflows without building the accountability layer that makes those decisions defensible later.

Pillar 1: Evidence. Can you show what data the AI decision was grounded in? Not the model's training data in the abstract, but the specific retrieval context that shaped this output, at this moment.
Pillar 2: Explainability and Evaluation. Can a non-technical stakeholder understand why the AI produced this output? Less about interpretability in the academic sense and more about whether a PM, a compliance officer, or a customer can follow the reasoning.
Pillar 3: Inputs. Are the inputs to the AI system documented, versioned, and accessible? This covers the prompt, the model version, the retrieval configuration, and any human instructions that shaped the output.
Pillar 4: Human Control. Is there a defined human in the loop, with a documented scope of authority? Who can override the AI, under what conditions, and is that recorded?
Pillar 5: Audit. Can you reconstruct a specific AI-assisted decision from any point in the past? Not a general description of model behavior. A precise replay: what exactly happened with this recommendation, this underwriting decision, this moderation call, at a specific moment three months ago.

He presented these as preconditions for AI that holds up under scrutiny: regulatory review, legal challenge, or internal post-mortem. The takeaway: a decision you can't reconstruct isn't a decision you can defend.

‍

The Numbers That Open the Argument

The session opened with data that should stop any AI program lead in their tracks. More than 80% of enterprise AI projects fail to deliver their intended value, per RAND Corporation research.² A separate Forrester / Anaconda survey found 88% of AI agent pilots never reach production.³

These are not model failures, he argued. The models work. The failure mode is unclear ownership, hidden dependencies, and decisions that cannot be defended after the fact. The 2026 trust numbers compound the picture. A Writer / Workplace Intelligence survey of 2,400 respondents found only 23% of executives see significant ROI from their AI agents, while 67% believe their company has already experienced a data breach from unapproved AI tools.⁴ A Kiteworks 2026 forecast adds that 33% of organizations lack audit trails for their AI systems, and 60% cannot terminate a misbehaving AI agent once it starts operating.⁵ Both, Kiteworks notes, are architecture problems, not model problems.

Adoption is near-universal. Trust is not. The Intelligent PDLC is an answer to exactly that gap.

‍

The Cases That Explain the Urgency

The session grounded the abstract risk with public failures. Air Canada. The airline's chatbot invented a bereavement refund policy. In Moffatt v. Air Canada (BCCRT 149, 2024), the tribunal held the company liable for negligent misrepresentation and rejected the defense that the chatbot was a separate legal entity.¹⁰ The precedent outlasts the modest penalty: companies own everything their AI says.

Google Bard. One hallucinated factual error during the February 2023 launch demo. Stock fell roughly 8%; approximately $100 billion in market cap evaporated in a single trading session.⁶

The growing legal record. The Charlotin AI Hallucinations database has documented over 1,200 court cases involving AI-generated content as of July 13, 2026.⁷ The Sixth Circuit issued $30,000 in sanctions for fabricated AI citations in Whiting v. City of Athens (March 2026).⁸ The Oregon Supreme Court characterized AI-generated falsehoods as outputs the system was designed to produce, declining to treat them as exceptional malfunctions.⁹

None were model failures. All were lifecycle failures. The models produced outputs. No infrastructure existed to hold those outputs accountable.

‍

What a Complete Audit Record for AI Requires?

Pillar 5 is where implementation difficulty concentrates. Garg was precise about what "audit" means here: not a log file, not a dashboard. A record that can be replayed. A complete audit record, in the Intelligent PDLC, includes the inputs to the AI, the prompt version, the model version, the evidence retrieved to ground the output, the output itself, who reviewed it, and what the outcome was. Written once. Auditable through hashing, so any modification after the fact is independently detectable.

That last clause is the hard part. Logging the output is straightforward. Making the log tamper-evident through hashing, so that any change to the record produces a different hash and anyone reviewing it later can confirm no one altered it, requires either a purpose-built database layer or storage that provides this property natively.

‍

What the Framework Gets Right

The value in the Intelligent PDLC isn't that the five pillars are new ideas. It's that Garg has made them operational.

Most AI governance frameworks describe what should be true. The Intelligent PDLC describes what you have to build to get there. The sequencing matters: evidence, explainability, and inputs address what the AI did and why. Human control addresses accountability in the moment. Audit addresses accountability across time.

Skip the first three and try to implement audit first, and there's nothing worth auditing because the record doesn't exist. Implement the first four without audit, and under pressure the record turns out not to be auditable.

The framework also makes failure modes legible to non-technical stakeholders. A CISO or general counsel reading these pillars can map them onto existing compliance obligations and identify which one is missing. That's rare in AI governance literature, and one reason the framework is worth carrying beyond the TechEx audience.

‍

Where Auditable Storage-Layer Infrastructure Can Help?

Pillar 5's implementation requirement, hashing applied so post-write modification is independently detectable, can be met at the database layer or at the storage layer. For teams whose architecture leads toward the storage layer, Akave Cloud is built around that model: an S3-compatible object store with an immutable storage ledger behind it, where any modification to a written object is independently detectable. It maps to Pillar 5's implementation requirement without a separate database layer to keep synchronized. The AI and ML workloads page covers how it maps to the specific pipeline components he described.

That's the supporting role storage can play. The framework and the discipline of the five pillars still belong with the team running the AI program. Garg's session is the better read.

‍

FAQ

What is the Intelligent PDLC?

The Intelligent Product Development Lifecycle is a framework presented by Ashish Garg for embedding AI governance into product delivery. It identifies five trust gaps (evidence, explainability, inputs, human control, and audit) and treats each as a precondition for AI that holds up under scrutiny. It was presented at TechEx North America in May 2026.

What does "reconstruct the decision" mean in the framework?

He argues that an AI-assisted decision without a reproducible record of the inputs, the model version, the retrieval evidence, and the human review isn't a decision an organization can defend. Pillars 1 through 5 exist to make reconstruction possible.

What makes an audit record auditable rather than just a log?

A standard log captures what happened but doesn't prevent alteration after the fact. An auditable record uses hashing so that any post-write modification is independently detectable. If the record has been changed, the hash no longer matches. This is the load-bearing property of Pillar 5.

Where does storage fit into the framework?

Pillar 5 (audit) is the pillar where storage-layer choices matter most. The record has to be durable, retrievable, and tamper-evident through hashing. The property Pillar 5 requires, post-write modification independently detectable because a changed object no longer matches its content hash, can be provided at the storage layer, removing the need for a separate database layer on top. You can review how Akave maps to AI pipeline components in the case studies.

The Intelligent PDLC: A Framework for Engineering Trust Into AI-Assisted Product Delivery