Provider or Deployer? AI Act Roles for Inference Engines

Distinguishing Providers and Deployers Under Article 3

When engineering teams build production applications on top of third-party inference endpoints, the question of regulatory classification under Regulation (EU) 2024/1689 (the EU AI Act) is often met with a dangerous oversimplification: "We did not train the model, so we are only a deployer." In European artificial intelligence law, this assumption fails. The roles of provider and deployer do not describe corporate identities in the abstract; they attach to specific technical artefacts and operational boundaries across your software stack. A single engineering organisation frequently holds both roles simultaneously for different components of its workload.

Article 3(3) of the AI Act defines a provider as "a natural or legal person, public authority, agency or other body that develops an AI system or a general-purpose AI model or that has an AI system or a general-purpose AI model developed and places it on the market or puts the AI system into service under its own name or trademark, whether for payment or free of charge". Article 3(4) defines a deployer as "a natural or legal person, public authority, agency or other body using an AI system under its authority except where the AI system is used in the course of a personal non-professional activity". These two classifications are not mutually exclusive alternatives; they represent distinct functional postures.

The Technical Boundary Between AI Models and AI Systems

To understand why an API consumer is rarely just a deployer, you must examine the definition of an AI system under Article 3(1). An AI system is a machine-based system designed to operate with varying levels of autonomy that infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions. A raw model checkpoint or a stateless inference API is an AI model, not a complete standalone AI system in production. When your team wraps an open-weights model or an API endpoint with application logic, retrieval-augmented generation (RAG) vector pipelines, system prompts, guardrails, and user interfaces, you are developing an AI system.

This architectural reality is codified in Article 3(68), which defines a downstream provider as a provider of an AI system, including a general-purpose AI system, that integrates an AI model, regardless of whether the model is provided internally or by another entity based on contractual relations. If you package an inference endpoint into a functional product that you distribute to users or operate internally under your brand, you hold the legal role of a downstream provider for that system. Furthermore, remember that the GDPR and EU AI Act overlap is functionally decoupled: your status as a data controller or data processor under Regulation (EU) 2016/679 has no bearing on whether you are classified as a provider or a deployer under the AI Act.

Clarifying these boundaries is the foundation of your compliance architecture. Confusing model hosting with system provisioning leads teams to misallocate engineering resources, ignore mandatory technical documentation, and fail downstream governance checks.

The Own Name or Trademark Trap for Internal AI Systems

A frequent point of confusion among internal infrastructure and tooling teams is the belief that internal tools escape provider duties because they are not commercialised. Machine learning leads often assume that if an application is built exclusively for internal staff, such as an internal customer support copilot, an automated CV screening tool, or an internal knowledge-base search engine, the building team remains strictly a deployer. This interpretation directly contradicts the statutory mechanics of the AI Act.

The trigger for provider obligations does not require external commercial sale. Article 3(3) attaches the provider role to a body that develops an AI system and "places it on the market or puts the AI system into service under its own name or trademark, whether for payment or free of charge", and Article 3(11) defines putting into service as "the supply of an AI system for first use directly to the deployer or for own use in the Union for its intended purpose". Supplying a system for own use means that the moment an enterprise deploys an internally developed AI application to its workforce, it has put that system into service.

Case Study: The Dual-Role Internal Hiring Screener

Consider an enterprise engineering group that builds an internal resume screening and candidate evaluation tool. The team connects an orchestration script to an upstream inference endpoint, injects customized rubric prompts, parses incoming PDF resumes, and provides candidate score rankings to human resources recruiters. In this scenario, the enterprise is not merely consuming a third-party service; it has developed and put into service an AI system for its own use.

1. System Development: The engineering team creates prompt templates, deterministic scoring filters, and data extraction pipelines, configuring the system's intended purpose.
2. Putting into Service: The organisation makes the tool available on its internal corporate network for recruitment evaluation, which is supply for own use in the Union within the meaning of Article 3(11).
3. Provider Qualification: Because the system is developed in-house and put into service for own use under the company's own name, the enterprise carries the provider obligations that Article 16 lists for high-risk systems.
4. Deployer Qualification: Because the human resources department then uses the tool under the company's authority to make employment-related assessments, the enterprise is simultaneously the deployer within the meaning of Article 3(4).

Saying "we never sold the software" or "it is just an internal script" offers no legal shield. If the application falls into a high-risk category under Annex III, such as employment recruitment or workforce management, the enterprise must meet full provider requirements (including risk management, data governance, and technical documentation) while also satisfying deployer requirements (such as operational oversight and logging).

Requalification Under Article 25

The AI Act recognizes that AI supply chains are modular. Downstream integrators frequently modify existing systems, rebrand third-party tools, or point general-purpose systems toward high-stakes vertical domains. To prevent regulatory evasion across these hand-offs, Article 25 establishes strict statutory rules under which an intermediate actor is legally requalified as the provider of a high-risk AI system.

The Three Requalification Triggers in Article 25(1)

Under Article 25(1), any distributor, importer, deployer, or other third party is considered a provider of a high-risk AI system and becomes subject to all provider obligations under Article 16 in any of three specific circumstances:

• Article 25(1)(a): "they put their name or trademark on a high-risk AI system already placed on the market or put into service, without prejudice to contractual arrangements stipulating that the obligations are otherwise allocated".
• Article 25(1)(b): "they make a substantial modification to a high-risk AI system that has already been placed on the market or has already been put into service in such a way that it remains a high-risk AI system pursuant to Article 6".
• Article 25(1)(c): "they modify the intended purpose of an AI system, including a general-purpose AI system, which has not been classified as high-risk and has already been placed on the market or put into service in such a way that the AI system concerned becomes a high-risk AI system in accordance with Article 6".

Point (c) is the primary trigger for API consumers. When an engineering team takes a general-purpose model, which is unclassified or low-risk in the abstract, and builds a dedicated system intended for credit scoring, critical infrastructure monitoring, or medical triage, that team has modified the intended purpose into an Annex III high-risk use case. Through that functional shift, the team becomes the full statutory provider under Article 25(1)(c). Downstream teams should note that questions regarding raw training compute thresholds and upstream base model responsibilities fall under GPAI model obligations, which govern the base model provider rather than the application integrator.

Displacement and Upstream Cooperation Under Article 25(2)

When requalification occurs under Article 25(1), Article 25(2) legally displaces the initial provider for that specific system while establishing mandatory cooperation mechanisms: "Where the circumstances referred to in paragraph 1 occur, the provider that initially placed the AI system on the market or put it into service shall no longer be considered to be a provider of that specific AI system for the purposes of this Regulation. That initial provider shall closely cooperate with new providers and shall make available the necessary information and provide the reasonably expected technical access and other assistance that are required for the fulfilment of the obligations set out in this Regulation, in particular regarding the compliance with the conformity assessment of high-risk AI systems".

However, downstream engineers must heed the critical statutory carve-out in the same paragraph: "This paragraph shall not apply in cases where the initial provider has clearly specified that its AI system is not to be changed into a high-risk AI system and therefore does not fall under the obligation to hand over the documentation". If an upstream model provider includes acceptable use terms prohibiting high-risk implementations, you lose statutory entitlement to their technical documentation and assistance, leaving your team solely responsible for proving conformity without upstream support.

Infrastructure Suppliers Do Not Share Your Role

A recurring misconception among engineering leads is that hosting workloads with a European cloud vendor allows their team to inherit or borrow an AI Act compliance posture. In reality, infrastructure providers operate purely as compute and hosting suppliers; they do not place your application on the market and do not put your AI system into service under their name.

An infrastructure supplier of this kind typically sells at several points in the chain: serverless inference on pre-hosted open models behind a shared endpoint, dedicated inference on isolated endpoints for custom containerised or open-weights models, on-demand GPU virtual machines with raw compute access, serverless training, and large-scale GPU cluster capacity. In all of them, the supplier provides execution capacity and runtime hosting. It does not define your application's intended purpose, it does not package your user-facing interfaces, and it does not take on your regulatory role under Article 3.

The Reality of Vendor Compliance and Attestations

Technical transparency requires being direct about what an infrastructure vendor does and does not provide. Lyceum has no EU AI Act conformity statement and no published position on the Act. We also do not hold ISO 42001 (the artificial intelligence management system standard, neither held nor in progress), ISO 27001, SOC 2, BSI C5, TISAX, ISAE 3402/3000, or ISO 9001. We do not provide external penetration test reports, publish named sub-processor lists, or publish standardized recovery time objectives (RTO), recovery point objectives (RPO), or breach-notification windows.

What we do provide to support your compliance file is concrete infrastructure engineering: a standardized Data Processing Agreement (DPA) published directly on our website, self-asserted GDPR compliance, self-asserted zero data retention across our inference endpoints, direct 24/7 access to engineering support, and workload-tailored rate limiting. Our compute runs in European data centres located in Paris and Finland, where the underlying physical data centre operators maintain their own ISO certifications (which belong strictly to those unnamed facility operators and not to us). You cannot cite a vendor's infrastructure to satisfy your system's conformity assessment; your regulatory role must be documented and defended in your own technical files.

Securing Article 15 Compliance Without an Upstream SLA

For teams providing or deploying high-risk AI systems, Article 15(1) imposes strict technical requirements: high-risk AI systems must be designed and developed to achieve an appropriate level of accuracy, robustness, and cybersecurity, performing consistently throughout their lifecycle. Under Article 16(a), the legal responsibility to ensure that the system complies with these requirements rests entirely on the provider.

A critical operational question arises: how does an engineering team maintain Article 15 robustness when downstream components rely on serverless inference APIs that carry no contractual uptime guarantee? Our own Serverless Inference and Smart Routing are provisioned self-serve on a per-token basis and carry no service level agreement (SLA), no availability tier, no uptime target, and no service credits. For Dedicated Inference, On-demand GPU VM, Serverless Training, and Large-Scale GPU Cluster, an SLA does exist, agreed individually per business contract with the availability tier set during proof-of-concept scoping.

Statutory Assistance via Article 25(4)

The absence of a public SLA on serverless endpoints is not an external compliance failure; it is an engineering constraint that you must address in your risk management system under Article 9. No supplier SLA or data centre certificate discharges your statutory duty under Article 15. The AI Act specifically accounts for supply-chain dependencies in Article 25(4):

"The provider of a high-risk AI system and the third party that supplies an AI system, tools, services, components, or processes that are used or integrated in a high-risk AI system shall, by written agreement, specify the necessary information, capabilities, technical access and other assistance based on the generally acknowledged state of the art, in order to enable the provider of the high-risk AI system to fully comply with the obligations set out in this Regulation".

• Client-Side Redundancy: Implement dynamic fallback routing between distinct physical clusters or dedicated backup nodes to mitigate transient upstream latency spikes.
• Circuit Breakers: Deploy deterministic rate limiters and timeout handlers to prevent cascade failures when upstream endpoints experience load surges.
• Written Bilateral Agreements: Utilize Article 25(4) written contracts for dedicated infrastructure to secure required technical access, performance parameters, and support channels.
• Audit Trail Logging: Record all failed inference calls and retry events locally to demonstrate system resilience in your Article 18 technical documentation.

Data Retention, DPAs, and the Application Logging Burden

A fundamental operational requirement for both providers (under Article 19) and deployers (under Article 26(6)) of high-risk AI systems is the retention of automatically generated event logs. Deployers must keep logs generated by high-risk systems under their control for at least six months, while providers must ensure systems possess native logging capabilities. Many engineering teams mistakenly assume that their API inference provider retains and archives these logs upstream on their behalf.

In an EU-sovereign infrastructure environment, that assumption is invalid. Our platform operates under a strict zero data retention architecture for prompts and model completions. This is a self-asserted operational standard with no third-party attestation behind it: prompts and generated tokens exist strictly within volatile GPU VRAM during CUDA kernel execution and are never written to persistent storage, cached in intermediate databases, or retained for model training. Because nothing is stored upstream, there are no prompt logs held on your behalf.

Designing Client-Side Logging and Data Governance

Because upstream inference leaves no trace, the entire burden of regulatory logging falls on your application layer. If your system requires compliance auditing, your software must intercept, sanitize, timestamp, and store all prompts, completions, latency metrics, and user identifiers within your own controlled storage perimeter.

1. Local Ingestion Gateways: Capture input prompts and model responses at your API gateway prior to dispatching requests to external inference endpoints.
2. Cryptographic Hashing: Generate tamper-evident audit logs using SHA-256 hash chains to prove log integrity without storing raw sensitive personal data unencrypted.
3. Data Processing Agreement Execution: Ensure your vendor relationship is covered by a valid Data Processing Agreement (DPA) governing data in transit, available directly in our website footer.
4. Model-Specific Residency Verification: Verify hosting location on a per-model basis. On Serverless Inference, hosting location is a per-model property rather than a uniform platform guarantee, so teams requiring strict EU data residency must confirm the specific data centre region for their chosen model string.

By implementing client-side logging, your team retains absolute control over data lifecycle policies while ensuring full compliance with both GDPR data minimisation principles and AI Act traceability rules.

Assigning and Defending Your Role Per System

To build a defensible regulatory posture, your organization must systematically assign and document its AI Act role for every software system in production. Attempting to classify your entire company under a single generic label will fail an audit. An enterprise almost always acts simultaneously as a deployer of third-party SaaS products, a downstream provider of proprietary internal tools, and a commercial provider of customer-facing applications.

A Four-Step System Classification Protocol

To establish clear boundaries for your technical compliance file, execute this evaluation sequence for every AI workload across your infrastructure:

1. Step 1: Define the System Boundary. Isolate the specific application, including retrieval pipelines, business logic, system prompts, and UI, rather than evaluating the raw model weights in isolation.
2. Step 2: Identify the Deployment Context. Determine whether the system is placed on the market under your trademark, put into service internally for your workforce (Article 3(11)), or consumed purely as a third-party turn-key application.
3. Step 3: Evaluate Risk Classification. Map the application's intended purpose against Annex III high-risk use cases to establish whether Article 16 provider obligations or Article 26 deployer duties apply.
4. Step 4: Execute Upstream Agreements. Ground your infrastructure dependencies via Article 25(4) bilateral agreements, and implement client-side logging architectures to satisfy Article 19 and Article 26(6) retention rules.

For teams deploying open-source models using sovereign European GPU infrastructure or self-hosting inference via engines like vLLM, owning your classification as a downstream provider is not a legal liability; it is an engineering reality. By establishing transparent system boundaries, maintaining local audit logs, and decoupling infrastructure hosting from statutory system accountability, you can scale high-performance ML pipelines that remain fully compliant with European regulation.