EU AI Act and GDPR Article 28: where AI vendor responsibility ends

A concept worth defining once

Where AI vendor responsibility ends under the EU AI Act and GDPR Article 28 is the question every regulated end-customer's compliance team asks, and one most vendor websites answer with vocabulary instead of architecture. "Sub-processor," "data residency," "tenant isolation," "compliance ready," "private AI": terms that mean different things to different audit teams. A single concept cuts through them: the audit boundary.

The audit boundary is the line between two different things on either side of an AI deployment. On one side is everything your end-customer's compliance team can audit themselves: the data, the access controls, the configuration, the logs of who did what to whom and when. On the other side is everything they cannot audit themselves: the vendor's internal systems, the vendor's staff actions, the vendor's choices about what data leaves the customer's environment. The audit boundary is the line that separates the two.

Where that line sits is the single most consequential architectural decision in any AI deployment for a regulated customer. It governs what the customer's compliance team can prove on the day of the audit. It governs which contractual clauses they need from the vendor. And it governs how the regulator-language fits onto the deployment: whether the vendor counts as a sub-processor under General Data Protection Regulation Article 28, a Critical ICT Third-Party Provider under the Digital Operational Resilience Act, a provider under the EU AI Act with the customer as the deployer carrying Article 26 obligations, or none of the above.

This post is for the founder, the chief technology officer, or the compliance lead at a regulated end-customer trying to evaluate where the audit boundary sits across three AI deployment shapes, and to make sense of the regulator language that maps onto each. We walk through the public AI API, deployment in your own cloud, and deployment in your customer's environment, locating the audit boundary in each. We state plainly when deeplit® acts as a controller, a processor, or neither. We link the GDPR DPA template for AI that scopes these patterns clause by clause.

Three deployment shapes, three audit boundaries

The three shapes below cover almost every AI deployment a regulated end-customer will see in 2026. Each one places the audit boundary in a different place. None of the three is intrinsically right or wrong. The right one for any given deployment is the one whose audit boundary matches the customer's compliance posture and the regulator language they have to answer to.

Shape 1: public AI API (audit boundary at the customer's network egress)

The model runs inside the vendor's infrastructure (or, for a public AI API on a hyperscaler substrate, inside the vendor's account on a hyperscaler the vendor controls). The customer sends inference requests over the public internet to the vendor's endpoint. The vendor's data processing agreement governs what happens to the request payload after it leaves the customer's network.

The audit boundary sits at the customer's egress. Everything before egress (the request payload assembly, the user identifier, the routing logic) is auditable inside the customer's environment. Everything after egress is in the vendor's audit boundary, which the customer can only audit via the vendor's contractual reporting (typically a SOC 2 Type II report, a quarterly compliance attestation, and the data processing agreement clauses).

Regulator-language mapping. Under General Data Protection Regulation Article 28 the vendor is a processor; the vendor's hyperscaler is a sub-processor; both must appear on the customer's sub-processor register. Under the Digital Operational Resilience Act the vendor and any of its designated providers may register as a Critical ICT Third-Party Provider; the customer's regulatory register grows by the count of designated providers in the vendor's stack. Under the EU AI Act the customer is the deployer and the vendor is the provider; both sets of obligations apply, and the deployer's Article 26 record-keeping, human-oversight, and incident-reporting duties are reachable only through the vendor's reporting and retention defaults, not through the deployer's own audit log.

Shape 2: deployment in your own cloud (audit boundary between you and your AI vendor)

You take an open-weight model and deploy it in a Google Cloud project, AWS account, or Azure subscription that you (the startup) control. You sell the AI capability to your end-customer via your own API. Your end-customer's data flows into your cloud account, gets inference, and the result flows back. You hold the data processing agreement with your end-customer; the hyperscaler holds it with you.

The audit boundary now sits between your team and your AI vendor (if you have one; for most teams running open-weight models there is no AI vendor, and the model is the open-weight artifact). Everything inside your cloud account is in your audit boundary, which your end-customer can ask you to attest to under their data processing agreement with you. Your hyperscaler is your sub-processor; your end-customer's sub-processor register includes your hyperscaler one level removed.

Regulator-language mapping. Under Article 28 you are a processor for your end-customer, and your hyperscaler is a sub-processor; both must appear on the end-customer's sub-processor register. Under the Digital Operational Resilience Act your hyperscaler may be a designated Critical ICT Third-Party Provider; whether that registration is on your end-customer's register depends on whether they consider you a critical provider in their own register. Under the EU AI Act your end-customer is the deployer and you are the provider. The deployer's Article 26 records on operation, oversight, and incident reporting are reachable through your reporting to the end-customer, but only inside the bounds your cloud account and contract carve out.

Shape 3: deployment in your customer's environment (audit boundary at the customer's perimeter)

You ship the same open-weight model and the same deployment shape, except now it lives inside your end-customer's cloud account or on their on-premises hardware. The data path is entirely inside their perimeter. You wrote the Terraform that brought it up; their IAM authorizes who runs it; their billing account pays for it; their audit logs record it.

The audit boundary now sits at your end-customer's perimeter. Everything inside that perimeter is auditable by their compliance team directly: the IAM trail, the data flow, the configuration changes, the access actions of any vendor staff during setup. There is nothing on the other side of the audit boundary that they need to take on contractual trust, except for the vendor's promise that the management plane has no back-channel. That promise is verifiable by checking the deployment's outbound network traffic, not by reading the vendor's compliance report.

Regulator-language mapping. Under Article 28 you may be a processor (if you have any handling of the end-customer's data, even ephemerally during setup), or you may be neither a controller nor a processor (if your role is vendor of infrastructure software without ever touching the data); the determination depends on the contract structure and the access pattern. Under the Digital Operational Resilience Act the customer's hyperscaler relationship is unchanged; you are not a designated provider regardless of your size, because you do not operate the customer's infrastructure. Under the EU AI Act the customer is the deployer and you are the provider. The deployer's Article 26 obligations resolve cleanly: the records of operation, the human-oversight assignments, the security and accuracy monitoring, and the incident logs all live inside the customer's perimeter, written to storage the customer owns, with retention configured by the deployer rather than the vendor.

Article 26 across the three shapes

Article 26 of the EU AI Act takes full effect on August 2, 2026. It places obligations on the deployer of a high-risk AI system: keep records of the system's operation for the duration of intended use, ensure human oversight by a competent natural person, monitor accuracy and security, and report serious incidents to the relevant national authority. Where the audit boundary sits determines which of those duties the deployer can discharge on their own timeline. In Shape 1 the records and logs live on the vendor's servers under the vendor's retention policies; the deployer can request them by contract but cannot demand them when the regulator asks. In Shape 2 they live in your account; you produce them for your end-customer through your reporting channel. In Shape 3 they live inside the deployer's perimeter; the deployer produces them directly. For the deployer-side read on the Digital Operational Resilience Act, see Financial services AI compliance.

When deeplit® acts as a controller, a processor, or neither

The role we play under General Data Protection Regulation Article 4 depends on the deployment shape, not on a marketing preference. Three patterns:

When the deployment is in the end-customer's environment (Shape 3 above) and our role is limited to the Terraform, the serving stack, and the operational software, with no access to the end-customer's data in production, we are neither a controller nor a processor. We are a vendor of infrastructure software, and we do not appear on the end-customer's sub-processor register because we do no processing.

When the deployment is in the end-customer's environment but our incident-response process requires read-only access to the audit logs (which may contain user identifiers as part of role-based access control entries), we are a processor for the duration of the incident response. We sign a data processing agreement scoped to that role. The audit boundary remains at the end-customer's perimeter; our access is logged in their IAM audit trail and is reversible at any time.

When the deployment is in our cloud account, we are a processor end-to-end and a hyperscaler sub-processor sits behind us. We do not offer that configuration today; we name it only to complete the General Data Protection Regulation Article 4 mapping.

The DPA template walks the three patterns and makes the audit boundary explicit in each.

How to use this when evaluating any AI vendor

Three questions, in order. They cut through more vendor marketing than any other line of inquiry.

First: where does the audit boundary sit? If the vendor cannot answer in one sentence and point to the perimeter on a diagram, the vendor has not thought about it carefully enough to deploy into a regulated environment. If the answer is "at the customer's perimeter," move to the second question. If the answer is "at the customer's network egress" (a public AI API), ask for the SOC 2 report and the sub-processor list.

Second: what is the vendor's role under Article 4 (controller, processor, or neither), and is that role the same in steady state as it is during incident response? Many vendors are processors during incident response and "neither" in steady state. That distinction belongs in the data processing agreement, not in a marketing page.

Third: what ongoing connectivity does the vendor's management plane keep into the deployment? The honest answer for any customer-environment deployment is "one outbound webhook for licensing, no inbound channel." Anything else needs justification.

If you are evaluating deeplit® against this checklist, the answers are: at your end-customer's perimeter; neither in steady state, processor during incident response under a scoped data processing agreement; one outbound licensing webhook, no inbound channel, customer-disconnectable. The full diagram and the DPA template are available before any deployment call.

deeplit® defaults to Shape 3: deployment on your end-customer's hardware or in their cloud account, Terraform-managed, with the audit boundary at their perimeter. Book a deployment call to walk through the three shapes against your specific deal and your end-customer's compliance posture.

If your customer's compliance lead is the one asking where the audit boundary sits, this post is written to be forwarded to them. The three-deployment-shape framing is theirs to use in their own audit.

The audit boundary is not what your AI vendor tells you it is. It is what your end-customer's compliance team can prove on the day of the audit.

Architecture is downstream of where you decide to put it.