By Kapil Raval · August 2026 · 4 min read
Enterprise technology has spent forty years trying to manufacture trust through certificates, seals and attestations. Most of those attempts failed — and they failed in the same way, repeatedly.
I filed a submission to the federal consultation on AI transparency today. One theme surfaced in almost every section of it, and it has very little to do with AI.
Every decade, our industry produces a new mechanism for proving that a system can be trusted. And every decade, most of those mechanisms quietly stop meaning anything.
The 1980s and 1990s gave us security evaluation. The Orange Book, and later Common Criteria, promised buyers a certificate confirming a system was secure. The problem was arithmetic: evaluations took years against products that shipped in months. Buyers stopped believing the certificates long before the schemes were formally retired.
The 2000s gave us process certification. CMM and ISO 9001 certified that you documented your process. Sarbanes-Oxley certified that financial controls existed. None of them certified that the product worked, or that the controls did anything once they existed.
Then there is SOC 2 — the one that genuinely worked. It is worth understanding why. SOC 2 replaced hundreds of bespoke customer security questionnaires with a single reusable artifact. It lowered cost on both sides of the table. That turns out to be the best single predictor of whether a trust mechanism survives or decays into paperwork.
The clearest pattern is self-certification. Safe Harbor. Then Privacy Shield. Then TRUSTe. Three attempts at an identical architecture — organizations certifying their own compliance — and three failures. Two were struck down by the courts. The third drew regulatory action for not conducting the reviews it advertised.
Voluntary AI commitments are built exactly the same way.
And independent audit is not sufficient on its own either. New York City now requires a third-party bias audit of automated hiring tools, with published results. A study of 391 employers found fewer than twenty had posted one. The city’s own comptroller later found that most complaints never reached the enforcing agency. An audit obligation works only where someone can raise a complaint and someone is required to act on it.
The person who installed the system and answered the phone when it broke.
Through the 1980s and 1990s, enterprise software was sold through value-added resellers. What the buyer trusted was not the vendor’s documentation. It was the local firm that showed up, configured the thing, and took the call at seven in the morning when it stopped working.
That trust was real, and it had two genuine defects: nobody outside the room could verify it, and it did not scale. Which is precisely why the industry spent the next thirty years trying to replace it with paperwork.
It did not work. The intermediary is still where the commercial relationship lives, regardless of how much documentation the large vendors produce.
For anyone selling technology through partners, this history has practical consequences.
Your disclosures probably stop at the reseller. You publish documentation. Your partner configures, customizes, and sells. Nothing ensures the customer ever sees what you wrote — or learns what was changed after it left you.
When something breaks, the customer calls the party least able to explain it. Fault sits somewhere between the developer, the integrator, and the deploying business. The first call goes to whoever shook hands.
The fix is contractual, not technical. Whoever configures a system for a customer should pass on the original disclosures plus a plain statement of what they changed. That is a clause in an agreement, not a platform investment.
It is a channel problem that AI has made more expensive to ignore. The gap between what a vendor documented and what a customer actually understands is now the gap where real harm happens.
Forty years of evidence points the same direction. Trust does not live in the certificate. It lives in the relationship. Any framework that addresses only the developer and the end user is addressing the two parties who almost never speak to each other.
That was the argument I put to the consultation. I will publish the full submission once the consultation period closes.