Change Management and Responsible Adoption

Chapter 14 named the roles an AI programme needs; this chapter concerns the much larger group of people who must use the systems those roles design, approve and oversee. An architecture that is compliant, observable and well evaluated still fails if case officers route around it, engineers distrust it, or a works council halts it on launch day. The chapter applies diffusion of innovation and Kotter's model of leading change to AI, adds employee consultation, expectation management and culture, and closes with an adoption dashboard as code, extending the treatment of organisational change in Architecture as Code (Chapter 17) to AI (66, Nordqvist, 2025).

Most large organisations that stall with AI do not stall for lack of models, but because a pilot that impressed a steering committee never became part of how work is done: recommendations are accepted at a rate suggesting nobody reads them, or a drafting assistant is used daily by a third of the department and never opened by the rest.

These adoption failures are architectural in two senses. The architecture shapes adoption, because a system that explains itself, fails gracefully and leaves the user in control is adopted differently from one that does not. And adoption data is architectural evidence: the override rate, the share of recommendations that users reject or change, is the clearest signal of whether human oversight is real, and Chapter 17 shows how public authorities publish it in their algorithm registers. Adoption is therefore a property of the system that is designed, measured and governed, not a communications task bolted on at the end.

Primary topics explored

1. Adoption is the binding constraint
2. Diffusion of innovation applied to AI
3. Kotter's model and its AI-specific pitfalls
4. Employee consultation in European labour contexts
5. Communication and expectation management
6. Psychological safety and generative culture