Skip to main content
Praxikon

Explorer

Why this object hangs off that object

Every object in this graph has its own address and can be cited on its own. This page shows which objects exist and, once you open one, why it hangs off another: from which source with its locator, through which condition or exception, to which consequence.

Since the last release an obligation states separately who carries the duty and who is merely affected. Filter by duty holder and you get the duties resting on a role; filter by actor and you get everything that is about that role. That difference is visible on purpose.

This is the knowledge layer under the four levels of the assessment. See the four levels.

Filters

Only dimensions the data carries. A dimension without values is absent rather than empty.

Eleven types, including evidence, control and standard.

Is about this role. Walks the role hierarchy upward.

The duty rests on this role, not merely: it is about it.

The article route this object hangs off.

Free slugs, not a taxonomy with objects of its own.

The phase of the object, not its quality.

Whether this object carries a source line of its own.

Searches label, summary, topics, conditions and statement texts. The ordering is the same heuristic as the search API; build on the identifiers, not on the ranking.

Time

Two axes. Legal time is what applied; knowledge time is what we had published by then. Leaving them empty means the default of this release.

Clear all

Objects

37 objects in this selection.

  1. ActionUpcomingv1.0.02 relations

    Justify the Article 6(3) exception against each individual condition

    praxikon:eu:ai-act:action:annex-iii-article-6-3-justification

    Name which of the four Article 6(3) conditions you invoke, with facts, and separately justify why the system poses no significant risk of harm to health, safety or fundamental rights and does not materially influence the outcome of decision making.

    Hangs off: Annex III: high-risk AI

    Editorially reviewed | high-risk

  2. Actionv1.0.05 relations

    Classify the use case and document the outcome

    praxikon:eu:ai-act:action:annex-iii-classify

    Assess Article 5, Article 6 and Annex III in that order and document purpose, context and any Article 6(3) exception.

    Hangs off: Annex III: high-risk AI

    Editorially reviewed | high-risk

  3. ActionUpcomingv1.0.02 relations

    Run the profiling test before invoking the Article 6(3) exception

    praxikon:eu:ai-act:action:annex-iii-profiling-test

    Establish as the first question whether the system performs profiling of natural persons; if yes, the Article 6(3) route falls away and the system remains high-risk, regardless of the four conditions.

    Hangs off: Annex III: high-risk AI

    Editorially reviewed | high-risk

  4. ActionUpcomingv1.0.03 relations

    Assign human oversight and give those people a mandate

    praxikon:eu:ai-act:action:appoint-and-empower-human-oversight

    Name, per high-risk system, who exercises oversight, and ensure that person has the competence, training, authority and support to actually set the output aside.

    Hangs off: Article 26: obligations of deployers of high-risk AI systems

    Editorially reviewed | high-risk-requirements

  5. Actionv1.0.04 relations

    Set up data governance per dataset

    praxikon:eu:ai-act:action:article-10-data-governance-act

    Assess origin, representativeness, errors and completeness and examine possible bias with appropriate mitigation.

    Hangs off: Article 10: data and data governance

    Editorially reviewed | high-risk-requirements

  6. Actionv1.0.03 relations

    Build the technical file per Annex IV

    praxikon:eu:ai-act:action:article-11-technical-documentation-act

    Document system description, development process, data, oversight measures, performance and risk management before market placement.

    Hangs off: Article 11: technical documentation

    Editorially reviewed | high-risk-requirements

  7. Actionv1.0.04 relations

    Design logging into the system

    praxikon:eu:ai-act:action:article-12-logging-act

    Ensure the system automatically records events relevant to risk identification and post-market monitoring.

    Hangs off: Article 12: logging and traceability

    Editorially reviewed | high-risk-requirements

  8. Actionv1.0.04 relations

    Provide complete instructions for use

    praxikon:eu:ai-act:action:article-13-instructions-act

    Describe capabilities, limitations, accuracy, oversight measures and expected lifetime in comprehensible form.

    Hangs off: Article 13: transparency towards deployers

    Editorially reviewed | high-risk-requirements

  9. Actionv1.0.04 relations

    Design and assign effective human oversight

    praxikon:eu:ai-act:action:article-14-human-oversight-act

    Determine oversight measures per system, appoint competent persons and give them the mandate to intervene or stop.

    Hangs off: Article 14: human oversight

    Editorially reviewed | high-risk-requirements

  10. Actionv1.0.03 relations

    Set and test performance and security levels

    praxikon:eu:ai-act:action:article-15-accuracy-robustness-act

    Determine appropriate accuracy, test robustness against errors and misuse, and take AI-specific security measures.

    Hangs off: Article 15: accuracy, robustness and cybersecurity

    Editorially reviewed | high-risk-requirements

  11. Actionv1.0.03 relations

    Set up an AI quality management system

    praxikon:eu:ai-act:action:article-17-quality-management-act

    Describe strategies, procedures and responsibilities for compliance, from design and data to post-market monitoring.

    Hangs off: Article 17: quality management system

    Editorially reviewed | high-risk-requirements

  12. Actionv1.0.05 relations

    Take role- and context-specific AI literacy measures

    praxikon:eu:ai-act:action:article-4-measures

    Determine for each role, system and context which combination of instruction, guidance, practice or training is appropriate.

    Hangs off: Article 4: AI literacy

    Editorially reviewed | ai-literacy

  13. ActionApplicablev1.0.03 relations

    Determine per role which knowledge is needed to use the specific system responsibly

    praxikon:eu:ai-act:action:article-4-role-needs-matrix

    Map roles against the AI systems they use and record per combination what a person must be able to judge: what the system does, where it fails, who it is applied to, and when to intervene or escalate.

    Hangs off: Article 4: AI literacy

    Editorially reviewed | ai-literacy

  14. ActionApplicablev1.0.03 relations

    Deliver instruction at the moment a new tool or a new employee arrives

    praxikon:eu:ai-act:action:article-4-tool-and-onboarding-instruction

    Attach the literacy measure to two fixed moments in existing processes: the rollout of a new AI tool and the onboarding of anyone gaining access to an existing tool.

    Hangs off: Article 4: AI literacy

    Editorially reviewed | ai-literacy

  15. Actionv1.0.04 relations

    Screen every use case against Article 5 first

    praxikon:eu:ai-act:action:article-5-screen

    Before procurement, build or deployment, check whether the use case falls under a prohibited practice and stop or redesign early rather than after the fact.

    Hangs off: Article 5: prohibited practices

    Editorially reviewed | prohibited-practices

  16. Actionv1.0.05 relations

    Implement the applicable disclosure, marking or label

    praxikon:eu:ai-act:action:article-50-disclosure

    First determine which paragraph of Article 50 applies, then implement the specific transparency measure.

    Hangs off: Article 50: transparency

    Editorially reviewed | transparency

  17. ActionApplicablev1.0.02 relations

    Record per publication channel when AI text carries a disclosure and who holds editorial responsibility

    praxikon:eu:ai-act:action:article-50-editorial-labelling-policy

    Determine per channel whether the text is published to inform the public on matters of public interest, who performs the human review, who holds editorial responsibility, and which standard wording you use when the disclosure is required.

    Hangs off: Article 50: transparency

    Editorially reviewed | transparency

  18. ActionApplicablev1.0.03 relations

    Test every system in your AI register against the five Article 50 scenarios

    praxikon:eu:ai-act:action:article-50-scenario-triage

    For each AI system, walk through the distinct Article 50 scenarios (direct interaction, synthetic output, emotion recognition or biometric categorisation, deep fake, published text on matters of public interest) and record per paragraph whether it applies, does not apply or falls under an exception, with the reason.

    Hangs off: Article 50: transparency

    Editorially reviewed | transparency

  19. Actionv1.0.03 relations

    Perform model evaluations and risk mitigation

    praxikon:eu:ai-act:action:article-55-gpai-systemic-risk-act

    Evaluate the model including adversarial testing, assess and mitigate systemic risks, report serious incidents and secure the model.

    Hangs off: Article 55: GPAI models with systemic risk

    Editorially reviewed | gpai-systemic-risk

  20. ActionApplicablev1.0.04 relations

    Apply to a sandbox and agree the sandbox plan

    praxikon:eu:ai-act:action:article-57-sandbox-application-and-plan

    Apply to the competent authority, agree a specific sandbox plan, and record which uncertainty about the Regulation you want resolved inside the sandbox.

    Hangs off: Article 57: AI regulatory sandboxes

    Editorially reviewed | innovation

  21. ActionApplicablev1.0.05 relations

    Submit the testing plan, obtain approval and register the test

    praxikon:eu:ai-act:action:article-60-testing-plan-and-authorisation

    Draw up a real-world testing plan, submit it to the market surveillance authority, obtain approval, register the test with a Union-wide unique single identification number, and record the division of roles with your deployer.

    Hangs off: Article 60: testing in real world conditions outside a sandbox

    Editorially reviewed | innovation

  22. Actionv1.0.04 relations

    Draw up a post-market monitoring plan

    praxikon:eu:ai-act:action:article-72-post-market-monitoring-act

    Systematically collect and analyse real-world data on the system’s performance and compliance throughout its lifetime.

    Hangs off: Article 72: post-market monitoring

    Editorially reviewed | post-market

  23. Actionv1.0.04 relations

    Set up an incident process with reporting routes

    praxikon:eu:ai-act:action:article-73-incident-reporting-act

    Define what a serious incident is, assign the reporting route to the supervisor and rehearse the process.

    Hangs off: Article 73: serious incident reporting

    Editorially reviewed | post-market

  24. Actionv1.0.03 relations

    Set up an iterative risk management process

    praxikon:eu:ai-act:action:article-9-risk-management-act

    Identify and analyse known and reasonably foreseeable risks, evaluate them and take measures, repeating the cycle on every change.

    Hangs off: Article 9: risk management system

    Editorially reviewed | high-risk-requirements

  25. ActionUpcomingv1.0.03 relations

    Assign an internal owner and a date to each point of Article 16

    praxikon:eu:ai-act:action:assign-article-16-provider-duties

    Translate the twelve points (a) to (l) into twelve named owners with a start date, so that no point falls between product management, quality and legal.

    Hangs off: Article 16: the twelve duties of a provider of a high-risk AI system

    Editorially reviewed | high-risk-requirements

  26. Actionv1.0.04 relations

    Complete the conformity route before market placement

    praxikon:eu:ai-act:action:conformity-ce-registration-act

    Select the correct assessment procedure, draw up the EU declaration of conformity, affix the CE marking and register in the EU database.

    Hangs off: Articles 43-49: conformity assessment, CE and registration

    Editorially reviewed | conformity

  27. ActionUpcomingv1.0.04 relations

    Map the affected groups and their specific risks of harm

    praxikon:eu:ai-act:action:fria-affected-groups-analysis

    Name the categories of natural persons and groups likely to be affected by the use in this specific context, and work out the specific risks of harm per category, using the information the provider supplied under Article 13.

    Hangs off: Article 27: FRIA

    Editorially reviewed | fundamental-rights

  28. Actionv1.0.06 relations

    Perform a FRIA before deployment

    praxikon:eu:ai-act:action:fria-assess

    Assess process, duration, affected persons, risks, oversight, mitigation and complaint mechanisms and notify results where required.

    Hangs off: Article 27: FRIA

    Editorially reviewed | fundamental-rights, high-risk

  29. ActionUpcomingv1.0.04 relations

    Set up the complaint mechanism and internal governance before the system runs

    praxikon:eu:ai-act:action:fria-complaint-mechanism-setup

    Describe the measures taken if a risk materialises, who decides internally, through which route an affected person can complain, within which deadline you respond, and who is authorised to stop the use.

    Hangs off: Article 27: FRIA

    Editorially reviewed | fundamental-rights

  30. Actionv1.0.04 relations

    Maintain GPAI documentation and transparency information

    praxikon:eu:ai-act:action:gpai-document

    Maintain technical documentation, information for downstream providers, a copyright policy and a public summary of training content.

    Hangs off: Article 53: GPAI model providers

    Editorially reviewed | gpai

  31. ActionApplicablev1.0.02 relations

    Assemble the downstream information package under Annex XII

    praxikon:eu:ai-act:action:gpai-downstream-information-package

    Build one package for providers integrating your model, covering the intended tasks and integration options, acceptable use policies, release date and distribution methods, interaction with external hardware or software, software versions, architecture and parameter count, modality and format of inputs and outputs including maximum size, licence, required technical means, and information on the training, testing and validation data used.

    Hangs off: Article 53: GPAI model providers

    Editorially reviewed | gpai

  32. ActionApplicablev1.0.02 relations

    Implement rights-reservation detection inside your copyright policy

    praxikon:eu:ai-act:action:gpai-rights-reservation-detection

    Record which techniques you use to identify a reservation of rights within the meaning of Article 4(3) of Directive (EU) 2019/790 when collecting training data, how often you recheck, and how you then comply with that reservation.

    Hangs off: Article 53: GPAI model providers

    Editorially reviewed | gpai

  33. ActionApplicablev1.0.03 relations

    Set up how you handle a request for an explanation

    praxikon:eu:ai-act:action:handle-explanation-requests

    Ensure your complaints or objections desk recognises a request for an explanation of an AI-supported decision, that it can be traced per decision which system in which version contributed to it, and that someone is designated to give the explanation.

    Hangs off: Article 86: right to an explanation of a decision

    Editorially reviewed | fundamental-rights

  34. ActionApplicablev1.0.03 relations

    Make sure you can answer a complaint with documents

    praxikon:eu:ai-act:action:prepare-for-a-complaint

    Record per AI system which assessment was carried out, by whom, on what date and against which system version, and agree who receives a question from the authority and within what period.

    Hangs off: Article 85: right to lodge a complaint with the market surveillance authority

    Editorially reviewed | fundamental-rights

  35. ActionUpcomingv1.0.03 relations

    Perform the Article 24(1) check before making available

    praxikon:eu:ai-act:action:run-distributor-market-check

    Verify the CE marking, the presence of the EU declaration of conformity and the instructions for use, and whether the provider and importer complied with Article 16, points (b) and (c), and Article 23(3).

    Hangs off: Article 24: obligations of distributors

    Editorially reviewed | value-chain

  36. ActionUpcomingv1.0.03 relations

    Run the four verifications of Article 23(1) before importing

    praxikon:eu:ai-act:action:run-importer-verification-checklist

    Check and record: the conformity assessment has been carried out, the technical documentation exists, the CE marking plus declaration and instructions for use are present, and an authorised representative has been appointed.

    Hangs off: Article 23: obligations of importers

    Editorially reviewed | value-chain

  37. Actionv1.0.04 relations

    Assess the value-chain role per system and change

    praxikon:eu:ai-act:action:value-chain-representative-act

    On white-labelling, substantial modification or purpose change, assess whether your organisation becomes the provider, and arrange the representative for non-EU supply.

    Hangs off: Articles 22-25: value chain and authorised representative

    Editorially reviewed | value-chain

What this explorer does not do

  • There is no article object. The article sits as a locator on the citations of an obligation, as free text. Filtering on the obligation is the same question, and the data does carry that.
  • No object carries an Annex III domain or use case. A selection of the form "systems for this purpose" cannot be expressed here.
  • A locator hangs on a statement in the data, not on a relation. The source next to a path is the source anchor of the object carrying the relation, not proof of that one connection.
  • The split between duty holder and affected actor exists on obligations only. On every other type the actor list is still one undifferentiated list.
  • The graph stores no inverse relations. The incoming direction is computed here over the same release and adds nothing to the data.
  • Topics are free slugs, not a taxonomy with objects, labels or a hierarchy of their own.

The same selection as data

The explorer and the API read the same object against the same two time axes. What you see here can be fetched with the same parameters.