Operating Models: Platform Teams, SRE, Managed Services and Sovereign Operations

An operating model is the answer to four questions about every service: who runs it, who owns it, who may act on it and who is called when it fails. For decades the answers followed from scarcity. Attention was scarce, so tickets queued; skill was scarce, so specialists were pooled into central teams; night cover was expensive, so it was bought. AI loosens the scarcity of attention without removing the other constraints, and the answers shift: the loop that one person can supervise becomes larger, the provider's tooling starts to act with its own rules, and the team that owns the platform acquires a new product, the operator's own agents. This chapter compares the operating models that European enterprises and public authorities actually use, shows what AI changes in team topology and in who owns what, sets out how a managed operations provider is bought when its AI acts, defines the operations conductor as a role, and treats the case of regional and national operators in the public sector. It concerns all five operations functions: O1 Observe, O2 Diagnose, O3 Change, O4 Restore and O5 Sustain, because an operating model decides who performs each of them and under which delegation.

The chapter builds on conclusions of the earlier volumes. Platform teams act as internal service providers and the system mirrors the organisation's communication paths (Architecture as Code (Chapters 17 and 18), F10) (295, Nordqvist, 2025). Hub-and-spoke scales when the hub is a platform team in X-as-a-service mode and control functions keep their independence through gates and records rather than meetings (AI Governance, Chapter 12, F22) (296, Nordqvist, 2026). Managed triage with embedded vendor AI is the Mode 0 blind spot in practice, and the answer is a contract that states levels and actions, sampling, audit rights, evidence, tuning and test rights and notice of model change (AI Blue, Chapters 7 and 16, F97) (302, Nordqvist, 2026). Four operating models recur, an organisation runs a mixture, and the decision is made per stage and recorded with exit criteria (AI Purple, Chapter 19, F133). Chapter 4 defines the autonomy budget and the observer principle used throughout.

Three questions per service, six operating models, the hybrid recorded per service, and what is kept in every model

Figure 21.1: Operating model options chosen per service, what stays with the organisation in every model, and the observer and stop path outside the provider.

What an operating model decides

Four things are fixed by an operating model, whether anyone wrote them down or not. The first is who performs each of the five functions: who reads the telemetry, who diagnoses, who changes, who restores, who plans capacity and learns. The second is who owns: the named person accountable for a service, an objective, a runbook and, since AI arrived, an agent. The third is who may act, which is the delegation profile of Chapter 4 and the decision rights of Chapter 22. The fourth is who is called, that is, the on-call and escalation structure of Chapter 25. A model that answers the first question well and leaves the other three implicit works until the first incident that crosses a boundary.

Melvin Conway stated the reason in 1968: organisations that design systems are constrained to produce designs that are copies of the communication structures of those organisations (271, Conway, 1968). For operations the corollary is practical. A service run by three teams that communicate through tickets acquires ticket-shaped interfaces, and a service whose night cover sits in another company acquires a contract-shaped seam at the point where an incident is most likely to need a conversation. The operating model is therefore an architectural decision of the same kind as the choice of database, and this book records it in the same way: per service, with an owner, with a date and with the evidence that would show it was wrong.

Two properties make the decision harder than it looks. Services differ in criticality, so no organisation runs a single model; the service catalogues of both example organisations rank services in Tier 1, 2 and 3, and Hansa Mutual adds the DORA flag for services that support a critical or important function. And the models differ in what they make visible. An in-house team sees its own telemetry, rota and runbooks. A provider shows what the contract obliges it to show, which is why the contract is part of the operating model and not an annex to procurement.

The options

Several models recur in European practice. They are not exclusive, and the sections that follow compare what each trades.

In-house site reliability engineering

Site reliability engineering (SRE) is the discipline in which engineers with software skills run production and automate operational work. Its founding statement caps the share of an SRE's time spent on operational work, tickets, on-call and manual tasks, at 50 per cent, redirects excess to the development teams and uses error budgets to align developers and operators on shared reliability goals (245, Treynor Sloss, 2017). The model answers a specific scarcity: headcount that would otherwise grow with traffic and complexity. What it trades is breadth for depth. An SRE team chooses whether and when to take on a service, on agreed conditions that rest on a service level objective and an error budget, is warned against spreading itself too thin across too many services, and can hand a service back to its developers when it no longer warrants the engagement (272, Beyer et al., 2018). The model fits services that are critical, change often and whose failures need judgement; it fits badly where the organisation cannot hire or keep the skill, which is the position of most public authorities.

The platform team with a product mindset

A platform team provides an internal product that speeds up other teams. Team Topologies names it one of four fundamental team types, alongside stream-aligned, enabling and complicated-subsystem teams, and describes three interaction modes between teams: collaboration, X-as-a-Service and facilitation (270, Skelton & Pais, 2025). The Platforms White Paper of the Cloud Native Computing Foundation defines a platform as an integrated collection of capabilities presented according to the needs of its users, assigns the platform team responsibility for the interfaces to and experiences with those capabilities, and asks that the platform be treated as a product with self-service access (273, CNCF TAG App Delivery & Platforms Working Group, n.d.). The trade is autonomy for consistency: product teams move without queueing for operations, and in return they accept the golden paths of the platform. The research evidence is mixed in a way that matters for what follows. The 2024 Accelerate State of DevOps Report of Google Cloud's DevOps Research and Assessment programme reports that using an internal developer platform improves individual productivity, team performance and organisational performance, and also that it can decrease change throughput and change stability, which the report ties to careful implementation (274, Google Cloud, 2024). The reported effects depend on how the platform is built, and the page consulted does not give the survey method or the effect sizes; this chapter uses the finding as a caution and not as a measurement.

Centralised and embedded

The oldest question of team topology is whether operational skill sits in a central team or inside the teams that build. The SRE Workbook describes the choices for a first SRE: embedded in a product team, in an operations team or in a horizontal role. It describes a consulting model in which a horizontal team advises and builds shared tooling, warns that such a team can be perceived as a gate that adds no value, and recommends committing to one stable and coherent model for the long term (272, Beyer et al., 2018). Centralisation buys consistency and a pool of scarce skill; embedding buys proximity to the service and ownership by the people who change it. Hansa Mutual shows both in one organisation: a central site reliability and incident management function of about 95 people, and product-line application operations teams of about 310 embedded in claims, motor, property, life and health. Nordvik Region shows neither at scale: its platform team of seven carries SRE practice and no one holds the title.

Managed service providers

A managed service provider (MSP) runs a defined set of operations for a fee against service levels. It answers the scarcity of night, weekend and specialist cover, and of the cost of running a 24-hour function for a few services. What it trades is visibility and control, and in the regulated sectors of the Union that trade is governed. Under DORA a financial entity remains fully responsible for compliance with its obligations when it uses ICT services under contract (Article 28(1)(a)), keeps a register of information on all such arrangements (Article 28(3)) and must have exit strategies for services supporting critical or important functions (Article 28(8)) (2, European Union, 2022). Under NIS 2 the management bodies of essential and important entities approve the cybersecurity risk-management measures and can be held liable for infringements, without prejudice to national rules on public institutions (Article 20(1)), and the measures include business continuity and supply chain security (Article 21(2)(c) and (d)) (3, European Union, 2022). Neither instrument allows responsibility to pass to the provider with the work. The section on buying operations with AI inside returns to the contract.

Follow-the-sun

Follow-the-sun hands the operational watch between sites in different time zones so that each works in daylight. It answers the cost and the health effects of night work, and it is available to organisations large enough to staff three sites. What it trades is the handover: every change of watch is a seam at which context is lost, so the model needs handover records, a common tooling surface and one incident commander on duty at any moment. It may be run with the organisation's own sites, with a provider, or with a mixture. Hansa Mutual runs it on its own: a 24-hour incident commander rota of 12 trained people across Hamburg and the Polish service centre, with the UK entity contributing the late shift. Nordvik Region cannot, with eleven people in its first-line technical rota and a duty manager rota of four.

Sovereign and national operators

In the public sector a further model is common: operations provided by a shared-service organisation owned by the state or a group of regions. It answers procurement lead times, the scarcity of skill and the wish to keep operational data under national or regional law. It trades dependence for capacity. The shared provider is a concentration of risk, since several authorities depend on it for the same services, and its operating decisions, including those taken by its AI, are decisions about the authority's services made elsewhere. The point is addressed in the section on public authorities below. The test of sovereignty is the one of AI Platform and Security, Chapter 13 (F47): digital sovereignty is a set of verifiable properties, namely knowing where workloads run, which law governs them, being able to move them and being able to continue if a provider fails, and not a postcode (297, Nordqvist, 2026). A national operator that satisfies the four properties is sovereign in the sense that matters; one that does not is merely domestic.

Hybrids

Most organisations run a hybrid, and the decision belongs to the service and not to the organisation. A Tier 1 service may be run in-house with the provider's night cover for first response; a Tier 3 service may be run entirely by a provider; a platform may be run by a platform team on a hyperscaler tenancy while a national operator supplies DNS and the recovery site. The hybrid is observable in both example organisations and in most large European organisations. The discipline it needs is a record per service of which model applies, which parts of the five functions sit where, and what the exit criteria are.

Model Answers the scarcity of Trades Typical strain
In-house SRE Headcount growth with load Breadth for depth; skill is hard to hire Operational share creeps above the cap; engagement by agreement erodes
Platform team Queueing for operations Autonomy for consistency Platform as a product needs product skills; throughput and stability can fall if it is built carelessly
Centralised Scarce expert skill Proximity to the service Seen as a gate; ticket-shaped interfaces
Embedded Ownership and context Consistency and pooled skill Uneven practice; isolated engineers
Managed provider Night, weekend and specialist cover Visibility and control Provider AI acts under its own rules; exit is hard
Follow-the-sun Cost and health effects of night work Handover seams Lost context at each change of watch
National or regional operator Procurement time and skill Dependence for capacity Concentration; decisions taken elsewhere

What AI changes

Three changes recur across the models, and each is a change in the work and not only in the tooling.

The first is smaller loops and larger scope per person. An operations assistant that retrieves runbooks and past incidents, a change-risk reviewer that scores a proposed change, a runbook runner that restarts and scales within a catalogued boundary: each removes a step that previously needed a person's attention. The effect is expected, not yet measured across European operations, and it is limited by the supervision that remains. What a person can responsibly supervise is bounded by the evidence that the agent is right, which is the autonomy budget of Chapter 4, and not by the agent's speed. The span of a conductor grows only as far as the independent verification allows (Chapter 17). The expected consequence for an organisation that reads the first gains in throughput as a reason to cut the number of people who can operate manually is that it has cut the capacity that handles the first novel failure; the grounds are Bainbridge's analysis and not a measurement. Bainbridge's analysis of automation made this point in 1983: when the routine tasks are automated the operator is left with those that cannot be, and loses the practice that would make him or her good at them (217, Bainbridge, 1983). Parasuraman and Manzey treat complacency and automation bias as attentional phenomena of people who supervise automation (218, Parasuraman & Manzey, 2010). Both are reasons to keep the loop's supervisors few enough to be trained and many enough to be practised, and Chapter 26 treats the craft.

The second is a new product in the platform team. The operator's agent team, with its skills, mandates, identities, runbook library and observer, is an internal platform in the sense of the Platforms White Paper: a collection of capabilities with interfaces and a user community (273, CNCF TAG App Delivery & Platforms Working Group, n.d.). It holds the broadest credentials in the estate and is Tier 0 (AI Platform and Security, Chapter 17). The natural owner is the platform team, run as a product, with the interaction mode of X-as-a-Service towards the teams that consume it and facilitation while they learn to write runbooks and mandates of their own (270, Skelton & Pais, 2025). The consequence is a load on a team that is already small. The platform team of Nordvik Region has seven engineers who carry the observability stack, the AI gateway, the reserved capacity and weekly on-call; adding an operations assistant to its remit without removing something else repeats the pattern that the 2024 report warns of, a platform introduced without the capacity to run it carefully (274, Google Cloud, 2024).

The third is a change in what ownership means. Before AI, an owner was accountable for a service and a set of people who operated it. Now an owner is also accountable for the actions of a system that acts with a service's credentials. The next section separates four kinds of owner, because the four fall to different people in different models. Control functions keep their independence through gates and records (AI Governance, Chapter 12, F22) and the evidence that supervisors receive is produced by the operation and not assembled afterwards (296, Nordqvist, 2026).

None of this is a reason to prefer one model. It shifts the strain in each: the in-house SRE team is tempted to widen scope faster than verification allows; the platform team inherits the agents; the managed provider's AI starts to act for many clients at once; the embedded team lacks the skill to write a mandate; the national operator concentrates all of it. The next three sections deal with ownership, with the contract and with the role that holds the loop together.

Ownership: four owners

Every record in this book has a named person. In operations four owners recur, and the operating model decides which person and which organisation holds each.

Owner Holds Cannot delegate Typical record
Service owner Accountability for the service, its tier, its risk acceptance and the decision to change its operating model Risk acceptance and the exit decision SVC-NR-*, SVC-HM-*
Objective owner The service level objective, its error budget and the decision to freeze change when it is spent The freeze decision SLO-NR-*, SLO-HM-*
Runbook owner The runbook's content, preconditions, verification and stop path, and its review date Sign-off of a level change for the runbook RBK-*
Agent owner The mandate of an agent, its identity and credentials, its evaluation and the budget it may consume The mandate and the stop MND-NR-OPS-*, MND-HM-OPS-*

The separation answers a failure pattern that earlier chapters describe: the runbook that nobody owns and that is out of date when it is needed, as in the Cloud A degradation of 2026 at Hansa Mutual, when failover to Cloud B was not attempted because the runbook was out of date (INC-HM-2026-0224), and the agent whose objective was not owned by anyone who would notice a shortcut (INC-HM-2026-0497). In an in-house model the four owners are usually in one organisation and the question is whether they are different people. A service owner who is also the agent owner of the agent that operates the service marks their own work; the observer principle asks for the verification to be independent of what performed the action (Chapter 17), and the same logic applies to ownership.

In a managed model the four owners straddle the contract. The service owner and the objective owner stay with the organisation; the runbook owner may be the provider for runbooks the provider wrote and the organisation for those it approved; the agent owner of a provider's agent is the provider, and the organisation holds a stop right and a sampling right instead. A table of owners that is empty in the organisation's column is a finding. The AI Act adds a statutory form of the same demand for high-risk AI systems: the deployer assigns human oversight to natural persons who have the necessary competence, training and authority, monitors the operation of the system, keeps the logs under its control for at least six months and, as an employer, informs workers and their representatives before putting a high-risk system into use at the workplace (Article 26(2), (5), (6) and (7)) (1, European Union, 2024). The provider of an operations service cannot hold those duties on the deployer's behalf.

The practice of the SRE literature gives a useful default. At the New York Times the application owners, and not the SREs, are directly responsible for making changes to an application, and at Google SRE teams mirror the developer organisation by product area (272, Beyer et al., 2018). The pattern is the same: the operational specialists advise, run and verify, and ownership of the thing that changes stays with the team that changes it. For AI-authored change (Chapter 8) the corresponding rule is that the agent that drafted the change does not own it.

Buying operations with AI inside

A managed operations provider uses AI whether or not it says so. Monitoring services correlate events, suppress noise and classify tickets with models; some propose or run remediation. From the customer's side this is Mode 0 Ambient AI: AI in a service the customer did not choose, acting under rules the customer cannot see. AI Blue, Chapter 16, reached the conclusion for managed security that the answer is a contract, six terms and conditions for data and exit, and that detection content, the decision rights for containment and disclosure, the case record, the ability to leave and enough skill to supervise stay with the organisation whatever the model (F97) (302, Nordqvist, 2026). The same pattern, the MS-2 pattern, carries over to operations with the nouns changed.

Term In managed security (AI Blue) In managed operations
1. Levels and actions Alert classes the provider's AI may close, with levels Action classes of Chapter 4 (read, annotate, notify, scale, restart, reconfigure, deploy, roll back, fail over, delete, restore-overwrite) the provider's AI may take, each at a stated level, with a never-list
2. Sampling Closed items per class each quarter Remediations and suppressed alerts per class each quarter, returned with the evidence used
3. Audit rights Location, subprocessors, retention, training The same, plus access for the competent authority
4. Evidence A record per closure A record per action in agreed fields: service, runbook, level, model or rule version, verification result
5. Tuning and test rights Provenance of detections, seeded incidents Provenance of runbooks and correlation rules, right to suppress or narrow them under the customer's version control, right to inject authorised seeded faults and receive the result
6. Notice of model change 20 working days before a change to a model, rule or threshold affecting closure The same for any change affecting suppression, correlation, remediation or paging, with a shorter after-the-fact notice for an emergency

Three additions are particular to operations. The first is the stop right outside the provider's platform: the customer can revoke the provider's credentials in its own console and order the provider's agents to cease acting on its services, and the provider's agents cannot disable that path. The second is the observer. A provider that measures its own service levels with its own probes reports on itself; the customer needs a probe that does not depend on the provider's platform, which is the observer principle applied to a contract (Chapter 17). The third is customer control over change. The root cause analysis that CrowdStrike published in August 2024 on Channel File 291 records a content update delivered to the field and lists, among its mitigations, staged deployment in rings with bake-in time and increased customer control over where and when content updates are deployed, with release notes to which customers can subscribe (78, CrowdStrike, 2024). The report does not say what other suppliers do. The architectural reading is the book's own: provider-side change reaches every client the provider has, and the customer's protection is a contractual right to notice, to stage and to hold.

The financial sector has these terms in statute. For ICT services supporting critical or important functions, DORA requires contracts to include full service level descriptions with precise quantitative and qualitative targets, notice periods and reporting obligations for developments that might materially affect the provider's ability to deliver, the provider's participation in the entity's threat-led penetration testing, unrestricted rights of access, inspection and audit by the entity and the competent authority, and exit strategies with a mandatory adequate transition period (Article 30(3)(a), (b), (d), (e) and (f)); all contracts must say whether subcontracting is permitted and under what conditions, state the locations where services are provided and data processed with advance notice of change, and oblige the provider to assist at no additional cost or at a cost determined ex ante when an incident occurs (Article 30(2)(a), (b) and (f)) (2, European Union, 2022). The entity must also weigh whether a provider is easily substitutable and whether it is concentrating dependence on one provider or on closely connected providers (Article 29(1)) (2, European Union, 2022). Where the operations service runs on a cloud or edge provider, the Data Act's switching terms apply to the provider: the contract must allow switching or porting after a maximum notice period of two months, with a mandatory maximum transitional period of 30 calendar days, and the provider must support the customer's exit strategy (Article 25(2)(a), (b) and (d)) (16, European Union, 2023). Chapter 24 treats these provisions and the exit test.

What the contract cannot do is make the first sample or stop request succeed. A contract right is a promise until it has been used (F111): the first quarterly sample, the first seeded fault and the first stop order show whether the provider's records and processes deliver what the annex says. The outlook for this market is labelled as follows. Managed operations with embedded provider AI are observable. Provider AI that acts at Level 3 Bounded across many clients under a single model or rule set is expected, since monitoring providers already correlate and classify across clients and the step to catalogued remediation is a small one; the grounds are the structure of the market and the direction of the product claims, and not a measured trend. A fully autonomous managed operations service with no named human decider on the customer side is speculation, and it would contradict the thesis that a person must remain accountable.

Practical guide: Adding an operations annex to a managed-service contract

Purpose. State what the provider's AI does, let the customer check it and give notice of change.

Roles. The head of operations sponsors; the service owner and the runbook owner write the technical terms; the procurement lead and the legal adviser check the annex against the framework agreement and public procurement law; the data protection officer reviews the data terms; employee representatives are informed where the annex creates logs of operators' work; for a financial entity the head of operational resilience checks it against DORA.

Steps.

  1. Ask the provider in writing which AI acts in the service, on which action classes, at which model version, with which actions and in which location. Record the answer, or its absence, as a finding.
  2. Assign a level per action class. Level 3 Bounded only for narrow, reversible classes inside a catalogued runbook; Level 1 or 2 otherwise. Write the never-list: irreversible actions on production data, any action outside a freeze on a critical function, any action on the observer or the stop path.
  3. Name the evidence for every action: service, runbook, level, version, verification result.
  4. Set the sample. Default: 50 actions per class each quarter, or all if fewer, returned within five working days. Adapt to volume.
  5. Set the notice period. Default: 20 working days for any change affecting suppression, correlation, remediation or paging, with the previous version kept in force during the notice period at the customer's request and notice within two working days of an emergency change.
  6. Write the stop right and its target. Default: 15 minutes to revoke and to cease acting, tested quarterly, and held by named roles who need no approval.
  7. Write the audit, data and exit terms. For a financial entity map each to Articles 28 to 30 of DORA; for others use NIS 2 Article 21(2)(d) and (3) as the demand and the contract as the form.
  8. Run the first sample, a seeded fault and a stop test within 90 days of signing, and record the results.

Definition of done. The annex is signed, the first sample, seeded fault and stop test are on record with dates and results, and the observer that checks the provider's service levels does not run on the provider's platform.

The operations conductor

The series' conductor theme (The Transformed Security Architect, Chapter 3, F72) describes an architect who stops being the sole author and becomes the accountable conductor of an AI team whose proposals must be verified (300, Nordqvist, 2026). AI Blue applied it to the blue team, and its team design divided the tier-1 pyramid into closure by class, sampling and review, the residual queue and learning what normal looks like (F108) (302, Nordqvist, 2026). Operations has the same figure. The operations conductor is the accountable person for a loop over a defined set of services and a defined window: the person who knows what the agents may do, sees what they did, verifies proposals before they take effect where the mandate requires it, keeps manual operation in practice and holds the right to stop.

The role is a charter and not a title. In a small organisation it is a duty of an existing post, such as the platform lead or the duty manager. In a large one it is held by people in a rota: the incident commander of a shift window who is also the agent operator for that window. What the charter must contain follows from the thesis. The mandate states the services and the window. The decision rights say what the conductor may approve, declare and stop, and refer to the delegation profile for the rest (Chapter 22). The prohibitions repeat the Level 4 limits of Chapter 4 as things no system and no conductor delegates. The independence clause says that the conductor does not verify the effect of an action by the same agent whose authority the conductor holds, without an independent probe. The competence clause says how the role is evidenced and kept: AI Blue concluded that competence is evidenced by exercises and not certificates, and that with fewer than two evidenced holders per site a Level 3 class falls back to Level 2 (F108) (302, Nordqvist, 2026). The people clause protects the holder: measures about the role are reported for teams and services and never per named person, which in both organisations is an agreement with employee representatives.

A conductor is not a supervisor of people in the sense of AI Boss, and the charter says so: it holds no function that decides about a named person's access to work. It is also not a replacement for the incident commander of Chapter 22. At Hansa Mutual the two meet in the night window, where the Polish incident commander on the rota is also the agent operator for the IT-operations agent, and at Nordvik Region they are held by different people.

Worked example: a role charter for an operations conductor

The record below is illustrative. It shows the charter of the night-window conductor of Hansa Mutual's Group Site Reliability and Incident Management, under the Konzernbetriebsrat's operations annex.

role: ROLE-HM-OPS-001
title: Operations conductor, night window (Polish service centre)
version: 1.0
effective: 2028-11-01
owner: Head of Group Site Reliability and Incident Management (Tobias Richter)
reviewers:
  - Head of operational resilience (second line)
  - Chair of the Konzernbetriebsrat (Thomas Brandt), under KBV-IT-2024-OPS-03
mandate:
  services: [SVC-HM-001, SVC-HM-002, SVC-HM-004, SVC-HM-006]
  window: "22:00-06:00 CET"
  loop_functions: [O1, O2, O3, O4, O5]
  agents_conducted: [HM-OPS-001, HM-OPS-002, HM-OPS-003]
decision_rights:
  may: [stop_any_operations_agent, approve_level_2_action, declare_tier_1_incident]
  referred_to: "delegation profiles DLG-HM-* (Chapter 22)"
  stop_right: no_approval_needed
  stop_path: outside the agents' platform
never_delegated:
  - irreversible action on production data
  - action outside an authorised change window or freeze on a critical function
  - action that disables observation or the stop path
  - any decision about a named person's access to work
independence:
  verification_of_agent_action: independent probe, not the acting agent
  conductor_may_not_verify_own_approval: true
competence:
  evidenced_by: exercises (CMP-HM-* records), not certificates
  minimum_evidenced_holders_per_window: 2
  fallback_if_fewer: Level 3 classes fall to Level 2
  manual_practice: one agents-off exercise per holder per quarter
people:
  metrics_reported_for: [teams, services]
  per_named_person_reporting: false
  minimum_group_size: 5
  agreement: KBV-IT-2024-OPS-02
review: 2029-03-31

Public authorities

A regional authority differs from a multinational group in four ways that matter for operating models, and a national shared-service provider changes the shape of the options.

The first is skill. Public pay scales, long procurement lead times and a small team make in-house SRE of the Hansa kind unavailable; the platform team of seven carries the practice, and the alternatives are to buy it or to share it. The second is procurement. A public authority buys under public procurement law, which favours criteria that are stated in advance and checked against evidence, and this suits the operations annex: a statement of the provider's AI, a demonstration against a seeded replay set and acceptance of the six terms are criteria that can be scored, in the way that AI Blue, Chapter 16, proposed for managed security. The third is liability. NIS 2 leaves the application of the management body's liability to national law as regards public institutions, public servants and elected or appointed officials (Article 20(1)), so the question of who is accountable for operations when the provider is a shared service is answered in national law and in the contract, not in the Directive (3, European Union, 2022). The fourth is the scope of the regime: whether a regional authority is in scope of NIS 2 depends on national transposition: the Directive covers regional public administration entities as defined by the Member State under national law and following a risk-based assessment, and leaves local level to the Member State's option (Article 2(2)(f) and (5)(a)) (3, European Union, 2022). An authority that plans as if its Tier 1 services were in scope loses little by it.

The shared operator is a concentration. When several authorities depend on one provider for DNS, identity federation and the recovery site, a fault at the provider is a fault in all of them, and the provider's own AI, where it monitors or remediates, acts on all of them under one rule set. The tests of the four sovereignty properties apply to the operator as to any provider (297, Nordqvist, 2026): where the workloads run, which law governs them, whether the authority can move them and whether it can continue if the operator fails. Two practices follow from the book's conclusions. The authority keeps an observer that does not depend on the operator, because a fault at the operator is also a fault in the operator's status page (the Region's monitoring saw the DNS fault of 2027 22 minutes after the operator's own status page did, INC-NR-2027-0298). And it restores the part of the estate that the operator hosts from the authority's own evidence, so that a recovery that depends on the operator's site is tested against the operator's cooperation (RST-NR-2027-002, failed on time at 5 hours 20 minutes against 2 hours and not yet re-tested at the start of the book).

A fully shared operating model, in which one national operator runs the operations of many authorities with a common agent platform, is expected to be proposed as a response to the shortage of operations skill in the public sector; no European deployment of an AI agent platform at that scale is documented in the sources of this book, and the claim rests on the shortage and on the logic of shared services. That an authority could hand the accountability to such an operator is speculation and conflicts with the allocation of responsibility in NIS 2 Article 20 and in the AI Act's deployer duties.

Choosing an operating model

The choice is made per service and recorded. The inputs are the criticality tier, the legal regime, the sovereignty properties that the service needs, the skill that the organisation has and can keep, and the evidence that a provider can show. Two rules limit the choice before preference enters. A service that supports a critical or important function under DORA needs an exit strategy whose exit plans are sufficiently tested and reviewed periodically (Article 28(8)); and Level 3 Bounded for any action class requires either the organisation's own mandate enforced by a policy decision point outside the agent or the provider's annex with a stop right outside the provider's platform.

Practical guide: Choosing an operating model by service criticality and sovereignty

Purpose. Decide, for each service in the catalogue, who runs it and at what ceiling of delegation, and record the decision with its exit criteria.

Roles. The service owner decides; the head of operations, the platform lead and the SRE lead advise; the CISO and the head of operational resilience review; procurement, the data protection officer and employee representatives are consulted where the decision creates a contract, processes personal data or changes standby or monitoring.

Steps.

  1. List the services with their tier and, for a financial entity, their DORA flag. Start with Tier 1.
  2. For each service, answer the four sovereignty questions: where workloads and operational data run, which law governs them, whether they can be moved and whether the service can continue if the provider fails. Record the answers with their evidence, such as a restore test or an exit test, and their date.
  3. Count the evidenced holders of the conductor role per window. Fewer than two in a window caps every Level 3 class in that window at Level 2, whatever the model.
  4. Choose per function. For each of O1 to O5, state who performs it: the organisation's own team, a provider or a shared operator. A split such as O1 Observe at a provider and O4 Restore in-house is legitimate if the seam is in the contract and in the runbooks.
  5. For every part that a provider performs, attach the operations annex and an observer that does not depend on the provider.
  6. Write the exit criteria: the condition that moves the service back in-house or to another provider, such as two missed samples, a model change without notice, or a failed exit test, and the time within which the move must be possible. Default: review every 12 months and after any Tier 1 incident that involved the seam.
  7. Record the decision as an ADR and, where AI is involved, as an AIDR, and review it with the service record.

Definition of done. Every Tier 1 service has a named model per function, a conductor with at least two evidenced holders per window or a recorded fallback to Level 2, an annex and an independent observer for every provider-performed part, a dated exit test, and exit criteria.

A reading aid for the outcome of such a decision is shown below.

Criticality and sovereignty need Default model Ceiling of delegation Evidence before relying on it
Tier 1, high sovereignty need, skill in-house In-house SRE, platform team provides tooling Level 3 for catalogued reversible classes, Level 2 otherwise Restore test and stop drill, dated
Tier 1, high sovereignty need, skill short Hybrid: own conductor, national operator for hosting and night first response Level 2 on the operator's side until sampling is on record Exit test and first sample
Tier 1, moderate sovereignty need Platform team and embedded operations, provider for out-of-hours Level 3 inside the provider's annex First seeded fault and stop test
Tier 2 or 3 Managed provider or follow-the-sun cover Level 1 or 2 Quarterly sample

Across the usage modes

The operating model decides whose AI sits in which mode and who holds the level. The table shows, for each model, the usual mode of the AI acting in the operations chain, the party that holds the level and the observer to ask for.

Operating model Usual mode of the AI in the chain Who holds the level Observer and stop path
In-house SRE Mode 3 agentic work tools for drafting; Mode 4 assistants; Mode 5 where a mandate exists The organisation, through its delegation profile Organisation's own, outside the agent's platform
Platform team Mode 4 and Mode 5 as a product to consuming teams The platform team for the product, the consuming team for its services Platform's own policy decision point, observer outside it
Embedded operations Mode 2 and Mode 3 in teams; agents inherited from the platform The embedded team within the platform's ceiling The platform's
Managed provider Mode 0 for the customer, stated by contract The customer and the provider, in the annex, at Level 3 at most for narrow classes The customer's probe and stop right
Follow-the-sun As the organisation's own, with the handover record The incident commander on duty Common across sites
National or regional operator Mode 0 where the operator monitors; Mode 4 or 5 where it runs agents The operator within the authority's mandate An observer independent of the operator
Hybrid A mixture, recorded per service Per service, recorded Per service

Nordvik Region and Hansa Mutual

Nordvik Region runs a hybrid in which the Region owns more than it operates alone. The platform team of seven, led by Maja Lindqvist, carries SRE practice, the observability stack and the operations assistant NR-OPS-001 (AIDR-0901, Level 0 Advisory). The national shared-service provider SamDrift (framework agreement NR-2026-088) hosts the disaster-recovery site and supplies identity federation and DNS; its network operations centre watches Tier 1 services around the clock and pages the Region's on-call, and its service desk takes calls out of hours with the Region's knowledge base. First-line technical on-call is the Region's own, eleven engineers one week in eleven, with Oskar Berg among the four duty managers who act as incident commanders. The Region has no Mode 5 agent. Its operating-model question, raised by the executive committee in AIDR-0900, is which parts of the loop can be owned by a team that small and which must be bought, and what it can prove about recovery. The conclusions of this chapter for the Region are four. The platform team's load must be reduced before the assistant's remit grows. The operations annex goes into the SamDrift framework agreement for the monitoring and paging service, including a stop right and an observer that does not run on SamDrift's platform. The first re-test of the failed portal failover (RST-NR-2027-002) must pass before the Region says that the portal is recoverable. And the role of conductor is held by the duty managers, not created as a post, with the minimum of two evidenced holders per window, which the rota of four can meet only if each completes the agents-off exercise (Chapter 26).

Hansa Mutual runs the larger and more varied estate and has more to separate. Group Site Reliability and Incident Management (about 95 people, head Tobias Richter) is the central function; product-line operations teams (about 310) are embedded; the incident commander rota of 12 covers 24 hours across Hamburg and the Polish service centre; the IT-operations agent HM-OPS-001 (AIDR-0027) acts at Level 3 Bounded for restarts, certificate renewal and horizontal scaling and at Level 2 for configuration change and rollback in its indicative profile. Alster Managed Services runs the night operations of SVC-HM-003 under contract HM-PROC-MSP-2025-03, with embedded AI in its monitoring that the group did not choose; Lumenscope supplies observability and an assistant under HM-PROC-OBS-2026-01, both on the DORA register of information. The group's question, put by the risk committee in AIDR-0950, is how far the agent's autonomy may reach, and the operating model gives the first answer: the level is set per service and per window, capped at Level 2 wherever the window has fewer than two evidenced conductors, and the provider's AI is brought under the same six terms before its scope is widened. The role charter above (ROLE-HM-OPS-001) is the instrument. The seam that the group watches is the one between Alster's monitoring and the group's own agents, and between Lumenscope's summaries and the incident commander's judgement.

Both organisations run a mixture and neither has chosen once. Nordvik's leverage is the contract and the few runbooks it owns; Hansa's is the platform, policy as code and the mandate. Nordvik cannot run follow-the-sun and Hansa already does; Nordvik's concentration is one national provider, Hansa's is the seams between several.

Summary

An operating model decides who performs the five operations functions, who owns what, who may act and who is called, and it is an architectural decision made per service and recorded with its exit criteria. Several models recur: in-house SRE, the platform team, centralised and embedded teams, managed providers, follow-the-sun, sovereign and national operators, and hybrids. Each answers a scarcity and trades something for it. AI changes the strain in each model: loops become smaller and the scope per person larger, the platform team acquires the operator's agents as a product, ownership extends to the actions of systems that hold service credentials, and the provider's AI begins to act under rules the customer cannot see. This concerns O1 Observe, O2 Diagnose, O3 Change, O4 Restore and O5 Sustain, because each of them can sit in a different place.

Four owners recur: service, objective, runbook and agent. In every model the organisation keeps the service owner, the objective owner and the right to stop and to leave, and it holds a stop right and a sampling right over any agent it does not own. A managed operations provider is bought with an annex that turns the MS-2 pattern into operations terms: action classes and levels, sampling, audit, evidence, tuning and test rights and notice of model change, with a stop right and an observer outside the provider's platform. In financial services DORA Articles 28 to 30 require parts of this by statute; elsewhere NIS 2 Article 21(2)(d) supplies the demand and the contract the form. A contract right is a promise until the first sample, seeded fault and stop test show it works.

The operations conductor is the accountable role that holds the loop together: it knows what the agents may do, verifies where the mandate requires, keeps manual operation in practice and holds the right to stop. With fewer than two evidenced holders per window, Level 3 classes fall back to Level 2. For public authorities the shared operator is both a remedy for scarce skill and a concentration, tested by the four sovereignty properties and by an observer that does not depend on it. The outlook is labelled: managed operations with embedded AI are observable, provider AI acting at Level 3 across clients is expected and a fully autonomous managed operations service with no named human decider is speculation.

The next chapter, Chapter 22, sets out who may approve change, declare an incident, authorise a failover and stop an agent, and how delegation profiles record it.

Sources

  1. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union. (1, European Union, 2024)
  2. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, 27 December 2022. (2, European Union, 2022)
  3. European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). Official Journal of the European Union. (3, European Union, 2022)
  4. Nordqvist, G. (2025). Architecture as Code. The Transformed Architecture, Book 1. (295, Nordqvist, 2025)
  5. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. The Transformed Architecture, Book 2. (296, Nordqvist, 2026)
  6. Nordqvist, G. (2026). AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. The Transformed Architecture, Book 3. (297, Nordqvist, 2026)
  7. Nordqvist, G. (2026). The Transformed Security Architect: Role, Craft and Career in the Age of AI in European Enterprises and Public Authorities. The Transformed Architecture, Book 6. (300, Nordqvist, 2026)
  8. Nordqvist, G. (2026). AI Blue: How Artificial Intelligence Transforms the Blue Team in European Enterprises and Public Authorities. The Transformed Architecture, Book 8. (302, Nordqvist, 2026)
  9. Bainbridge, L. (1983). Ironies of Automation. Automatica 19(6), 775-779. (217, Bainbridge, 1983)
  10. Parasuraman, R. & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation: An Attentional Integration. Human Factors 52(3), 381-410. (218, Parasuraman & Manzey, 2010)
  11. Skelton, M. & Pais, M. (2025). Team Topologies (second edition). IT Revolution. (270, Skelton & Pais, 2025)
  12. Conway, M. E. (1968). How Do Committees Invent? Datamation, April 1968. (271, Conway, 1968)
  13. Treynor Sloss, B. (2017). Introduction, Chapter 1 of Site Reliability Engineering: How Google Runs Production Systems, edited by Betsy Beyer. O'Reilly Media. (245, Treynor Sloss, 2017)
  14. Beyer, B., Murphy, N. R., Rensin, D. K., Kawahara, K. & Thorne, S. (eds) (2018). The Site Reliability Workbook: Practical Ways to Implement SRE. O'Reilly Media. (272, Beyer et al., 2018)
  15. CNCF TAG App Delivery, Platforms Working Group. CNCF Platforms White Paper. Cloud Native Computing Foundation. (273, CNCF TAG App Delivery & Platforms Working Group, n.d.)
  16. Google Cloud (2024). Accelerate State of DevOps Report 2024. DevOps Research and Assessment programme. (274, Google Cloud, 2024)
  17. CrowdStrike (2024). External Technical Root Cause Analysis: Channel File 291. 6 August 2024. (78, CrowdStrike, 2024)
  18. European Parliament and Council of the European Union. Regulation (EU) 2023/2854 on harmonised rules on fair access to and use of data (Data Act). Official Journal of the European Union. (16, European Union, 2023)