Are we a provider or a deployer of our AI system?

The default is deployer if you purchased or licensed the system and use it under the upstream provider's parameters. You become a provider under Article 25 if you put your name on the system and resell it, if you make a substantial modification, or if you put it into service for a new intended purpose. The role determination memo described above is the artifact that captures the decision.

What if we fine-tune a foundation model on our own data?

Fine-tuning sits on the edge of substantial modification. Light task-specific tuning that does not change the intended purpose or affect compliance with the high-risk requirements typically does not flip the assignment. Substantial changes to the system's classification behavior, the data scope, or the action space can flip it. A deliberate Article 25 analysis is warranted.

Does the deployer obligation apply if our system is not high-risk?

The Article 26 obligations apply specifically to high-risk AI systems. Non-high-risk systems have lighter obligations, primarily transparency for limited-risk systems under Article 50. The classification under Annex III determines which regime applies.

What is the Fundamental Rights Impact Assessment?

The FRIA under Article 27 is required for deployers of certain high-risk AI systems, particularly public-sector deployers and certain private-sector ones. The assessment documents the use case, the categories of natural persons affected, the specific risks to fundamental rights, the mitigation measures, and the governance arrangements. The FRIA is a deployer artifact, not a provider artifact.

How long do the Article 19 logs need to be retained?

At least six months as the floor under Article 19. Sectoral law often requires longer: financial-services deployers face five-to-ten-year retention under existing financial regulation; healthcare deployers face HIPAA-style retention obligations. The practical answer is that six months is the minimum and the operational retention is typically much longer.

What happens on August 2, 2026?

The high-risk AI system obligations take effect for systems placed on the market on or after that date. Systems placed on the market before that date have a transition window under Article 111, but operational deployer obligations like Article 19 logging apply at the August 2 boundary for any high-risk system in active use. The practical interpretation in most national contexts is that deployers should be prepared to demonstrate compliance on August 3.

EU AI Act Providers vs Deployers: Splitting the Obligations Before August 2, 2026

The EU AI Act assigns different obligations to providers and deployers of high-risk AI systems. Article 16 covers provider obligations. Article 26 covers deployer obligations. The split matters because most enterprises operating AI in the EU are deployers, not providers, and the deployer obligations get routinely underestimated. The provider built the system; the deployer puts it into use under its own authority. With the August 2, 2026 high-risk enforcement date 35 days away, every deployer running on someone else's foundation model needs a clear read on which obligations belong to them and which sit with the upstream provider.

The split is not always intuitive. A SaaS vendor that integrates a foundation model and resells it under their own brand becomes a provider under Article 25, even though they did not train the underlying model. An enterprise that takes a vendor's high-risk AI system and modifies it substantially can become the provider of the modified system. A deployer that puts a CE-marked high-risk system into use still owns most of the operational obligations regardless of who built the system.

I want to walk through the provider-deployer split as the regulation actually assigns it, the cases that flip the assignment, the architectural artifacts each side needs to produce, and the documentation patterns that hold up under a deployer audit.

The default split

The default assignment is straightforward when the AI value chain has clear roles.

Provider obligations under Article 16 include the risk-management system (Article 9), data and data governance (Article 10), technical documentation (Article 11), record-keeping/automatic logging in the system as designed (Article 12), transparency and information to deployers (Article 13), human oversight design (Article 14), accuracy and cybersecurity (Article 15), and the quality management system (Article 17). The provider also handles conformity assessment, EU declaration of conformity, CE marking, and registration in the EU database before placing the system on the market.

Deployer obligations under Article 26 include using the system in accordance with the provider's instructions, assigning human oversight to natural persons with the necessary competence, ensuring that input data is relevant and sufficiently representative for the intended purpose, monitoring operation, suspending use when the system presents a risk to health, safety, or fundamental rights, keeping the automatically generated logs for at least six months (Article 19), informing affected persons about the use of the high-risk system, and conducting a Fundamental Rights Impact Assessment (Article 27) where applicable.

A clean way to summarize the default split: the provider proves the system was built right; the deployer proves the system is being used right.

The cases that flip the assignment

Four cases change the default assignment and turn a presumed deployer into a provider for regulatory purposes.

Substantial modification (Article 25(1)(c)). A deployer that makes a substantial modification to a high-risk AI system becomes the provider of the modified system. The regulation defines substantial modification as a change to the intended purpose or a modification that affects compliance with the high-risk requirements. Fine-tuning a foundation model on the deployer's own data, materially changing the system's classification thresholds, or adding a tool surface that changes the action space all sit on the edge of substantial modification and warrant a deliberate decision.

Branding and resale (Article 25(1)(a)). An organization that puts its name or trademark on a high-risk AI system already placed on the market becomes a provider of that system. A SaaS company that integrates a third-party AI system and resells it as its own product is in this category by default unless the contractual arrangement explicitly preserves the underlying provider's role.

Repurposing for a new intended purpose (Article 25(1)(b)). An organization that puts an existing system into service for a different intended purpose than what the original provider declared becomes the provider for that new purpose. The classic case is taking a general-purpose system and deploying it for an Annex III high-risk use case it was not originally documented for.

GPAI integration that crosses systemic-risk thresholds. The general-purpose AI provisions create a separate role for GPAI providers with additional obligations triggered when the model crosses computational or capability thresholds. An enterprise that builds on top of a GPAI model is typically not the GPAI provider, but the integration choices the enterprise makes can affect whether the resulting system is itself a high-risk AI system.

The architectural artifacts each side needs

The artifacts the provider produces are different in kind from the artifacts the deployer produces.

Provider artifacts include the technical documentation under Article 11 (system description, design specifications, development process, training data summary, performance metrics, risk-management measures), the EU declaration of conformity, the CE marking, the registration in the EU database, the post-market monitoring plan, the incident reporting procedure, and the documentation provided to deployers under Article 13 that explains capabilities, limitations, intended purpose, performance characteristics, and the human-oversight measures the deployer needs to implement.

Deployer artifacts include the assignment of human oversight roles and the competence evidence for the natural persons in those roles, the input-data review record showing the data is relevant and representative for the intended purpose, the monitoring log showing the system has been observed in operation, the incident log capturing any suspension events and the reasons, the records of automatic logging retained for at least six months under Article 19, the Fundamental Rights Impact Assessment where applicable under Article 27, and the records showing affected persons were informed about the AI system's use.

The deployer's logging obligation under Article 19 is the artifact most enterprises underestimate. The system as designed must produce the automatic logs (provider obligation); the deployer must actually retain them in a form a regulator can examine. An application that emits logs into a rotated file that gets overwritten every 30 days fails the deployer obligation even when the provider's design satisfied the production obligation.

The documentation patterns that hold up under a deployer audit

Three documentation patterns recur across enterprise deployers preparing for the August 2 enforcement date.

The role determination memo. A short document, signed by legal and the business owner, that states the enterprise's role for each high-risk AI system in production: provider, deployer, both, or neither. The determination cites Article 25 explicitly for any case where the default has been flipped. The memo is the single source of truth that all downstream compliance work references.

The Article 26 obligations matrix. A table that maps each Article 26 obligation to the natural person responsible, the artifact that demonstrates compliance, the location of the artifact, the retention period, and the review cadence. The matrix is the operating system of the deployer's compliance posture. Auditors ask for it by name.

The Article 19 log architecture diagram. A diagram showing how every AI request produces a log entry, where the log is stored, how the storage handles retention, how the integrity of the log is protected, and how the deployer would produce the log on a regulator's request. The diagram is the artifact that turns the abstract logging obligation into something a security architect can review.

What sits with the foundation model provider regardless

GPAI providers operating in the EU have their own obligations under the GPAI provisions of the regulation. Those obligations include technical documentation about the model, information available to downstream providers integrating the model, and the additional obligations for models with systemic risk. The deployer is not on the hook for the GPAI provider's documentation; the deployer is on the hook for using the GPAI-integrated system within the parameters the upstream documentation specifies.

This is the case where the contractual arrangement matters as much as the regulatory text. A deployer that selects a foundation model from a provider whose documentation is thin has a deployer-side problem: the input-data and intended-purpose obligations under Article 26 cannot be discharged if the upstream documentation does not specify the parameters. The procurement workflow needs to test for documentation adequacy before contract signing.

The architectural artifact every deployer underestimates: identity-bound logs

Article 19 specifies what goes in the automatic logs: period of use, reference databases checked, input data leading to a match, and the identity of natural persons involved in result verification. The last item is the one most deployers fail. AI systems running on shared service credentials cannot identify the natural person behind a request. The credential identifies the application, not the human or agent on whose behalf the application is acting.

The architectural answer is identity-bound logging at the AI request layer. Every request that reaches the model carries the verified identity of the natural person or agent that initiated it, and the log entry records the identity alongside the request and response. The artifact that satisfies the obligation is a per-decision audit record with identity context attached at the request boundary.

Application logs that the application controls do not satisfy the obligation reliably because the application can suppress them, the application can fail to write them on crash, and the application can selectively omit the identity field. The control needs to live at the layer that sees every request independently of the application.

DeepInspect

This is the deployer-side infrastructure DeepInspect was built to provide. DeepInspect sits inline between authenticated users or agents and the LLMs they call, binds every request to a verified identity, enforces per-route per-role policies, and writes a per-decision audit record outside the calling application.

For the Article 26 deployer obligations and the Article 19 logging requirement, DeepInspect produces the records the deployer needs in the form an auditor can examine. The records include identity, role, policy version, data classification applied, decision outcome, and timestamps with sufficient precision to correlate across systems. The records are signed and tamper-evident. The records are retained for the configured retention period (six months minimum under Article 19; longer for jurisdictions and sectors with longer obligations).

For the role determination question, the gateway-layer log is the same artifact regardless of which natural-person role the deployer ultimately occupies. The deployer obligation is the same whether the underlying provider is OpenAI, Anthropic, Bedrock, or an internal fine-tune.

If you are facing the August deadline and your Article 26 readiness depends on application logs that the application controls, let's talk today.