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.

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.

Primary topics explored

1. Conway's law applied to AI
2. Three operating models
3. The AI platform team and enabling teams
4. Enablement team will
5. Enablement team will not
6. Exit criteria (all required)