Supplier, Contract and Sovereignty Tools

This chapter serves one activity: buying AI, binding the supplier to terms the buyer can check, deciding where a service may come from and run, and being able to leave. The tools are mostly artefacts, that is, records, schedules and annexes that the earlier volumes define (a vendor assessment record, a sovereignty requirements profile, an operations annex), with a small number of methods (the exit test, the injected-test clause, the choice of an operating model) and four third-party standards and frameworks (Gaia-X, the Cloud Sovereignty Framework, OpenAPI and AsyncAPI). They come from AI Governance (2, Nordqvist, 2026), AI Platform and Security (3, Nordqvist, 2026), AI Red Team (4, Nordqvist, 2026), AI Threat (5, Nordqvist, 2026), The Transformed Security Architect (6, Nordqvist, 2026), AI Boss (7, Nordqvist, 2026), AI Blue (8, Nordqvist, 2026), AI Purple (9, Nordqvist, 2026) and AI Operations (10, Nordqvist, 2026), and with Architecture as Code (1, Nordqvist, 2025) for interface contracts.

The tools sit on a line from the tender to the exit, drawn in Figure 9.1. Before award the buyer states what it needs and records what it received; in the contract it makes the terms testable; in operation it re-assesses when the supplier changes something and samples what the supplier's AI does; at exit it relies on a plan whose last test has a date and a result. The series' recurring claim is that a clause without a control that checks it is a promise the organisation cannot verify (2, Nordqvist, 2026). The entries below are therefore read as pairs: the clause or requirement, and the evidence that shows it holds.

Supplier lifecycle with exit test

Figure 9.1: Supplier lifecycle with exit test. The artefacts before award, in the contract, in operation and at exit, and the loops that send a change back to re-assessment and an exit test back into operation.

Laws are not tools and are not entered here. Where an entry rests on an instrument (the AI Act, DORA, NIS 2, the Data Act, Directive 2014/24/EU) the originating book attributes the statement to the article, and this chapter repeats the attribution as that book gives it, as an architectural implication and not as legal advice. The EU model contractual AI clauses, published by the Commission's Public Buyers Community for pilot use in two versions, one for high-risk AI systems and one for other systems (63, European Commission, 2023), are the nearest thing to a shared contract vocabulary; AI Governance describes them as a schedule of AI-specific terms and not a complete contract, and that is how they are treated here.

How the tools relate

Five families cover the 34 inventoried entries.

Procurement and vendor assessment records what the buyer asks for and what it has received: the vendor assessment record, the contract clause checklist, and the requirement annexes that three books wrote for different buyers (a security annex, a boundary annex, a security-AI annex and a requirement set for management functions).

Operational contract annexes turn the provider's duties during operation into terms that can be sampled and drilled: the provider annex for AI visibility (MS-2), the operations annex (OPA-*), and the methods that explain how to write them.

Sovereignty assesses origin, hosting and legal reach: the model-origin assessment record, the sovereignty requirements profile, the sovereignty decision matrix, the controls file for a cloud AI service, and two frameworks, Gaia-X and the Commission's Cloud Sovereignty Framework. Two records extend the assessment to the supplier's relationships and to the provider's own safety commitments.

Exit and concentration is the family of plans for leaving a supplier, with the exit test as the method that gives a plan its evidence.

Interface and data contracts are the technical form of an agreement between a producer and a consumer: the OpenAPI contract for a probabilistic service, the data contract for an AI data product and the AsyncAPI definition. They are the machine-checkable end of the same idea as the contract annex.

Procurement and vendor assessment

AI Governance begins from the observation that buying AI is buying an obligation, and that vendor assessment is routinely done badly: the security questionnaire is reused, a question about AI ethics is appended, and the vendor answers yes to everything (2, Nordqvist, 2026). The remedy the book gives is to ask for artefacts rather than assurances and to record the assessment in a form that can be re-run. Everything in this family follows from that.

Vendor assessment record
Kind Artefact
Origin AI Governance, Chapter 7
Purpose Assess a model provider against AI Act and contract criteria and record what was received, not what was claimed.
Use when Before contracting a model or AI service, and again when the gateway reports that the vendor changed the model version or the terms change.
Inputs The vendor's documentation, the contract terms, the organisation's own role under the AI Act, and the register-of-information entry for financial entities.
Outputs An outcome (for example approved_with_exception) with an exception owner and an expiry date.
Identifier family vendors/assessments/*.yaml
Full template AI Governance, Chapter 7, "The vendor assessment schema"

The schema records, per artefact, whether it was received and which provision of the AI Act it answers to, so that a missing artefact is a finding that blocks the contract or becomes a recorded exception with an owner. It also carries the contract terms that matter (training use, processing location, update notice, version pinning, incident notification, exit assistance) and the DORA fields for a financial entity. A model card is an artefact; a statement that the vendor follows responsible AI principles is not. The assessment is re-run on a cadence and whenever the model version changes. The template follows, quoted from AI Governance, Chapter 7, as published in the book's current version, with no field removed.

# vendors/assessments/model-provider-alpha.yaml
vendor_assessment:
  vendor: Model Provider Alpha
  offering: hosted general-purpose AI model, API access
  assessed: 2026-09-15
  ai_act_role_of_vendor: provider of a general-purpose AI model
  our_role: deployer
  artefacts_received:
    technical_documentation: {received: true, reference: AI Act Article 53(1)(a)}
    downstream_integration_information: {received: true, reference: AI Act Article 53(1)(b)}
    copyright_policy: {received: true, reference: AI Act Article 53(1)(c)}
    training_content_summary:
      received: false
      reference: AI Act Article 53(1)(d)
      finding: requested, not yet supplied
  contract_terms:
    customer_data_used_for_training: false
    data_processing_location: EU only
    model_update_notice_days: 90
    version_pinning_months: 12
    serious_incident_notification_hours: 24
    exit_assistance_months: 6
  dora:
    supports_critical_or_important_function: true
    register_of_information_entry: ROI-2026-031
    exit_strategy_reference: exit/model-provider-alpha.md
  outcome: approved_with_exception
  exception_owner: head_of_ai_platform
  exception_expires: 2027-03-31

Contract clause checklist
Kind Artefact
Origin AI Governance, Chapter 7
Purpose Check a model-supplier agreement for clauses on data use, model updates and audit rights, and pair each clause with the control that enforces it.
Use when Reviewing a draft master agreement before signature.
Inputs The draft agreement; the clause table (customer data use, processing location, model updates, documentation delivery, incident notification, audit and access rights, exit assistance); the DORA Article 30 provisions for a financial entity.
Outputs A status per clause (OK, GAP, MISSING) and a verdict on readiness for signature.
Full template AI Governance, Chapter 7, "Worked example: model-supplier contract clause checklist" (Markdown table)

The checklist keeps the AI-specific clauses and the DORA provisions in separate parts, because they have different owners and sources, and it notes where one contractual change closes both. In the book's worked example Hansa Mutual's review of draft v3 of its master agreement ends with "not ready for signature", four clauses missing and eight with gaps. The rule that makes the checklist more than a list is the one stated beside it: a clause the organisation cannot verify through its own gateway, evaluation service or evidence pipeline is recorded as a gap even when the wording is acceptable (2, Nordqvist, 2026).

Procurement security requirements annex
Kind Artefact
Origin The Transformed Security Architect, Chapter 20
Purpose Testable security requirements for a tender, with evidence obligations.
Use when Writing or renewing a tender for a system whose supplier the architect cannot inspect.
Inputs The control catalogue (CTRL-SUP-nnn supplier controls), the decision record for the procurement, the verification method for each requirement.
Outputs A versioned annex in which every requirement has an identifier, a level (mandatory or weighted), a catalogue link, a verification with an owner and a consequence on failure.
Identifier family SECREQ-* (for example SECREQ-NR-2026-117), requirements SR-nn
Full template The Transformed Security Architect, Chapter 20 (abridged excerpt of two of four requirements)

In the worked example the first requirement puts the stop path outside the supplier (named stop holders can suspend the ranking function without the supplier's staff or software taking part, verified by a drill at acceptance and in operation) and the second sets a log delivery time and a retention longer than the AI Act's six-month floor in Article 26(6), because appeals can arrive later (6, Nordqvist, 2026). The annex is published with a version number, and any part that would reveal the authority's defences is marked confidential. The book's practical guide also asks for a dry run against the incumbent's current system before publication, which is the step most easily skipped.

Tender annex for a supplier boundary
Kind Artefact
Origin The Transformed Security Architect, Chapter 7
Purpose Testable boundary requirements for a supplier, written as an annex.
Use when The boundary around a supplier's automated function is the control, and the buyer cannot inspect the supplier's code.
Outputs Five requirements (S4.1 to S4.5), each with a test the buyer can run without the supplier's cooperation, and a statement of verification rights.
Identifier family TA-* (for example TA-NR-S4)
Full template The Transformed Security Architect, Chapter 7

The five requirements cover a policy decision point that the supplier's model cannot configure, default-deny egress, per-job credentials that expire within 60 minutes, a stop path outside the supplier's system and an append-only copy of job and tool-call logs. The annex says that an unverified requirement counts as declared, with the remedy in the contract schedule. The book's comment is the useful one: a supplier that cannot satisfy the stop-path requirement has told the buyer something it needed to know before award (6, Nordqvist, 2026).

Supplier assurance requirements for security AI
Kind Artefact
Origin AI Red Team, Chapter 8
Purpose Contract-level requirements and evidence that a vendor's AI feature must meet before it is enabled in the security operations centre.
Use when Tendering for, or amending the contract of, a security service that embeds AI (a SIEM, an email gateway, a managed service).
Inputs The supplier's declaration of AI features, model provider and version, automatic actions and effective autonomy level, processing location.
Outputs A file that a tender evaluation can check key by key and that links the contract to change-triggered reassessment.
Identifier family NR-SUP-* (for example NR-SUP-SECAI-001)
Full template AI Red Team, Chapter 8 (the book's Appendix B lists it as planned; see Chapter 25)

The file declares what the supplier must state at tender and at every material change, sets automatic features to off until the buyer enables them, requires an action log delivered to the buyer's SIEM, and fixes change notification (30 days ahead for a model or feature change, 24 hours for an urgent security fix, an unnotified change counting as a breach). It names what the buyer may test and states that red teaming support runs under the buyer's rules of engagement. Its exit block lists what must be portable (detection rules, playbooks, action logs) and a six-month transition. AI Red Team adds that for security AI the realistic exit is often a fall-back to the process without AI and not a move to another vendor, so the plan must say how the operations centre works without the feature tomorrow; switching a feature off for a day in a controlled test turns that statement into evidence (4, Nordqvist, 2026).

Procurement requirement set for management functions
Kind Artefact
Origin AI Boss, Chapter 24, and Appendix B.15
Purpose Tender requirements, acceptance tests and contract conditions so that a public employer can meet safety, equality and public-law duties when it buys a system that manages people.
Use when Accepting a new release of, or retendering, a rostering, ranking or similar management system.
Outputs Requirements typed as specification, award criterion or review clause, each with its legal basis and (for specifications) a verification, plus a list of excluded features.
Identifier family NR-PRQ-MGT-01
Full template AI Boss, Chapter 24

The set is negotiated with the unions, tied to a delegation profile, and records a decision. Its requirements include constraints enforced as feasibility conditions and never as penalties, a technical stop held by the buyer with effect within one hour, logs of every roster, offer and override with rule and model version, an outcome export by contract type, sex and age band, an award criterion weighted for demonstrated constraint enforcement, and a review clause that makes the next change to a management function a contract procedure including the unions. It excludes Level 4 Autonomous for any consequence function, emotion inference and individual ranking of staff. The weights and retention periods are described by the book as illustrative (7, Nordqvist, 2026). The set is the template for any public employer that buys people-management AI; Chapter 22 treats the delegation profile it refers to.

Operational contract annexes

Procurement ends at signature, but the provider's AI keeps acting. The tools of this family are annexes written for the period after signature, and each carries the same four ingredients: a declaration of what the provider's AI does, evidence the customer can sample, notice of change and a stop right held outside the provider's platform.

Provider annex for AI visibility (MS-2)
Kind Artefact
Origin AI Blue, Chapter 16, and Appendix B.14
Purpose Make a managed provider's AI visible: levels, actions, evidence, sampling, audit and notice of change.
Use when A managed detection and response provider closes, isolates or escalates on the customer's behalf with its own AI.
Outputs Closure classes with a level per class and a never-list, quarterly sampling, audit rights, evidence fields, seeded-incident terms, model-change notice and exit terms.
Identifier family MS-2 (annex to agreement NR-2025-044)
Full template AI Blue, Appendix A, "Annex MS-2 to NR-2025-044"

The worked annex grants the provider Level 3 Bounded for narrow classes (closing reported bulk mail, closing scanner noise on public hosts, isolating an end-user workstation under a named playbook) and Level 1 Assisted for everything else. It excludes servers, accounts, citizen-facing services and disclosure. It sets a minimum of 100 sampled items per class each quarter returned within five working days, five seeded incidents per class per quarter that are not treated as incidents, a stop within 15 minutes by written instruction or credential revocation, 20 working days' notice of model change, and a four-hour notice of provider incidents so that the customer's reporting clocks can start (8, Nordqvist, 2026). The companion annex MS-1, on paging and detection-content ownership, is referred to in the book but not given as a template; that is recorded in Chapter 25.

Operations annex to a managed-service contract (OPA-*)
Kind Artefact
Origin AI Operations, Chapters 21 and 24
Purpose State what a provider's AI does, give notice of change, provide transparency and set exit-test terms so that the customer can check them.
Use when A cloud, managed or shared-service provider runs DNS, identity federation, a recovery site, paging or monitoring for the customer.
Outputs Terms for change notice, incident transparency (machine-readable status feed), observer rights, provider AI declaration with sampling, a stop right, a test calendar and an exit with a transition period.
Identifier family OPA-* (for example OPA-NR-SD-01)
Full template AI Operations, Chapter 24, "Worked example: contract annex for operational transparency and exit test"

The annex extends the six terms of Chapter 21 of that book. It also permits customer probes from other networks and a secondary authoritative name service at another provider, so that the customer's observer does not depend on the provider's platform. An abridged copy follows, with the fields status_and_incidents, tests and the closing publicity field removed, quoted from AI Operations, Chapter 24.

annex: OPA-NR-SD-01
agreement: NR-2026-088
decision: AIDR-0924
effective: 2029-03-01
services_in_scope: [external-dns, identity-federation, recovery-site, noc-paging]
change_notice:
  working_days: 20                  # any change affecting DNS, federation, paging or the recovery site
  emergency: {notice_within_working_days: 2}
  hold_on_request: true             # previous version stays in force during notice
observer:
  customer_probes_from_other_networks: permitted
  secondary_authoritative_dns: permitted   # zone transfer to a second provider
provider_ai:
  declaration: {actions: [alert_closure, paging, remediation], levels: stated, model_version: stated}
  sampling: {per_class_per_quarter: 50, return_working_days: 5}
  model_change_notice_working_days: 20
stop_right:
  held_by: [duty-manager, platform-lead]
  mechanism: customer revokes provider credentials in its own identity service
  provider_agents_cease_within_minutes: 15
  drill: quarterly
exit:
  exportable: [dns-zones, federation-metadata, recovery-site-config, runbooks-hosted-by-provider]
  transition_period_days: 90
  data_return_format: open
  erasure_certificate_after_retrieval: true
  exit_test: {per_year: 1, record: "RST-NR-*"}

Methods for writing the annexes

Four methods from AI Operations and AI Purple explain how the annexes are written and tested. They are procedures with purpose, roles, steps, an interval and a definition of done, and Appendix A lists each.

Method Origin What it does
Adding an operations annex to a managed-service contract AI Operations, Chapter 21 Asks the provider in writing which AI acts, assigns a level per action class with a never-list, names the evidence per action, sets the sample (default 50 actions per class each quarter), the notice (default 20 working days), and a stop right (default 15 minutes, tested quarterly), and runs the first sample, a seeded fault and a stop test within 90 days of signing.
Writing the operational transparency and exit-test annex to a cloud or managed contract AI Operations, Chapter 24 Draws the dependency map, sets change notice and incident transparency, secures the observer, declares the provider's AI, agrees a test calendar, writes the exit with the Data Act's Article 25 as the floor for data processing services, enters the arrangement in the register before signature and adds a pipeline gate that refuses routing to an unregistered provider.
Choosing an operating model by service criticality and sovereignty AI Operations, Chapter 21 Decides per service, and per operations function, who runs it and at what delegation ceiling, answers four sovereignty questions with dated evidence, and records the decision with exit criteria.
Operating model options AI Operations, Chapter 21 Compares in-house site reliability engineering, a platform team, centralised and embedded teams, managed providers, follow-the-sun and sovereign or national operators, and hybrids recorded per service.
Writing an injected-test clause for a managed-service contract AI Purple, Chapter 13 Gives each provider closure class seeds authored by someone other than the detection owner, sets a rate (default five seeds per class per quarter), states what the provider may and may not know, scores in numbers (one escape in a class opens a finding; two, or any escape in a class touching citizens or payments, suspends closure by that class until a re-test passes) and protects the seeds.

The injected-test clause is the one that most often fails in negotiation: a clause that lets the provider tell its staff which alerts are tests is not an injected test, as AI Purple says plainly (9, Nordqvist, 2026). The defaults in all five methods are the originating books' defaults and are meant to be adapted to volume, contract value and class risk.

Sovereignty assessment

Sovereignty in the series is not a label. AI Governance separates model origin from hosting, and AI Platform and Security writes sovereignty into tender profiles as criteria that can be verified. The tools here assess, require, decide and control.

Model-origin assessment record
Kind Artefact
Origin AI Governance, Chapter 6
Purpose Score the geopolitical risk of a model or provider across five risk categories: legal access, continuity, behaviour, supply chain and regulatory.
Use when Before a model or provider is approved, at a trigger event, and within twelve months.
Inputs The deployment mode, the parties in the chain with ultimate parent and jurisdiction, behaviour tests in every deployment language, provenance checks.
Outputs A score and rationale per category, an overall rating, a decision with controls and a review date.
Identifier family GEO-* (for example GEO-2026-017)
Full template AI Governance, Chapter 6

The overall rating is the highest category score, not the average. The practical guide in the book sets defaults for the behaviour tests (at least 200 prompts in every deployment language against a reference model, refusal rate no more than five percentage points above the reference) and says that they suit a large organisation handling personal data without a national security function. The record below is quoted from AI Governance, Chapter 6, where it is marked illustrative.

# assessments/GEO-2026-017.yaml - Hansa Mutual, illustrative example
assessment_id: GEO-2026-017
subject: {model: example-coder-32b, version: "2.1", licence: apache-2.0}
deployment_mode: self_hosted_weights
data_class_max: internal            # source code, no customer data
assessed: 2026-10-20
scores:
  legal_access: {score: 1, rationale: No prompts or telemetry leave Hansa; egress denied.}
  continuity: {score: 2, rationale: Held version runs indefinitely; fixes depend on the developer.}
  behaviour: {score: 3, rationale: "Political-topic refusals 11 points above reference in Chinese, not a deployment language."}
  supply_chain: {score: 3, rationale: "Safetensors, hash pinned; training data undocumented."}
  regulatory: {score: 2, rationale: Hansa likely provider of a minimal-risk internal system.}
overall: 3                          # maximum of the category scores
decision: approved_with_controls
controls: [egress_denied, no_tool_access, suggestions_reviewed_by_engineer, quarterly_behaviour_eval]
review_by: 2027-04-20

The example makes the book's point: how a model is run mattered more than where its developer is established, because a hosted service from the same developer would have scored 4 on legal access and been refused for anything beyond public data (2, Nordqvist, 2026).

Sovereignty requirements profile
Kind Artefact
Origin AI Platform and Security, Chapter 13
Purpose Weighted and mandatory sovereignty requirements for a tender, each stating how it will be verified.
Use when Tendering for a managed inference or similar service, so that the evaluation committee scores evidence and the platform team can check the same attributes after award.
Outputs Requirements with level (mandatory or weighted), weight and verification; a scoring rule under which a mandatory failure excludes the tender.
Identifier family procurement/profiles/*.yaml, requirements SOV-nn
Full template AI Platform and Security, Chapter 13

Only what the legal analysis makes non-negotiable is mandatory; everything else, including a Gaia-X self-description, is weighted, which keeps the tender open to competition in line with the equal-treatment principles of Directive 2014/24/EU. The excerpt is quoted from AI Platform and Security, Chapter 13, with the requirements SOV-02, SOV-03 and SOV-07 omitted as the book does.

# procurement/profiles/managed-inference-2026.yaml - Nordvik Region (illustrative)
apiVersion: ai-architecture.example.org/v1
kind: SovereigntyProfile
metadata:
  tender: NR-2026-031 managed inference for internal AI systems
  owner: chief-architect
requirements:
  - id: SOV-01
    level: mandatory
    text: All processing, storage and backups of customer data in the EEA
    verify: [contract-annex, region-pinning-policy-export]
  - id: SOV-04
    level: mandatory
    text: Inputs, outputs and logs are not used to train the supplier's models
    verify: [contract-clause]
  - id: SOV-05
    level: mandatory
    text: Open-weight models from the agreed list can be served, and weights exported on exit
    verify: [technical-demonstration, exit-plan]
  - id: SOV-06
    level: weighted
    weight: 15
    text: Machine-readable self-description of jurisdiction and data handling, e.g. a Gaia-X label
    verify: [self-description-file]
  - id: SOV-08
    level: weighted
    weight: 10
    text: Exit assistance of at least 12 months with data returned in open formats
    verify: [contract-clause, exit-plan]
scoring:
  mandatoryFailure: tender-excluded

Sovereignty decision matrix
Kind Artefact
Origin AI Platform and Security, Chapter 13
Purpose Weigh model origin and hosting options against the workload's data and risk class.
Use when At intake of every new AI workload.
Inputs The workload's data classification and risk class (supplied by classification as code in AI Governance, Chapter 8).
Outputs A placement per workload attribute: permitted, permitted with a transfer assessment, with a data protection impact assessment and key custody, preferred, not permitted or required.

The matrix has four hosting columns (hyperscaler EU region, hyperscaler with sovereign controls, European cloud or Gaia-X labelled, on premises or confidential computing) and six workload rows, from public information to national security or classified. The thresholds are explicitly the organisation's own to adjust. The matrix can be encoded as a rule set that the intake pipeline evaluates, so a change to a use case's descriptor re-evaluates its placement. Its most useful job, in the book's account of Nordvik Region, is to stop a workload going to the most convenient placement while the compliant one is not yet ready (3, Nordqvist, 2026).

Cloud AI service controls
Kind Artefact
Origin AI Platform and Security, Chapter 14
Purpose Contract and configuration controls required per cloud AI service.
Use when Before a production workload depends on a cloud AI service, and on every change of the provider's terms.
Outputs One file per service and platform covering retention, residency, versioning, deprecation, exit and regulatory position, with a review trigger.
Identifier family cloud-ai-service-controls.yaml
Full template AI Platform and Security, Chapter 14

The defaults in the book are at most 30 days' retention of prompts and outputs with no training use, EU or EEA processing for personal data, dated model versions with automatic upgrade disabled, 180 days' notice of deprecation for generally available models, an annual switch test and a 90-day review. The definition of done includes that the deployed configuration matches the file and that a substitute model has passed evaluation (3, Nordqvist, 2026).

Gaia-X and the Cloud Sovereignty Framework

Tool Kind Origin What the series uses it for
Gaia-X Third-party standard (association with policy rules, labels and a federated trust model) AI Platform and Security, Chapters 4 and 13 Machine-readable self-descriptions of jurisdiction and data handling, so that a sovereignty requirement becomes an attribute a pipeline can check (62, Gaia-X, n.d.).
Cloud Sovereignty Framework Third-party framework (European Commission, version 1.2.1, October 2025) AI Operations, Chapter 24 A vocabulary of eight sovereignty objectives and five assurance levels, lifted as questions for a tender (64, European Commission, 2025).

Both are used as vocabularies for tender questions and neither is a certificate of the series' own. AI Operations draws the limit for the Cloud Sovereignty Framework: it is described by its publisher as defining sovereignty objectives for the cloud services requested in the procurement procedure for which it was issued, without presenting itself as a legal requirement, and a level reached by a tenderer is a claim assessed on answers and evidence, which is a promise until tested. An exit test shows ease of migration and a stop drill shows operational control (10, Nordqvist, 2026). Gaia-X is likewise a basis for self-descriptions, not proof that they are true.

Supplier evidence request and supplier-exposure record

Two records from AI Threat extend the assessment to the supplier's commitments and relationships, and both are marked illustrative by the book.
Kind Artefact (two records) and one method
Origin AI Threat, Chapters 29 and 21
Purpose The supplier evidence request (SER-*, for example SER-HM-2026-01) derives each question to a model provider from a commitment in its published safety framework and says how each answer will be weighed. The supplier-exposure record (SXR-*, for example SXR-HM-2026-03) records the defence-sector exposure of a critical AI supplier, with facts, sources and dates, scenarios and the date a response was last tested.
Method Supplier defence-exposure assessment, which extends the model-origin assessment GEO-* with the supplier's defence exposure.
Full template AI Threat, Chapter 29 (worked example) and Chapter 21 (worked example)

The evidence request's acceptance rule states that provider answers are context and that acceptance rests on the buyer's own evidence; each unanswered item is recorded as a finding. The exposure record's value lies, as the book puts it, in the field response_tested, because a scenario whose response has never been exercised is a hope and not a control (5, Nordqvist, 2026).

Exit and concentration

Dependence is acceptable when it can be undone. Three books define an exit plan, and they define it with different emphasis; the overlap is recorded in Chapter 25.

Exit and substitution plan
Kind Artefact (plan), with the method of the exit test
Origin AI Governance, Chapters 6 and 7; AI Threat, Chapter 15; The Transformed Security Architect, Chapter 20
Purpose Keep a second source ready, so that a sanction, ruling or supplier failure is an operational event and not a crisis; for a procured system, say what leaves, how fast and what keeps the function running.
Use when For every system that handles confidential data or decides about people, and for every service in scope of a regulator's exit expectations.
Inputs Gateway routing by capability, a second source in a different jurisdiction or self-hosted open weights, versioned prompts per model, a portable evaluation suite.
Outputs A plan with triggers and a drilled switch time.
Identifier family EXIT-* (EXIT-004, EXIT-NR-01)
Full template None; the originating books describe the plan in prose and steps

AI Governance gives the most complete procedure. Route every call through the gateway by capability, choose a second source, run the portable evaluation suite monthly with a default acceptance of 90 per cent of the primary's task score, keep the second source warm with 1 to 5 per cent shadow traffic, write the triggers into the plan, and twice a year route one capability's traffic to the second source for a working day. The default switch times are ten working days for standard systems and two for critical ones, a default that The Transformed Security Architect takes over (2, Nordqvist, 2026) (6, Nordqvist, 2026). AI Threat uses EXIT-NR-* entries as the exit plan referenced from its dependency map, without defining the template (5, Nordqvist, 2026). The Transformed Security Architect adds the observation that for a procured system the realistic exit is often the process without the AI.

The exit test is the method that gives any of these plans evidence. In AI Operations it is recorded as a restore-test style record (RST-*) with a date, an elapsed time and a quality gate, so that a plan can be classified by the age of its last test. At Nordvik Region the first exit test missed its quality gate (0.87 against 0.90) and was scheduled for re-test, which is the outcome the method exists to produce before the exit is needed (10, Nordqvist, 2026).

Interface and data contracts

The technical contracts in this family belong to the same activity because they bind a producer to a consumer in a form that can be linted, versioned and tested. Each is an artefact or a third-party specification used as one.

API contract for a probabilistic service
Kind Artefact built on a third-party specification
Origin AI Platform and Security, Chapter 12
Purpose Express in an OpenAPI contract what a deterministic contract never needed to: calibrated confidence, provenance, the model that produced the answer, and refusal and fallback as first-class outcomes.
Identifier family openapi.yaml
Full template AI Platform and Security, Chapter 12

The specification is the OpenAPI Initiative's, a language-agnostic standard for describing HTTP APIs (66, OpenAPI Initiative, 2021). The series' contribution is the schema: a status enumeration (completed, partial, refused, fallback), a confidence field that is calibrated and not a raw token probability, a provenance block, the registry identifier, version and prompt version of the model, and a disclosure block. The book's versioning rule is the point to keep: a model change behind an unchanged contract is a minor version if the evaluation suite passes and a major version if it does not, and the consumer's contract tests, not the provider's assurances, decide (3, Nordqvist, 2026).

Data contract for an AI data product
Kind Artefact
Origin AI Platform and Security, Chapter 6 and Appendix A (06_CODE_CONTRACT)
Purpose Declare schema, quality, freshness, purpose and access terms between a data producer and an AI consumer.
Outputs A versioned contract with servers, schema (with personal-data flags), quality rules with severities, service levels, a legal block (lawful basis, residency, third-country transfer) and an aiUse block that says whether training, fine-tuning and evaluation are permitted.
Identifier family contracts/*.yaml (kind DataContract)
Full template AI Platform and Security, Appendix A

The book models the shape on the open data contract specifications of the data mesh community. In the supply context the useful field is aiUse, which states the purposes the producer permits and so turns a data-use clause into something an ingestion pipeline can enforce (3, Nordqvist, 2026).

AsyncAPI saga definition and the saga patterns

Architecture as Code (Chapter 8) declares API specifications and event schemas as code and registers them in a catalogue, so that tooling can flag a breaking change before production (1, Nordqvist, 2025). Its artefact is an AsyncAPI 3.0 document for an order-payment saga, given in JSON: one channel (order/payment/requested), a message with orderId, amount and currency as required properties and one send operation. AsyncAPI is a specification for message-driven APIs in a machine-readable format (65, AsyncAPI Initiative, 2023). The saga and event sourcing patterns, a method the same chapter names, break a long-running business transaction into local transactions, each of which publishes an event; the chapter treats them as patterns, not procedures with steps. They are relevant here only because they show what an event contract must carry.

Entries named but not developed

Entry Origin One-line purpose Treatment
Taking a supplier-default rule into the repository AI Blue, Chapter 6 Convert a supplier-default detection into a tested, owned record Method of detection engineering; belongs with Chapter 12, referred to here because it applies the provenance, access, tuning and simulation rights that Annex MS-2 contracts for
Risk-appetite statement, supplier and other templates listed as planned in Appendix B AI Red Team, Appendix B Index of templates marked planned An index only; several planned items already exist as worked examples in chapters (see Chapter 25)
Pact Architecture as Code Consumer-driven contract tests Inventoried as a passing mention; the text of the book does not use it as a tool (see Chapter 25)
OpenAPI and AsyncAPI as a pair Architecture as Code, Chapter 8 Contract-first specification of events and APIs Covered above under their artefacts

Across the usage modes

The contract form, and with it the clauses worth negotiating for, follow the usage mode (2, Nordqvist, 2026).

Usage mode Typical contract form Tools that matter most
Mode 0 Ambient AI Existing software agreement amended by the supplier Change control for new AI features; MS-2 and OPA-* style declarations; supplier assurance requirements for security AI
Mode 1 Conversational assistants Enterprise SaaS licence Vendor assessment record; cloud AI service controls; sovereignty matrix by data class
Mode 2 Embedded workplace assistants Add-on to an office suite agreement Inherited data terms; audit log access; cloud AI service controls
Mode 3 Agentic work tools SaaS licence with consumption pricing Data use for code and files; tool permissions; the boundary annex TA-*
Mode 4 Built AI applications API terms or negotiated model-supply agreement Clause checklist; vendor assessment; model-origin assessment; exit and substitution plan; OpenAPI contract
Mode 5 Autonomous production agents Negotiated platform and model contracts As Mode 4, with service levels, audit rights, a second source kept warm and a stop right outside the provider

Mode 0 is the case procurement most often misses because no purchase takes place: a supplier switches on an AI feature inside a licensed product. The remedy is change control in every existing agreement. On the degrees of delegation, the annexes of this chapter set the ceiling for the provider's AI: MS-2 and OPA-* allow Level 3 Bounded only for narrow, reversible classes and never for servers, accounts or the customer's stop path, and a provider's AI at Level 3 across clients is the case to write for because one change alters behaviour for every client at once (10, Nordqvist, 2026).

Nordvik Region and Hansa Mutual

Nordvik Region buys under public procurement law. Its sovereignty requirements profile is attached to tender NR-2026-031 for managed inference; its security annex for the benefits-triage renewal is SECREQ-NR-2026-117 and its boundary annex TA-NR-S4; its provider annex for the managed detection service is MS-2 to NR-2025-044; its management-function requirement set is NR-PRQ-MGT-01; and its operations annex to the shared-service agreement NR-2026-088 is OPA-NR-SD-01. Its constraint is that switching suppliers is expensive, so a weak exit clause becomes lock-in for years, and the first exit test recorded for its staff assistant missed its quality gate.

Hansa Mutual buys as a private group under financial-sector rules. Its clause checklist for Model Provider Alpha applies DORA Article 30, its model-origin assessment is GEO-2026-017, its exit plan EXIT-004 for claims correspondence has a European open-weight second source in Frankfurt that scored 0.89 against the primary's 0.94, and the drill in April 2026 took nine hours and exposed a GPU quota that was too low before a later drill switched in four hours. Its supplier records SER-HM-2026-01 and SXR-HM-2026-03 come from AI Threat. One group contract is used by seven entities, so Hansa's challenge is one contract that must satisfy seven regimes (2, Nordqvist, 2026).

How many entries are treated

All 34 inventoried entries of this chapter are accounted for: the principal artefacts have entries of their own, the methods, the two frameworks, the two AI Threat records and the three exit plans are treated in family tables or together, and the minor items are named in the closing table. Appendix A lists every entry with its identifier, origin and location. Four templates are quoted in full or in abridged form (the vendor assessment record, the model-origin assessment record, the sovereignty requirements profile and the OPA-NR-SD-01 annex); the others are linked by book and chapter.

Summary

This chapter's own conclusions follow. The tools for suppliers, contracts and sovereignty form one chain from tender to exit, and each link is useful in proportion to the evidence attached to it: a requirement states how it will be verified, a clause names the control that enforces it, an annex fixes a sample and a stop right outside the provider's platform, and an exit plan carries the date and the result of its last test. Sovereignty is handled by three separate tools that should not be confused: the origin assessment scores risk, the requirements profile and the matrix decide what a tender or a workload may use, and the frameworks (Gaia-X, the Cloud Sovereignty Framework) give a vocabulary whose claims remain promises until tested. The series defines the exit plan three times with different emphasis, and the annex for a managed provider twice under different identifiers, which a reader should take into account when choosing between them. A practitioner who must start from nothing can begin with the vendor assessment record, the clause checklist and the exit test, then add the operations annex when a provider's AI acts on the organisation's estate.

Sources

  1. Nordqvist, G. Architecture as Code. (1, Nordqvist, 2025)
  2. Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (2, Nordqvist, 2026)
  3. Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (3, Nordqvist, 2026)
  4. Nordqvist, G. AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. (4, Nordqvist, 2026)
  5. Nordqvist, G. AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities. (5, Nordqvist, 2026)
  6. Nordqvist, G. The Transformed Security Architect: Role, Craft and Career in the Age of AI in European Enterprises and Public Authorities. (6, Nordqvist, 2026)
  7. Nordqvist, G. AI Boss: When Artificial Intelligence Manages People in European Enterprises and Public Authorities. (7, Nordqvist, 2026)
  8. Nordqvist, G. AI Blue: How Artificial Intelligence Transforms the Blue Team in European Enterprises and Public Authorities. (8, Nordqvist, 2026)
  9. Nordqvist, G. AI Purple: How Red and Blue Learn Together When AI Joins the Loop in European Enterprises and Public Authorities. (9, Nordqvist, 2026)
  10. Nordqvist, G. AI Operations: How Artificial Intelligence Transforms IT Operations in European Enterprises and Public Authorities. (10, Nordqvist, 2026)
  11. Gaia-X European Association for Data and Cloud AISBL. Gaia-X: A Federated Secure Data Infrastructure. (62, Gaia-X, n.d.)
  12. European Commission. EU model contractual AI clauses to pilot in procurements of AI. (63, European Commission, 2023)
  13. European Commission. Cloud Sovereignty Framework, Version 1.2.1. (64, European Commission, 2025)
  14. AsyncAPI Initiative. AsyncAPI Specification 3.0.0. (65, AsyncAPI Initiative, 2023)
  15. OpenAPI Initiative. OpenAPI Specification v3.1.0. (66, OpenAPI Initiative, 2021)