Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

Short answer: The EU AI Act (Regulation (EU) 2024/1689) assigns different responsibilities according to what an organisation does and what kind of AI is involved. A provider places an AI system on the market or puts it into service; a deployer uses it. High-risk systems trigger the most extensive controls, while prohibited practices, transparency-regulated systems and general-purpose AI models follow separate rules. A company can hold more than one role, and rebranding, substantially modifying or changing the intended purpose of a high-risk system can make it the provider under the value-chain rules.

The duties are phased rather than governed by one deadline. The relevant date depends on the provision, system category, lifecycle stage and any transition rule. This guide explains the role analysis, category framework, provider and deployer duties, dates and an implementation sequence. It is general information, not a classification opinion or legal advice.

Start with the activity, role and system category

The Act’s first practical question is not “Which checklist applies?” It is “What is the organisation doing, and what is the AI system intended to do?” The same organisation may be a provider for one product, a deployer for another and an importer, distributor or other operator elsewhere in the supply chain.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Provider

A provider is the organisation that develops an AI system or has one developed and places it on the market or puts it into service under its name or trademark. Provider obligations therefore attach to making a system available or operational in the Union, not merely to using a tool internally.

Deployer

A deployer is the organisation or person using an AI system under its authority, except where the system is used in a personal, non-professional activity. Deployer duties concern operational use: following instructions, assigning oversight, monitoring performance and responding to risks.

When another operator is treated as the provider

The value-chain rules can transfer provider treatment. An importer, distributor, deployer or other third party may be treated as the provider of a high-risk system when it:

  • puts its own name or trademark on the system;
  • substantially modifies the system while it remains high-risk; or
  • changes the system’s intended purpose so that it becomes high-risk.

A modification does not automatically transfer every provider duty. The facts, the system’s continuing classification, the intended purpose and the specific statutory exceptions determine which obligations apply.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Classify the AI before applying obligations

The Act is risk-based. It separates prohibited AI practices, high-risk AI systems, systems subject to transparency rules and general-purpose AI models. A high-risk checklist cannot simply be applied to every product or use case.

Category What it means for analysis Typical compliance focus
Prohibited practices Practices banned by the Act, subject to the provision’s scope and stated exceptions. Stop the prohibited practice; do not treat it as a normal product-compliance exercise.
High-risk AI systems Systems falling within the high-risk categories and provisions, including systems classified under Article 6(2) and Annex III or Article 6(1) and Annex I. Detailed provider controls, conformity procedures and operational duties for deployers.
Transparency-regulated systems Systems for which users or affected people must receive specified information, even when the system is not high-risk. Clear notices and other transparency measures required by the applicable provision.
General-purpose AI models Models governed by a separate set of obligations for providers of those models. Model-provider duties and the dates applicable to that regime.

Classification depends on the system’s intended purpose and the legal definitions, not on marketing language alone. Record the purpose, deployment context, users, affected people and technical configuration that support the decision. Revisit the analysis after a significant design change or a change of intended purpose.

What providers of high-risk systems must do

Before placing a high-risk system on the market or putting it into service, the provider is responsible for meeting the requirements that apply to that system and completing the relevant conformity process. The Act’s chapters and exceptions control the exact scope.

Risk management

Maintain a documented, ongoing risk-management process covering the foreseeable risks associated with the system’s intended purpose and reasonably foreseeable misuse. The process is not a one-time assessment: it must inform design, testing, deployment and corrective action.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Data and data governance

Apply the data-governance requirements relevant to the system, including controls over the quality and suitability of data used in the system’s development and operation. Keep evidence showing how data practices support the system’s intended function and reduce relevant risks.

Technical documentation and records

Prepare the technical documentation required for the system and keep it current. Providers must also support record-keeping, including the system information needed to demonstrate conformity and traceability. Automatically generated logs are part of the wider accountability picture, with retention responsibilities also applying to deployers where logs are under their control.

Information and instructions for deployers

Supply usable instructions and information that allow deployers to operate the system as intended, understand relevant limitations and apply human oversight. Instructions should be specific enough for the actual deployment, not merely a generic product description.

Human oversight

Design the system and its operating instructions so competent people can oversee it, interpret outputs, detect abnormal behaviour and intervene or stop the system when necessary. The provider must account for the skills, authority and operating conditions of the people expected to supervise it.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Accuracy, robustness and cybersecurity

Meet the applicable requirements for accuracy, robustness and cybersecurity. These are system-level obligations: providers should be able to explain how the system performs for its intended purpose, how it handles errors or changes in conditions and how it is protected against relevant attacks or manipulation.

Quality management, conformity and registration

Operate the required quality-management system, complete the applicable conformity assessment, prepare the required declarations or markings and register the system where the Act requires registration. The exact route depends on the high-risk classification and any available exception.

Corrective action and cooperation

Monitor the system after it is made available, investigate non-compliance and take corrective action when necessary. Depending on the circumstances, that may include bringing the system into conformity, withdrawing it or recalling it. Providers must cooperate with the relevant authorities and with deployers that need information or technical assistance to comply.

What deployers of high-risk systems must do

Deployers are accountable for how a high-risk system is used in practice. Their obligations are operational and must be read with the relevant exceptions.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Follow the instructions and control the deployment

Use the system in accordance with the provider’s instructions for use. Put appropriate technical and organisational measures in place, including access controls, approved workflows and procedures for handling outputs that are uncertain, incomplete or unsuitable for the intended decision.

Assign competent human oversight

Assign oversight to people with the competence, training, authority and support needed to supervise the system. Oversight should be meaningful: the person must be able to understand the output in context, disregard it where appropriate and intervene when the system behaves unexpectedly.

Monitor operation and retain logs

Monitor the system’s operation and investigate material deviations from expected performance. Retain automatically generated logs when they are under the deployer’s control, for the period and purposes required by the applicable rules and internal retention policy. Protect logs against unauthorised alteration and limit access to legitimate personnel.

Give required workplace notices

Where the Act requires it, inform workers that they are subject to the use of an AI system. The notice duty is context-specific; do not assume that every internal AI tool requires the same notice or that a general privacy notice is always sufficient.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Complete impact assessments where required

Certain public-sector deployers and deployers providing particular essential services must carry out an impact assessment before use, subject to the conditions and exceptions in the applicable provision. A private organisation should not assume that this public-authority obligation applies to it, but it should check whether another role or sector-specific rule does.

Escalate risks and serious incidents

If the system presents a risk, stop or restrict use as appropriate, inform the provider and take the other action required by the Act. Serious incidents require escalation through the prescribed channels and cooperation with the provider or authorities. Keep a decision record showing what happened, who assessed it and what remediation followed.

Provider versus deployer: the practical boundary

Question Provider perspective Deployer perspective
Lifecycle trigger Placing the system on the market or putting it into service. Using the system under the organisation’s authority.
Primary evidence Technical file, risk process, quality system, conformity records and instructions. Deployment records, oversight assignments, monitoring results, logs and incident actions.
Main control Build and release a compliant system, then correct defects. Operate the system within its instructions and organisational safeguards.
Role change risk Rebranding or substantial modification can make another operator the provider. Changing intended purpose can make the deployer the provider of a high-risk system.

Contracts do not decide the legal role by themselves. Analyse the actual activity, technical control, name or trademark, intended purpose and changes made to the system. A business can therefore need two coordinated compliance tracks: provider controls for a product it supplies and deployer controls for tools it uses internally.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Application dates and transition rules

The Act applies in stages. The dates below are statutory application summaries and are not a substitute for checking the provision, category and transition rule that applies to a particular system.

What’s actually slowing this PC down?

Pick the symptom - the matching free tool is one click away.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Date What the official timeline identifies
2 February 2025 AI-literacy provisions and most prohibitions began to apply, with specific exceptions to the prohibited-practice start date.
2 August 2025 Some provisions, including governance and penalties, and obligations for providers of general-purpose AI models, began to apply.
2 August 2026 The Regulation generally applies, subject to stated exceptions and later category-specific dates.
2 December 2026 Under Regulation (EU) 2026/1744, providers of AI systems, including general-purpose AI systems, that generate synthetic audio, image, video or text content and were placed on the market before 2 August 2026 must take steps to comply with Article 50(2).
2 December 2027 High-risk requirements identified for systems under Article 6(2) and Annex III are listed to apply.
2 August 2028 High-risk requirements for systems under Article 6(1) and Annex I are listed to apply.
2 August 2030 The amended text gives providers and deployers of high-risk systems intended for use by public authorities this date to take the necessary compliance steps.

Article 111 transition rules also address systems placed on the market or put into service before the relevant application dates and systems that undergo significant design changes. Do not reuse an older timeline graphic without checking the consolidated text dated 27 July 2026 and Regulation (EU) 2026/1744.

A workable implementation sequence

  1. Map every system and supplier. Record the model or system, owner, provider, deployer, importer or distributor, intended purpose, users, affected people and deployment locations.
  2. Determine the legal category. Check prohibited-practice rules, high-risk provisions, transparency requirements and the separate general-purpose AI model regime.
  3. Test for provider treatment. Ask whether your organisation applies its name or trademark, substantially modifies a high-risk system or changes its intended purpose into a high-risk use.
  4. Assign the applicable date. Match the category and lifecycle stage to the staged dates and Article 111 transition rules. Record the legal basis for the date.
  5. Build the evidence file. For providers, assemble risk, data-governance, technical-documentation, quality, conformity and corrective-action records. For deployers, assemble instructions, oversight assignments, monitoring, log-retention and incident procedures.
  6. Set human and technical controls. Define who can approve use, override outputs, suspend the system, access logs and notify the provider or authorities.
  7. Review changes continuously. Reassess classification and role after model updates, retraining, integration changes, new users, new geography or a changed intended purpose.

Common mistakes to avoid

  • Treating every AI tool as high-risk: category and intended purpose come first.
  • Using one deadline: the Act has staged dates and amendment-specific transitions.
  • Assuming the vendor carries all responsibility: deployers have independent operational duties.
  • Assuming every change transfers provider status: the value-chain rule refers to specified rebranding, substantial modification and intended-purpose changes.
  • Relying on a contract label: actual conduct and control determine the role.
  • Keeping only a policy document: compliance requires operational evidence such as logs, oversight records, technical documentation and corrective-action files.
  • Ignoring public-authority rules: some impact-assessment and transition provisions depend on the organisation and use context.

What the Act is designed to achieve

Article 1 states the purpose of Regulation (EU) 2024/1689: “The purpose of this Regulation is to improve the functioning of the internal market and promote the uptake of human centric and trustworthy artificial intelligence (AI), while ensuring a high level of protection of health, safety, fundamental rights enshrined in the Charter, including democracy, the rule of law and environmental protection, against the harmful effects of AI systems in the Union and supporting innovation.”

For an organisation, that purpose translates into a disciplined sequence: identify the role, classify the system, apply the obligations for that category, follow the correct date and retain evidence that the system was designed and used as required. The consolidated legal text and later amendments should be checked whenever a system, purpose or deployment context changes.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.