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.
Active filters
Objects
66 objects in this selection.
- 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
- 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
- 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
- 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
- ActionApplicablev1.0.04 relations
Appoint an authorised representative and record the mandate
praxikon:eu:ai-act:action:appoint-gpai-authorised-representative
Determine whether you are the provider of the model, appoint an authorised representative established in the Union by written mandate before placing the model on the market, and write out in that mandate the four tasks in paragraph 3, the access to the Annex XI documentation and the point of contact under paragraph 4.
Hangs off: Article 54: authorised representative of a provider of a GPAI model
Editorially reviewed | gpai, value-chain
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- ActionApplicablev1.0.04 relations
Inform the test subject and obtain consent to participate
praxikon:eu:ai-act:action:article-61-inform-and-obtain-consent
Give every test subject concise, clear, relevant and understandable information beforehand on the five points of Article 61(1), then obtain freely-given informed consent, date and document that consent, and give a copy to the subject or the legal representative.
Hangs off: Article 61: informed consent of test subjects for testing in real world conditions
Editorially reviewed | fundamental-rights, innovation
- ActionEditorialv1.0.04 relations
Make use of the SME facilities in Article 62
praxikon:eu:ai-act:action:article-62-claim-sme-facilities
Apply for priority access to the AI regulatory sandbox, use the national communication channel for questions about implementation, sign up for the standardisation process, and on a conformity assessment under Article 43 ask how the fee reduction has been applied.
Hangs off: Article 62: measures for providers and deployers that are SMEs or start-ups
Editorially reviewed | governance, innovation
- ActionEditorialv1.0.03 relations
Determine and bound the simplification of your quality management system
praxikon:eu:ai-act:action:article-63-scope-simplified-quality-management
Test whether you are a microenterprise with no partner or linked enterprises, build the Article 17 system, mark which elements you would want to simplify once the Commission guidelines exist, and keep the nine articles of Article 63(2) expressly outside that simplification.
Hangs off: Article 63: derogations for SMEs in the quality management system
Editorially reviewed | high-risk-requirements, innovation
- 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
- 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
- ActionEditorialv1.0.03 relations
Record the state of the art and the intended purpose per system
praxikon:eu:ai-act:action:article-8-state-of-the-art-baseline
Establish, per high-risk system, what currently counts as the generally acknowledged state of the art and against which intended purpose the requirements of Section 2 have been met, with a fixed re-assessment moment and with the location in the risk management file of Article 9.
Hangs off: Article 8: compliance with the requirements for high-risk AI systems
Editorially reviewed | conformity, high-risk-requirements
- 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
- ActionEditorialv1.0.04 relations
Scope a voluntary code of conduct and separate it from your duties
praxikon:eu:ai-act:action:article-95-scope-a-voluntary-code
Choose the paragraph 1 or the paragraph 2 route, name which requirements you apply voluntarily and which you do not, give the code clear objectives and key performance indicators, and keep the voluntary commitments administratively separate from the obligations that continue to apply in full.
Hangs off: Article 95: codes of conduct for voluntary application of specific requirements
Editorially reviewed | governance, innovation
- ActionEditorialv1.0.08 relations
Assign to each obligation the penalty ceiling that belongs to it
praxikon:eu:ai-act:action:article-99-101-map-penalty-tiers
Walk through your obligations register and mark per line which ceiling applies: Article 99(3) for Article 5, Article 99(4) for the role duties enumerated there, Article 25(2) and (4) and Article 50, Article 99(5) for answering information requests, and otherwise the national penalty regime under Article 99(1). Add the Article 101 regime wherever you provide a general-purpose AI model yourself, and the Article 75c regime wherever the AI Office is competent.
Hangs off: Article 99, 100 and 101: the penalty structure per obligation
Editorially reviewed | enforcement, governance
- ActionEditorialv1.0.03 relations
Determine and record whether your AI component is a safety component
praxikon:eu:ai-act:action:assess-safety-component-role
Describe, per AI component inside a product under Annex I, Section A, which function it performs, whether that is a safety function, what happens on failure or malfunctioning, and whether the mandatory third-party conformity assessment rests on health and safety risks or only on other risks. A recommended practice, not a legal duty.
Hangs off: Article 6(1a) to (1c): the tightened classification route
Editorially reviewed | conformity, high-risk
- ActionUpcomingv1.0.04 relations
Assess for every design change whether it is significant
praxikon:eu:ai-act:action:assess-significant-design-change
Fix a moment in your change and release process at which someone assesses and records whether an intended change to a legacy high-risk system is a significant change in its design, before the change goes into production.
Hangs off: Article 111(2): legacy high-risk systems and the 2 August 2030 date
Editorially reviewed | high-risk, timeline
- 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
- 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
- ActionEditorialv1.0.04 relations
Take and record the decision whether you adhere to a code of practice
praxikon:eu:ai-act:action:decide-and-record-gpai-code-adherence
Determine per general-purpose AI model whether you adhere to a code of practice, to which version and which chapter, whether under paragraph 7 the obligations in Article 53 suffice for you, and which elaboration of your own you apply for the issues in paragraph 2 where you do not join.
Hangs off: Article 56: codes of practice for general-purpose AI models
Editorially reviewed | governance, gpai, gpai-systemic-risk
- ActionUpcomingv1.0.06 relations
Enter your data in the EU database and keep it up to date
praxikon:eu:ai-act:action:enter-and-maintain-eu-database-data
Compile per system the data listed in Sections A and B of Annex VIII, or Section C where you are a public deployer, designate the natural person with the legal authority to register, and make sure the entry stays correct when the status, the Member States or the declaration of conformity change. Section C can only be completed after the provider has entered Section A, because point 3 asks for the URL of that entry.
Hangs off: Article 71: EU database for high-risk AI systems listed in Annex III
Editorially reviewed | conformity
- ActionUpcomingv1.0.03 relations
Establish the product route per product
praxikon:eu:ai-act:action:establish-annex-i-product-route
Determine per product which Annex I legal act it falls under and whether that is Section A or Section B, which conformity assessment procedure applies there, which AI functions are safety components and who is thereby the provider.
Hangs off: Article 6(1): the product route to high risk
Editorially reviewed | conformity, high-risk
- ActionApplicablev1.0.03 relations
Establish per system who your supervisor is
praxikon:eu:ai-act:action:establish-competent-supervisor
Assess per AI system whether it falls under the exclusive competence of the AI Office or under a national authority, record the outcome with its reasoning, and determine which carve-out in paragraph 1 applies if any and which counter follows from it.
Hangs off: Article 75: market surveillance, mutual assistance and the powers of the AI Office
Editorially reviewed | enforcement, governance
- 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
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
- 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
- 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
- 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
- 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
- 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
- ActionEditorialv1.0.04 relations
Record per requirement which standard or specification you rely on, and justify every departure
praxikon:eu:ai-act:action:justify-standards-and-specification-choices
Keep a coverage matrix of the requirements of Section 2 against the harmonised standards, common specifications and own documents applied, noting per row the publication status in the Official Journal, and write out the Article 41(5) justification for every common specification you do not apply.
Hangs off: Articles 40 to 42: standards, common specifications and presumption of conformity
Editorially reviewed | conformity, standards
- ActionUpcomingv1.0.03 relations
Set up the ten year retention of the system documentation
praxikon:eu:ai-act:action:keep-high-risk-documentation-available
Bring the five components of Article 18(1) together per high-risk system in an identifiable place, record both the date of placing on the market and the date of putting into service, calculate the end date from the later moment, and assign the upkeep to a role rather than to a person.
Hangs off: Article 18: documentation keeping
Editorially reviewed | high-risk-requirements
- Actionv1.0.03 relations
Manage the life of the certificate
praxikon:eu:ai-act:action:manage-notified-body-certificate
A practical working out for whoever holds a certificate: watch the expiry date, ask in time for the re-assessment that carries the extension, test every change against the substantial modification of Article 43(4), and make sure a deadline set by the body for corrective action reaches an identifiable person. Also track the body itself, because on cessation or withdrawal of its designation the deadlines of Article 36 apply.
Hangs off: Article 44: certificates of notified bodies
Editorially reviewed | conformity
- ActionUpcomingv1.0.04 relations
Map every system to a point of Annex III
praxikon:eu:ai-act:action:map-system-to-annex-iii-area
Determine per AI system which of the eight areas and which lettered subpoint the intended purpose touches, or establish with reasons that no point applies. Then run the Article 6(3) test and record the outcome as Article 6(4) requires. Do so at the level of the intended purpose and not at the level of the department or the sector.
Hangs off: Annex III: the eight areas separately
Editorially reviewed | high-risk
- ActionEditorialv1.0.05 relations
Mark and register what you submit to an authority or body
praxikon:eu:ai-act:action:mark-confidential-material-on-submission
State on every submission which part is confidential business information, trade secret or source code, keep track of what was handed to whom on what date, and on a further request ask about the necessity and the purpose within the meaning of Article 78(2).
Hangs off: Article 78: confidentiality of what you submit to an authority
Editorially reviewed | enforcement, governance
- ActionApplicablev1.0.03 relations
Notify the Commission within two weeks
praxikon:eu:ai-act:action:notify-systemic-risk-threshold
Notify the model as soon as it meets the condition in Article 51(1), point (a), or as soon as it becomes known that it will, with the information necessary to demonstrate that the requirement has been met, and with any substantiation that the model does not present systemic risks after all.
Hangs off: Article 52: notification of a GPAI model with systemic risk
Editorially reviewed | gpai-systemic-risk
- ActionEditorialv1.0.04 relations
Make sure a report about an AI system reaches your reporting channel
praxikon:eu:ai-act:action:open-a-protected-reporting-route
Only for organisations that must already have a reporting arrangement. Make visible in it that an infringement of the AI Regulation is a reportable infringement, designate who receives such a report, agree how the identity of the person reporting stays out of the rest of the process, and record whether you handle anonymous reports.
Hangs off: Article 87: reporting of infringements and protection of reporting persons
Editorially reviewed | fundamental-rights, governance
- ActionApplicablev1.0.04 relations
Plan compliance for legacy public sector systems by 2 August 2030
praxikon:eu:ai-act:action:plan-legacy-public-system-compliance
Determine which high-risk systems are intended to be used by public authorities and were already running before the cut off date for their route, and count back from the conformity assessment and the registration to a plan that finishes before 2 August 2030.
Hangs off: Article 111(2): legacy high-risk systems and the 2 August 2030 date
Editorially reviewed | high-risk, timeline
- ActionEditorialv1.0.05 relations
Prepare a derogation request and the exit plan that goes with it
praxikon:eu:ai-act:action:prepare-article-46-derogation-request
Write in advance the reasoning paragraph 1 calls for, with the exceptional reason invoked, the evidence that the system complies with the requirements of Section 2, the status of the ongoing conformity assessment, and an exit plan in case the authorisation is refused or withdrawn.
Hangs off: Article 46: derogation from conformity assessment procedure
Editorially reviewed | conformity, enforcement
- ActionUpcomingv1.0.04 relations
Make your conformity file deliverable on request
praxikon:eu:ai-act:action:prepare-authority-information-request
Map per high-risk system where each part of the file sits, which system version it belongs to, who assembles it, how long the logs are kept and in which language indicated by the Member State concerned you can supply it, so that a reasoned request becomes a delivery task rather than a search.
Hangs off: Article 21: cooperation with competent authorities
Editorially reviewed | high-risk-requirements
- 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
- ActionApplicablev1.0.06 relations
Justify and record your reliance on Article 4a
praxikon:eu:ai-act:action:record-bias-testing-legal-basis
Only for those who themselves decide to process special categories of personal data for bias testing. In that case record which paragraph of Article 4a you rely on and whether that paragraph is open to your role, why other data do not suffice, which safeguards apply, who has access and when the data are deleted. Replace old references to Article 10(5) while you are there.
Hangs off: Article 4a: legal basis for bias testing with special categories of personal data
Editorially reviewed | fundamental-rights, high-risk-requirements
- ActionApplicablev1.0.07 relations
Register yourself and the system before it reaches the market or is put into service
praxikon:eu:ai-act:action:register-in-eu-database-before-market-entry
Determine per system which of the four Article 49 routes applies, the ordinary Annex III route, the Article 6(3) route, the secure section for law enforcement, migration, asylum and border control management, or the national route for point 2 of Annex III, and complete the registration before the system is placed on the market, put into service or used.
Hangs off: Article 49: registration in the EU database before the system reaches the market
Editorially reviewed | conformity, high-risk
- ActionApplicablev1.0.03 relations
Request reassessment after a designation
praxikon:eu:ai-act:action:request-systemic-risk-reassessment
If your model has been designated under Article 52(4), you may request reassessment by reasoned request. The request must contain objective, detailed and new reasons that have arisen since the designation decision, and may be made at the earliest six months after that decision; where the designation is maintained, a further six months apply.
Hangs off: Article 52: notification of a GPAI model with systemic risk
Editorially reviewed | gpai-systemic-risk
- ActionUpcomingv1.0.03 relations
Route reporting and conformity assessment to the AI Office
praxikon:eu:ai-act:action:route-high-risk-duties-to-ai-office
Adjust your incident procedure so that a serious incident concerning a high-risk system under the competence of the AI Office reaches the Office, with the Article 73 deadlines intact, and establish whether your third-party conformity assessment now runs through the Commission, including the fees you pay directly to the notified body.
Hangs off: Article 75(1a) and (1e): reporting to and assessment by the AI Office
Editorially reviewed | enforcement, high-risk-requirements
- ActionUpcomingv1.0.03 relations
Set up the procedure for corrective actions and notification
praxikon:eu:ai-act:action:run-corrective-action-procedure
Work out the four measures in paragraph 1 as scenarios with an owner and a lead time, keep a record per system version of who runs it and how you reach that party, and set out the route along which the investigation of causes, the notification to the market surveillance authorities and the message to the notified body run once paragraph 2 comes into play.
Hangs off: Article 20: corrective actions and duty of information
Editorially reviewed | high-risk-requirements, post-market
- 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
- 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
- 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
- ActionEditorialv1.0.03 relations
Check the standing and independence of your notified body
praxikon:eu:ai-act:action:verify-notified-body-standing
At the moment of choice and periodically thereafter, verify whether the body appears in the Commission public list, for which activities and system types it is notified, whether its designation has been restricted or suspended, and whether the independence of Article 31(4) and (5) holds; also ask which tasks are subcontracted and give your agreement under Article 33(3) in writing.
Hangs off: Articles 28 to 39: notifying authorities and notified bodies
Editorially reviewed | conformity, governance
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.