Content to action
Qubicweb keeps the discovery and trust-education layer lightweight. When you need governed account, commerce, service, or trust actions, continue in the canonical app without losing the article’s source context.
Content to action
Qubicweb keeps the discovery and trust-education layer lightweight. When you need governed account, commerce, service, or trust actions, continue in the canonical app without losing the article’s source context.
Brief points
Key points will appear here once TrustOps condenses this read. Use the source link below if you need the full article immediately.
The EU AI Act has been on the calendar since 2024. The deadline most teams have to actually plan for is August 2, 2026, when high-risk AI system obligations start applying. If you are shipping AI into the EU, this is the post you need before that date.
This is not a legal explainer. It is a list of what you have to put in place, with the article number next to each measure, and an honest map of which ones RootCX helps with.
Regulation (EU) 2024/1689. Entered into force August 1, 2024. Risk-based: it classifies AI systems into 4 tiers and assigns obligations per tier. It applies to providers (whoever puts an AI system on the market) and deployers (whoever uses one professionally), regardless of where they are based, as long as the output is used in the EU.
That last part is what catches teams outside Europe. You are based in San Francisco, your customers are in Germany, the Act applies.
Unacceptable risk. Banned outright since February 2, 2025. Social scoring by public authorities, untargeted scraping of facial images, emotion recognition in workplaces and schools, biometric categorization for race or political opinion, predictive policing based on profiling, real-time remote biometric identification in public spaces (with narrow law enforcement exceptions). If your product does any of this in the EU, stop.
High risk. Listed in Annex III plus AI used as safety components in regulated products (Annex I). The Annex III categories: biometrics, critical infrastructure, education, employment and HR, access to essential private and public services (including credit scoring), law enforcement, migration and border control, administration of justice and democratic processes. Most of the obligations in this article apply to this tier. Starts applying August 2, 2026.
Limited risk. Transparency obligations. Users must be told they are interacting with an AI (chatbots), AI-generated content must be labeled (deepfakes, synthetic media). Article 50.
Minimal risk. Everything else. No specific obligations under the Act.
There is a separate track for General Purpose AI (GPAI) model providers, with obligations that started August 2, 2025.
Date
What applies
August 1, 2024
Regulation in force
February 2, 2025
Prohibitions on unacceptable risk
August 2, 2025
GPAI model obligations, governance bodies, penalties framework
August 2, 2026
Most provisions, including high-risk AI systems under Annex III
August 2, 2027
High-risk AI systems used as safety components in Annex I products
These are the requirements that have to be satisfied before the system is placed on the EU market or put into service. Each maps to a specific article in the Act.
Obligation
Article
What it means in practice
Risk management system
Art 9
Documented process to identify, analyze, evaluate, and mitigate risks across the system's lifecycle. Not a 1-time exercise.
Data governance
Art 10
Training, validation, and testing datasets meet quality criteria. Relevance, representativeness, freedom from errors. Documented.
Technical documentation
Art 11 + Annex IV
Pre-market technical file covering system design, capabilities, limitations, training data, performance metrics, risk controls.
Record-keeping
Art 12
Automatic logging of events during operation. Sufficient to trace the system's functioning over its lifetime.
Transparency to deployers
Art 13
Clear instructions for use. Performance characteristics, intended purpose, known limitations, human oversight measures.
Human oversight
Art 14
Measures that let a natural person monitor, intervene, override, or stop the system. Designed into the system, not bolted on.
Accuracy, robustness, cybersecurity
Art 15
Performance levels declared. Resilience to errors. Protection against adversarial inputs and unauthorized access.
Quality management system
Art 17
Documented procedures across design, development, testing, monitoring, and incident handling.
Registration
Art 49
High-risk systems registered in the EU database before market placement.
Conformity assessment
Art 43
Either self-assessment or notified body assessment, depending on the system category. CE marking on success.
Post-market monitoring
Art 72
Continuous monitoring after deployment, with corrective actions if performance deviates.
Serious incident reporting
Art 73
Report serious incidents to market surveillance authorities within 15 days (less for some categories).
If you are using a high-risk AI system rather than placing it on the market, your obligations are in Article 26. They are shorter but real.
Use the system according to the provider's instructions. Not a generic clause. Specific and documented use that matches the intended purpose declared by the provider.
Assign human oversight to natural persons who are competent, trained, and have the authority and resources to do it.
Ensure input data is relevant for the intended purpose. Garbage in is your responsibility once you are the deployer.
Monitor operation. If you have reason to consider the system poses a risk, suspend use and inform the provider and the market surveillance authority.
Keep automatically generated logs for at least 6 months, where you have control over them. Longer if other laws (sectoral, GDPR) require it.
Inform workers and worker representatives before deploying a high-risk system at the workplace. Art 26(7).
Inform natural persons subject to a high-risk AI decision that affects them. Art 26(11).
Cooperate with competent authorities.
Public bodies and certain private deployers in essential services also have to conduct a Fundamental Rights Impact Assessment (FRIA) before first use, under Article 27.
If your AI system interacts with humans or generates synthetic media, you tell users it is AI, and you label generated content as AI-generated. Article 50.
For providers of general-purpose AI models (Articles 53-55):
Technical documentation of the model.
Information for downstream providers integrating the model.
Policy to comply with EU copyright law.
Sufficiently detailed public summary of the training content.
For models with systemic risk (compute threshold or designated): model evaluations, adversarial testing, serious incident reporting, cybersecurity protections.
If you are integrating a GPAI model into a high-risk system as a provider, both sets of obligations apply.
These are the headline numbers. Member states can set them higher, not lower.
Prohibited practices (Art 5 violations): up to €35 million or 7% of total worldwide annual turnover, whichever is higher.
Non-compliance with other obligations (most of the above): up to €15 million or 3% of turnover.
Supply of incorrect, incomplete, or misleading information to authorities: up to €7.5 million or 1% of turnover.
SMEs and startups: the lower of the 2 amounts applies, not the higher.
The Act covers a lot of ground. Some of it is platform work. A lot of it is paperwork, legal review, and engineering process that no platform replaces. Here is what RootCX actually helps with, and what it does not.
Article
RootCX maps?
How
Art 12 (record-keeping)
Yes
Every action by humans and AI agents is appended to the project's immutable audit log, scoped to user, agent, tool, and resource. Append-only by design. Queryable for the lifetime of the system.
Art 14 (human oversight)
Partial
RBAC on every action gives a natural person the authority to scope, review, and revoke. Approval gates on write actions. Agents run under their own identity, governed by the same RBAC as humans, so a person can suspend them. The Act also requires UI affordances for intervention, which is on you to design.
Art 15 (cybersecurity)
Partial
SSO with your OIDC provider, encrypted secrets vault, per-tool RBAC, network-level controls in self-host. The accuracy and robustness side of Art 15 is on you.
Art 26(5) (deployer log retention ≥ 6 months)
Yes
Logs are immutable and retained per project. Retention can be extended to match sectoral requirements.
Art 26(2) (assign human oversight to competent persons)
Partial
RBAC lets you scope oversight to named individuals with the right role. The training and competence of those individuals is not platform work.
What RootCX does not help with, to be clear:
Risk management system (Art 9). This is your documented internal process.
Data governance for training data quality (Art 10). RootCX runs the production system. Your model training pipeline is upstream.
Technical documentation and Annex IV file (Art 11). Document, not feature.
Quality management system (Art 17). Organizational process.
Conformity assessment (Art 43) and registration (Art 49). Regulatory steps.
Post-market monitoring (Art 72) and serious incident reporting (Art 73). Process. The audit log is useful evidence, but the obligation is procedural.
Fundamental Rights Impact Assessment (Art 27). Cross-functional assessment, not a tool output.
GPAI training data summary (Art 53). Only applies if you are a GPAI provider.
The honest version: if your team is shipping a high-risk system or deploying one in the EU, RootCX covers the "automated logs, identity, and access control" pillar cleanly. The legal, procedural, and documentation pillars still need to be done.
If you are a deployer using an AI system that falls under Annex III, you have a finite list to work through before August 2, 2026.
Confirm whether your system is in Annex III. If unclear, get a written opinion.
Read the provider's instructions for use. Identify the intended purpose and limitations.
Assign 1 or more named individuals as human oversight, with training and authority.
Verify your input data is relevant and fit for the intended purpose.
Set up monitoring and a suspension procedure if risk is identified.
Enable automatic logs with at least 6 months retention.
If you have workers using or affected by the system, brief them and inform worker representatives.
Update your privacy notices to inform affected natural persons of high-risk AI use.
If you are a public body or covered private deployer, complete the Fundamental Rights Impact Assessment.
Keep records of all of the above. The market surveillance authority will ask.
Most teams reading this are deployers, not providers. The deployer obligations are lighter than the provider list, but they assume the platform you are running on can produce automatic logs, scope human oversight, and inform people. If your AI system today runs on a stack where the audit log is grep against stdout and the access control is an API key in .env, you are not ready.
Whatever platform you choose, the questions on August 2, 2026 are: who acted, when, against what data, with what authorization, and can you prove it. The Act does not let you answer "we'll check the logs" without showing the logs.
RootCX handles the identity, RBAC, and audit layer. Same OIDC your humans use (Okta, Microsoft Entra, Google Workspace, Auth0). Per-tool RBAC for humans and agents. Immutable, append-only audit log with retention you control. Self-host for full data sovereignty if your sector requires it.
The rest of the Act, the risk management, the technical file, the conformity assessment, is still on you. We are not selling compliance. We are selling the part of the stack that produces the evidence your compliance work needs.
You can start a project free and have the logging, identity, and RBAC layer in place before the deadline.
This post is operational guidance, not legal advice. Read the Regulation, talk to counsel.
Spot something off?