1 June 2026DILAIG

"Placing on the Market" vs "Putting into Service" Under the AI Act: Key Legal Distinctions

The AI Act''s two key triggering concepts — placing on the market and putting into service — determine when obligations apply and who bears them. Getting the distinction wrong is one of the most common compliance errors.

Last updated: June 2026 · Reading time: 7 minutes

Two short phrases — "placing on the market" and "putting into service" — appear throughout the EU AI Act and determine when high-risk AI obligations are triggered and who must meet them. Many organisations misunderstand these concepts, resulting in compliance programmes that either activate too early, too late, or leave gaps in who takes responsibility.

This article explains both concepts precisely, shows how they differ, and maps them to the real-world scenarios where the distinction matters most.

The Definitions

Both concepts are defined in Article 3 of Regulation (EU) 2024/1689.

Placing on the market (Article 3(9)): the first making available of an AI system or a general-purpose AI model on the EU market.

Putting into service (Article 3(11)): the supply of an AI system for first use directly to the deployer or for the deployer''s own use in the EU for its intended purpose.

At first glance, these sound similar. They are not. The distinction maps to different actors and different moments.

The Core Distinction: Commercial Supply vs. Operational Deployment

Placing on the market is a commercial act — it is the moment when a provider makes an AI system available to others. It typically occurs when:

A software company releases a new AI system product for purchase or licensing
An AI company makes an API-based model available for integration by third parties
A vendor publishes an AI system on an app store or marketplace

Putting into service is an operational act — it is the moment when an AI system is first actually used for its intended purpose. It occurs when:

An organisation deploys an AI system it built itself for its own operations
An organisation that purchased an AI system activates it in a live production environment
A public body begins using a procured AI system to make real decisions

The key difference: placing on the market involves making the system available to others. Putting into service involves actually using it.

DILAIG automates this step — free AI Act audit in 20 min, FRIA generation, Annex IV Technical Documentation and EU Declaration of Conformity included. See all features → Why the Distinction Matters: Provider vs. Deployer Obligations

The AI Act assigns obligations based on which of these two events applies to your organisation''s role.

Providers are those who place an AI system on the market or put it into service under their own name or trademark. Provider obligations under Articles 9–17 include: risk management, data governance, technical documentation, logging, transparency, human oversight, accuracy and robustness, conformity assessment, registration, and post-market monitoring.

Deployers are those who use a high-risk AI system under their own authority. Deployer obligations under Article 26 include: using the system in accordance with instructions for use, ensuring human oversight, monitoring for anomalies, notifying the provider of risks, and — where applicable — conducting a FRIA.

The concept of "putting into service" is what creates provider obligations for organisations that build AI systems for internal use. If a bank builds its own credit scoring model and uses it in its own operations, it has put a high-risk AI system into service under its own name — and bears provider obligations under the AI Act, not merely deployer obligations.

Scenario Analysis: Where the Distinction Creates Compliance Questions

Scenario 1: A software vendor sells an AI screening tool to HR departments

The software vendor places the system on the market. Provider obligations apply to the vendor from the moment the system is made available.

Each HR department that purchases and activates the system puts it into service. The HR department is a deployer with Article 26 obligations.

The vendor''s provider obligations include: technical documentation, conformity assessment, instructions for use, EU Declaration of Conformity, and CE marking.

The HR department''s deployer obligations include: implementing the provider''s oversight instructions, monitoring for unexpected outcomes, and conducting a FRIA if the organisation is a public body.

Scenario 2: A large bank develops an internal fraud detection AI

The bank develops the system for its own use. It does not sell or license it to others. The bank puts the system into service.

Because the bank is putting the system into service under its own name or trademark, it is also the provider under Article 3(3)''s inclusive definition. The bank bears full provider obligations under Articles 9–17 plus Article 26 deployer obligations — all within a single organisation.

This is the "own use" scenario that surprises many organisations. Internal development for own use does not escape provider obligations.

Scenario 3: A company acquires an AI system and substantially modifies it before deployment

Article 25 of the AI Act addresses this. If a downstream entity makes a substantial modification to a high-risk AI system — one that changes the system''s intended purpose or affects its compliance with the mandatory requirements — that entity becomes a new provider. It must conduct a new conformity assessment and draw up new technical documentation before putting the modified system into service.

"Substantial modification" is not defined by a simple technical threshold. It requires assessment against whether the modification changes the system in ways that matter to the risk classification and technical compliance. Fine-tuning a model on domain-specific data, without changing its purpose or risk profile, may not be substantial. Adding a new use case to an existing system likely is.

Scenario 4: A SaaS company provides AI-as-a-Service via API

The SaaS company places the AI system on the market by making it available via its API. Each business customer that integrates the API and activates it in a production system puts it into service.

If the AI system is high-risk, the SaaS company (provider) must have completed its conformity assessment before making the system available. Business customers using the API are deployers.

However, if a business customer builds a distinct AI application on top of the API — adding functionality that changes the system''s purpose or creates a new high-risk application — that customer may become a provider of a new AI system.

Scenario 5: A single EU member state public authority deploys an AI system for benefits eligibility screening

The public authority procures an AI system from a private vendor (vendor places on market, authority deploys). The authority puts the system into service when it activates it for live decisions.

The vendor is the provider. The public authority is the deployer. The authority must comply with Article 26, including the FRIA obligation under Article 27 (public bodies must complete FRIAs for high-risk AI).

The Compliance Timeline Implications

The timing distinction matters for the August 2026 compliance deadline.

The AI Act''s high-risk obligations apply:

For new systems placed on the market or put into service from August 2026: Full compliance required before placement or deployment.
For systems already on the market or in service before August 2026: A transitional period applies, with some flexibility for systems already deployed under national law before that date.

Systems that were placed on the market before the applicable date but are substantially modified after it are treated as new systems for compliance purposes.

How DILAIG Helps

Whether you are placing a system on the market or putting it into service, DILAIG''s 50-question audit generates the four mandatory documents required by the AI Act — tailored to your specific role as provider.

→ Start your free AI Act audit — 20 minutes, no credit card required.

See all features and generated documents · View pricing

FAQ: "Placing on the Market" vs "Putting into Service"

Q: Can a system be "placed on the market" without being "put into service"? Yes. A vendor can make an AI system commercially available without any deployer yet having activated it. The placing on the market event occurs at the moment of making available, regardless of whether the system is yet being used.

Q: Can both events happen simultaneously? Yes, in the own-use scenario. When an organisation develops an AI system for its own use and activates it, it places the system on the market and puts it into service at the same moment — and is simultaneously provider and deployer.

Q: Does a beta release or pilot deployment count as "placing on the market"? Generally yes, if the beta or pilot involves making the system available to external parties — even free of charge. The AI Act does not require commercial consideration. Making a system available for testing purposes to parties outside the developer''s organisation constitutes placing on the market for compliance purposes.

Q: Does the distinction affect the CE marking obligation? Yes. The CE marking must be affixed before a system is placed on the EU market or put into service. It cannot be applied retrospectively. This means conformity assessment and all documentation must be complete before either triggering event occurs.

Key Takeaways

"Placing on the market" is a commercial act: making an AI system available to others.
"Putting into service" is an operational act: activating an AI system for actual use.
Both events trigger AI Act obligations, but they trigger different obligations for different actors.
Organisations that build AI for their own internal use bear provider obligations — not merely deployer obligations.
Substantial modification of a procured system after deployment can transform a deployer into a provider, requiring a new conformity assessment.