Subprocessor of Record: Why Runtime Responsibility Decides Enterprise Deals

When security or procurement asks who your subprocessor of record is, they are asking a precise legal question: which named vendor has signed a contract taking responsibility for how your data is handled, and can we add them to the list we show our customers? For software an AI generated and shipped, the answer is often nobody, and that gap is what blocks the deal. You cannot patch your way past it, because the question is about who signs.

What a subprocessor of record actually is#

Under GDPR Article 28, a controller (the enterprise) may only use processors that provide "sufficient guarantees" to protect personal data, and the arrangement must be governed by a written contract. A subprocessor is a processor's processor, the third party your vendor brings in to help handle the data. Article 28 is strict about the chain: a processor "shall not engage another processor without prior specific or general written authorisation of the controller," the same data protection obligations must flow down to that subprocessor by contract, and the original processor "shall remain fully liable" if the subprocessor fails.

That liability clause is the whole game. Becoming a subprocessor of record takes more than getting named on a page. The vendor accepts, in writing, legal responsibility for what it does with the data. Everything below follows from that.

Why enterprises maintain lists and demand DPAs#

Because the obligation flows downstream, enterprises manage it as a list. A processor must document every subprocessor, bind each one with a data processing agreement (DPA) carrying "equivalent data protection terms," and disclose the roster to its own customers, who retain the right to object. In practice this shows up as the public subprocessor pages you see on vendor trust portals. OpenAI's sub-processor list is a representative example, naming each entity, its purpose, and its data location. The standard pattern grants general authorization for the vendors on that page and promises advance notice, commonly 30 days, before a new one is added.

For an enterprise buyer, the list is a control surface. Every entity on it has been through security review and is bound by a DPA, and every entity that touches data must be on it. Procurement uses those disclosures alongside SOC 2 reports to judge vendor maturity. A clean, complete list is what lets a deal clear review rather than stall in it.

Code generators won't sign, and couldn't#

Here is where AI-built software breaks the model. A code generator writes the code and then leaves. Cursor, v0, Lovable, and the rest are extraordinary at producing working software, and they hold no runtime responsibility. They never see your production data, they aren't present when the generated app executes against a customer record, and they have nothing to accept liability for. Asking a code generator to be your subprocessor of record is a category error, because it isn't processing your data and has nothing to sign.

None of that is a criticism of those tools. It is a description of where their responsibility ends. It does leave a hole. The app runs, it reads and writes real data, and no named party has signed for what happens at runtime. When security asks "who is the subprocessor here?", the honest answer for a lot of AI-built internal software is that there isn't one. There is no processor of record, which under Article 28 means the app cannot lawfully be handed the data in the first place.

Runtime responsibility is what makes compliance transferable#

What an enterprise needs a signature on is the execution, and authorship of the code has little to do with it. Responsibility attaches to whatever actually runs against data: which calls it makes, what it can reach, whether egress is controlled, whether there is an attributable log of what happened. Owning that surface is runtime responsibility, and it is the one thing that can be signed for, because it is the one thing present when the data is at risk.

This is why the runtime makes the natural signer. Whoever owns the boundary the code executes inside can accept the Article 28 obligations, bind them in a DPA, and appear on the list, because they can actually enforce what they are promising. Compliance becomes transferable the moment one party owns execution across every app, and stops depending on each new AI-built artifact somehow carrying its own guarantees. That is the shift from reviewing code to trusting the boundary it runs in, and it is the ground your compliance posture stands on. Someone has to sign. The runtime is the one that can.