Use case
From a deployer's call to the notification under Article 73: a workflow for reporting serious incidents involving high-risk AI under the EU AI Act.
A software company with 120 employees makes software for pre-selecting job applications; its customers are the HR departments of 60 companies. Friday, 14:30: the head of HR at one customer calls. While double-checking, her team has noticed that for three weeks the system has been ranking applications from people with gaps in their CVs at the bottom almost without exception, among them a striking number of women returning from parental leave. From this call, the clock of the AI Act is running: fifteen days at most, only two in the case of a widespread infringement, and the same model version is running at 59 other customers. What you buy from us is the software your quality manager uses to work through an incident like this. Legal advice and the notification stay with you.
Duty
What the law requires
The reporting duty applies only to high-risk AI systems, and most of the workflows we build are not high-risk: product texts, data cleansing, sorting enquiries. But anyone who selects applicants, assesses performance, checks creditworthiness, controls critical infrastructure or builds safety components for machinery needs the reporting chain.
| Legal basis | The EU AI Act, Regulation (EU) 2024/1689, Article 73; information of the provider, importer or distributor and the market surveillance authority by the deployer, Article 26(5) |
|---|---|
| Who is affected | Providers of high-risk AI systems, meaning whoever develops such a system and places it on the market under its own name. Deployers that use the system inform the provider. |
| Trigger | A serious incident: death or harm to health, disruption of critical infrastructure, infringement of obligations intended to protect fundamental rights, serious harm to property or the environment, caused by the system or with a reasonable likelihood of having been caused by it |
| Deadlines | Immediately after a causal link, or the reasonable likelihood of one, has been established, and no later than 15 days after becoming aware; no later than 2 days in the case of a widespread infringement or a disruption of critical infrastructure; no later than 10 days in the event of a person's death. An incomplete initial report, followed up with further information, is permitted. |
| Recipient | The market surveillance authority of the member state in which the incident occurred |
| Timetable | Following the Digital Omnibus (Regulation (EU) 2026/1744, in force since 27 July 2026), from 2 December 2027 for stand-alone high-risk systems under Annex III, from 2 August 2028 for systems in products under Annex I |
| Fine | Up to €15 million or 3 percent of annual turnover for infringements of provider and deployer obligations (Article 99(4)) |
| Legal position as of | October 2026. We build the workflow; the legal assessment of whether a system is high-risk and whether an incident must be reported stays with your legal department or law firm. |
Clock
The workflow, day by day
The clock starts when you become aware, but the notification is due as soon as the link has been established. So the investigation cannot simply take as long as it happens to take.
- Minute 0
The report arrives, whoever it comes from
A report from a deployer, an alert from your own monitoring, a complaint from an affected person or an enquiry from an authority: every incoming report becomes a case. The workflow records when it came in and which deployer and which model version are affected.
- Hour 1
What happened, from the logs
High-risk systems record their operation automatically under Article 12. From these records, the workflow extracts the affected decisions and shows since when, and at which deployers, the same pattern has occurred. That way a first reconstruction is ready on Friday afternoon.
- Hour 2
Classification with a proposal and reasons
The workflow proposes a classification: whether a causal link has been established or is reasonably likely, how serious the incident is and which of the three deadlines applies. Your quality manager confirms or changes it. As long as it is unclear whether there is a widespread infringement, the clock works with the shortest deadline.
- by day 2
Warning deployers, preparing the initial report
All deployers of the same model version receive a first message with an immediate measure they can take themselves, such as suspending the function. In parallel, the draft initial report is produced. If the two-day deadline applies, it goes out now after approval, even if the cause has not yet been established.
- by day 10
Notification in the event of a death
If a death is connected with the system, the ten-day deadline applies. The clock escalates to management if nobody approves in time.
- by day 15
The notification, at the latest here
In all other cases, day 15 is the outer limit. The workflow writes the notification from the case: system, version, what happened, affected deployers and persons, initial assessment, measures taken. Whatever is missing is marked as open: an incomplete initial report is permitted, waiting for the complete one is not.
- afterwards
Further information, corrective action, lessons
The cause and the corrective action are submitted as soon as they have been established. The lessons go into your quality management: changed thresholds, new test cases in the reference set, revised instructions for use.
Cascade
Who learns what has happened, and when
The AI Act has two roles, and the chain runs through both: deployers inform the provider and the authority, the provider files the report under Article 73. If a deployer cannot reach the provider, Article 73 applies to the deployer itself. Each wave going out has a draft, a person who approves it and a point in time in the log; the internal alert goes out immediately.
| Wave | Recipient | Channel | Content | Approval |
|---|---|---|---|---|
| 1, in the first hour | The provider's management, quality manager, legal department, development | Teams or Slack, a call if there is no response | The report, affected version, first reconstruction, deadline running | None, internal alert according to a fixed list |
| 2, by day 2 | All deployers of the same model version, starting with those with the most decisions in the affected period | Email to those responsible for human oversight, a call to large deployers | What is known, which version, which immediate measure | Quality manager and management |
| 3, within the deadline | Market surveillance authority of the member state in which the incident occurred; for products under Annex I also the notified body, if your conformity assessment provides for this | The authority's reporting channel, prepared from the case | Initial report with everything that has been established, open points marked as open | Management |
| 4, by agreement | Affected persons, such as rejected applicants, via the respective deployer | Template for the deployer, who is in contact with the persons | What happened, what the deployer is doing now, such as a fresh review by people | Deployer, coordinated with your legal department |
| 5, with the corrective action | All deployers, the authority as further information | Email, customer portal, supplement to the notification | Corrective action: rolling the model back to the previous version, changing thresholds or switching it off, with its effect and the check | Development, quality manager and management |
The workflow knows from your version control which version is running at which deployer. If a deployer has not confirmed by Monday morning, your customer service calls them.
Approval
What stays with your people
- The classification. Whether there is a link, how serious the incident is and which deadline applies is decided by your quality manager, in case of doubt with the legal department. The workflow presents the reasons.
- Every notification to the authority. No draft goes out without approval.
- Every message to deployers. Wording, group of recipients and immediate measure are confirmed before sending.
- The corrective action. Rolling back to the previous version, changing thresholds or switching off is decided by your development team together with management.
- Human oversight. Article 14 requires people to monitor a high-risk system and to be able to intervene. We plan this in from the start: who sees which deviation and who holds the stop switch.
Integration
Which systems the workflow sits in
The reporting chain is part of the provider's quality management. It reads from the systems you have and writes back to them.
- IncomingSupport inbox, hotline, customer portal, alerts from your own monitoring
- LogsThe system's automatic records, monitoring metrics, reference set
- VersionsModel registry or version control showing which deployer uses which version
- CaseJira, ServiceNow or your development team's ticketing system, plus your quality management documents
- CustomersCRM such as Salesforce or HubSpot with the deployers' contacts
- AuthorityThe market surveillance authority's reporting channel. Authority portals rarely have an interface: the workflow pre-fills the notification, a person enters it, and the timestamp goes into the log.
Evidence
The log is the evidence
When the authority asks when you became aware, when the link was established and when you reported, the answer is an export. Every step is in the case with a timestamp: receipt, reconstruction, classification with reasons and name, information to deployers, initial report, further information, corrective action.
Reports that turned out not to be a serious incident also stay in the case with their reasons, so every check is documented. Auditors and deployers who ask about your quality management receive the same export.
Twice a year a made-up incident runs through without anything going out; it shows whether the mapping of versions to deployers is right.
Experience
What we bring
In our own operations, workflows check our customers' systems every night and report only the deviation, with where it was found and a log. At a spare parts dealer, every new version goes live in waves, with quality checks, a stop switch and a bit-for-bit rollback to the previous version: exactly this return is the corrective action a reporting chain needs. Matching incoming items at scale is something we know from a technology distributor with twelve sites, where enquiries from twelve sites across Europe reach the right team according to rules.
We put the chain through to the market surveillance authority into operation with your development team and your quality management. For acceptance, a made-up incident runs through: it must show that the workflow uses your system's records to find every deployer with the affected model version, and that the initial report is ready and approved within two days. You see an example log in the first call.
Price
Price and scope
The order of magnitude first: the workflow analysis costs €4,900 at a fixed price and takes three days. Based on our projects, a custom tool typically costs between €25,000 and €60,000, as a fixed price that becomes binding after the analysis; the first version is ready in about six weeks, longer with several duties and languages. Ongoing operation after that starts at €2,900 a month and can be cancelled monthly. More precision in advance would be guesswork, because five deployers and two hundred in four countries do not need the same tool. What determines the price:
- whether your system's logs can already be evaluated or first have to be structured
- number of deployers, model versions and member states
- number of incoming channels and languages
- whether the workflow covers only Article 73 or also the data breach that often comes with it when personnel data is involved
Data flow: incident data, logs and personal data stay on your server or in a German data centre. The AI components run on open models on your own servers or via EU data centres. Data flow per service.
Related
Related use cases
- Medical devices: reporting a serious incident. The same staggered deadlines of two, ten and fifteen days, and anyone who uses AI in a medical device has both duties.
- Cyber Resilience Act: reporting a vulnerability. If an attack has manipulated the system, a second clock is running.
- Whistleblower protection: the internal reporting office. The first hint that a system is behaving oddly often comes from within your own ranks.
- All use cases: reporting duties with deadlines, with the table of deadlines across all duties.
Further reading: The EU AI Act for mid-sized companies: which obligations arise for which workflows and Monitoring and maintaining an AI workflow.
Questions
Questions about the reporting chain under the AI Act
What providers and deployers of high-risk systems ask before they set up a reporting chain. More answers under Questions and answers.
Our AI workflows write product texts and sort enquiries. Do we need this?
As a rule, no. Workflows like these carry minimal risk, and the reporting duty under Article 73 applies only to high-risk systems. It concerns areas such as selecting applicants, credit checks and safety components of machinery. Whether your system is one of them is for your legal advisers to clarify.
The obligations only apply from December 2027. Why build now?
Because the reporting chain builds on data that a system has to supply from the start: logs, versions per deployer, contacts for human oversight. Anyone building or running a high-risk system today should build the chain along with it.
We only use a high-risk system. What do we have to do as a deployer?
You inform the provider as well as the importer or distributor and the market surveillance authority without undue delay when you identify a serious incident; if you cannot reach the provider, you report under Article 73 yourself. For this we build the incoming part: collecting reports, recording what happened, informing the provider with a timestamp and following up.
Who is there at night and at the weekend, and who is liable for what?
If the report comes in on Friday afternoon, the workflow opens the case, works with the shortest deadline as a precaution and calls the people on your on-call list until someone confirms. As part of ongoing operation we monitor that the workflow is running, with response times on working days; round-the-clock standby is agreed separately. If it fails, the on-call list, templates and the mapping of versions to deployers are ready as an export so that your team can carry on by hand. Your company remains responsible as the provider for the notification; we are liable for the tool under our terms and conditions.
Handover
The first step is a 30-minute call.
You tell us about the workflow that costs you the most time. We tell you honestly whether AI pays off there and what the next step would be. Whether a workflow analysis follows is up to you.