Preface

Why a CIO Needs an Engineering Book

Every AI quote that reaches a chief information officer has two problems, and they are the same problem seen from two sides. The first is the price: a number per person per month that scales with headcount whether or not anyone uses the thing. The second is where the data goes: into a system the institution does not run, through a model it did not choose, under terms it cannot audit. Most of the industry treats these as separate conversations, one for procurement and one for security. They are not separate. Both are consequences of a single architectural decision, made by the vendor, about who owns the stack.

This book is about making that decision yourself.

I have spent the last several years building and deploying AI platforms inside universities, companies and government agencies, and the pattern I see is consistent. The organizations that get the most out of AI are not the ones with the largest budgets or the earliest pilots. They are the ones whose leaders understood, early, that the model is a commodity, that the data must stay where it lives, and that the applications their people use should be built on an identity and agent layer the institution controls. Everything else follows from those three convictions.

I call the discipline of acting on them sovereign AI engineering. Sovereign because the institution holds the code, the data, the model choice and the keys. Engineering because sovereignty is not a policy statement or a procurement clause. It is a set of design decisions about where tokens live, how a connector reaches a system of record, what a harness is allowed to do, and how a new application gets built without anyone handling a secret.

The audience is the CIO and the people who report to them: the enterprise architect, the CISO, the head of data, the director of infrastructure. I assume you have signed software contracts and regretted some of them. I assume you have been asked by a board or a cabinet what happens to the institution's data when it is sent to an AI vendor, and that you would like a better answer than the one in the vendor's trust center. I do not assume you write code, but I do assume you want to know what the engineers are deciding on your behalf.

The book is organized by layer. Part I makes the case that the current model is breaking, and defines sovereignty in terms you can verify. Part II is about models: why the frontier is not where your value is, how to route among providers, and what hardware you can actually buy and put in a rack. Part III is about data: why migration projects fail and how connectors built on the Model Context Protocol read live data through a broker that holds the credentials. Part IV is about clients: how one backend serves the web, a Chrome side panel, desktop and mobile apps, and the terminal, all sharing one identity system that never puts a secret in an application. Part V is about agents: what a harness is, which attributes make it trustworthy, and what a headless application looks like once the subscription software it replaces is gone. Part VI is the operating model, from the first pilot to the exit clause you will never need to use.

Each chapter ends in numbers where numbers exist. Where they do not, I say so, because the second most expensive thing in this field, after lock-in, is a confident figure that nobody measured.

I have tried to write a book that will still be useful when the model names in it are forgotten. The specific products will change. The architecture, if it is built on ownership, will not have to.

Miguel Amigot New York, 2026