Organisational Design for AI

Every item of the evidence that Chapter 11 described is produced by someone in a role, inside a team, under a reporting line, and Part IV turns to that organisation, beginning with its shape. An AI programme fails organisationally long before it fails technically: the platform is sound and the models evaluate well, yet nothing ships, because nobody can say who owns the use case, who may approve it, or who answers when it misbehaves. This chapter describes the operating models, the platform and enabling teams, and the place of the control functions. It ends with a team topology and a responsibility matrix expressed as code, because an operating model that exists only in an organisation chart cannot be tested.

Figure 12.1: Operating models for AI. The hub-and-spoke model separates the platform, enablement, and control functions and leaves use-case ownership with the teams closest to the business.

Conway's law applied to AI

Conway (1968) observed that organisations design systems whose structure copies their communication structure (59, Conway, 1968), and Architecture as Code (Chapter 17) applied the observation to infrastructure and platform teams (66, Nordqvist, 2025). AI systems obey the law with unusual fidelity because their data, models, infrastructure, policies and oversight are owned by different groups. Where those groups do not talk, the seam that is missing in the organisation is the one that fails in production.

A citizen-facing assistant built by a digital team with a vendor's model and a records office's documents typically lacks lineage and version trace, and the data protection officer learns of it at launch, not because anybody chose that design but because the organisation had no place where those concerns met. Organisational design for AI creates those places on purpose and codifies them so that they persist when people move on.

Three operating models

Most large organisations pass through three operating models as their AI programme matures. They are not mutually exclusive; the point is to choose deliberately and know the failure mode of the choice.

Centralised

In the centralised model a single AI team, often grown from a data science group, builds and runs every use case. It is the right start while use cases are fewer than engineers, and it gives consistency. Its failure mode is the queue. As demand grows, business units wait, the impatient ones build their own systems in the shadows, and the central team ends up accountable for systems it has never seen.

Federated

In the federated model each business unit or agency runs its own AI team under a thin layer of shared standards. It is fast and close to the domain, but units duplicate gateways and vendor relationships, interpret the AI Act differently, and the organisation cannot produce an inventory. Under Regulation (EU) 2024/1689, the AI Act, each unit that uses a system under its own authority is a deployer whatever the operating model (1, European Union, 2024), so federation does not reduce obligations; it multiplies the places where they must be met.

Hub-and-spoke

The hub-and-spoke model keeps a central hub that provides the platform, the standards and specialist support, while use cases are owned by the teams closest to the business. It is the model that scales; its failure mode is a hub that drifts into one of the other two, either building use cases itself or shrinking into a standards committee.

Dimension	Centralised	Federated	Hub-and-spoke
Use-case ownership	Central team	Business unit	Business unit, on the platform
Platform ownership	Central team	Each unit	Platform team in the hub
Obligation interpretation	Consistent	Divergent	Consistent, enforced by gates
Inventory and evidence	Complete while small	Fragmented	Complete, generated from pipelines
Typical failure	Queue and shadow AI	Duplication and divergence	Hub drifts to one of the others

The AI platform team and enabling teams

Skelton and Pais (2019) distinguish four team types, stream-aligned, platform, enabling and complicated-subsystem, and three interaction modes, collaboration, X-as-a-service and facilitating (69, Skelton & Pais, 2019). The hub is therefore not one team but at least two, interacting with the spokes in different modes.

The platform team

The AI platform team owns the gateway, model registry, evaluation service, guardrail library, observability stack and golden path templates. Controls are enforced there uniformly, because every model call passes the gateway and every new use case starts from a template that already carries the logging, guardrails and evidence hooks on which Chapter 11 relies. The team offers these as a service and measures itself by adoption. It does not build use cases, because the moment it does, it competes with its customers for its own capacity and the queue returns. It may host a complicated-subsystem team for specialist work such as fine-tuning, which also serves the spokes rather than replacing them (69, Skelton & Pais, 2019).

The enabling team

The enabling team, often called the AI centre of excellence, works in facilitating mode. It helps a stream-aligned team adopt the golden path, write its first evaluation set, classify its first use case and pass its first readiness review, and then it leaves; its success is measured by how quickly a team no longer needs it. A centre that reviews every use case indefinitely has become a control function in disguise, and one that builds use cases has become the central team. Its long-term form is a community of practice in which the spokes maintain the golden paths together.

Worked example: enabling team engagement charter

Illustrative example. Every engagement of Hansa Mutual's AI enablement team starts with a short charter, agreed with the receiving team's manager and committed to the enablement repository. Its exit criteria are stated in terms the competence framework of Chapter 14 can verify.

# Engagement charter: AI enablement x Motor Claims team
Engagement ID: ENG-2026-09 | Time box: 12 weeks (2026-09-01 to 2026-11-24)
Use case: UC-2026-022 Repair estimate review assistant
Sponsor: Head of Motor Claims

## Enablement team will
- Pair on intake, risk classification and the first AIDR.
- Co-write the first 150 evaluation cases and review the rest.
- Rehearse the readiness review once before the real gate.

## Enablement team will not
- Write production code, prompts or evaluation cases after week 6.
- Approve any gate, or act as on-call for the production service.

## Exit criteria (all required)
1. Readiness review passed with the team presenting.
2. Competence records show practitioner level in evaluation engineering
   for two team members.
3. The team has interpreted a failing evaluation result without assistance.

The "will not" list keeps the team in facilitating mode, and checkable exit criteria end the engagement when the capability has transferred rather than when the calendar runs out.

Stream-aligned teams and use-case ownership

The spokes are the stream-aligned teams in business units and agencies. They own the use case end to end, from the intake record and AI Decision Record to the evaluation set, oversight design and production service, and the accountable executive sits in their line, not in the hub. This is the point most often negotiated away, yet an accountable executive who owns the system will insist on evidence, whereas one who has delegated it to the hub will insist on speed.

Across the usage modes

End-to-end ownership by a stream-aligned team is the answer for built systems, but not for every usage mode of Chapter 2 (compared in the usage-mode matrix); the team that owns a mode is the one that controls its configuration.

Usage mode	Owning team	Role of the AI hub
Mode 0 Ambient AI	Owner of each affected application or supplier relationship	Register of supplier-enabled features; guidance
Mode 1 Conversational assistants	Digital workplace team	AI literacy and acceptable-use guidance
Mode 2 Embedded workplace assistants	Digital workplace team, with owners of mail and document stores	Logging; support for staged enablement
Mode 3 Agentic work tools	Developer platform team	Tool permission baselines with security
Mode 4 Built AI applications	Stream-aligned team	Platform as a service; facilitating enablement
Mode 5 Autonomous production agents	Stream-aligned team, with the business process owner	As Mode 4, plus a complicated-subsystem team for agent runtime

Do not hand Modes 0 to 2 to the AI hub because they carry the label "AI"; they are configuration of workplace products owned by the teams that run them. A Mode 5 agent needs an owner that can stop it at any hour, which keeps ownership with the team that runs the process. Chapter 13 sets out which forum approves each mode.

Worked example: RACI for a high-risk AI use case

Illustrative example. Nordvik Region's bought benefits-triage system orders applications for caseworkers and is high-risk under Annex III point 5(a) of the AI Act. In the matrix, R does the work, A holds the decision, C is consulted and I is informed; each activity has exactly one A.

Activity	Head of Benefits	Product team (spoke)	AI platform	Caseworker team leaders	Data protection officer	Model risk
DPIA and FRIA	A	R	C	C	C	C
Evaluation thresholds	I	R	C	C		A
Gateway and logging configuration	I	C	A, R			I
Oversight design and training	A	R		R	I	C
Go-live decision	A	R	C	C	C	C
Monitoring risks (Article 26(5))	A	R	C	R	I	C

The Head of Benefits holds the A everywhere except the evaluation thresholds, where model risk is accountable so that the builders do not set the bar they must clear, and the gateway configuration, which belongs to the platform. The caseworker team leaders are responsible, not merely consulted, for oversight training and monitoring, because they are the natural persons Article 26(2) of the AI Act requires the Region to assign.

Working with the control functions

Data protection, information security, legal and risk are neither spokes nor part of the hub. Their independence is protected by law and by the organisation's own governance, and the operating model must preserve it while keeping them out of the critical path of every change.

Independence by design

Article 38(3) of the GDPR requires the data protection officer to act independently and not to receive instructions regarding the exercise of their tasks (2, European Union, 2016). Placing that officer inside the platform team compromises independence, while leaving them outside produces the launch-day surprise. The resolution is to give each control function a defined gate in the production readiness review, where it signs off its own criteria against recorded evidence, and an input to the risk classification (Chapter 8), while decision rights stay with the accountable executive. The oversight persons that Article 26(2) requires, whose role Chapter 14 describes, are operational staff in the spoke, and the control functions verify that the assignment is real.

Gates instead of meetings

To keep the control functions effective without making them a queue, follow Architecture as Code (Chapter 11): express their requirements as checks that pipelines run, reserve their time for judgements automation cannot make, and route exceptions to them as records with owners and expiry dates (66, Nordqvist, 2025). ISO/IEC 42001 likewise has top management assign responsibilities and authorities and operate the management system as defined processes rather than ad hoc review (32, ISO/IEC, 2023).

Culture is a design input

Chapter 5 set out Westrum's typology of cultures. AI failures are probabilistic and are first noticed by oversight staff, and if reporting a bad output triggers blame, the reports stop. The operating model therefore needs an explicit, blameless path from an oversight observation to an incident record and a model evaluation, and leaders who are seen to reward the report.

Group and national entities

A multinational group, unlike a single authority, is a set of legal persons, each with its own board, supervisor, labour law and, outside the Union, its own AI regime, so it must settle which parts of the hub are group capabilities and which must exist in every entity.

What the group can own and what stays with the entity

The group can own what is the same everywhere and gains from scale: the platform, the baseline policy set, the evaluation service, complicated-subsystem teams, the enabling team and the model risk method. The entity keeps what the law ties to it: the accountable executive per use case, the oversight staff, the supervisory relationship, employee consultation and transparency towards customers. Solvency II assigns system-of-governance duties to each undertaking (184, European Union, 2009), and EIOPA expects insurers to set out roles and responsibilities for AI systems in proportion to their risk (185, EIOPA, 2025); a group team acting without a named counterpart in the entity satisfies neither.

Between the two sits a role many groups forget: a market liaison in each entity, usually in compliance, who maintains the market's policy overlay and translates group decisions into the entity's terms. A service centre binds each piece of work to the entity whose customer it concerns.

Employee representation shapes the topology

Rights of employee representatives differ by country, from co-determination in Germany to consent rights in the Netherlands and negotiation in Sweden, as Chapter 15 sets out. The group platform team cannot run the consultation, because it is not the employer; the entity runs it, with a consultation pack the platform generates from the system record, and a group-built assistant rolls out entity by entity.

Entities outside the AI Act

A UK subsidiary works under the UK GDPR (193, UK Parliament, 2018) and a sector-led approach to AI (188, DSIT, 2023); a Swiss subsidiary under FINMA's guidance, which expects an inventory, risk classification and clear responsibilities (192, FINMA, 2024); a Norwegian subsidiary receives the AI Act only once it is incorporated into the EEA Agreement (187, EFTA, n.d.). The design that works is one operating model and one set of role definitions, with these entities applying the group control baseline as group policy and their own regimes on top; treating them as out of scope creates a shadow operating model.

Worked example: group and entity responsibilities

Illustrative example. Hansa Mutual records the split between group and entity beside its team topology, and a validation job checks that every market in a system's applies_in has an entry.

# organisation/group-entities.yaml  (Hansa Mutual, illustrative)
group:
  headquarters: DE
  group_capabilities:
    owner: group_it_hamburg
    provides: [ai-platform, ai-enablement, baseline-policy-set, evaluation-service, agent-runtime]
  entity_rules:
    accountable_executive: one per use case per market
    oversight_staff: employed by the entity that serves the customer
    overlays: overlays/markets/<country>.yaml, maintained by the market liaison
  entities:
    - {market: DE, ai_act: law, representation: works_council_codetermination, liaison: compliance_de}
    - {market: NL, ai_act: law, representation: works_council_consent, liaison: compliance_nl}
    - {market: SE, ai_act: law, representation: trade_union_negotiation, liaison: compliance_se}
    - {market: NO, ai_act: group_policy_until_eea_incorporation, liaison: compliance_no}
    - {market: UK, ai_act: group_policy, local_regime: [uk_gdpr, pra_fca_expectations], liaison: compliance_uk}
    - {market: CH, ai_act: group_policy, local_regime: [revised_fadp, finma_guidance_08_2024], liaison: compliance_ch}
    - {market: PL, role: service centre, ai_act: law, serves: [DE, NL, SE, NO], work_bound_to: market_of_claim}
  rollout_gate:
    embedded_workplace_assistant:
      enable_only_where: consultation_status == completed
      consultation_status: {DE: completed, NL: in_progress, SE: completed, NO: not_started, UK: completed, CH: not_started}

The ai_act field labels the non-EU entities' evidence honestly as group policy, and the rollout gate makes the consultation a precondition the platform enforces.

Public-sector shared services

In public administrations the spokes are separate legal persons that cannot be reorganised by executive decision. The pattern that works is a shared-service body that hosts the platform and enabling teams and provides them to agencies under service agreements, in X-as-a-service mode, while each agency remains the deployer of its own systems with its own accountable executive, oversight staff and, for high-risk systems, its own registration duty under Article 26(8) of the AI Act.

Two design rules follow. The platform must be multi-tenant at the level of evidence, so that each agency can produce its own inventory, logs and readiness records without exposing another's. And the shared-service body must not become the accountable party by default. Letting it approve use cases for small municipalities is tempting but wrong, because the municipality remains the deployer and must explain its own systems to its citizens and auditors.

Worked example: shared AI platform service agreement

Illustrative example. Nordvik Region's digital services unit hosts the AI platform for the Region's departments and offers it to the municipalities within the Region. The excerpt is the machine-readable schedule of the agreement with one municipality.

# agreements/ai-platform/nordvik-municipality-eastby.yaml
service_agreement:
  id: SA-AI-2026-007
  provider_of_service: Nordvik Region digital services
  customer: Eastby Municipality
  interaction_mode: x-as-a-service
  services: [ai-gateway, evaluation-service, guardrail-library, observability]
  tenancy:
    isolation: separate tenant per municipality
    logs: stored in customer tenant, retention 180 days minimum
    inventory_export: customer can export own inventory and evidence at any time
  accountability:
    ai_act_role_of_customer: deployer for each AI system it uses
    ai_act_role_of_service_provider: neither provider nor deployer of customer use cases
    use_case_approval: customer accountable executive only
    eu_database_registration: performed by customer, AI Act Article 26(8)
    human_oversight_staff: assigned and trained by customer, Article 26(2)
  service_provider_duties:
    - notify customer of model changes behind the gateway 60 days in advance
    - provide logs and evidence within 5 working days of a customer request

The accountability section matters most: it leaves approval, registration and oversight staffing with the municipality, while the duties section commits the platform to supplying the logs and documentation the municipality needs to carry them out.

Sourcing and supplier dependence

Chapter 7 covers supplier contracts; the organisational question is which roles supplier staff may fill. Retain the roles that carry accountability or judgement against the supplier's interest: the accountable executive, the oversight staff that Article 26(2) of the AI Act requires a deployer to assign (1, European Union, 2024), the owner of evaluation thresholds, the seat in the design authority and the owner of each exit plan. Supplier staff can fill other roles under a named internal counterpart. Article 28 of DORA keeps financial entities fully responsible for compliance when they use ICT third-party service providers (3, European Union, 2022), and the switching rights of the Data Act (5, European Union, 2023) help only an organisation that retains people able to switch.

The transition path between models

Most organisations must reach hub-and-spoke without stopping delivery. From a centralised start, split the central team into platform and enabling teams and hand use cases to stream-aligned teams one at a time; from a federated start, begin with an inventory and a single gateway, then migrate each unit onto the shared platform.

Practical guide: handing a use case from a central team to a stream-aligned team

Purpose. Transfer ownership of a production AI system to the business team that uses it, without a gap in accountability, oversight or on-call.

Roles. The receiving accountable executive and team; the central team lead; the enabling team.

1. Confirm that the system runs on the platform's golden path; migrate it first if it does not.
2. Name the receiving accountable executive and update the responsibility matrix in a change signed by the old and new accountable roles.
3. Open an enabling engagement with a charter like the one above, time-boxed to one quarter by default.
4. Run four weeks of shadowed on-call, the receiving team leading, then rehearse one incident and one provider model update.

Definition of done. The inventory shows the receiving team as owner, it has led the rehearsals, and the central team appears in the matrix only as platform provider.

Codifying the topology

An operating model that lives only in slides drifts. The file below lets the inventory tooling validate that every use case has an owning team of the right type and every gate an assigned role; the matrix is deliberately short.

# organisation/ai-team-topology.yaml
topology:
  teams:
    - {name: ai-platform, type: platform, interaction_mode: x-as-a-service}
    - {name: ai-enablement, type: enabling, interaction_mode: facilitating, engagement_limit_weeks: 12}
    - name: claims-operations
      type: stream-aligned
      owns_use_cases: [UC-2026-014]
      accountable_executive: head_of_claims_operations
  control_functions:
    - {role: data_protection_officer, gates: [dpia-approved, oversight-roles], independent: true}
    - {role: information_security, gates: [threat-model-approved, guardrail-policy]}
    - {role: model_risk, gates: [risk-classification, evaluation-threshold]}
  raci:
    risk_classification: {R: stream-aligned, A: accountable_executive, C: model_risk, I: data_protection_officer}
    platform_change:     {R: ai-platform, A: head_of_ai_platform, C: information_security, I: stream-aligned}
    readiness_review:    {R: ai-enablement, A: accountable_executive, C: [data_protection_officer, information_security, model_risk]}
    exception_to_policy: {R: stream-aligned, A: model_risk, C: data_protection_officer}
  sourcing:
    retained_roles: [accountable_executive, oversight_staff, evaluation_threshold_owner, design_authority_seat, exit_plan_owner]
    supplier_staffed_team_requires: named_internal_counterpart
    max_supplier_share_per_team: 0.6

Three properties matter. The accountable role for use-case activities is in the spoke and for platform change in the hub, so a validation job can reject a use case whose accountable executive sits in the platform team. The control functions appear as consulted or accountable parties on gates, never as responsible for building. And the retained roles are listed, so a matrix that gives one to supplier staff can be rejected; the supplier share is a threshold each organisation sets for itself.

Nordvik Region and Hansa Mutual

Nordvik Region runs hub-and-spoke in a public body: the digital services unit is the hub, the social services department owns the use case, and accountability runs to elected politicians. As one legal person it has no entity layer to design, so its hard question is sourcing. It depends on TriageSoft and on the provider hosting its open-weight models, so the roles it retains are few but non-negotiable: the Head of Benefits, the caseworker team leaders who exercise oversight, and someone who can read a release note and run the evaluation gates.

Hansa Mutual has moved from federation towards hub-and-spoke, with the platform and enabling team in group IT in Hamburg and use cases owned in each subsidiary. Each subsidiary is a regulated undertaking whose board keeps the responsibilities Solvency II assigns at entity level (184, European Union, 2009), so the platform cannot absorb accountability that the law places in Stockholm, Amsterdam, Oslo, London or Zurich. Nordvik designs for scarce skills, supplier dependence and political accountability; Hansa designs for a group in which teams are shared but legal accountability is not.

Summary

Conway's law guarantees that an AI system will have the seams, and the gaps, of the organisation that built it, so organisational design for AI is architecture by other means: deciding where the groups that build and oversee a system meet, and codifying those meeting places so that they survive turnover.

The centralised model fails at the queue and the federated model at the inventory. Hub-and-spoke scales when the hub is a platform team in X-as-a-service mode and an enabling team in facilitating mode, with use-case ownership in the stream-aligned teams, and when the control functions keep their independence through gates and records. A multinational group adds an entity layer linked by market liaisons, and public administrations reach the same shape through shared-service bodies.

A topology and responsibility matrix in version control make the operating model something a pipeline can validate. Chapter 13 turns to where decisions are taken, from the management body to the design authority and the stop authority. Chapter 14 then turns to competence, including the AI literacy obligation of Article 4 of the AI Act.

Sources

1. Conway, M. E. (1968). How Do Committees Invent? Datamation, 14(4), pp. 28–31. (59, Conway, 1968)
2. Nordqvist, G. (2025). Architecture as Code. Companion volume to this book, published at aac.geon.se. (66, Nordqvist, 2025)
3. 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, 12 July 2024. (1, European Union, 2024)
4. Skelton, M. & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. Portland, OR: IT Revolution Press. ISBN 978-1-942788-81-2. (69, Skelton & Pais, 2019)
5. European Parliament and Council of the European Union. Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data (General Data Protection Regulation). Official Journal of the European Union, 4 May 2016. (2, European Union, 2016)
6. International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system. Geneva: ISO, December 2023. (32, ISO/IEC, 2023)
7. European Parliament and Council of the European Union (2009). Directive 2009/138/EC on the taking-up and pursuit of the business of Insurance and Reinsurance (Solvency II) (recast). Official Journal of the European Union, L 335, 17 December 2009. (184, European Union, 2009)
8. European Insurance and Occupational Pensions Authority (2025). Opinion on Artificial Intelligence governance and risk management. EIOPA, 6 August 2025. (185, EIOPA, 2025)
9. United Kingdom (2018). Data Protection Act 2018 (c. 12), with the UK General Data Protection Regulation. (193, UK Parliament, 2018)
10. Department for Science, Innovation and Technology and Office for Artificial Intelligence (2023). A pro-innovation approach to AI regulation (CP 815). UK Government, 29 March 2023. (188, DSIT, 2023)
11. Swiss Financial Market Supervisory Authority (2024). FINMA Guidance 08/2024: Governance and risk management when using artificial intelligence. FINMA, 18 December 2024. (192, FINMA, 2024)
12. European Free Trade Association. EEA-Lex factsheet 32024R1689: the Artificial Intelligence Act. EFTA. (187, EFTA, n.d.)
13. 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. (3, European Union, 2022)
14. 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, 22 December 2023. (5, European Union, 2023)