AI Governance · Module 4 · Organisation and Leadership

Organisational Design for AI

The lesson treats organisational design for AI as architecture by other means. Participants compare the centralised, federated and hub-and-spoke operating models and their failure modes, distinguish the platform team from the enabling team, place the control functions at gates, and split responsibilities between a group and its entities. They finish with a RACI for a high-risk use case and a team topology that a pipeline can validate.

Lesson 12 of 26Chapter 1275 minutes

Read the chapterThe whitepaperThe slides

All courses / AI Governance / Module 4 / Chapter 12

Learning objectives

After the lesson the participant can:

Key concepts

Hub-and-spoke model
A central hub provides the platform, the standards and specialist support, while use cases are owned by the teams closest to the business. Its failure mode is a hub that drifts into building use cases itself or shrinks into a standards committee.
AI platform team
Owns the gateway, model registry, evaluation service, guardrail library, observability stack and golden path templates, offered as a service. It does not build use cases, because it would then compete with its customers for its own capacity and the queue returns.
Enabling team
Often called the AI centre of excellence, it works in facilitating mode: it helps a stream-aligned team through its first use case and then leaves. Its success is measured by how quickly a team no longer needs it.
Retained roles
Roles that carry accountability or judgement against the supplier's interest and must not be filled by supplier staff: the accountable executive, the oversight staff, the owner of evaluation thresholds, the design authority seat and the owner of each exit plan.
Market liaison
A role in each entity of a group, usually in compliance, that maintains the market's policy overlay and translates group decisions into the entity's terms, linking group capabilities to the accountability the law ties to the entity.

Interactive exercises

Do them here and get feedback at once. Choose a card and then where it belongs, or drag it.

Interactive exercise 1 · Sort

Three operating models

Sort each statement under the operating model for AI that it describes.

Interactive exercise 2 · Scenario

The enabling team is asked to stay

Apply Hansa Mutual's engagement charter and the chapter's account of the enabling team.

Teaching plan

10 minOpening: participants sketch who owns data, model, infrastructure, policy and oversight for one of their AI systems and mark where those groups never meet.
20 minTeacher presentation of the three operating models, the platform and enabling teams, stream-aligned ownership, control functions at gates and the group and entity split.
10 minGroup reading of Hansa Mutual's engagement charter for the Motor Claims team: why the will-not list and the exit criteria matter.
25 minExercise in groups: build a RACI for one high-risk use case and list the retained roles.
10 minDebrief: groups check each other's matrices for activities with two accountable roles or none, and for builders setting their own thresholds.

Discussion

  1. In Nordvik Region's matrix, model risk is accountable for the evaluation thresholds so that the builders do not set the bar they must clear. Who sets that bar in your organisation today?
  2. An accountable executive who owns the system will insist on evidence, whereas one who has delegated it to the hub will insist on speed. Where have you seen this, and what did it cost?
  3. A shared-service body must not become the accountable party by default for small municipalities. Why is that tempting, and what goes wrong when it happens?

Written exercise

Exercise · 25 minutes

A RACI for a high-risk use case

Take a high-risk or otherwise consequential AI use case in your organisation, or Nordvik Region's bought benefits-triage system. List six activities: impact assessments, evaluation thresholds, gateway and logging configuration, oversight design and training, the go-live decision, and monitoring of risks. Name the roles involved, including the business owner, the product team, the AI platform, the people who exercise oversight, the data protection officer and model risk. Fill in R, A, C and I so that each activity has exactly one A. Then state which operating model you run today, its failure mode as you observe it, and which five roles you would never hand to supplier staff.

Deliverable: A six-row RACI with exactly one accountable role per activity, a one-paragraph diagnosis of the current operating model, and a list of retained roles.

Self-test

Choose an answer to see whether it is right, or open the answer below each question.

  1. What is the typical failure of the federated operating model, according to the chapter?

    Show the answer

    C. Duplication and divergence, with an inventory the organisation cannot produce
    In the federated model units duplicate gateways and vendor relationships and interpret the AI Act differently, and the organisation cannot produce an inventory. The centralised model fails at the queue.

  2. Why should the AI platform team not build use cases?

    Show the answer

    A. Because it then competes with its customers for its own capacity and the queue returns
    The platform team offers its components as a service and measures itself by adoption. The moment it builds use cases it competes with its customers for its own capacity, recreating the central team's queue.

  3. In Nordvik Region's shared platform service agreement with Eastby Municipality, who approves the municipality's use cases?

    Show the answer

    D. The municipality's own accountable executive only
    The accountability section leaves approval, registration and oversight staffing with the municipality, which remains the deployer. The service provider is neither provider nor deployer of the customer's use cases.