Classification and readiness assessment
We determine the role an organisation holds under Regulation (EU) 2024/1689, whether each AI system is high-risk under Art. 6 with Annex I or Annex III, whether a model is a general-purpose AI model, and which duties under Art. 50 apply to each function, under PR-CLS v1.0. The client receives a classification memo, an obligation register with application dates from the regulation data In force, a gap list and a readiness roadmap. Regulation (EU) 2026/1744 moved application dates and left the obligations unchanged; the register carries each date with its entry.
Deliverables
The set answers the first question a procurement questionnaire, a due-diligence list or an internal audit function asks: which role, which risk tier, which articles, and from which date. Each type is specified with a synthetic sample on the deliverables page: the classification memo follows the assessment memo specification, the obligation register and the roadmap follow the register or checklist specification, and the gap list follows the findings register specification.
| Deliverable | Type | Format | Designed to satisfy |
|---|---|---|---|
| Classification memo: role (provider, deployer, importer, GPAI), risk tier, Article 6(3) rationale where applicable, presented as a reasoned technical assessment for discussion with counsel | Assessment memo | PDF with Markdown source | |
| Obligation register with applicability dates from the regulation data | Register or checklist | XLSX; CSV; Markdown | |
| Gap list against the applicable articles | Findings register | XLSX; CSV; PDF summary | |
| Prioritised readiness roadmap ordered by deadline and effort | Register or checklist | XLSX; CSV; Markdown |
Who this is for
- Startups
- Enterprises
- Non-EU providers
A small company with a new product meets the Act through an enterprise buyer's questionnaire or an investor's due-diligence list, and the first question is classification: which role, which risk tier, whether Art. 50 applies, and whether an Art. 6(3) condition removes the Annex III label. A large organisation runs many AI use cases, some built, some bought and some embedded in vendor software, and each one has to be inventoried and classified by role, Annex III match, Art. 6(3) filter, Art. 50 function and general-purpose AI use before one register can serve internal audit, risk and the CISO. A company established outside the Union is in scope under Art. 2(1) when its system is placed on the Union market or its output is used in the Union; work already done for NIST AI RMF 1.0Published or ISO/IEC 42001:2023Published is mapped to the applicable articles as evidence rather than assumed to carry over.
Two entries set the urgency: the Omnibus entry into force, from which the amended text applies, and the Annex III application date, from which the high-risk package applies to systems classified under Art. 6(2).
Scope
The engagement covers the three determinations and three applicability checks of PR-CLS v1.0, for one system or for a portfolio; the limits of every determination are stated on what we cannot do. Role: which Art. 3 definition fits the organisation for each system (provider, deployer, importer, distributor, authorised representative), whether an Art. 25(1) trigger turns a deployer or distributor into a provider, and whether Art. 2(1) brings a third-country organisation into scope. Risk tier: whether the system is high-risk under Art. 6(1) with Annex I or under Art. 6(2) with Annex III, whether one of the four Art. 6(3) conditions removes the Annex III classification, and whether the Art. 6(4) documentation and the Art. 49(2) registration data set that follow a not-high-risk conclusion are in place. The criteria for the Art. 6 routes come from Commission guidelines on high-risk classificationDraft, a guideline whose stage the badge shows, so the memo names the stage on every citation and a final version can change a recorded result. The application date of the registration duty that follows an Art. 6(3) conclusion is an unsettled point; the register records both readings, and the PR-CLS page shows them.
General-purpose AI status is determined against Commission guidelines on GPAI scopePublished: whether the model meets Art. 3(63), whether the cumulative training compute meets the Art. 51(2) presumption, and whether a fine-tuning or continued-training modification makes the modifier the provider of a new model. Where a model is in scope, the GPAI evaluation support service continues from the determination records. Applicability of Art. 50 is checked per function against Commission guidelines on Article 50 transparency obligationsPublished: which paragraphs apply and whether each claimed exemption matches the observed behaviour of the function. The Art. 50 duties already apply In force, and a system that generates synthetic content and was placed on the market before that date has a grace period for the Art. 50(2) marking duty under Art. 111(4) Deferred.
The applicability check decides which Art. 50 paragraphs apply to a function. It does not decide whether a marking technique is adequate under Art. 50(2); that point is unsettled, and the marking, survivability and detectability tests run under the Article 50 transparency and marking/watermark testing service.
Where the role determination names a deployer within Art. 27(1), that is a body governed by public law, a private entity providing public services, or a deployer of an Annex III point 5(b) or (c) system, the obligation register carries the fundamental rights impact assessment under Art. 27 with its applicability entry. The timing of that duty is an unsettled point, and the register records the working reading and the alternative.
The engagement does not test against the high-risk requirements in Art. 9 to Art. 17, the content of Annex XI or Annex XII documentation, or the evaluation of a model with systemic risk; each has its own protocol, and the obligation register names the hand-off per testable element. The classification memo is a reasoned technical assessment for discussion with counsel. A market surveillance authority, the AI Office or a court can reach a different result. No harmonised standard is cited in the Official Journal as of the anchor date, so no presumption of conformity is available for any determination in this service; the standards page tracks the count.
What we test
The table lists the testable elements of the obligation records this service covers, with the protocol that tests each element and the artifacts it produces for the record.
| Obligation | Testable element | Protocol | Artifacts |
|---|---|---|---|
| Art. 50 | Each function of the system is assigned to the Art. 50 paragraphs that apply to it (interaction, generation, emotion recognition or biometric categorisation, deep fake, public-interest text), and each claimed exemption under Art. 50(1), (2), (3) or (4) is checked against the observed behaviour of the function. | PR-CLS v1.0 |
|
| A natural person who starts an interaction sees or hears that they interact with an AI system at the latest at the first interaction, in a clear and distinguishable manner, without opening a separate page or document (Art. 50(1) with Art. 50(5)). | PR-CLS v1.0 | ||
| Every synthetic output of each modality (audio, image, video, text) carries a machine-readable mark on generation, verified on a sample of outputs per modality and per output path (Art. 50(2)). | PR-CLS v1.0 | ||
| Each marked output is detectable as artificially generated or manipulated by a detection solution that a party other than the provider can run, verified by running the detection on marked samples (Art. 50(2), detectability). | PR-CLS v1.0 | ||
| The mark survives a defined set of ordinary transformations for the modality (re-encoding, resizing, cropping, screenshot, format conversion, transcoding, copy and paste for text), verified per transformation with the survival result recorded (Art. 50(2), robustness). | PR-CLS v1.0 | ||
| The mark is readable by tools other than the provider's own, such as a provenance manifest validator or a shared detection interface, verified against at least one independent reader (Art. 50(2), interoperability). | PR-CLS v1.0 | ||
| The detection solution returns the correct result on marked outputs and on non-generated control samples, with the detection rate and the false-positive rate recorded against the target the provider justified (Art. 50(2), reliability and effectiveness). | PR-CLS v1.0 | ||
| A natural person exposed to an emotion recognition or biometric categorisation system receives the notice of its operation at the latest at the first exposure, verified on the deployment interface or premises (Art. 50(3) with Art. 50(5)). | PR-CLS v1.0 | ||
| Deep fake content shown to a natural person carries a disclosure that is perceivable at the latest at the first exposure, embedded so that ordinary display does not hide it, verified on each distribution surface (Art. 50(4) with Art. 50(5)). | PR-CLS v1.0 | ||
| Published AI-generated text on matters of public interest carries a disclosure at the point of publication, unless the editorial-control exemption is recorded for that publication, verified on the published surface (Art. 50(4) with Art. 50(5)). | PR-CLS v1.0 | ||
| Each disclosure under Art. 50(1), (3) and (4) conforms to the applicable accessibility requirements, verified with the accessibility checks the applicable requirement prescribes (Art. 50(5)). | PR-CLS v1.0 | ||
| Art. 54 | Mandate verification: the written mandate exists, appoints a representative established in the Union, carries a date earlier than the placing of the model on the Union market, lists each task in Art. 54(3)(a) to (d) and the power in Art. 54(4), and a copy in one of the official languages of the institutions of the Union is produced on request (Art. 54(1), (3) and (4)) | PR-CLS v1.0 |
|
| Retrieval exercise: on a simulated reasoned request, the representative produces from its own custody the current Annex XI technical documentation copy, the provider's contact details and the information that shows the Chapter V obligations are fulfilled (Art. 54(3)(b) and (c)) | PR-CLS v1.0 |
Regulation (EU) 2024/1689 sets one numeric figure in the scope of this service, the Art. 51(2) training-compute presumption, and every other criterion is qualitative. Thresholds follow a six-level hierarchy: a harmonised standard cited in the Official Journal, of which none exists as of the anchor date; a JTC 21 draft standard named with its stage, of which none covers classification; an ISO/IEC standard or technical report; a Commission guideline or code of practice; NIST AI RMF or a sector framework; and the provider's justified state of the art. The criteria in use here sit at the Commission-guideline level and at the provider's justification level. Where no published threshold exists, such as the reading of "obvious" under Art. 50(1) or an acceptable retrieval time for the Art. 54 exercise, the determination-rationale step of PR-CLS v1.0 records the provider's justification and its source. No figure is attributed to the Act other than the Art. 51(2) figure.
Protocols used
One protocol runs the service; its version and derivation are on its page.
- PR-CLS v1.0Classification and role determination protocolv1.0
PR-CLS v1.0 covers role, risk tier and general-purpose AI status, and the applicability of Art. 50, Art. 53(2) and Art. 54 with the Art. 55 classification gate. It produces a role determination record, a high-risk classification record, an Art. 6(3) assessment record, an Art. 50 applicability and exemption determination record, an obligation register with a regulation entry id per date, a determination rationale record and a classification report. It does not give a legal opinion on classification, observes exemption behaviour only on the functions and interface named in the access record, and checks the training-compute calculation without re-running training or verifying hardware utilisation.
Engagement shape
The service is fixed-scope, scoped per request, and is the entry service: the obligation register it produces is the scoping input for every other service on this site. The client provides the intended-purpose materials, a function inventory on the protocol template, interface access for behaviour observation, and, where relevant, model cards, licence texts, training records, an existing Art. 6(3) assessment and the EU database registration draft. The work follows the order of the protocol: preparation, in which the inventory and the materials are recorded and the access is verified; execution, in which each determination and each applicability check is run and its record written; analysis, in which the records are resolved into one classification per system and the obligation register is assembled with its dates from the regulation data; and reporting, in which the memo, the register, the gap list and the roadmap are issued with the counsel note on each determination.
What we cannot do
- We do not perform conformity assessments where a notified body is required.
- We do not issue CE marking or the EU Declaration of Conformity.
- We are not a notified body.
- We do not give legal opinions on classification or liability.
- We test against requirements, prepare evidence, and structure documentation; compliance decisions remain with the provider or deployer, their notified body, and their counsel.
For this service the classification memo is a reasoned technical assessment for discussion with counsel; it is neither a legal opinion on classification nor a conformity assessment under Art. 43. The roadmap orders the applicable obligations by date and effort; the decision to place a system on the market rests with the provider.
What the client must have ready
The documentation and process elements below are read and cross-checked during the engagement; the memo records which are present and which are missing.
Art. 50Transparency obligations for providers and deployers of certain AI systems
- Record of the assessment that an interaction is obvious to a reasonably well-informed, observant and circumspect person, for each function where the provider relies on the Art. 50(1) exemption. documentation
- Marking architecture description per output modality: the metadata, watermark and provenance layers in use, the point in the pipeline where each is applied, and the detection solution that reads each layer (Art. 50(2)). documentation
- Justification of the technical solution against the four Art. 50(2) criteria (effective, interoperable, robust, reliable), stating the technical feasibility limits, the specificities of each content type, the cost of implementation and the state of the art relied on. documentation
- Exemption determination record for each generating function claimed to perform an assistive function for standard editing or not to substantially alter the input data or its semantics (Art. 50(2)). documentation
- Detection solution description available to third parties: how a party other than the provider detects the mark, on what terms, and for which modalities (Art. 50(2), detectable). documentation
- Data protection record for the personal data processed by an emotion recognition or biometric categorisation system, and the record of the Art. 3(40) ancillary-and-strictly-necessary determination where the system is treated as outside the definition of a biometric categorisation system. documentation
- Editorial responsibility record naming the natural or legal person who holds editorial responsibility, and a description of the human review or editorial control measures, for each publication where the Art. 50(4) exemption is relied on. documentation
- Artistic-work determination record for each deep fake use where the limited disclosure under Art. 50(4) is relied on. documentation
- Law-enforcement authorisation record for any function that relies on the criminal-offence exception in Art. 50(1), (2), (3) or (4). documentation
- Obligation register entry that lists the Chapter III requirements and the other Union or national transparency duties that apply alongside Art. 50 (Art. 50(6)). documentation
- Record of adherence to the Code of Practice on Transparency of AI-Generated Content, or of the alternative means used to show conformity with Art. 50(2) and (4) (Art. 50(7)). documentation
- Grace-period record for a system placed on the market before the Art. 50 application date: the steps taken to meet Art. 50(2) and the date each step completed (Art. 111(4)). documentation
- Re-run the marking presence, survivability and detectability tests after each change to the model, the output encoder, the distribution surface or the marking library (Art. 50(2)). process
- Review the marking technique against the generally acknowledged state of the art and relevant technical standards at a set interval, and record the review outcome (Art. 50(2)). process
- Keep the detection solution available and operating for the outputs of every version of the system that remains in use (Art. 50(2), detectable). process
- Process the personal data of persons exposed to an emotion recognition or biometric categorisation system under the applicable data protection law throughout the use of the system (Art. 50(3)). process
- Operate the human review or editorial control workflow for public-interest text, and keep the named editorial responsibility current, wherever the Art. 50(4) exemption is relied on. process
- Operate the labelling workflow that attaches the deep fake or text disclosure before publication on each distribution surface (Art. 50(4)). process
- Monitor the Commission's adequacy assessment of the Code of Practice and any implementing act with common rules, and update the marking and labelling measures when either changes (Art. 50(7)). process
- Complete the steps to bring a system placed on the market before the Art. 50 application date into conformity with Art. 50(2) within the Art. 111(4) grace period. process
Art. 54Authorised representatives of providers of general-purpose AI models
- Mandate copy held by the representative in one of the official languages of the institutions of the Union, ready for the AI Office (Art. 54(3)) documentation
- Copy of the Annex XI technical documentation held by the representative, at the version the provider maintains (Art. 54(3)(b)) documentation
- Record of the provider's contact details held by the representative (Art. 54(3)(b)) documentation
- Applicability record: the provider's place of establishment, the placing of the model on the Union market, and, where the exception is claimed, evidence for each Art. 54(6) condition, namely the licence terms, the public availability of the parameters, the weights, the model architecture information and the model usage information, and the absence of a systemic-risk classification under Art. 51 documentation
- The provider enables the representative to perform the mandate tasks: access to the Annex XI documentation, a channel for documentation updates, and a contact path to the provider (Art. 54(2)) process
- The representative verifies that the Annex XI documentation has been drawn up and that the Art. 53 and, where applicable, Art. 55 obligations have been fulfilled, before placing on the market and again on each documentation change (Art. 54(3)(a)) process
- The representative retains the Annex XI copy and the provider's contact details for the period in Art. 54(3)(b), with the copy updated when the provider updates the documentation process
- The representative handles reasoned requests from the AI Office and competent authorities: it provides information and documentation and it cooperates in any action on the model, including where the model is integrated into AI systems in the Union (Art. 54(3)(c) and (d)) process
- The representative is reachable by the AI Office and competent authorities in addition to or instead of the provider on all issues that relate to the provider's obligations (Art. 54(4)) process
- The representative monitors for reason to consider that the provider acts contrary to its obligations, terminates the mandate where that is the case, and immediately informs the AI Office with the reasons (Art. 54(5)) process
Inputs take the formats listed on the PR-CLS page: materials as PDF exports or a URL list, the function inventory as a table on the protocol template, model and licence material as text files, training records as a spreadsheet or log export per run, and the registration entry as an export or screenshot of the Annex VIII Section B fields.
Questions
How are systems classified as high-risk under the EU AI Act?
Art. 6 of Regulation (EU) 2024/1689 sets two routes. Under Art. 6(1), a system is high-risk when it is a product, or a safety component of a product, listed in Annex I that needs third-party conformity assessment. Under Art. 6(2), a system is high-risk when its intended purpose matches an Annex III use case, unless one of the four Art. 6(3) conditions applies and the system performs no profiling of natural persons. PR-CLS steps 12 to 16 record each route per function.
What changed for high-risk AI systems?
Regulation (EU) 2026/1744 moved the application dates of the Chapter III high-risk requirements and left their content unchanged. Amended Art. 113(c) sets the Annex III date for systems classified under Art. 6(2), and a separate date for Annex I systems. Art. 9 to Art. 17 and Art. 26 and Art. 27 are unchanged in what they require; the Omnibus moved the Art. 10(5) legal basis for special-category data into a new Art. 4a and amended Art. 27(4) and (5) on the cross-reference to a data protection impact assessment. The obligation register in this service carries each date from the regulation data with its entry id, so the roadmap is re-ordered when an entry changes.
What is the extraterritorial scope of the EU AI Act?
Art. 2(1) of Regulation (EU) 2024/1689 applies the Act to providers that place an AI system on the Union market or put it into service in the Union, irrespective of where they are established. It also applies to providers and deployers in a third country where the output of the system is used in the Union. Art. 22 requires a third-country provider of a high-risk system to appoint an authorised representative in the Union. PR-CLS steps 8 to 11 record the territorial-scope test per system.
What does EU AI Act conformity readiness cover?
Readiness in this service means the classification and the obligation register that precede any conformity assessment: the role, the risk tier, the general-purpose AI status and the Art. 50 function of each system, the articles that apply, and the application date of each from the regulation data. The gap list records which elements are present or missing, and the roadmap orders the missing ones by date and effort. Conformity assessment under Art. 43 is a separate step that stays with the provider and, where required, a notified body.
Every inquiry receives a reply within 24 hours. Scope and availability are discussed per request.