Imagine an AI workflow flags an exception at 2:13 a.m. The system has done exactly what the governance plan asked: it has stopped and called for a human. There is only one problem. The person qualified to make the decision starts work at nine.
That gap matters in any operation that runs beyond office hours. A policy can assign an owner and draw a neat escalation line. At 2 a.m., neither helps if the only person who understands the call, or has permission to make it, is offline.
So availability belongs in the control itself. For a system that runs overnight, the practical questions are blunt: who’s covering, what can they decide, what do they need to see, and what happens if nobody picks up? The answer also has to survive a change of shift.
Regulation Has a Clock. Operations Have Several
The regulatory calendar gives the issue a timely edge. On August 2, 2026, the European Commission’s AI Office and national authorities began enforcing applicable provisions of the AI Act, and new transparency rules took effect.
That date shouldn’t be stretched into a claim that every high-risk AI obligation became enforceable at once. The Commission’s current schedule places rules for Annex III high-risk systems on December 2, 2027, with rules for high-risk AI embedded in regulated products following on August 2, 2028.
The narrower operational point is more useful anyway. Governance requirements are moving from policy work toward enforcement, while the systems being governed already run across nights, weekends and time zones. A control designed around a Monday-to-Friday org chart will eventually meet a Saturday-morning exception.
Many governance plans don’t describe that encounter. They specify who owns the system, who approves a use case and which committee reviews risk. Those are necessary decisions. They don’t tell the overnight operator whether the transaction should remain on hold for seven hours, whether an on-call analyst can release it or who accepts the risk if the queue keeps growing.
The policy has a name in a box. The operation needs a person on the clock.
A Human in the Loop Assumes a Roster
Unite.AI has already made the case that a real validation gate needs meaningful visibility and control. The reviewer needs to see the proposed action and why the system stopped. More importantly, the screen must let them do something useful: approve it, change it, reject it or shut the process down.
Coverage is the next design problem. A well-designed review screen can’t help when the only eligible reviewer is asleep, on leave or working in another region without a formal handoff.
This is where the phrase “human in the loop” becomes too vague. It can hide several different jobs. The workflow owner is accountable for how the process operates, while the on-shift reviewer interprets the exception and gathers missing context. A subject-matter specialist judges the domain risk. An approver has the authority to allow, change or stop the proposed action. When the exception signals a wider failure, an incident owner coordinates the response.
Combining roles isn’t automatically a problem. On a low-risk workflow, it may be the cleanest arrangement. But write it down. The analyst who understands a model’s output may still lack permission to release a large payment, override a safety limit or approve an action that affects customers.
The NIST AI Risk Management Framework is useful here because it treats governance as an operating structure. Its Govern function calls for clear roles, responsibilities and lines of communication, with appropriate people empowered, responsible and trained. It also calls for human-oversight processes to be defined, assessed and documented. “A human will review it” doesn’t meet that standard of clarity.
Decide What Qualified Means Before the Alert Arrives
Being on duty doesn’t make someone ready to decide. They may know the business process well and still have no basis for judging this particular model exception.
Qualification should be defined against the decision, not against a broad job title. An organization might require a reviewer to understand the workflow’s purpose, the evidence shown by the system, the limits of the model, the relevant policy threshold and the consequences of each available action. Some roles may also need current training, a certification or recent supervised practice.
Recency matters. A person who completed training two years ago may still appear qualified in a static spreadsheet even though the model, interface and escalation rules have changed twice since then. The governance question is whether the evidence of readiness still matches the current workflow.
Authority must be recorded separately. Consider a fraud analyst who can explain why a transaction was flagged. That analyst may be fully qualified to assess the evidence but unable to release the payment above a set amount. The overnight decision then depends on two kinds of coverage: someone capable of making the judgment and someone allowed to authorize the action.
This distinction prevents a common failure. Teams find a knowledgeable person, treat that availability as complete coverage and discover during an incident that the person can’t take the required step. The escalation continues upward until it reaches someone who is both qualified and authorized, often after the operational deadline has passed.
A usable coverage definition starts with four questions. What must the reviewer know? Which evidence proves it? The reviewer also needs a defined decision limit. Finally, when does that permission expire or require reassessment? If those answers live in different systems, the escalation process needs to reconcile them before assigning the case.
Give the Reviewer Authority and the System a Safe Default
An after-hours reviewer needs more than a notification. The alert should arrive with the proposed action, the sources or records behind it, the exception that triggered review, the time available and the consequences of delay. It should also show what the reviewer is permitted to do.
Those permissions need edges. Is the reviewer allowed to approve the action as proposed or edit it? Rejection may be permanent, or it may only return the case to a queue. Several similar exceptions might also justify stopping the wider workflow. The final boundary is the point at which a second approver must be called.
These questions belong in the design of runtime controls for AI agents, not in an emergency discussion after the queue has already formed. Pause, quarantine and restricted-permission states give operations teams somewhere safe to put uncertain work. Telemetry and audit records show what happened while the process was waiting.
The hardest case is no response. Every governed workflow needs a pre-approved answer for that condition. Depending on the risk, the system might hold the action, queue it for the next qualified shift, continue in a reduced mode or stop the affected process. A customer-support system might pause an unusually large refund while continuing routine requests. A manufacturing-quality workflow might quarantine a questionable batch instead of allowing the line to treat silence as approval.
Silence can’t count as approval.
Delegation works only with guardrails. Record who passed the authority, who received it, which calls it covers, when it expires and any limits. Without that trail, the after-hours process is just a string of messages that will be impossible to piece together later.
Shift Handover Is Part of the Control
Some exceptions will outlast a shift. The outgoing reviewer may have gathered evidence, contacted a specialist and ruled out one option without reaching a final decision. A ticket number and a hurried note aren’t much of a handover. The next reviewer wastes precious time reconstructing work that has already been done.
This isn’t a new problem. Safety-critical operations have long treated handover as work in its own right. The UK Health and Safety Executive describes effective shift handover as a three-part process: preparation by outgoing personnel, an exchange of task-relevant information and a cross-check by incoming personnel as they assume responsibility. Its guidance favors two-way communication supported by written and verbal information, with enough time and resources to do the job.
An AI exception handoff needs the same discipline, adapted to the workflow. The record should carry the proposed action, the evidence presented by the system, the reason for escalation, steps already taken, options ruled out, time remaining and the current risk tier. It also needs named ownership on both sides of the transfer.
The most important part is the acknowledgement. A log can show that information was written down. It can’t prove the incoming reviewer understood the state of the case or accepted responsibility for the next decision. A cross-check gives the incoming person a chance to challenge missing evidence, confirm the deadline and restate the next allowed action.
Interface design matters here. A handoff screen shouldn’t bury the model’s rationale, the human’s notes and the permission state in separate tabs. The incoming reviewer needs to see what changed during the previous shift and which facts still need checking. Otherwise, every handoff creates a fresh opportunity for context to disappear.
Map Qualified Coverage Across Shifts
Most teams can produce a list of people associated with an AI workflow. Fewer can show that every operating period has the right mix of knowledge and authority.
The practical starting point is a role-by-shift view. Build the view around actual decisions, not names on a roster. For each possible escalation, record the knowledge it requires, how current competence is proved and the authority needed to act. Then lay that against the people covering nights, weekends and holidays.
A skills or competency matrix can make the staffing risk visible by mapping qualified coverage across shifts, roles and sites before an exception occurs. The matrix may reveal that one person holds the only current qualification for a critical review, that a certification will expire during a planned deployment or that a weekend shift has technical expertise but no final approver.
The gaps become concrete. That visibility isn’t proof that anyone can perform the work, however, because demonstrated practice, current training and observed decisions still matter, and a matrix can’t grant legal or organizational authority. Its job is narrower: show where the coverage model relies on assumptions, stale records or a single person.
Once the gaps are visible, teams have choices. They can cross-train another reviewer, adjust on-call coverage, narrow the overnight workflow’s permissions or change the safe fallback until coverage improves. The right response depends on the consequence of delay and the consequence of a wrong decision. A low-risk queue can wait. A safety-related exception may need immediate specialist coverage or a hard stop.
Coverage should also be tested, not merely documented. Run an after-hours exercise. Trigger a representative exception, follow the escalation path and measure whether the assigned person receives enough context to act within the allowed time. Then repeat the test across a shift change. Paper coverage often looks reassuring until the first message goes to an outdated phone number or reaches someone whose approval limit is too low.
Run the Night-Shift Test
Enterprise governance already depends on defined owners and escalation paths. The night-shift test checks whether those structures remain usable when the usual people aren’t at their desks.
Start with a real workflow and one plausible exception. Ask who receives the alert at the least convenient hour. Confirm that the person is qualified for that exact judgment, then check what they can approve, change, stop or delegate. Follow the no-response route. Finally, carry the unresolved case through a shift handoff and see whether the incoming reviewer can explain its status without rebuilding the investigation.
The test will usually expose mundane problems: a role without an on-call rota, a qualification record that doesn’t match the current model, an approver whose limit is too low or a handoff that transfers notes without transferring ownership. Mundane is good. These are fixable operating problems, provided they are found before a live exception puts them on a deadline.
An AI workflow can run all night. Its governance has to do the same.
