What AI incident response must cover under the EU AI Act
Providers of high-risk AI systems must report serious incidents to market surveillance authorities within 15 days of becoming aware of them, with a shorter two-day deadline for a widespread infringement or a serious and irreversible disruption of critical infrastructure and a 10-day deadline when a death is involved. Deployers have a different job: they must monitor the system in use, suspend it when it presents a risk, and inform the provider and the authority, reporting serious incidents to the provider first. If a compliance lead has been asked for an AI incident process, the first question is which of those roles the organization holds for each system, because that answer sets the clock, the recipient and the paperwork. The organization owns its incident duties. Its legal and compliance function decides what counts as a serious incident, who signs the report, and when a system is suspended. An implementation partner such as DeployOpen can prepare the operating pieces inside your own environment: the incident intake and triage workflow, the logging that lets you reconstruct what the system did, the report templates, and the evidence trail that shows each deadline was tracked. Only the market surveillance authorities, the AI Office where it applies, and independent auditors or notified bodies act as reviewers, and none of them accept a partner's word in place of your records. The risk category and the system's supervising authority change the detail. A high-risk system supervised by the AI Office under Article 75(1) reports to the AI Office, and providers of general-purpose AI models with systemic risk follow a separate route under Article 55. Before building the process, confirm with counsel which Annex category each system falls under, whether your organization is a provider, deployer or both, and whether the draft guidance and reporting template the Commission published for consultation on 26 September 2025 has been finalized. Map those answers to a single system inventory first, because a process designed for one role will miss the duties of the other.
How a provider's reporting clock works after an AI incident
This sequence shows the order in which a provider of a high-risk AI system moves from becoming aware of a serious incident to reporting it, investigating it and correcting the system. Each step has a defined output that a regulator or assessor can check.
Establish awareness and the causal link
The provider's incident owner records when the organization first became aware of an event that may be a serious incident under Article 3(49), which covers death or serious harm to health, serious and irreversible disruption of critical infrastructure, infringement of Union law protecting fundamental rights, and serious harm to property or the environment. The reporting clock under Article 73 starts once the provider has established a causal link between the system and the event, or once that link is reasonably likely. The output is a dated incident record stating the awareness date, the facts known at that point, and the reasoning behind the causal-link decision. Ask counsel and the quality function to review the record, so the decision can be defended later.
Select the applicable reporting deadline
The provider classifies the incident against the deadlines in Article 73(3) and (4) and the general deadline in Article 73(2). The general deadline is 15 days after awareness. The deadline is shorter for a widespread infringement or a serious and irreversible disruption of critical infrastructure, and for a death the deadline is 10 days. The output is a documented deadline decision, with the date by which the initial report must reach the market surveillance authority. Where the AI system is supervised by the AI Office under Article 75(1), the report goes to the AI Office under Article 75(1a) instead, so the authority must be confirmed at this step.
Submit the initial report to the authority
The provider sends the initial report to the competent market surveillance authority, or to the AI Office where that route applies, by the selected deadline. The report should state the system, the event, the known harm, the causal link or the reasonable likelihood of one, and the immediate containment steps taken. Facts that are not yet known should be marked as open. The output is a submitted report with the date of transmission and a reference from the authority, kept in the incident file. Confirm the submission channel and template with the authority, since the Commission consulted on a draft reporting template in 2025.
Complete the incomplete initial report
Article 73(5) allows the provider to file an incomplete initial report and then submit a complete one. The provider tracks the open items from the initial report, such as root cause, affected population and harm extent, and files the complete report once they are established. The output is a complete report that updates each open item, with a cross-reference to the initial report and a note on any items that remain unknown and why. Keep a log of each supplementary submission, since the authority will compare the two reports against each other.
Investigate causes and assess the risk
Under Article 73(6), the provider investigates the incident, assesses the risk the system presents and identifies the causes. The investigation covers the system's logs, its data inputs, its performance against the intended purpose, and the deployer's use of it, where relevant. The output is a written investigation report with a root-cause conclusion, a risk assessment, and a list of affected users, deployers and downstream parties. Ask the investigation team to record which evidence was preserved and when, so the causal analysis can be reproduced by an assessor.
Preserve the system state before changes
Article 73(6) prohibits the provider from altering the system in a way that could affect the evaluation of the causes before the authorities are informed. Before any fix, the provider captures a forensic copy of model versions, configuration, training and validation records, and relevant logs, and records the hash or version identifiers. The output is a preservation record listing each artifact, its identifier and the time of capture. Where a containment step is necessary to prevent further harm, the provider should document the change, the reason and the authority notified, and confirm that the change does not distort the causal analysis.
Take corrective action and inform parties
If the provider considers, or has reason to consider, that the high-risk system does not conform, Article 20(1) requires it to bring the system into conformity immediately, or to withdraw, disable or recall it. Where the system presents a risk under Article 79(1), Article 20(2) adds duties to investigate immediately with the reporting deployer and to inform the market surveillance authorities and any notified body that issued a certificate. The provider must also inform distributors, importers, the authorised representative and deployers where applicable. The output is a corrective action record listing each measure, its owner, the parties notified and the verification that the fix works. Confirm with counsel which notices are required for each market.
Close the incident file
Once the corrective measures are verified and the authority has the complete information, the provider closes the incident. The closure file links the awareness record, the deadline decision, both reports, the investigation, the preservation record, the corrective action record and the notifications sent. The output is a signed closure memo that can be produced to an authority or independent assessor on request. Schedule a review of the file against the quality management system so that lessons feed back into risk management and post-market monitoring.
Provider duties versus deployer duties after an incident
A provider of a high-risk AI system carries the heaviest post-incident duties under the AI Act. When the provider considers, or has reason to consider, that a system does not conform to the Act, Article 20(1) requires it to act immediately: bring the system into conformity, or withdraw, disable or recall it. The provider must also inform its distributors and, where applicable, deployers, the authorised representative and importers. Where the system presents a risk within the meaning of Article 79(1), Article 20(2) adds an obligation to investigate the causes immediately, with the reporting deployer where applicable, and to inform the competent market surveillance authorities and any notified body that issued a certificate.
- Immediate conformity action: Document the decision to fix, withdraw, disable or recall, with the time it was taken and the reasoning.
- Downstream notice: Keep a current contact list of distributors, importers, deployers and the authorised representative so notices can go out without delay.
- Risk investigation: Run the Article 20(2) investigation with the deployer, and record root cause analysis separately from the fix.
- Authority and notified body notice: Confirm which authority and which notified body apply to each system before an incident, since the notice must reach them.
- Serious incident reporting: Use the Article 73 route for serious incidents, which the Article 73 topic covers in detail.
Check that your playbook names an owner for each of these notices and that the owner can reach every party within the same working day.
A deployer that uses a high-risk system under its own authority has a separate set of duties, and these apply even when the provider's product is the root cause. Article 26(5) requires the deployer to monitor the system in operation, suspend its use where it presents a risk, and inform the provider and the relevant authority. If the deployer identifies a serious incident, it must report it to the provider first. Article 26(4) adds a duty for deployers that control input data: they must ensure that the data is relevant and sufficiently representative for the system's intended purpose. Input data problems are a common root cause, so the deployer's logs and data checks often hold the first evidence.
- Monitoring in operation: Define the signals the deployer watches, such as output anomalies, complaints and error rates, and who reviews them.
- Suspension authority: Name who can switch the system off or stop a workflow, and how fast that decision can be taken outside office hours.
- Provider first, then authority: Build the report to the provider as the first outbound notice, with the timestamps the provider will need.
- Input data controls: Record how the deployer checks relevance and representativeness of the data it feeds into the system.
- Retained logs: Keep the operating logs the deployer controls so that the provider can investigate.
Confirm with your legal team how the deployer's contract with the provider allocates notice, cooperation and log access, because the contract decides what the provider can obtain from you.
Most incidents involve both parties, so the handoffs matter as much as the individual duties. The deployer detects a problem and suspends use, the provider investigates and decides on corrective action, and both must keep a consistent account of the timeline. The Act places these duties on each organization separately, so neither party can rely on the other to notify the authority. Each party should be able to show what it knew, when it knew it and what it did with that knowledge.
- Single incident timeline: Keep one shared record of detection, notices sent, and decisions, with timestamps in one time zone.
- Contract handoff terms: Agree on the contact path, the format of the first report and the working hours for responses before an incident happens.
- Avoid changing evidence: Ask the provider before any change to the system that could affect the investigation of causes.
- Separate roles: Assign a deployer lead and a provider lead who own their own notices and are not waiting on each other.
- Exercise the path: Test the notice chain in a tabletop exercise so the first real incident does not reveal missing contacts.
Before relying on this split, confirm each party's role under the Act with counsel, because a deployer that modifies a system can take on provider duties.
The duties above belong to the organization that holds the role, not to any consultant. The provider or deployer owns its controls, decides whether a serious incident has occurred, and signs and sends each notice. An implementation partner such as DeployOpen can help prepare the playbooks, notice templates, logs and evidence folders that the organization uses. Only the competent authorities and the notified bodies act on the reports they receive, and an independent auditor or certification body issues any formal assessment result. The organization should not expect outside help to decide what counts as a serious incident on its behalf.
- Owned by the organization: Incident decisions, notices, corrective actions and regulatory contact.
- Prepared with a partner: Playbooks, role cards, notice templates, log retention settings and tabletop material, as agreed in a written scope.
- Confirmed with counsel: Role classification, contract terms and whether a notice is required in a given case.
- Checked by an assessor: Whether the process works in practice, which only an independent assessor can state.
- Revisited regularly: Update the playbook after each exercise, incident or change to the system.
Ask any partner to state in writing which parts of the playbook it prepares and which parts your own staff must run.
Systemic-risk model incidents and the AI Office route
Providers of general-purpose AI models carry their own incident duty under Article 55(1)(c) and (d). They must track, document and report serious incidents and corrective measures to the AI Office without undue delay. That duty sits alongside the system-level rules in Article 73, so a provider that builds a model and also ships a product on it needs both. The incident log should therefore record, for each event, whether it concerns the model, a downstream system, or both, and which reporting route applies. Article 55(1)(d) adds a separate requirement to ensure adequate cybersecurity for the model and its physical infrastructure, which means the incident process must cover security events against model weights, training and serving environments as well as output harms. Confirm with your legal team how the general-purpose model obligations apply to your organization's specific model and any open-source exemptions, since these depend on the model's characteristics.
For high-risk systems, the AI Office route depends on who supervises the system. Since the 2026 amendment, Article 75(1a) requires providers of high-risk systems that the AI Office supervises to report serious incidents to the AI Office. Under Article 75(1), as amended in 2026, the AI Office is exclusively competent for AI systems built on a provider's own general-purpose model and for AI in very large online platforms and search engines. That exclusivity matters for routing: an organization that builds a high-risk system on its own general-purpose model should not assume its national market surveillance authority is the only recipient. Map each system in your inventory to its competent authority before the first incident, and record the answer in the incident runbook so the on-call team does not have to decide it under time pressure.
National market surveillance authorities handle every other AI system. For systems outside the AI Office's exclusive competence, the reporting path under Article 73 runs to the national authority in each relevant Member State. Confirm with counsel which authorities apply to each deployment, particularly where a system is offered across several Member States. Keep the AI Office and national contacts, and the form each one accepts, in the same controlled document as the reporting deadlines, and rehearse at least one cross-border scenario in a tabletop exercise so the routing decision is tested before a real event.
What the incident process must be able to produce
Each card names an evidence artifact that an assessor or market surveillance authority can ask for after an AI incident. Together they show whether the process can classify an event, protect the system's state, meet reporting clocks and close the loop with corrective action. The organization owns these records; an implementation partner can build the workflow, but only the regulator or an independent assessor judges whether it is adequate.
Incident intake and classification record
Every reported event, including near misses and malfunctions raised by users or monitoring, needs a dated intake entry with the affected system, the reporter and the first facts known. The classification step decides whether the event meets the Article 3(49) definition of a serious incident, which covers death or serious harm to health, serious and irreversible disruption of critical infrastructure, infringement of Union law protecting fundamental rights, and serious harm to property or the environment. Check that the record shows who classified the event, when, and why the decision was reached, including decisions not to report.
Evidence preservation log
Before any fix changes the system, the team must capture logs, model versions, input data samples, configuration snapshots and prompts tied to the event. Article 73(6) expects providers to investigate without altering the system in a way that could affect the evaluation of causes before the authorities are informed. The preservation log should record hashes or immutable copies, who accessed them, and the retention period. Confirm with your legal team how long evidence must be kept under your own record-keeping obligations.
Reporting deadline tracker
A deadline register converts the awareness date into the clocks that apply to the event. Under Article 73, the general limit is 15 days after the provider becomes aware, with two days for a widespread infringement or serious and irreversible disruption of critical infrastructure, and 10 days where a death is involved. The tracker should record the awareness date, the category applied, the due date, and each submission, including any initial report later completed under Article 73(5). Treat the category decision as a recorded judgment that a reviewer can challenge.
Stakeholder notification records
The incident file needs a separate record for each party informed: the deployer and distributors under Article 20, the authorised representative and importers, the notified body that issued a certificate, and the market surveillance authority. Article 26(5) requires deployers to inform the provider first when they report a serious incident, so the provider's record should show when that report arrived. Each entry should name the recipient, the channel, the content sent and the time, so a reviewer can rebuild who knew what and when.
Corrective action register
Each corrective step, whether a fix, a withdrawal, a disablement or a recall, needs its own line with an owner, a status and a link to the incident that triggered it. Article 20(1) requires immediate action once a provider considers or has reason to consider a high-risk system non-conforming, and Article 20(2) requires an immediate investigation where the system presents a risk. The register should show when each action was verified as effective, so the file proves the problem was closed rather than only recorded.
Post-incident review record
After closure, a written review should state the root cause, whether the risk management system and post-market monitoring missed a signal, and which controls changed as a result. For general-purpose AI models, Article 55 also requires tracking and documenting serious incidents and corrective measures for the AI Office. Store the review with the risk assessment and technical documentation, so the same incident can be traced from detection through to the updated controls. Ask an independent assessor to confirm the review criteria before you rely on them.
Incident response questions buyers ask
Does a deployer have to report a serious AI incident directly to the market surveillance authority?
Not as a first step. Under Article 26(5), a deployer that identifies a risk must monitor the system, suspend its use, and inform the provider and the relevant authority, and it must report serious incidents to the provider first. The provider then carries the Article 73 reporting duty to the market surveillance authorities. Your deployer process should therefore make the provider notification fast and documented, and it should record when you suspended use. Confirm with your provider how they expect to receive deployer reports, and agree that contact route in the contract before go-live. Your own legal team should confirm how the authority route applies to your specific system and jurisdiction.
When does the 15-day reporting clock start for a serious incident?
The clock under Article 73(2) starts when the provider becomes aware of the serious incident, and the report is due no later than 15 days after that point. The reporting duty also applies immediately after the provider establishes a causal link between the system and the incident, or the reasonable likelihood of one. That means awareness, not final root-cause proof, is the trigger. Your incident intake should log the time a person first learned of the event, so the team can show when awareness occurred. Shorter deadlines apply for a widespread infringement or serious and irreversible disruption of critical infrastructure (two days) and for a death (10 days).
What should we do if we can only file an incomplete initial incident report?
File the initial report on time and mark it as incomplete. Article 73(5) allows a complete report to follow. Missing root-cause analysis or affected-user counts should not delay the first filing. The initial report should state what is known, what is being investigated, and when the next update will come. Keep a dated record of each gap and each follow-up. Under Article 73(6), the provider must also investigate, assess the risk and take corrective action, and must not alter the system in a way that could affect evaluation of the causes before informing the authorities. Build a change freeze or forensic snapshot step into your runbook so that investigation evidence is preserved while the report is still open.
Does a proof-of-concept exploit or a near miss count as a serious incident?
It depends on whether the event meets the Article 3(49) definition. A serious incident is an incident or malfunction that leads to death or serious harm to health, serious and irreversible disruption of critical infrastructure, infringement of Union law protecting fundamental rights, or serious harm to property or the environment. A proof-of-concept exploit in a test environment that causes no such harm generally falls outside that definition, but the internal record should still show the assessment. A near miss is judged the same way: the question is whether the malfunction led to the listed harms. Document each determination with the facts you relied on, and have counsel review borderline cases. Keep near misses in your internal log because they feed risk assessment and corrective action.
What should a readiness test for AI incident response include?
A useful readiness test runs a realistic tabletop or live drill against a named AI system and checks each step in the runbook. Include: detection and intake, classification against the Article 3(49) categories, the timestamp when awareness occurs, escalation to legal and the provider or deployer contacts, the suspend or disable decision, and the preservation of logs and model versions. Test whether the team can produce a first report within the shortest applicable deadline, and whether an incomplete report can be filed and updated. Record gaps, owners and retest dates. Ask your test provider to define the scenario, scoring criteria and output format in writing before the exercise starts.
What can an incident response partner do for us, and what must stay with our own staff?
A partner can prepare the systems and evidence that support your response. DeployOpen, for example, can help plan and document the process, build logging and monitoring for self-hosted AI platforms, run incident simulations, and test the response through security testing. Those services are scoped in writing before work starts. A partner cannot make the legal classification of a serious incident for you, cannot file reports on your behalf unless your contract and authorities allow it, and cannot issue an audit report or certification. Ownership of decisions to suspend, report and notify stays with your organization, and the independent auditor or certification body is the only party that issues reports or certificates. Confirm these split responsibilities in the statement of work.
What to confirm with counsel, the authority and your auditor
Start by confirming which regulator will receive your reports. Article 73 reporting goes to the market surveillance authorities, but the route changes if your system is supervised by the AI Office under Article 75(1), since providers of those high-risk systems report serious incidents to the AI Office under Article 75(1a). Ask counsel to document, in writing, whether your system falls under national supervision or AI Office supervision, and whether any system built on a provider's own general-purpose model changes that answer. Also confirm the status of the Commission's Article 73 guidance and incident report template before you build forms or fields around them. The draft guidance and template were published for consultation on 26 September 2025, and you should check the Commission's current publication status rather than assume the draft is final. Ask the authority for its intake channel, the format it accepts for initial and complete reports, and whether it expects a named contact for each system.
Next, map overlaps with other incident regimes. An AI system used in a bank, insurer, hospital or essential entity can trigger AI Act reporting alongside NIS2 or DORA reporting for the same event. Ask counsel and your sector regulator whether one incident can be reported once with a shared template, which clock starts first, and what each regulator expects in the initial notice. Confirm who in your organization is authorized to make those notifications, and whether your incident register can hold one incident record with several regulatory deadlines attached. Write these answers down before an incident occurs, because the shortest deadline in the Act, two days for a widespread infringement or a serious and irreversible disruption of critical infrastructure, will not wait for a legal review.
Finally, ask your auditor how the process will be tested. Confirm whether the auditor will sample past incidents, walk through a tabletop exercise, or review the investigation record for evidence that the system was not altered in a way that could affect the investigation of causes, as Article 73(6) requires. Ask which records they expect to see for deployer duties under Article 26(5), including suspension decisions and notices to the provider. Agree the evidence format in advance and confirm that the auditor is independent of the team that prepared your process. Note that DeployOpen can prepare the process, runbooks and evidence, but only an independent auditor or assessor issues the conclusion on it. Ask each party for its scope and deliverables in writing before work starts.
How DeployOpen prepares AI incident response evidence
DeployOpen plans, implements and documents the self-hosted open-source platforms that carry incident detection, triage, reporting and corrective-action workflows inside your own infrastructure. Your organization keeps ownership of its controls, reporting decisions and legal obligations, and an independent auditor or authority assesses the result.
How we scope
- Confirm which AI systems are provider or deployer responsibilities, and which fall under national authorities or the AI Office.
- Define the incident categories, reporting clocks and named owners that your written scope will cover.
- Agree deliverables, timelines and exclusions in writing before work starts, since most engagements are fixed-scope.
How we build
- Configure logging, monitoring and alerting for model inputs, outputs and performance so suspected incidents surface for triage.
- Build case-handling workflows that preserve system state and records before any change that could affect root-cause evaluation.
- Test the escalation path end to end, including suspension steps, provider notification and authority reporting drafts.
How we hand over
- Deliver an incident response runbook, reporting templates and a register of corrective actions mapped to your scoped systems.
- Document the configuration, data flows and access controls behind each evidence source so an assessor can trace them.
- Run a walkthrough with your security, legal and AI governance staff so they can operate the process without us.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers once the initial scope is delivered.
- Retainers can cover updates to runbooks and templates when guidance from the Commission or AI Office changes.
- Confirm with your counsel and assessor which decisions stay with your organization and which support can be delegated.
