EU AI Act: assess roles, use cases and application dates

The obligations created by the EU AI Act depend on the particular system, its intended purpose and the organisation's role. A company using finished writing software starts from a different position than a provider of applicant assessment software. An agency can obtain a third-party model while supplying its own AI system. A defensible assessment therefore begins with a described use case rather than the name of a tool.

Jurisdiction and review date: Germany and the European Union, checked on 9 November 2026. This article explains an approach to business decisions. The legal classification of a particular system depends on its actual characteristics and conditions of use. The worksheets and fictional examples do not replace that individual assessment.

Start with the correct version of the legislation

The starting point is Regulation (EU) 2024/1689. Regulation (EU) 2026/1744 amended it. That amending regulation was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. The Digital Omnibus on AI considered here is therefore enacted amending legislation. An earlier announcement about a proposal or a political agreement does not describe this final legal position.

The consolidated German EUR-Lex text dated 27 July 2026 brings the amendments together for reading and includes the indicated corrections. A consolidation is an information text. The versions of the legal acts published in the Official Journal remain authoritative. The published amending Regulation 2026/1744 provides the direct legislative evidence. A saved assessment should identify its review date, legal sources and the system version examined.

This distinction has practical consequences. A brochure repeating the original August date for all high-risk requirements is no longer an adequate implementation calendar. Conversely, an extended high-risk deadline does not suspend transparency, prohibitions or other areas of law. Each obligation needs its own applicable provision and date.

Describe a use case in terms that can be checked

“We use AI in sales” provides too little information. A better description is that staff create a draft response to general quotation questions from approved product information. An assigned person checks facts, prices and the recipient before independently deciding whether to send it. Personal special cases and automatic contractual commitments are outside the intended scope. Purpose, inputs, outputs and consequences now become visible.

The boundaries matter just as much. May the system only compose text or may it also prioritise enquiries? Does it receive customer names or only general product data? Can an output change a booking without another action? An apparently modest assistant can become a materially different use case when additional decision-making powers are introduced. Those changes belong in the description rather than disappearing into a technical maintenance label.

Article 3 connects intended purpose with the provider's information, instructions, promotional material and technical documentation. Product promises and actual functions therefore need to agree. Someone marketing a tool as an objective suitability assessment cannot base the entire legal analysis on the friendlier internal description of a writing assistant.

Separate the model, the system and the organisation

A general-purpose AI model is not the same thing as a finished business application. Different systems with different tasks can be built on the same model. A search interface with document retrieval, access control and response generation has a different scope from the underlying model. The role assessment should show where each component originates and who takes responsibility for the complete system.

Under its conditions, the provider definition includes having a system developed and putting it into service under one's own name. Training an original model is not a necessary condition for being the provider of an AI system. Equally, consuming a third-party interface does not automatically make a company the provider of the underlying model. These are separate layers of analysis.

Territorial scope under Article 2 is not simply a question of server location. Establishment outside Europe does not necessarily exclude the Act when the Union market or certain outputs used in the Union are involved. A normal German business should not describe its business deployment as the excluded purely personal, non-professional activity. It should identify the actual organisation and use instead.

Determine roles from what each party actually does

In simplified terms, a deployer is the organisation using an AI system under its authority. A provider, subject to the legal conditions, develops a system or has it developed and places it on the market or puts it into service under its own name or trademark. The Act also recognises importers, distributors and authorised representatives. These roles are not optional contractual headings.

A company can hold several roles. An external development agency is not necessarily the only legally relevant provider merely because it wrote the source code. The commission, branding, supply and actual allocation of responsibility need to be considered together. The record should contain a reasoned provisional conclusion and clearly identify any documents still missing.

Check prohibited practices before ordinary risk classification

A possible prohibition belongs at the beginning. An extensive documentation folder cannot authorise a prohibited practice. Article 5 in its current wording contains different prohibitions with their own conditions. One relevant example is the general prohibition of emotion inference in workplace and educational settings, subject to particular medical or safety exceptions. Not every analysis of emotional language necessarily meets the legal definition of an emotion recognition system.

The conditions of manipulative practices must not be omitted either. The regulation does not simply prohibit every persuasive advertisement. The characteristics of the technique, the interference with behaviour and the relevant harm need to be examined. Where a function may fall within a prohibition, its actual operation should first be bounded and referred for competent assessment.

The added prohibitions concerning certain non-consensual intimate representations and child sexual abuse material have their own application date of 2 December 2026 under Article 113. That does not imply the conduct is permitted under other law before that date. The AI Act is one legal layer among several. No compliance calendar should turn a future application date into an assertion of present permission.

High risk is not a synonym for every important application

Article 6 provides different routes to high-risk classification. For certain regulated products, the product connection and the condition of a relevant third-party conformity assessment need to be examined together. The mere presence of an AI feature in a device is insufficient for that conclusion. The safety function and the consequences of failure remain important.

The second route concerns the uses listed in Annex III. Especially relevant to businesses are systems for recruitment or selection, analysing and filtering job applications or evaluating candidates. The annex also covers other specified areas, including certain educational decisions, creditworthiness assessments and essential public services. The actual listed purpose matters more than the software's general marketing category.

Article 6(3) provides a conditional exception for certain Annex III systems. A narrow procedural or preparatory task may be relevant, but a label does not establish an exemption. The conditions, actual influence and documentation under paragraph 4 need assessment. Profiling of natural persons within the relevant Annex III scope requires particular attention. A final human confirmation does not automatically remove high-risk status.

Four fictional cases with different assessment questions

Case one: a product description draft. A retailer generates a proposed description from approved technical characteristics. The system does not evaluate people or execute orders. These facts alone do not establish one of the high-risk uses described above. Role, literacy measures, data handling and the particular publication still need consideration. Invented product characteristics would remain a professional and legal problem.

Case two: information on a website. An application answers visitors' questions directly. Alongside deployer status, the parties must establish who provides the complete system. Information about AI interaction and its timely presentation become important. A hidden paragraph in a general privacy notice cannot simply replace an appropriate disclosure in the immediate interaction.

Case three: sorting applications. A system evaluates documents for inferred suitability and produces a ranking used in selection. Having someone in human resources confirm the result does not automatically make it a simple document repository. Annex III, possible exceptions, data protection, workers' rights and the actual influence on selection demand a more detailed assessment.

Case four: changing an assistant's purpose. An agency adds candidate evaluation to a general writing application under its own brand. The changed purpose and provider role now need fresh consideration. The earlier assessment for writing assistance cannot simply be copied unchanged into the approval record. All four cases are learning examples rather than accounts of particular customers.

Recognise changes of responsibility during modifications

Article 25 addresses particular responsibilities along the value chain. Important situations include placing one's own name on a high-risk system, substantially modifying such a system and changing the intended purpose of a previously non-high-risk system so that it becomes high-risk. The conditions differ and must be checked against the actual modification.

A random edit to an instruction does not automatically satisfy every one of these conditions. Conversely, a new decision-making function is not insignificant simply because it is introduced through configuration instead of a large programming change. A useful change record describes the previous purpose, new purpose, affected people, influence on decisions and required supplier information.

The parties should address access to necessary technical information, known limitations and assistance. A contractual sentence assigning every obligation to the customer does not replace statutory role analysis. Nor does a fully completed agreement make an unlawful use lawful. Contractual preparation supports a sound operational arrangement but cannot substitute for the underlying legal conditions.

Understand transparency as several distinct obligations

Article 50 distinguishes provider obligations from deployer obligations. Systems intended to interact directly with natural persons raise the question of informing those people that they are interacting with AI, unless this is already obvious under the legal test and circumstances. Information should be clear, distinguishable and available by the first interaction or exposure. Applicable accessibility requirements also matter.

Machine-readable marking of certain synthetic outputs by providers under paragraph 2 is a separate issue. A visible note in an article and a technical marking perform different functions. A deployer should understand the information and capabilities available in its system. It should not assume that an independently added visible footnote fulfils every obligation placed on the provider.

For deployers, the Act includes disclosure requirements for deepfakes and a separate rule for AI-generated text published to inform the public on matters of public interest. The text provision contains an exception involving human review or editorial control together with editorial responsibility. That exception does not automatically remove other obligations or responsibility for inaccurate published claims. “Every AI text always needs the same label” is therefore as imprecise as abandoning transparency entirely.

Match literacy measures to actual work

The amended version of Article 4 requires providers and deployers to take measures supporting the development of AI literacy among the relevant people. Knowledge, experience, education, context and affected groups are factors to consider. The provision expressly does not require guaranteeing any individual's specific level of AI literacy.

For an editorial assistant, checking sources, identifying invented statements and handling confidential information may be central learning objectives. Someone overseeing consequential decisions needs different knowledge and authority. A short product-specific introduction may form part of the measures. The provision does not create a blanket requirement for a particular paid certificate, fixed number of hours or specific training vendor.

As an editorial implementation recommendation, a short record is useful: target group, function used, explained limitations, exercises and a responsible contact. This is not a statutory universal form. It helps establish whether the measures suit daily work and whether a changed function requires an update. Attendance alone should not be confused with a system's suitability or the legality of its deployment.

Record application dates obligation by obligation

The current version of Article 113 does not provide one common date for everything. The following selection is an orientation. Specific conditions and transitional rules must be examined alongside it.

Article 111 supplies further transitional rules. These include certain models marketed before 2 August 2025 and certain systems generating synthetic outputs marketed before 2 August 2026. For the latter, 2 December 2026 is relevant to Article 50(2). This is not a general extension of every transparency obligation. Existing high-risk systems also require a specific transitional assessment rather than an assumption that every older system is permanently exempt.

Separate the duties of different high-risk actors

For a relevant high-risk system, Article 16 describes provider duties concerning conformity, quality management, documentation and other procedural steps. That does not establish a universal certification requirement for every company using writing software. The relevant conformity assessment depends on the system and applicable procedure. A procurement team needs the appropriate evidence rather than a generic compliance badge.

Deployer duties under Article 26 include using a system according to instructions and assigning human oversight to people with appropriate competence and authority. Where the deployer controls input data, relevance and representativeness matter. Monitoring operation and responding to risks are also important. These high-risk duties should be planned with their applicable dates rather than described as already applying to every ordinary assistant.

The provision on automatically generated logs is bounded too. It concerns logs under the deployer's control and takes account of purpose and other applicable law. It should not be turned into an indiscriminate instruction to store every confidential prompt from every AI application. A fundamental rights impact assessment under Article 27 concerns specified deployers and uses. It is not a universal form for every small enterprise. Data protection impact assessments remain a separate consideration.

Create a case record that leaves unresolved decisions open

When a third-party model is involved, the information route matters. Article 53 assigns certain documentation and information duties to general-purpose AI model providers. An ordinary business does not acquire responsibility for reporting the original model's training merely by using it. A downstream system provider may nevertheless need information about the model's capabilities and limitations. A prominent upstream name is no substitute for assessing the complete system.

Procurement and development should therefore examine the same configuration. If procurement orders a general tool but development turns it into an assessment of people, the two teams are no longer discussing the same documented purpose. Their records need to be brought together before deployment. Functional tests can establish actual data flows and triggered actions. They cannot by themselves decide the legal role or exemption.

The following fictional data example structures an unfinished assessment. It calculates no risk category. Keeping facts separate from conclusions helps prevent a technically valid record from being mistaken for legal approval. German keys are retained so the two language versions refer to the same record.

{
  "lernfall": true,
  "fassung": "2026-11-09",
  "zweck": "Antwortentwurf aus freigegebenen Produktdaten",
  "direkter_personendialog": false,
  "personenauswahl": false,
  "eigene_marke": "zu klaeren",
  "rolle": "offen",
  "verbotspruefung": "offen",
  "hochrisikopruefung": "offen",
  "transparenzpruefung": "offen",
  "anwendungsfristen": "einzeln zu pruefen",
  "entscheidung": null
}

An actual record needs evidence behind these fields: a functional description, instructions, role reasoning and the configuration examined. Unknown facts should remain visibly unknown. A missing supplier response should not be replaced by the most convenient assumption. Equally, an assessment of a different product version is insufficient without considering the differences.

Checklist for procurement, introduction and changes

• Describe the complete system and intended purpose in a few verifiable sentences.
• Separate the model supply, integration work and business deployment.
• Support the organisation's roles with actual actions and documents.
• Examine possible prohibitions before ordinary risk classification.
• Compare Article 6 and relevant Annex III entries with the specific use.
• Split transparency obligations by actor and output format.
• Record the legal version, application date and transition for each obligation.
• Organise literacy measures, actual oversight and accessible responsibility.
• Assess data protection, copyright, workers' rights and sector requirements separately.
• Treat new purposes, decision-making powers and branding as reasons to reassess.

A defensible introduction consequently has a reasoned assessment and clear limits. It rests on the system actually deployed and the current law. A general badge or automatically generated green indicator cannot replace that work.