Five articles a compliance team actually has to operate.

Article 9 of the EU AI Act — Risk management system says that for every high-risk AI system you must establish, document and maintain a risk-management process across the system’s whole life. Not a one-time report. A continuous loop: identify the risks the system can cause to health, safety and fundamental rights, evaluate them, mitigate them, then come back next quarter and do it again with new evidence.

In practice that means three artefacts a market-surveillance authority will ask for: (1) a written risk register linked to the specific system, (2) a record of the mitigations applied and their residual risk, and (3) a dated trail showing the register was actually reviewed — not just printed once and filed. The regulator’s test is whether the process looks alive.

How Secruna covers it. Each high-risk system in your inventory carries a live Article 9 risk register. The dashboard tracks every change with a two-person sign-off, stamps each review with a UTC timestamp, and surfaces overdue reviews on the operations queue so they never quietly age out. The export pack assembles the register, the mitigation history and the review log into one audit-ready PDF per system.

Where this lives in Secruna: /risks → pick any high-risk system → the Article 9 evidence tab.

Next action: open Risks, click the system you’re most worried about, and confirm the register has at least one entry with a recorded mitigation and a review date in the last 90 days. If it doesn’t, that system is your first audit gap.

Article 14 — Human oversight requires that every high-risk AI system is designed and used so a person can effectively oversee it during the period it is in service. That oversight has to be appropriate to the risk: not just a named owner on a wiki page, but a person with the authority and the tools to override, pause or roll back the system when it behaves unexpectedly.

Plain English: the AI Act expects a clear human in the loop with three concrete capabilities. They must be able to (1) understand what the system is doing well enough to spot when it stops working, (2) interpret the output before it reaches the affected person, and (3) decide not to use the output, or stop the system, when they see something off. Documented. Trained. Refreshed.

How Secruna covers it. The dashboard ships a four-eyes flow on every classification and risk decision — no single reviewer can approve a high-risk verdict alone. A human-in-the-loop (HITL) queue routes flagged outputs to a named oversight role, captures the reviewer’s decision and reason, and writes both into the seven-year audit log. The operating manual and training record per system are stored alongside, so a regulator can see who oversaw what, when, and what they were trained on.

Where this lives in Secruna: /oversight for the HITL queue; /systems/<id>/oversight for per-system oversight roles, training records and the override history.

Next action: pick one high-risk system and confirm two things — there is a named oversight owner who is not the system’s builder, and there is at least one recorded override in the last quarter. No overrides ever is itself a finding.

Article 27 — Fundamental rights impact assessment (FRIA) applies to deployers of certain high-risk AI systems before they put the system into use. It bites hardest on bodies governed by public law, private operators providing public services, and deployers using AI for creditworthiness or life and health insurance pricing. If you sit in any of those buckets, the FRIA is not optional — and it is not the same document as your GDPR Article 35 DPIA, even though you can reuse a lot of the underlying evidence.

The FRIA has to describe the deployment context, the categories of natural persons affected, the specific risks of harm to fundamental rights (dignity, non-discrimination, access to services, due process), the human-oversight measures, and the steps to take when those risks materialise. The deployer notifies the market-surveillance authority that the FRIA was carried out.

How Secruna covers it. Each system flagged as in-scope for Article 27 carries a FRIA workspace pre-populated with the Annex III category, the affected-person categories, and a cross-reference to any existing GDPR Article 35 DPIA so legal does not redo the same analysis twice. The export pack ships the FRIA as a standalone PDF plus the linked evidence — risk register, oversight roles, data-governance record — so counsel can attach it to the MSA notification in one upload.

Where this lives in Secruna: /systems/<id>/fria on every system whose Annex III classification triggers Article 27. The export pack download is on /systems/<id>/evidence.

Next action: filter your system list by “FRIA required” and check that each one has a started — not just empty — FRIA workspace. An unstarted FRIA on an in-scope system is the single most common audit finding for deployers in this category.

Article 73 — Reporting of serious incidents requires providers of high-risk AI systems to notify the market-surveillance authority of any serious incident as soon as the causal link between the AI system and the incident is established. The default outer window is 15 days. For incidents involving widespread infringement of fundamental rights or critical infrastructure disruption the window tightens — down to two days in the tightest categories.

“Serious incident” is defined narrowly: death or serious harm to a person’s health, a serious and irreversible disruption of critical infrastructure, breach of EU law obligations meant to protect fundamental rights, or serious harm to property or the environment. The clock starts not at the moment of the event but at the moment your team can plausibly tie the AI system to the outcome — which is why most operational programmes fail this article. They have no instrumented way to make that link in time.

How Secruna covers it. The platform fires an incident.reported notification to your registered ops queue the moment a system is flagged. The incident workspace prompts for the causal-link evidence, the affected population, the regulatory category, and auto-generates the MSA notification draft pre-filled with the system’s technical documentation reference, the deployer record and the audit trail. A countdown surfaces the 15-day (or shorter) deadline against the established-causal-link timestamp so the clock is visible to everyone, not just the on-call.

Where this lives in Secruna: /incidents for the queue and the deadline dashboard; /incidents/<id> for the per-incident workspace and MSA notification draft.

Next action: open Incidents and run the dry-run wizard against your top high-risk system. If your team cannot produce a draft notification inside an hour, the gap is process, not paperwork — and that is the gap to close before August 2026.

Article 99 — Penalties sets the financial bracket each Member State must enforce. Three tiers, not one. The numbers are the higher of a fixed cap or a percentage of total worldwide annual turnover for the previous financial year — and for most enterprise deployers, the percentage is the binding number.

Top bracket — €35M / 7%. Reserved for breaches of Article 5 (the prohibited-AI practices: subliminal manipulation, social scoring by public authorities, real-time remote biometric identification in public spaces with narrow exceptions, and the rest of the Article 5 list). This is the bracket the press writes about and the one your CFO needs to know exists.

Middle bracket — €15M / 3%. Applies to most other obligations on providers and deployers of high-risk systems: the Article 9 risk management duty, the Article 14 oversight duty, the Article 27 FRIA, the Article 73 incident-reporting duty, transparency obligations, the technical documentation under Article 11, and the conformity-assessment duties. This is the bracket that hits a normal high-risk-system breach.

Lower bracket — €7.5M / 1%. Applies to the supply of incorrect, incomplete or misleading information to authorities. SMEs and start-ups get a slightly lighter treatment — the cap is the lower of the percentage and the fixed amount, not the higher.

How Secruna covers it. Every system in the inventory carries a live exposure figure against each bracket, computed from your declared annual turnover and the system’s current Annex III classification. The dashboard surfaces the worst-case fine the buying team is signing off on every quarter — useful when the conversation moves from compliance to budget.

Where this lives in Secruna: /exposure for the consolidated bracket view; the per-system exposure card sits at the top of every /systems/<id> page.

Next action: open Exposure and sort by worst-case fine. The systems at the top of that list are where the next quarter of compliance work earns the most return per hour spent.