For high risk systems, the EU AI Act asks engineers for a lifecycle risk process, data governance, technical documentation, automatic logging, usable instructions, human oversight features, and accuracy, resilience and cybersecurity. Start by checking whether your system is high risk at all, then build each item into the delivery pipeline.
Is your system in scope?
The Act sorts AI into four tiers: unacceptable risk (prohibited), high risk (most of the regulation), limited risk (transparency duties, such as telling users they talk to a chatbot) and minimal risk. The summary page we fetched maps provider duties for high risk systems to Articles 9 to 15. Whether you are high risk depends on the Act's annexes and your use case, so get legal advice before you build.
Which dates matter?
That same summary lists these dates: most prohibitions from 2 February 2025, general purpose AI obligations from 2 August 2025, AI Office enforcement powers and Article 50 transparency rules from 2 August 2026, and high risk obligations for Annex III systems from 2 December 2027 and for Annex I systems from 2 August 2028. Dates have been moving, so check the official text and Commission announcements before you plan.
The checklist, by article
Risk management (Art. 9). A documented, lifecycle risk process: hazards identified, risks estimated, mitigations chosen, residual risk reviewed. Engineering link: a risk register tied to releases, with testing against identified risks before each release.
Data governance (Art. 10). Training, validation and test datasets that are relevant, representative and as free of errors as practical. Engineering link: dataset versioning, lineage records, documented sources and cleaning steps, bias checks where relevant.
Technical documentation (Art. 11). Documentation that shows compliance. Engineering link: model cards or design docs generated from the repository and kept with each release.
Record keeping (Art. 12). Automatic logging of relevant events. Engineering link: structured logs of inputs, outputs, model version, and human overrides, with access control, retention rules and tamper evidence. Keep personal data out of logs unless you need it.
Instructions for use (Art. 13). Information for deployers. Engineering link: documented intended purpose, accuracy levels, limits and known failure modes shipped with the product.
Human oversight (Art. 14). Features that let a person understand, intervene and stop the system. Engineering link: confidence or explanation displays, review queues, override and kill switch, and testing that they work.
Accuracy, resilience and cybersecurity (Art. 15). Engineering link: test suites with metrics tracked by release, resilience testing to errors and misuse, protection of models, data and pipelines, dependency scanning and patching.
Also on the list
The summary notes further provider duties: conformity assessment, CE marking, EU database registration and accessibility requirements. Those are process steps your legal and product teams own, with engineering supplying evidence.
General purpose AI
If you provide a general purpose model, separate duties apply, including technical documentation, information for downstream providers, a copyright policy and a training content summary. Systemic risk models have more, such as evaluations and incident reporting.
Mistakes to avoid
- Assuming a vendor's compliance covers your use case.
- Logs that miss model version and human overrides.
- Documentation written once for launch and never updated.
- Human oversight that exists on paper but no one can use at speed.
What to do
- Classify each AI system with counsel.
- Build a risk register tied to releases.
- Version datasets and record lineage.
- Generate technical documentation from the repo each release.
- Add structured, protected logging with model version.
- Build and test oversight and override features.
- Track accuracy and security tests per release, and scan dependencies.
- Recheck dates and obligations every quarter.
Quick check
Which articles cover high risk provider duties?
Articles 9 to 15 cover risk management, data governance, documentation, logging, instructions, human oversight, and accuracy, resilience and cybersecurity.
Are the application dates fixed?
They have been changing. The summary we read lists high risk Annex III obligations from 2 December 2027, but check official sources before planning.
How Safeguard helps automate this
Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs continuously between audits. That keeps release by release records of tests, scans and fixes current.
Technical evidence comes from your real code and dependencies, through scans, SBOMs and reachability, which supports the cybersecurity and documentation items above. Safeguard's agent can open tested fix pull requests for vulnerable dependencies and other findings. It is off by default, every category starts on Manual, and you choose which categories run automatically and set the approval level. Conformity assessment and enforcement belong to the bodies named in the Act. Safeguard helps prepare and keep evidence ready, and does not make you compliant.
See it at /demos/framework-mapping.
Want to see it on your own stack? Book a call.
Sources
Last reviewed: 18 October 2026.
