{"slug": "the-eu-ai-act-a-concrete-compliance-checklist", "title": "The EU AI Act: A Concrete Compliance Checklist", "summary": "The EU AI Act, which entered into force on August 1, 2024, establishes a risk-based framework classifying AI systems into four tiers, with most obligations for high-risk systems applying from August 2, 2026. The regulation applies to both providers and deployers globally if their AI system's output is used in the EU, and it mandates specific compliance measures such as risk management, data governance, technical documentation, and human oversight, each tied to a specific article of the Act.", "body_md": "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.\nThis 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.\nRegulation (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.\nThat last part is what catches teams outside Europe. You are based in San Francisco, your customers are in Germany, the Act applies.\nUnacceptable 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.\nHigh 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.\nLimited 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.\nMinimal risk. Everything else. No specific obligations under the Act.\nThere is a separate track for General Purpose AI (GPAI) model providers, with obligations that started August 2, 2025.\nDate\nWhat applies\nAugust 1, 2024\nRegulation in force\nFebruary 2, 2025\nProhibitions on unacceptable risk\nAugust 2, 2025\nGPAI model obligations, governance bodies, penalties framework\nAugust 2, 2026\nMost provisions, including high-risk AI systems under Annex III\nAugust 2, 2027\nHigh-risk AI systems used as safety components in Annex I products\nThese 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.\nObligation\nArticle\nWhat it means in practice\nRisk management system\nArt 9\nDocumented process to identify, analyze, evaluate, and mitigate risks across the system's lifecycle. Not a 1-time exercise.\nData governance\nArt 10\nTraining, validation, and testing datasets meet quality criteria. Relevance, representativeness, freedom from errors. Documented.\nTechnical documentation\nArt 11 + Annex IV\nPre-market technical file covering system design, capabilities, limitations, training data, performance metrics, risk controls.\nRecord-keeping\nArt 12\nAutomatic logging of events during operation. Sufficient to trace the system's functioning over its lifetime.\nTransparency to deployers\nArt 13\nClear instructions for use. Performance characteristics, intended purpose, known limitations, human oversight measures.\nHuman oversight\nArt 14\nMeasures that let a natural person monitor, intervene, override, or stop the system. Designed into the system, not bolted on.\nAccuracy, robustness, cybersecurity\nArt 15\nPerformance levels declared. Resilience to errors. Protection against adversarial inputs and unauthorized access.\nQuality management system\nArt 17\nDocumented procedures across design, development, testing, monitoring, and incident handling.\nRegistration\nArt 49\nHigh-risk systems registered in the EU database before market placement.\nConformity assessment\nArt 43\nEither self-assessment or notified body assessment, depending on the system category. CE marking on success.\nPost-market monitoring\nArt 72\nContinuous monitoring after deployment, with corrective actions if performance deviates.\nSerious incident reporting\nArt 73\nReport serious incidents to market surveillance authorities within 15 days (less for some categories).\nIf 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.\nUse 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.\nAssign human oversight to natural persons who are competent, trained, and have the authority and resources to do it.\nEnsure input data is relevant for the intended purpose. Garbage in is your responsibility once you are the deployer.\nMonitor operation. If you have reason to consider the system poses a risk, suspend use and inform the provider and the market surveillance authority.\nKeep automatically generated logs for at least 6 months, where you have control over them. Longer if other laws (sectoral, GDPR) require it.\nInform workers and worker representatives before deploying a high-risk system at the workplace. Art 26(7).\nInform natural persons subject to a high-risk AI decision that affects them. Art 26(11).\nCooperate with competent authorities.\nPublic bodies and certain private deployers in essential services also have to conduct a Fundamental Rights Impact Assessment (FRIA) before first use, under Article 27.\nIf 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.\nFor providers of general-purpose AI models (Articles 53-55):\nTechnical documentation of the model.\nInformation for downstream providers integrating the model.\nPolicy to comply with EU copyright law.\nSufficiently detailed public summary of the training content.\nFor models with systemic risk (compute threshold or designated): model evaluations, adversarial testing, serious incident reporting, cybersecurity protections.\nIf you are integrating a GPAI model into a high-risk system as a provider, both sets of obligations apply.\nThese are the headline numbers. Member states can set them higher, not lower.\nProhibited practices (Art 5 violations): up to €35 million or 7% of total worldwide annual turnover, whichever is higher.\nNon-compliance with other obligations (most of the above): up to €15 million or 3% of turnover.\nSupply of incorrect, incomplete, or misleading information to authorities: up to €7.5 million or 1% of turnover.\nSMEs and startups: the lower of the 2 amounts applies, not the higher.\nThe 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.\nArticle\nRootCX maps?\nHow\nArt 12 (record-keeping)\nYes\nEvery 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.\nArt 14 (human oversight)\nPartial\nRBAC 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.\nArt 15 (cybersecurity)\nPartial\nSSO 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.\nArt 26(5) (deployer log retention ≥ 6 months)\nYes\nLogs are immutable and retained per project. Retention can be extended to match sectoral requirements.\nArt 26(2) (assign human oversight to competent persons)\nPartial\nRBAC lets you scope oversight to named individuals with the right role. The training and competence of those individuals is not platform work.\nWhat RootCX does not help with, to be clear:\nRisk management system (Art 9). This is your documented internal process.\nData governance for training data quality (Art 10). RootCX runs the production system. Your model training pipeline is upstream.\nTechnical documentation and Annex IV file (Art 11). Document, not feature.\nQuality management system (Art 17). Organizational process.\nConformity assessment (Art 43) and registration (Art 49). Regulatory steps.\nPost-market monitoring (Art 72) and serious incident reporting (Art 73). Process. The audit log is useful evidence, but the obligation is procedural.\nFundamental Rights Impact Assessment (Art 27). Cross-functional assessment, not a tool output.\nGPAI training data summary (Art 53). Only applies if you are a GPAI provider.\nThe 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.\nIf 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.\nConfirm whether your system is in Annex III. If unclear, get a written opinion.\nRead the provider's instructions for use. Identify the intended purpose and limitations.\nAssign 1 or more named individuals as human oversight, with training and authority.\nVerify your input data is relevant and fit for the intended purpose.\nSet up monitoring and a suspension procedure if risk is identified.\nEnable automatic logs with at least 6 months retention.\nIf you have workers using or affected by the system, brief them and inform worker representatives.\nUpdate your privacy notices to inform affected natural persons of high-risk AI use.\nIf you are a public body or covered private deployer, complete the Fundamental Rights Impact Assessment.\nKeep records of all of the above. The market surveillance authority will ask.\nMost 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\n, you are not ready.\nWhatever 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.\nRootCX 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.\nThe 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.\nYou can start a project free and have the logging, identity, and RBAC layer in place before the deadline.\nThis post is operational guidance, not legal advice. Read the Regulation, talk to counsel.", "url": "https://wpnews.pro/news/the-eu-ai-act-a-concrete-compliance-checklist", "canonical_source": "https://dev.to/rootcx/the-eu-ai-act-a-concrete-compliance-checklist-517n", "published_at": "2026-05-21 07:14:16+00:00", "updated_at": "2026-05-21 07:32:57.714193+00:00", "lang": "en", "topics": ["artificial-intelligence", "policy-regulation", "enterprise-software", "data", "products"], "entities": ["EU AI Act", "RootCX", "Regulation (EU) 2024/1689", "Annex III", "Annex I"], "alternates": {"html": "https://wpnews.pro/news/the-eu-ai-act-a-concrete-compliance-checklist", "markdown": "https://wpnews.pro/news/the-eu-ai-act-a-concrete-compliance-checklist.md", "text": "https://wpnews.pro/news/the-eu-ai-act-a-concrete-compliance-checklist.txt", "jsonld": "https://wpnews.pro/news/the-eu-ai-act-a-concrete-compliance-checklist.jsonld"}}