A scored assessment in five sections, one per property of the framework. Each statement is scored 0 (false), 1 (partly true or true for a pilot only), or 2 (true across the estate and verifiable today). Thirty statements, sixty points. The bands at the end map a total to a level in Appendix A. The assessment is designed to be completed by the CIO with the enterprise architect, the CISO and the head of data in one sitting; disagreements about a score are usually the most valuable output.
Section 1: You own the code
| # | Statement | Score |
|---|
| 1.1 | Our engineers can read the complete source of the AI platform we use, including backend services and infrastructure definitions, today. | |
| 1.2 | The license permits us to modify the source and run the modified platform in production. | |
| 1.3 | Our engineers have built the platform from source at least once in the last year. | |
| 1.4 | Our engineers have deployed the platform to an environment we control without vendor hands on keyboards. | |
| 1.5 | The platform that runs in the vendor's cloud is the same code, byte for byte, as the one we can deploy ourselves. | |
| 1.6 | If the vendor ceased to exist tomorrow, the platform would keep running and we could patch it. | |
Section 2: You own the data, in place
| # | Statement | Score |
|---|
| 2.1 | AI agents read our systems of record at query time rather than from a copy ingested in advance. | |
| 2.2 | Every connector between an agent and a system of record runs on infrastructure we control. | |
| 2.3 | The credentials connectors use to reach our systems live in a secret store we control, never in an agent or a client. | |
| 2.4 | Tool calls are denied by default and allowed by an explicit, versioned policy table we administer. | |
| 2.5 | Every tool call is written to an audit log we own, with user, agent, tool and decision. | |
| 2.6 | No copy of our institutional data exists in the vendor's infrastructure that we could not delete today. | |
Section 3: You choose the model, and can change it
| # | Statement | Score |
|---|
| 3.1 | The model behind any agent can be changed by an administrator in a settings screen without engineering work. | |
| 3.2 | We have switched a production agent's model at least once and measured the result against an evaluation set. | |
| 3.3 | At least two commercial providers and at least one open-weight model are configured and routable. | |
| 3.4 | Routing rules can confine data of a given classification to approved models, and the rules are enforced by the platform. | |
| 3.5 | A fallback chain exists so that a provider outage does not stop our services. | |
| 3.6 | We see model spend by agent, by model and by day, against a cap we set. | |
Section 4: Your clients share one identity
| # | Statement | Score |
|---|
| 4.1 | Every client of the platform, web, browser extension, desktop, mobile and terminal, signs in through one hand-off using our institutional identity provider. | |
| 4.2 | No client application, ours or the vendor's, holds an organization-level credential. | |
| 4.3 | A team can build a new application on the platform with institutional single sign-on, roles and organization scoping without writing authentication code. | |
| 4.4 | The sign-in flow exists in one shared component, so a security fix lands in every client at once. | |
| 4.5 | Multi-organization membership, switching and visiting are handled by the shared identity layer, not by individual applications. | |
| 4.6 | An agent's memory, guardrails and approval behaviour are the same on every surface because the components are shared. | |
Section 5: Your agents run inside a harness you can inspect
| # | Statement | Score |
|---|
| 5.1 | We can read the harness that runs our agents: the loop, its tools, its limits. | |
| 5.2 | Every run has a step limit and a token budget, and a human can stop it at any time. | |
| 5.3 | Approval modes exist and are set per agent, so consequential actions can require a human. | |
| 5.4 | Agent memory is held in three scopes in our own database, and each person can see and switch off their own. | |
| 5.5 | Code an agent writes runs in a sandbox on our infrastructure with an explicit network boundary. | |
| 5.6 | We have tried to violate a governance rule from the chat window and the infrastructure, not the model, refused. | |
Scoring
| Total | Level | Reading |
|---|
| 0 to 12 | 1, Rented | The vendor runs the estate. Begin with Section 1: without the source, the rest cannot be fixed. |
| 13 to 24 | 2, Configured | Institutional identity and administration exist; the structure is still the vendor's. The deciding move is a source-licensed deployment into infrastructure you control. |
| 25 to 40 | 3, Deployed | The two problems from Chapter 1 are solved for the deployed estate. Close the gaps in Sections 2 and 5, then rehearse the exit. |
| 41 to 52 | 4, Owned | The institution could run without the vendor. Prove it quarterly and add local models for restricted data if not yet done. |
| 53 to 60 | 5, Sovereign | Verify the air-gapped build annually. The remaining work is operational discipline, not architecture. |
Using the result
Score the estate, not the best pilot. Record who scored each statement and why; a 1 that one person thinks is a 2 is a conversation worth having. Re-score every quarter alongside the exit verification from Chapter 20, and keep the history: the trend is the real measure of a sovereignty programme, and it is the figure a board understands.
Run the stack this book describes
ibl.ai is the agent operating system you run yourself: you own all the code and the data, in your cloud, on-premise or air-gapped, with any model, one identity across web, browser, desktop, mobile and terminal, and no per-seat pricing.