Skip to main content
Bureau of AI
Category: Deployment Practices

Putting into Service

Also known as: Put into service
Simply put

Putting into service refers to the point at which a product or system is first made available for its intended use within the European Union, either supplied directly to the party who will use it or made available for the supplier's own use. In the context of the EU AI Act, it marks the moment an AI system is first supplied for use, as distinct from being placed on the market for sale. It is a timing concept used to determine when certain regulatory obligations attach.

Formal definition

In EU regulatory instruments, "putting into service" is a market-access timing trigger denoting the first use of a product or system for its intended purpose within the Union. As defined in the EU AI Act, it refers to the supply of an AI system for first use directly to the deployer or for the provider's own use on the Union market. The concept appears across multiple EU frameworks with sector-specific formulations: in medical device regulation it is described as the stage at which a device is ready for use on the market for the first time, and devices may be put into service only where they comply with the applicable regulation when duly supplied and properly installed, maintained, and used. Practitioners should note that "putting into service" is typically distinguished from "placing on the market" (making a product available for the first time), and that its precise legal definition and the obligations it triggers vary by the specific EU regulation and sector in question. The definitions cited here are drawn from EU AI Act and EU device regulation contexts; applicability outside these specific instruments and jurisdictions is out of scope of this entry.

Why it matters

"Putting into service" functions as a timing trigger in EU regulatory instruments, and getting that timing right determines when legal obligations attach to an AI system. Because the EU AI Act distinguishes putting into service (supplying a system for first use) from placing on the market (making it available for sale), an organization can fall within scope of the regulation even when no commercial sale occurs — for example, where a provider deploys an AI system for its own use on the Union market. Misjudging this moment can leave an obligation unmet at the point it legally crystallizes.

The concept also matters because it is not uniform across EU frameworks. As commonly defined, the same phrase carries sector-specific formulations: in medical device regulation it is described as the stage at which a device is ready for use on the market for the first time, and devices may be put into service only where they comply with the applicable regulation when duly supplied and properly installed, maintained, and used. Practitioners who assume a single definition applies across the AI Act, device regulation, and other product rules risk applying the wrong trigger and the wrong set of obligations.

For compliance and legal teams, precision here supports defensible decisions about when conformity, documentation, and other requirements must be satisfied. The definitions discussed in this entry are drawn from EU AI Act and EU device regulation contexts; the term's precise legal meaning and the obligations it triggers vary by the specific EU regulation and sector in question, and applicability outside these instruments and jurisdictions is out of scope.

Who it's relevant to

Compliance officers and legal specialists
Those determining when EU AI Act obligations attach need to identify the point of putting into service, particularly where a provider deploys a system for its own use without a commercial sale, since obligations may attach even absent placing on the market.
AI system providers and deployers
Providers supplying a system for first use — including for their own use on the Union market — and deployers receiving it should understand this trigger, as it marks the moment certain regulatory requirements crystallize under the EU AI Act as defined.
Medical device and regulated product teams
Teams operating under EU device regulation should note the sector-specific formulation, under which a device may be put into service only if it complies with the applicable regulation when duly supplied and properly installed, maintained, and used.
Auditors and market-access specialists
Professionals assessing compliance timelines must distinguish putting into service from placing on the market and confirm which EU instrument governs, since the precise definition and triggered obligations vary by regulation and sector.

Inside Putting into Service

Placing on the Market vs. Putting into Service
In the EU AI Act's terminology, 'putting into service' commonly refers to the supply of an AI system for first use directly to the deployer or for the provider's own use for its intended purpose, whereas 'placing on the market' refers to first making the system available on the EU market. The two are distinct triggering events, and an entry should not treat them as synonyms.
Triggering Event for Obligations
Putting into service typically functions as a moment that can trigger applicable obligations under the EU AI Act for the relevant actor. The precise obligations depend on the system's risk classification and the actor's role, and this may vary from the point of placing on the market.
Intended Purpose
As commonly framed, putting into service is tied to use for the system's intended purpose. The intended purpose, typically defined by the provider, is a reference point for assessing conformity and for distinguishing normal operation from misuse.
Actor Roles
The concept implicates the roles of provider and deployer (and potentially the provider's own internal use). Which obligations attach depends on which role an organization occupies, and roles may shift depending on how a system is modified or supplied.

Common questions

Answers to the questions practitioners most commonly ask about Putting into Service.

Does putting into service mean the same thing as placing on the market?
No, and professionals frequently conflate the two. As commonly defined in the EU AI Act framework, 'placing on the market' typically refers to the first making available of a system on the market, while 'putting into service' refers to the supply of a system for first use directly to a deployer or for a provider's own use for its intended purpose. A system can be put into service without ever being placed on the market, for example where an organization builds and deploys a system for its own internal use. Treat them as distinct triggering events rather than interchangeable terms.
Does putting into service always require a commercial sale or transaction?
No. As the concept is commonly framed, putting into service concerns first use for the intended purpose, which can occur without any sale, payment, or transfer of ownership. Internal deployment for a provider's own use may fall within scope. Because interpretation can be fact-specific and jurisdiction-specific, organizations should not assume that the absence of a commercial transaction removes a system from scope, and should seek qualified legal advice on borderline cases.
How can an organization determine the point at which a system is considered put into service?
In practice, organizations typically identify the moment the system is first supplied for use for its intended purpose, which may differ from development completion, testing, or procurement. It can help to document the transition from testing or piloting to operational use, since the intended-purpose criterion is central. Because this determination is fact-specific and can carry legal consequences, confirm the assessment with legal or compliance functions rather than relying solely on internal engineering milestones.
What documentation should support a putting-into-service determination?
Commonly, organizations maintain records that evidence when and how a system entered operational use for its intended purpose, the defined intended purpose itself, and the roles of the parties involved. Because the determination affects which obligations attach and to whom, keeping a clear, dated record of the transition to first use supports auditability and helps second-line and third-line functions review the basis for the classification. The specific evidentiary expectations can vary by framework and context.
How does putting into service relate to the allocation of provider and deployer responsibilities?
The point of putting into service is often relevant to identifying which party bears which obligations, since roles such as provider and deployer typically carry different duties. Where an organization both develops and puts a system into service for its own use, it may hold obligations associated with more than one role. Because role classification can be complex and fact-dependent, organizations should map responsibilities deliberately rather than assuming a single actor holds all duties.
How should putting into service be integrated into existing governance and model risk processes?
Organizations commonly treat the transition to first operational use as a control point, aligning it with governance gates such as approval to deploy and with model risk activities such as validation sign-off and ongoing monitoring. Note the distinction: putting into service is a regulatory-status concept concerning first use for the intended purpose, whereas validation and monitoring are model risk management activities that reduce, but do not eliminate, risk. Coordinating the two helps ensure that a system is not put into service before required approvals and controls are in place, without collapsing the legal concept into the risk process.

Common misconceptions

Putting into service and placing on the market mean the same thing.
They are distinct concepts in the EU AI Act's terminology. Placing on the market concerns first availability on the market, while putting into service concerns first supply for use, including a provider's own use, for the intended purpose. Conflating them can lead to misidentifying which obligations are triggered and when.
Putting into service is a general, jurisdiction-neutral term that applies to all AI governance and model risk frameworks.
The term is most closely associated with EU product and AI legislation terminology and its specific scope. It should not be assumed to carry the same meaning, or any defined meaning, under frameworks such as the NIST AI Risk Management Framework, ISO/IEC 42001, or supervisory guidance like SR 11-7, which are issued by different bodies and are not interchangeable.
Once a system is put into service, obligations end because the deployment moment has passed.
Putting into service is typically a triggering event rather than an endpoint. Obligations, which vary by risk classification and actor role, may continue after deployment. Reaching this milestone reduces and manages compliance risk but does not eliminate ongoing responsibilities.

Best practices

Determine and document whether a given event constitutes 'placing on the market' or 'putting into service' for each AI system, since the two can trigger different obligations at different times.
Clarify and record your organization's role (provider, deployer, or provider using the system for its own purposes) before deployment, and reassess if the system is modified or re-supplied.
Define and document the intended purpose of the system and confirm that actual deployment aligns with it, treating deviations as a signal to re-evaluate applicable obligations.
Scope your analysis to the correct jurisdiction and instrument, and avoid assuming that this EU-oriented terminology maps onto voluntary standards or supervisory guidance issued by other bodies.
Establish post-deployment monitoring and record-keeping so that obligations potentially continuing after putting into service are tracked, rather than treating deployment as the end of compliance activity.
Where the applicability of a specific obligation, effective date, or classification is uncertain, seek qualified legal review rather than relying on generalized assumptions about the term.