Who Is Responsible Across the AI Stack? Mapping Roles from Model Providers to Enterprise Customers

Key Takeaways

• Responsibility across the AI stack cannot be determined from contractual vendor labels alone. It requires a functional analysis of the relevant system, processing operations, market role and decision-making points.
• Under Art. 25(1) of the EU AI Act, specified downstream actors can be treated as providers of a high-risk AI system in defined circumstances. Ordinary customization does not by itself trigger this role change.
• The EU AI Act and GDPR use parallel but distinct legal roles; a SaaS vendor may simultaneously act as a GDPR processor for one processing operation and an AI Act provider of a downstream AI system.
• Information duties differ by context. Art. 53(1)(b) EU AI Act addresses information for downstream AI system providers, while Art. 25(4) establishes a separate written-agreement rule for high-risk AI systems.

Introduction

For technical founders and compliance teams in the AI value chain, identifying regulatory roles is a complex but practical challenge. Responsibility cannot be determined solely by identifying the model supplier or reading the vendor contract. The analysis should begin with the system architecture, data flows, intended purpose and the actors that make relevant decisions. The EU AI Act applies in stages: obligations for general-purpose AI (GPAI) model providers began to apply on 2 August 2025 and the Commission's enforcement powers began to apply on 2 August 2026. Following the AI Omnibus, the high-risk system rules apply from 2 December 2027 for Annex III systems and from 2 August 2028 for systems embedded in products covered by Annex I. This guide maps the interplay between the AI Act and the General Data Protection Regulation (GDPR) to help organizations assign roles, manage lifecycle risks and prepare evidence for enterprise procurement in the EU.

1. Start with the Architecture, Not the Legal Labels: Understanding AI Stack Responsibility

A common pitfall is assigning regulatory roles before analyzing how data, models, code and instructions move through the system. Compliance teams should first map the technical architecture and the relevant processing operations. Under the GDPR, roles depend on who determines the purposes and means of processing; under the EU AI Act, classification depends on defined activities such as developing, marketing, deploying or modifying an AI system. Contract terms are relevant, but they do not by themselves settle either analysis.

1.1. Identify the main layers of the stack

A useful simplified map of the modern AI stack has three layers: infrastructure and hardware; the model layer, which may include a GPAI model; and the application or downstream integration layer. This is a technical map, not a legal taxonomy. Each layer may involve actors that host, provide, configure or modify different parts of the system. For example, hosting an open-weights model on a private cloud and accessing a proprietary model through a closed API involve different facts, but the use of open weights alone does not determine a party's legal role or establish an exemption.

1.2. Trace the legally significant decisions

To map compliance duties, identify where legally relevant decisions are made. These engineering choices may include configuring system prompts, designing Retrieval-Augmented Generation (RAG) pipelines, setting inference parameters and defining the boundaries of fine-tuning datasets. Such choices can be relevant to the system's intended purpose and to the means of personal-data processing, but they do not determine either concept on their own. Under the EU AI Act, the intended purpose is based on the use, context and conditions specified by the provider; under the GDPR, the role analysis asks who determines the purposes and essential means of each processing operation.

1.3. Separate technical contribution from regulatory responsibility

Technical contributions do not automatically establish a particular legal role or type of liability, although they may be relevant to the analysis. An infrastructure provider that only hosts a model may act as a processor or another service provider, depending on the processing operation and its actual influence. An integrator that configures a system for a high-risk use case may be a provider, deployer or another operator under the EU AI Act, depending on how the system is marketed, modified and used. These roles should be assessed separately under each applicable legal framework.

2.Assign Roles Under the EU AI Act: Mapping AI Stack Responsibility

The EU AI Act defines several operator roles in Art. 3. Correct classification matters because different obligations and penalty provisions attach to different roles. Art. 99 EU AI Act provides maximum fines of up to EUR 15 million or, for an undertaking, up to 3% of worldwide annual turnover for breaches of specified operator duties, with the applicable ceiling and amount determined under the Article's size-sensitive and case-specific rules. .

2.1. GPAI model provider

Under Art. 51-55 of the EU AI Act, providers of GPAI models face tiered obligations. Art. 53 requires providers to maintain technical documentation, supply specified information to downstream AI system providers, put in place a policy to comply with EU copyright law and publish a sufficiently detailed summary of the content used for training. Qualifying free and open-source models are exempt from the documentation duties in Art. 53(1)(a) and (b), unless they pose systemic risk; the copyright-policy and public-summary duties still apply. Art. 55 adds model evaluation, systemic-risk assessment and mitigation, serious-incident reporting and cybersecurity duties for GPAI models with systemic risk. Exceeding 10^25 floating-point operations in cumulative training compute creates a presumption of systemic risk rather than an irrebuttable classification. The duties apply to models placed on the market from 2 August 2025; providers of models placed on the market before that date have until 2 August 2027 to comply. Since 2 August 2026, the Commission can enforce the GPAI obligations, including through fines.

2.2. Provider of the downstream AI system

Under Art. 3(3) EU AI Act, a "provider" develops an AI system or GPAI model, or has one developed, and places it on the market or puts the AI system into service under its own name or trademark. A downstream SaaS vendor may therefore be the provider of its downstream AI system, but integration of a third-party model alone is not decisive. If the resulting system is classified as high-risk, the provider must comply with the applicable requirements in Art. 8-15 and provider obligations in Art. 16-21, including risk management and the relevant conformity-assessment process, once those provisions apply.

2.3. Deployer

Under Art. 3(4) EU AI Act, a "deployer" is an entity using an AI system under its authority in a professional capacity. An enterprise customer using a SaaS AI tool internally will often be a deployer, although it may hold a different role for another activity. Art. 26 EU AI Act applies specifically to deployers of high-risk AI systems. Once the relevant provisions apply, it requires measures such as following the instructions for use, assigning competent human oversight, monitoring operation and retaining automatically generated logs that are under the deployer's control for the required period.

2.4. Other operators in the value chain

The AI Act also assigns duties to authorised representatives, importers and distributors under Art. 22-24. Two information-flow rules are particularly relevant. Art. 25(4) EU AI Act requires the provider of a high-risk AI system and a third-party supplier of an AI system, tool, service, component, or process used in that system to specify the necessary information, technical access, and assistance in a written agreement, subject to the provision's limited open-source exception. Separately, Art. 53(1)(b) EU AI Act requires GPAI model providers to make specified information and documentation available to providers that intend to integrate the model. Neither rule creates an unrestricted right to proprietary information; intellectual-property, confidentiality, and trade-secret protections continue to apply.

2.5. Role changes

Under Art. 25(1) EU AI Act, a distributor, importer, deployer or other third party is treated as the provider of a high-risk AI system in three specified circumstances: it rebrands an existing high-risk system; substantially modifies an existing high-risk system so that it remains high-risk; or changes the intended purpose of a previously non-high-risk system so that it becomes high-risk. The provision does not apply merely because any customization occurs. Where it does apply, the downstream actor assumes the provider role and the corresponding obligations under Art. 16 EU AI Act for that system. Under Art. 25(2) EU AI Act, the initial provider generally ceases to be the provider of that specific system and must cooperate with the new provider, subject to the provision's stated exception. This role allocation is not an automatic transfer of every form of legal liability.

3.Overlay GDPR and Contractual Roles: Aligning AI Stack Responsibility

A common error is to conflate AI Act roles with GDPR roles. The same organization may be a provider under the AI Act while acting as a processor, controller or joint controller under the GDPR, depending on the processing operation. 3.1. Controller and processor roles
Under Art. 4(7) GDPR, a "controller" determines the purposes and means of processing personal data, while Art. 4(8) defines a "processor" as an entity that processes personal data solely on behalf of a controller. In a typical B2B SaaS arrangement, the enterprise customer often acts as a controller for the business use of personal data and the SaaS vendor often acts as processor, although this must be assessed for each operation. If the vendor uses customer data for its own model-training purpose, it may act as an independent controller for that use where it determines the purpose and essential means. This role analysis should be kept separate from supervisory jurisdiction. For example, the Court of Rome annulled the Italian Garante's EUR 15 million decision against OpenAI on one-stop-shop jurisdictional grounds; it did not decide whether the underlying processing complied with the GDPR..

3.2. Different roles for different processing operations

During model development, an entity is a controller only where personal data is processed and it determines the purposes and essential means of that processing. During deployment, a SaaS vendor may act as a processor under Art. 28 GDPR when it follows the enterprise customer's documented instructions. If two parties jointly determine the purposes and means of a specific operation through common or converging decisions, they may be joint controllers and must establish an arrangement under Art. 26 GDPR.

3.3. Contracts cannot replace functional analysis

The European Data Protection Board (EDPB) Guidelines 07/2020 confirm that controller and processor roles are functional and cannot be changed by contractual labels alone. Decisions on purposes and essential means, including the type of personal data, duration of processing, categories of data subjects and recipients, are reserved to the controller. More practical implementation choices, such as particular hardware or software, may be left to the processor where they do not affect essential means. Art. 32 GDPR nevertheless places security obligations on both controllers and processors, subject to their respective roles.

3.4. Model and infrastructure providers require separate assessment

Enterprise compliance teams should assess model providers and infrastructure hosts separately. An infrastructure host may act as a processor under Art. 28 GDPR where it processes personal data on documented instructions, but that result is not automatic. A model provider may likewise be a processor for customer-directed inference while acting as an independent controller for a separate use of data. Joint controllership requires joint participation in determining the purposes and means; it does not follow merely from technical complexity or a high level of abstraction.

4.Build Responsibility Across the System Lifecycle

Responsibility should be mapped and monitored across the system lifecycles, from initial development and classification to integration, operation, change management and ongoing information exchange. The applicable duties depend on the system, use case, processing operation and each actor's role.

4.1. Development and classification

At the development and intended-purpose stage, the relevant actor under EU AI Act should assess whether the system falls within a prohibited practice under Art. 5 or may qualify as high-risk under Art. 6 and the relevant annexes. Most of the original prohibitions under Art. 5 EU AI Act have applied since 2 February 2025; the new prohibitions introduced by the AI Omnibus concerning non-consensual intimate material and child sexual abuse material apply from 2 December 2026. The high-risk duties are subject to the later application dates noted above. Where personal data is processed, Art. 25 GDPR requires the controller to implement data protection by design and by default. Controllers and processors must maintain records of processing under Art. 30 GDPR where that provision applies; not every developer is a controller, and this article contains a limited exemption.

4.2. Integration and deployment

During integration, identify whether the organization acts as a provider or deployer under the EU AI Act and as a controller or processor under the GDPR for each operation. Where personal data is processed, Art. 32 GDPR requires controllers and processors to implement technical and organizational measures appropriate to the risk. Where the SaaS vendor acts as a processor, API use should remain within the controller's documented instructions and the applicable data processing agreement. Use of an upstream model provider may also require a processor or sub-processor analysis, authorization under Art. 28 GDPR, and an international-transfer assessment under Chapter V where relevant.

4.3. Operation and supervision

Once the system is in operation, organizations should implement the controls linked to the classification and the role identified above. For high-risk systems, this includes operationalizing the deployer duties under once Art. 26 EU AI Act. Monitoring model drift, bias and security vulnerabilities may also be appropriate risk-control measures, but the precise scope depends on the system and use case. Art. 29 GDPR applies to persons acting under the authority of a controller or processor; it does not apply to an organization merely because it is a deployer under the EU AI Act.

4.4. Change management

Post-deployment modification should trigger a documented review. Under Art. 3(23) EU AI Act, a substantial modification is a change that was not foreseen or planned in the provider's initial conformity assessment and that affects compliance with the high-risk requirements or changes the intended purpose for which the system was assessed. The review should determine whether this definition or another role-change scenario under Art. 25(1) EU AI Act is engaged. A new architecture or use case may be relevant evidence, but it is not an automatic trigger on its own.

4.5. Information exchange across the stack

A workable lifecycle framework should translate the information-flow rules discussed in section 2.4 into operational processes. Procurement teams should check whether contracts and service terms support access to required documentation, change notifications and incident escalation. These arrangements can support compliance, but cannot guarantee it..

Conclusion

Navigating responsibility across the AI stack requires moving beyond static legal labels. An organization’s obligations depend on the functions it performs, the influence it exercises over the system and the decisions it makes throughout the AI lifecycle. Because the same organization may occupy different roles under the EU AI Act and the GDPR, these roles should be assessed separately rather than inferred from contractual labels alone. Clear information flows, documented responsibility allocation and ongoing review of changes in models, data, intended purposes and deployment conditions can help AI vendors and enterprise customers identify compliance gaps, respond to regulatory scrutiny and meet procurement expectations more effectively.