PRGuard
Get started →

Assurance · EU AI Act

The EU AI Act, Article by Article.

The EU AI Act regulates the AI system you ship, and you as its provider.
PRGuard keeps the evidence for how that system’s code changes, automatically, as you ship. Here is how it helps, article by article, with each article linked to the law’s own text.

Watch the overview Go article by article
The video’s words

The EU AI Act does not regulate how you review code. It regulates the AI system you ship. So what can PRGuard show for it?

Halcyon's risk engine decides who gets credit. Under the Act that makes it a high-risk system, and Halcyon its provider.

The Act asks a provider for a quality management system: how changes are designed, checked and controlled. And for something that shows it was followed.

This is that record. Every change to the risk engine, the rules it was checked against, and what was done about each finding.

Where an AI wrote the change, it says so, and it names the person who approved it.

A risk that was accepted has a name, a reason and an end date.

At the end of the quarter, it is one file your assessor can check.

PRGuard Assurance keeps the evidence that your process was followed, change by change, ready for the day your assessor asks.

Halcyon Payments is a fictional company. Its credit decisions make its risk engine a high-risk system.

Overview

What It Asks. How PRGuard Helps.

The Act’s high-risk rules ask a provider for a quality management system and a risk management system that run for the system’s whole life, for technical documentation kept up to date, and for the system itself to keep logs and be overseen by people while it is in use.

PRGuard sits where your system’s code changes. It audits each change against your own rules and records what happened to every change that reached a default branch: how it was audited, what was found and fixed, who or what wrote it, who approved it, and what risk was accepted, by whom and until when. When the quarter ends, that record is one file your assessor checks on their own machine.

That record is your strongest evidence for Article 17, and covers the code side of Articles 9 and 11: the risks found in the code, and the changes made to the system through its life. Beside Article 14, oversight the running system provides, it adds a record of the people who approved each change.

  1. Article 9Risk management systemCovers the code
  2. Article 11Technical documentationCovers the code
  3. Article 14Human oversightEvidence alongside
  4. Article 17Quality management systemStrongest fit

Before you start

Who, Which and When.

Who the rules are for

The high-risk rules fall on the provider: whoever develops an AI system, or has one developed, and places it on the market or puts it into service under their own name or trademark (Article 3(3)).

The duties stay with you as the provider, which is why the evidence matters. PRGuard is a tool you build with: it gathers that evidence for you as you work.

Which systems are high-risk

A system is high-risk when it is a safety component of a product, or is itself a product, covered by the laws in Annex I and needing a third-party assessment under them, or when it is used for a purpose Annex III lists (Article 6). Since the amendment, a system used solely for non-safety aspects such as user assistance, efficiency, convenience or quality control is not a safety component unless its failure would endanger health and safety (Article 6(1a) and (1b)). A product assessed by a third party only for risks other than health and safety, such as radio interference, does not meet that condition (Article 6(1c)).

Annex III includes AI that evaluates the creditworthiness of people or sets their credit score. AI used to detect financial fraud is excepted. An Annex III system can fall outside the rules where it does not pose a significant risk of harm (Article 6(3)); whether yours does is a judgement for you and your advisers. A system that profiles people is always high-risk, whatever risk it poses (Article 6(3), last subparagraph), and one that scores a person’s credit ordinarily profiles them.

When they apply

From 2 December 2027 for a system listed in Annex III, and from 2 August 2028 for one in a product covered by Annex I (Article 113, as amended).

Regulation (EU) 2026/1744, in force since 27 July 2026, set those dates. They had been 2 August 2026 and 2 August 2027. A quarter of evidence takes a quarter to gather, so the time to start keeping it is before the date.

Article by article

Four Articles. What Each Asks.

The articles Readiness tracks for the Act: what each asks, and how PRGuard helps you show it.

Article 9

Risk management system

Covers the code
The video’s words

Article 9 asks for risk management across a high-risk system's whole life. Code is where many risks first appear, and that is where PRGuard keeps watch.

Halcyon's rules for changing its risk model are a rule file, mapped to Article 9.

Every change to the risk engine is audited against those rules. Each finding is fixed, or kept on the record.

And a risk the business chooses to accept becomes an exception, with a reason, an approver who did not ask for it, and an end date.

When the end date passes, the finding opens again, so no accepted risk is quietly forgotten.

Your risk assessment covers the system. PRGuard adds the evidence from its code: every risk found, fixed or accepted, with a name and a date.

What the Act asks

A provider keeps a risk management system for a high-risk system: a continuous process, planned and run across its whole life, that identifies and analyses the risks it can pose, estimates and evaluates them, and adopts measures to address them, with regular review.

How PRGuard helps

Code is where many risks first appear, and that is where PRGuard keeps watch.

Each change to the system’s repositories is audited against your rules, and each finding is fixed or kept on the record. A risk your business chooses to accept becomes an exception, with a reason, an approver who is not the person who asked, and an end date. When the date passes, a finding closed under it opens again, so no accepted risk is quietly forgotten.

Map the rule file that holds your risk rules for the system to Article 9, and Readiness shows the audits that ran with it.

Where you see itCoverageExceptionsReadiness

What stays with you

The risk assessment of the system as a whole: its intended purpose, how it could be misused, and what monitoring it in use shows. PRGuard feeds it with the evidence from the code: every risk found, fixed or accepted, with a name and a date.

Article 11

Technical documentation

Covers the code
The video’s words

Article 11 asks a provider to document a high-risk system before it ships, and keep it up to date. Among other things, that documentation describes the changes made to the system through its life.

Halcyon's procedures for changing the risk engine's code are a rule file, mapped to Article 11. Readiness shows the audits that ran with it.

Every change that reached the risk engine's main branch is on the record: when it merged, who or what wrote it, and how it was audited.

Open one, and you see who approved it, and what became of each finding.

A change that got no audit is there too, with the reason.

The rest of the documentation is yours: the system's design, its data, its testing. PRGuard keeps the record of how its code changed, as it changes.

What the Act asks

A provider draws up technical documentation for a high-risk system before it is placed on the market or put into service, and keeps it up to date. Annex IV sets out what it holds: among other things, how the system was developed, its risk management system, and a description of the relevant changes made by the provider to the system through its life. A small or medium-sized enterprise, a start-up included, or a small mid-cap may give those elements in a simplified form, which the Commission is to set out.

How PRGuard helps

Annex IV asks the documentation to describe the changes made to the system through its life. PRGuard keeps that record for the code as the changes happen.

Each change that reached a default branch of the system’s repositories is on it: when it merged, who or what wrote it and who approved it, how it was audited, and what became of each finding. A change that got no audit is there too, with the reason.

Map the rule file that holds your procedures for the system’s code to Article 11, and Readiness shows the audits that ran with it. When the quarter ends, the evidence pack carries the record.

Where you see itCoverageReadinessPacks

What stays with you

The rest of the technical documentation: the system’s purpose and design, its data, how it was tested and how it performs; and the event logs, which are built into the running system. PRGuard keeps the record of the changes to its code, which that documentation describes.

Article 14

Human oversight

Evidence alongside
The video’s words

Article 14 asks that people can oversee a high-risk system while it runs. Assessors also ask who was in control while it was being built. PRGuard answers that.

PRGuard records who or what wrote every change: a person, an assistant, an agent, a bot or other automation, classified from what can be seen.

When an agent writes a change, you see which people approved it before it merged.

As AI writes more of your code, PRGuard shows who wrote each change and which people let it through. Human oversight of the build, on the record.

What the Act asks

A high-risk system must be designed and developed so that people can oversee it effectively while it is in use: understand what it can and cannot do, notice when it goes wrong, interpret its output, and decide not to use it, override it or stop it.

How PRGuard helps

Assessors also ask who was in control while the system was being built. PRGuard answers that.

It records who or what wrote every change, classified from observable signals: a person, a person with an assistant, an agent, or a bot or other automation. And it records which people approved each change before it merged. As AI writes more of your code, that is human oversight of the build, on the record.

Where you see itAI registerCoverage

What stays with you

Oversight of the running system, the ability to understand its output and to override or stop it, which is designed into the system itself. PRGuard covers the people behind how it was built.

Article 17

Quality management system

Strongest fit
The video’s words

Article 17 asks every provider of a high-risk AI system for a quality management system, and for something that shows it is followed. PRGuard builds that record as you ship.

Halcyon's change procedures live in a rule file, mapped to Article 17. Readiness shows every audit that ran with it.

Every change to the risk engine is on the record: the rules it was checked against, what was found, whether it was fixed, and who approved it.

Even a change that slipped past the audit is accounted for, with the reason.

And when the quarter ends, it is one evidence pack your assessor can verify on their own machine.

PRGuard Assurance turns every change into evidence for Article 17, kept for you as you ship. Your assessor gets a record, not a reconstruction.

What the Act asks

A provider puts a quality management system in place, documented as written policies, procedures and instructions. Among other things it covers how the system is designed and how its design is controlled and verified, how it is developed and its quality controlled, how it is examined, tested and validated, and how changes to it are managed. How far it goes is proportionate to the provider’s size, an SME, a start-up or a small mid-cap in particular, though never below the rigour the requirements call for (Article 17(2), as amended).

How PRGuard helps

This is where PRGuard fits best. Your rule files are your written procedures for how the system’s code is checked; map them to Article 17.

From then on each change to the system’s repositories is on the record: the rules it was checked against, what the audit found, whether it was fixed, and who approved it. Even a change that slipped past the audit is accounted for, with the reason. When the quarter ends, an owner can sign it off and the record becomes one evidence pack your assessor verifies on their own machine. A record, not a reconstruction.

Where you see itCoverageReadinessPacks

What stays with you

The parts of a quality management system beyond the code, such as data management, monitoring after release and who is accountable for what. PRGuard covers the code changes, every day, as you ship.

In PRGuard

Set It Up in Five Steps.

  1. On the Assurance Settings tab, tick EU AI Act.

  2. In the scope grid, put in scope the repositories that hold the high-risk system, and give every other repository its reason for being left out.

  3. Map your rule files to the articles they support: your change procedures to Article 17, your risk rules to Article 9.

  4. Readiness for the EU AI Act then shows, over the repositories in scope, which articles have a rule that audits ran with.

  5. When a quarter ends, an owner can sign it off, and an evidence pack carries the record.

The guide to Assurance, part by part

Scope

Evidence Your Assessor Can Use.

PRGuard gives you evidence that your process for changing the system’s code was followed, gathered as you ship and ready to hand over. Whether the system conforms to the Act, which articles apply to you and whether what you have is enough are judgements for you, your advisers and whoever assesses you; PRGuard does not make that call for you. This page explains what PRGuard records. It is not legal advice.

The law’s own text

Each article links to its page on the European Commission’s AI Act Service Desk, which shows the text as amended. The texts published in the Official Journal are on EUR-Lex. This page was checked against the amended text on 19 October 2026.

Keep the Record as You Ship.

Switch Assurance on and the last 90 days are read for you.

Start the $10 trial