Presto Automation and Nate Inc. did not get caught lying about what their AI could do. They got caught not noticing that what their AI could do had changed. Both companies described autonomous AI systems to investors in language that was accurate at the moment it was written. Neither company had a mechanism for finding out when it stopped being accurate. The SEC's Cyber and Emerging Technologies Unit, formed in February 2025 specifically to close this gap, did the finding for them. That is the enforcement pattern now operating against every organization that has made a public claim about what its AI system does: the claim was true once. Nobody has checked since.
This is not a story about dishonesty. It is a story about an infrastructure gap that most boards do not yet know exists, because the gap does not look like a governance failure until an examiner, a plaintiff's attorney, or a due diligence team finds it first.
This analysis was developed in the Ethics as an Advantage: Why Trust Will Be the Most Valuable Currency in the 2026 Economy Executive Leadership Playbook, which includes a functional white paper for the CIO and CTO audience on building the technical verification infrastructure this piece describes.
The claim decays even when nobody lied
AI systems are not static. A model's performance shifts as the data it encounters in production diverges from the data it was trained on, a phenomenon with a name, model drift, and a well-documented tendency to happen quietly. Customer behavior changes. Input patterns shift. The proportion of transactions a system can complete without a human stepping in moves, usually in the wrong direction, without triggering any alarm on a dashboard built to track uptime rather than capability decay.
The public claim, meanwhile, does not move. "Our platform autonomously processes customer orders using AI" was written once, approved once, and left in the investor deck, the product page, and the earnings call script indefinitely. Six months after that sentence was approved, the system it describes may be completing a materially smaller share of those orders without human intervention. Nobody rewrote the sentence, because nobody was assigned to check whether the sentence still described reality. That is the exact gap the SEC's Presto Automation settlement and its parallel action against Nate Inc. both turned on: engineering logs and operational dashboards told one story, investor communications told another, and the organization had no process that would have caught the divergence before an examiner did.
The document that would have stopped it
The technical fix is not exotic. It is a document, issued on a schedule, by someone with the authority to withhold it.
Call it a Technical Verification Certificate. It states the exact claim being made, the current performance data supporting that claim, the human intervention rate the claim either discloses or omits, and a re-verification date, the point at which the certificate expires and the claim must be checked again before it can keep running in investor-facing material. The certificate is not issued once at launch and forgotten. It is issued against performance data no more than ninety days old, because a certificate built on stale data has already answered a different question than the one an examiner will ask.
Behind that certificate sits a Capability Specification, a technical description precise enough to be tested: not "AI-powered order taking" but the completion rate, by transaction category, measured against a defined test set, as of a stated date. And behind the specification sits ongoing monitoring, a drift alert that fires when performance crosses a threshold the organization set in advance, routed automatically to the person accountable for the claim rather than left to surface on its own in a quarterly review. An organization that can produce this chain on request, on the day an examiner asks for it, is answering a factual question with evidence. An organization that cannot produce it is answering with a policy document, and a policy document has never once satisfied a securities examiner asking whether a specific claim was true on a specific date.
Whose job this actually is
The reason this infrastructure rarely gets built is not technical difficulty. It is a boundary failure. The Governance Boundary Principle holds that the board governs the standard and management executes within it; the failure mode here runs in both directions at once. Boards that adopt an AI governance policy and consider the obligation discharged have declared a standard without ever defining what verification means in practice, leaving the technical work to accumulate wherever it happens to land, usually nowhere in particular. Meanwhile, the technical teams capable of building the Capability Specification and the drift-monitoring architecture have no board-level mandate telling them the verification cadence that matters, so the infrastructure that does get built optimizes for uptime and cost, not for claim accuracy, because nobody in the room asked for the second thing.
The fix is not a new policy. It is the conversation the Accountability Contract Model describes: a named individual, told explicitly what they are accountable for, granted explicit authority to suspend a claim, and given an explicit deadline by which the first verification cycle runs. "The compliance team owns AI governance" is not that conversation. "The Chief Technology Officer is accountable for issuing a Technical Verification Certificate for every investor-facing AI claim, on a ninety-day cycle, with authority to suspend any claim the certificate cannot support" is. The first sentence produces a policy binder. The second produces a person who can be asked, by name, whether a specific claim is currently true, and who has already built the evidence to answer.
The most common failure inside organizations attempting this is architectural rather than moral: the verification system exists because the current CTO personally maintains it, not because it is written into a documented process, a training program, and a technology roadmap that survives that person's departure. A drift-detection system that lives in one engineer's head is not a governance system. It is a favor, and favors do not show up in an examiner's document request.
What this changes for the next board conversation
Boards that have adopted an AI ethics policy and received a quarterly update have not built a defense. They have built the first half of one. The second half is a specific, testable question, asked at the next meeting where AI capability is on the agenda: for each AI system this organization describes publicly, who is accountable for confirming, on a defined cycle, that the claim is still true, and when was that confirmation last issued.
An organization that answers with a name and a date has built the architecture before an examiner asked for it. An organization that answers with a policy has built a document, and the difference between the two is the entire distance between a competitive asset and a contingent liability. What a board leaves behind here is not a compliance record. It is a technical infrastructure that keeps making accurate claims possible after the people who built it have moved on, tested against a standard set once and maintained on a schedule, rather than rebuilt from memory after the first claim is challenged.