Every function of the operations loop ends, at some hour of the night, in a person. A page from the observability platform (O1 Observe) reaches an engineer who must work out what is wrong (O2 Diagnose), decide whether a change is safe at that hour (O3 Change), bring the service back or stop an agent that is acting on it (O4 Restore), and then, on a later day, help to remove the cause so that the next engineer is not paged for it (O5 Sustain). Earlier chapters designed the loop, its autonomy budget and its observer. This chapter treats the people who carry it: the engineers on call, the duty managers who act as incident commanders, the service-desk staff and the agent operators, and what the research reports about the load on them, the effect of automation on their attention and sense of responsibility, the law that governs their time, and the rights of the employee representatives who must agree to the arrangements.
The argument has four parts. The load on operators is a design property of the loop and not a personal failing, so it is measured for a rota and never for a named engineer. Automation does not remove the operator from the loop. It changes the work into supervision and takeover, which the research on vigilance and complacency describes as hard to do well and which concentrates blame on the nearest person when it goes wrong. On-call time is not free time in law once the constraints on it are heavy enough, and the organisation therefore has to design response times, rest and compensation with the rules in view. And in both of the book's organisations, a charter written with the representatives first is the instrument that carries these decisions.
The table pairs each source of load with what studies report and the lever in the on-call charter. Every lever is agreed first with the works council or union and reviewed monthly, and the observer and the stop path sit outside the agent.
Primary topics explored
- The on-call burden
- Alert fatigue and toil
- Automation and the operator
- Blameless culture and psychological safety
- Working time
- Co-determination
About AI Operations
AI Operations is Book 10 of The Transformed Architecture. It takes IT operations as its subject and asks what happens when AI takes part in it: the five operations functions (observe, diagnose, change, restore, sustain), the autonomy budget and the Level 4 prohibitions, the observer principle, resilience as a claim that needs evidence, operating AI systems, the operator's own AI as Tier 0 and how to defend it, operating models, decision rights, regulation (DORA, NIS 2, the AI Act), and the people involved, for European enterprises and public authorities.
It builds on the conclusions of Architecture as Code, AI Governance, AI Platform and Security, AI Red Team, AI Threat, The Transformed Security Architect, AI Boss, AI Blue and AI Purple.
CIOs and heads of IT operations, SRE and platform leads, incident commanders and on-call engineers, service-desk and service-management leads, FinOps and capacity managers, architects, CISOs and heads of resilience and third-party risk, boards and management bodies, procurement and vendor managers, supervisors and auditors, works councils and unions, data protection officers, and public-sector leaders.
Gunnar Nordqvist
Conceived, directed and published the books of The Transformed Architecture.
Continue with the full chapter
Chapter 25: Operators as People: On-Call, Toil, Trust and Wellbeing in AI Operations gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “People and Career” and is one of 35 drawn from the manuscript.