Did Your Pager Miss the AI Act's First Deadline?

The first reporting window under Article 73 of the EU AI Act closed this week. High-risk obligations started applying on 2 August 2026, 24 months after the regulation entered into force. Providers must report a serious incident to market-surveillance authorities without undue delay: 15 days after awareness as the outer bound, and as little as 2 days for death, serious harm, or critical infrastructure. Fifteen days from 2 August lands around 17 August. If you have not already asked whether anything in production should have been reported, the clock did not wait for a legal review.

This is not a policy memo. It is an on-call problem. Article 72 requires post-market monitoring. Article 73 requires you to notice a class of failure, classify it as serious, and produce evidence on a deadline. Most coverage of the 2 August go-live talked about DPIAs, model cards, and risk registers. Those documents do not page anyone at 02:00. Latency, error-rate, and uptime dashboards were never designed to see harm to health, safety, fundamental rights, or critical infrastructure. A green service can still be in a reportable serious incident.

The miss is detection, not documentation

We already argued, in When the AI Budget Runs Out, Is Your Service Down?, that a system can stay technically available while a critical capability silently fails. The same pattern now has a reporting SLA attached. A classifier that routes a high-risk case to the wrong queue can return HTTP 200. A scoring model that systematically denies a protected group can stay inside its latency SLO. A control-loop model that misreads a safety interlock can look healthy because the API never threw. Nobody gets paged because the failure does not look like a 5xx.

That is the operational miss. If your stack cannot map production signals to the Act's incident definition, you do not have 15 days. You have an unknown clock and no evidence trail. Awareness starts the reporting SLA. If monitoring never surfaces the event, awareness never starts. That is not a defense you want to test after a market-surveillance inquiry.

In Can Your Pager See an AI Referral?, we made the same point about a new class of traffic that never trips existing alerts. Article 73 is that gap with a harder consequence: the event may be reportable while Grafana is green.

What a reportable incident looks like in production

Do not wait for counsel to invent the signals. Translate the Act into things an on-call engineer can actually see.

Serious, here, is not "P1 because the CEO is angry." It is an event that leads to, or could reasonably lead to, death or serious damage to health, a serious and irreversible disruption of critical infrastructure, or a serious infringement of fundamental rights. Your uptime chart does not encode any of those.

Map the systems you actually run:

• A clinical-decision model that starts recommending the wrong pathway while remaining fast and available
• An identity, hiring, or credit model whose error rates jump for a specific demographic, region, or document type
• A safety classifier on industrial or energy operations that suppresses alarms, mislabels a fault, or fails open
• An access-control system that locks people out of essential services at scale
• An agent that takes a privileged action without the intended human gate

None of those need a 500. They need outcome signals: decision-distribution drift, human-override spikes, safety-interlock disagreements, complaint clusters, downstream tickets that mention the model, and volume of "the model said no" that does not match the baseline. A page that only watches p95 latency will miss all of this. You want something closer to:

- alert: AIDecisionDriftNeedsClassification
  expr: |
    (
      abs(ai_decision_deny_ratio - ai_decision_deny_ratio_7d)
      / clamp_min(ai_decision_deny_ratio_7d, 0.01)
    ) > 0.25
    and increase(ai_human_override_total[1h]) > 10
  labels:
    severity: page
    incident_class: review_for_article_73

That is not a legal determination. It is a signal that a human with authority has to classify, on a clock. If those signals do not exist, you cannot classify. If they exist but have no owner, you cannot start the clock. If they have an owner but no evidence pack, you will burn the window assembling logs that were never retained.

Who owns the page, who owns "serious"

Assign three roles before the next shift.

Detection owner. On-call for the product that serves the model. Fire when outcome signals move, not only when error rate moves. If the only page is p95 over 800ms, you are not covering Article 73.

Classification owner. A named incident commander plus the product safety lead, reachable on a 30-minute join, with authority to call an event serious under your written definition. Do not leave this to whoever acked Slack. Classification is a decision with a timestamp. That timestamp is when awareness starts.

Evidence owner. The person who can attach a frozen artifact pack: model version, prompt or policy config, lawful samples, decision IDs, override logs, who was paged, and what containment ran. If that pack lives in five SaaS tools with 7-day retention, you will miss the window even if you noticed on time.

Write the runbook as you would for a SEV-1. Trigger, join, classify within a fixed number of minutes, contain, then report if the classification is serious. The report path is to the market-surveillance authority of the Member State where the incident occurred. If that contact list sits in a lawyer's inbox and not in PagerDuty, it is not a runbook.

The check for this week

Do this before the next on-call rotation.

1. List every AI system in production that can affect health, safety, essential services, employment or credit decisions, biometric processing, or infrastructure controls. If you cannot produce that list from inventory in an hour, that is the first gap.
2. For each system, name the page that would fire if the model were wrong while the API was up. If the answer is none, you have a silent-failure path.
3. Name the human who can classify serious at 02:00, and the backup. Put both in the escalation policy.
4. Assemble a dry-run evidence pack. Pretend today is T+2 hours after awareness. Can you attach the time of the first anomalous decision (not the first 5xx), model and config versions, the affected population or system, containment actions with timestamps, and why you did or did not treat it as serious?
5. Time the dry run. If gathering that pack takes more than a day, you do not have a 2-day capability. If classifying serious has no owner, you do not have a 15-day capability either.

Boards and CISOs are asking this week whether anything since go-live should have been reported. If the answer is that dashboards were green, you have not answered it.

Tink is built to make server and workflow failures visible in plain language, with an audit trail of what was seen, who was asked, and which action was approved. Keep that evidence next to the page, not in a folder you reconstruct after the deadline.

If you cannot say which AI failures page someone, who classifies serious, and what you would attach to a 2-day or 15-day report, the first window already closed without you. The next 2-day clock can start on this shift. Put the signals in the pager, put a name on classification, and keep the evidence where the incident actually lives.