The Missing Layer in the AI-Enabled Enterprise
A response to a16z’s “Why the World Still Runs on SAP”
Eric and Seema Amble at a16z published a sharp piece this week on why enterprises still run on SAP, and how AI will finally make that bearable. They are right about almost everything. The problem description is accurate. The opportunity sizing is credible. The pattern they identify — unbundling the legacy UI into composable, governed, AI-assisted thin apps — is exactly what is happening.
But there is one word in their thesis that does all the weight-bearing and receives almost no examination: governed.
Eric and Seema Amble describe the endgame as “an operating layer: a unified data and action plane with a semantic model of business objects, plus guardrails that make AI trustworthy in production.” The guardrails they propose are RBAC, audit trails, approval workflows, and human-in-the-loop checkpoints. These are reasonable engineering answers to a software problem. They are not adequate answers to a legal problem.
And when AI agents start posting journal entries to SAP, onboarding vendors across three jurisdictions, processing employee data in HRIS systems, and executing procurement workflows on behalf of finance teams — you no longer have a software problem. You have a legal accountability problem. Who is responsible for that action? Under which legal authority was it taken? On whose behalf? With what data? For what purpose? Provable how, and to whom?
RBAC cannot answer those questions. An audit log cannot answer those questions. An approval workflow cannot answer those questions, because the workflow itself is a configuration inside the enterprise system — and an enterprise system can be misconfigured, overridden, or compromised. None of these mechanisms produce a legally attributable, independently verifiable proof that a specific authorised person permitted a specific operation on specific data.
There is exactly one architecture that produces such a proof. It is called a wallet.
What the a16z thesis is missing
The a16z piece describes a world with two actors: the enterprise and its systems. The vendor being onboarded, the customer whose purchase history is being analysed, the employee whose performance data is being accessed by an AI — these people appear in the article as objects in the system. Data subjects. Passive.
This is not how the law sees them. GDPR, the UAE PDPL, and the EU’s new Business Wallet regulation (COM(2025) 838, mandating wallet adoption for 32.7 million organisations within 24 months) treat data subjects as legal persons with rights that must be exercised in real time. The right to know what is being processed, why, under what legal basis. The right to withdraw consent and have processing stop. The right to access, rectify, and erase. Not as a support ticket to a privacy team. As an exercisable right against a system that must respond.
The a16z model has no mechanism for this. The “thin app” serves the enterprise user. The vendor, the customer, the employee — they have no representation in the architecture.
The wallet architecture makes the data subject a participant with cryptographic standing.
What a wallet actually is
A wallet in the European Digital Identity sense is not a cryptocurrency wallet. It is a signed identity container — a legal instrument that holds credentials, authorisations, and receipts. It is issued to a legal or natural person. It carries that person’s qualified electronic signature, certified by a national trust service provider. When a wallet signs something, the signature is legally equivalent to a handwritten signature across the entire EU/EEA, and increasingly in jurisdictions that have modelled their trust frameworks on eIDAS — including the UAE, which adopted ETSI signature standards explicitly.
When an enterprise deploys a wallet-native application — a Vendor Onboarding app, a Contract Execution app, a Data Processing Authorization app — it does not simply give the vendor a form to fill in. The enterprise’s Business Wallet issues a consent notice to the vendor’s Business Wallet. The notice is generated from a Processing Operations Specification: a machine-readable document that defines exactly what data will be collected, for what purpose, under which legal basis, with which recipients, for how long. The vendor’s wallet reviews this specification, and the vendor makes a decision. If they consent, a ConnectionAuthorization is created — a signed instrument, not a configuration — that attributes the permission to a specific legal person, for a specific operation, under a specific legal framework. The vendor receives a consent receipt as a Verifiable Credential. They hold cryptographic proof of what they agreed to, independently of the enterprise’s systems.
Now when the AI agent executes “onboard this vendor, collect documents, route approvals, post to SAP” — every action it takes is governed by the specification, attributable to a signed authorisation, and provable in any court that accepts qualified electronic signatures.
That is what “guardrails that make AI trustworthy in production” actually means when the production environment is a regulated enterprise operating across multiple jurisdictions.
The specification is the source code
The a16z article describes the most valuable deployments becoming “reusable intent packs — quote-to-cash, vendor onboarding, period close — that encode not just what to do, but how to do it safely in your environment.”
This is exactly right. But “safely” has a legal dimension that software architecture alone cannot provide.
What we have built at Signatu is a system where the Processing Operations Specification is the source code for both the application and its governance. You write one specification — defining purposes, legal bases, data categories, storage conditions, recipient types, rights, and KROG authorisation rules — and from that single source of truth you generate: the wallet-native application, the GDPR Record of Processing Activities, the AI agent’s operational identity (what it is permitted to do, why, and who authorised it), the consent notice the data subject receives, and the signed authorisation that governs every agent action.
The specification is not documentation for the system. It is the system. You cannot run a governed operation outside what the specification authorises, because the governance kernel enforces this architecturally — not through configuration, but through formal deontic logic applied at the connection layer.
When the a16z article describes the moat compounding from real usage — “every successful workflow becomes a reusable intent, every exception becomes a guardrail” — what they are describing is, without knowing it, the accumulation of Processing Operations Specifications. Each one is a formal record of how the enterprise has chosen to govern a specific type of data processing. Over time, these specifications become the institutional memory that SAP itself once encoded — but expressed as machine-readable legal instruments rather than table configurations, and governed by cryptographic proof rather than access control lists.
The jurisdictional problem AI makes urgent
There is one dimension of the enterprise AI problem that the a16z piece does not address: jurisdictional fragmentation.
Masdar, the UAE state renewable energy company, is a concrete example. They now operate in 40+ countries following a 2025 strategic pivot to agentic AI in energy operations. Their Claude agents process SCADA data, execute carbon accounting workflows, handle contractor onboarding, and manage energy certificate chains — across UAE assets governed by UAE PDPL and TDRA trust services, Greek and Spanish assets governed by GDPR and eIDAS, UK assets under UK GDPR, and portfolio assets in the Philippines, Uzbekistan, and the US, each with local data sovereignty requirements.
No single RBAC configuration handles this. No audit log makes this legally accountable across jurisdictions. You need, for each entity in each jurisdiction, a Processing Operations Specification that defines the legal basis applicable in that jurisdiction, generates the correct ROPA for that jurisdiction’s regulator, and produces wallet-native applications whose AI agents operate within jurisdiction-appropriate governance envelopes.
This is not a compliance overhead. It is the infrastructure that makes the entire AI deployment possible — the thing that allows Masdar’s board to answer the question “who is accountable if an agent makes an error in the Greek energy market” with a signed document rather than a shrug.
The category a16z has not yet named
The a16z piece identifies that “the systems of record endure; the interface, automation, and extension layer becomes the new software frontier.” They are right. The winners in this market will not replace SAP. They will become the governance layer that sits between SAP and the AI agents that operate it.
But “governance layer” understates what this is. The wallet architecture makes data subjects participants, not objects. It makes every AI agent action legally attributable, not just technically logged. It makes governance violations architecturally impossible, not just policy-prohibited. It makes the enterprise’s Processing Operations Specifications the machine-readable institutional memory that SAP’s table configurations once encoded — but portable, jurisdiction-aware, and provable in court.
The interface layer becomes the new software frontier. The wallet is the identity and governance layer beneath that interface. Without it, the thin apps a16z describes are capable but unaccountable. With it, they are the governed, legally attributable infrastructure for how enterprises will operate in a world where AI agents take consequential actions on behalf of legal persons.
That is the category that needs to be named. We are building it.
Georg Philip Krog is the founder of Signatu and the author of the KROG formal theorem — a complete combinatorial proof of all bilateral normative positions between any two actors, derived from rule logic and process calculi. Signatu builds interaction infrastructure for the governed digital society.
The EU Business Wallet regulation (COM(2025) 838) mandates wallet adoption for 32.7 million organisations within 24 months. The a16z article was published on 16 March 2026.