Nordvik Region and Hansa Mutual: Platform and Security Conclusions

Every chapter of this book has ended by asking what its subject meant for Nordvik Region and Hansa Mutual; this chapter collects those answers into one platform and security conclusion for each. Nordvik, a Nordic regional authority of about 6,000 staff, mostly buys its AI and runs a reduced platform around a procured high-risk system. Hansa, a Hamburg-based mutual insurer of about 9,500 people with entities in seven countries, builds most of its AI on one group platform and lets agents act on production systems. For each, the chapter records the decisions of Chapters 1 to 23, what worked, what was hard, and the next 24 months; conclusions it draws for itself are marked as such.

Nordvik Region runs a reduced platform around a procured system and on-premises inference with one evidence store; Hansa Mutual runs a group baseline on a shared platform with market overlays, a Polish service centre and per-market evidence

Figure 24.1: A reduced platform around a procured core for Nordvik Region; a group baseline with market overlays on one shared platform for Hansa Mutual.

Nordvik Region

Starting point

For the platform, Nordvik Region's legal position comes down to a short list of things to evidence. Ranking applications for essential public assistance puts the benefits-triage system in Annex III point 5(a) of the AI Act, so the Region must show what Articles 26, 27 and 49 ask of a deployer: monitoring and logs, a fundamental rights impact assessment and registration (1, European Union, 2024). Its processing rests on Article 6(1)(e) of the GDPR, and health and social-care workloads carry Article 9 data (2, European Union, 2016), which pins some of them to its own hardware. NIS 2 applies as transposed nationally to the extent that regional government is in scope (4, European Union, 2022), and public procurement law governs almost everything the Region buys (9, European Union, 2014). Since the high-risk system comes from TriageSoft under tender NR-2026-117 and the engineering team is small, Chapter 4 placed the Region's leverage in the gateway and in the evidence its contracts can require.

Platform and security decisions across the book

Platform shape. The public-authority overlay of Chapter 4, recorded in AIDR-0002, states only what differs from the reference model: national placement, external connectors limited to the European Economic Area, a FRIA workflow, and 120 months of archived evidence. On top of it runs Chapter 4's reduced variant, which keeps the gateway, the registry and the acceptance suites, reuses existing identity, logging and archive services as the control plane, and leaves out an agent runtime.

The procured high-risk core. AIDR-0007 accepted the ranking model, AIDR-0011 designed oversight, and AIDR-0018 replaced the model version (Chapter 5). Caseworkers see a band and three reasons rather than a score, and team leaders can suspend ranking so that the queue reverts to arrival order within five minutes. When parity drifted to 0.06 for 61 days against a retirement criterion of 0.05 for 60 days, AIDR-0018 removed postcode features and promoted version 4.0.0, with parity at 0.02. Because removing features lies outside the change envelope of Chapter 7, the change needed a new record and an updated FRIA instead of passing as planned retraining under Article 43(4) (1, European Union, 2024).

Placement and security. Chapter 13 placed the triage system on premises, and the staff assistant, under AIDR-0211, on an open-weight model served by a European cloud provider under contract NR-2026-031, EEA only, with customer-held keys. Correspondence summaries, UC-2026-017, were postponed until two additional accelerators are installed, and Chapter 15 sends all agentic work above internal to one pinned self-hosted code model. The staff assistant acts through five-minute delegated tokens carrying the officer's identity (Chapter 12), no agent holds credentials for the triage system (Chapter 19), and the incident runbook of Chapter 21 notifies the supplier under Article 26(5), the data protection authority and, where NIS 2 applies, the national CSIRT.

Usage-mode profile

The platform carries Nordvik's systems almost entirely in Mode 4: the triage system, the staff assistant and the citizen-service assistant of AIDR-0014. Below that, its control points are contracts and configuration: Mode 0 features that suppliers enable, a Mode 2 embedded-assistant pilot, and Mode 1 only through the approved enterprise tool. Mode 3 is one coding agent in the platform team, and the register excludes Mode 5 altogether (Chapter 2). That narrowness lasts, as Chapter 19 points out, only as long as something enforces it.

What it built first

The reduced variant of Chapter 4 is, in effect, the Region's build order: the gateway, a registry, acceptance suites the authority owns, and the decision-record repository of Chapter 5, with model-building left to the supplier. The first service on it was the staff assistant, piloted with about 2,400 staff and extended to about 3,200 (Chapter 23).

What worked

Four artefacts did what they were written to do. The change envelope meant that when parity breached, the Region already had a route, with a shadow period and a revised FRIA, instead of an emergency. Residency enforced by configuration, down to the deployment profile's egress: deny-all, gives an auditor something to test. The statement of applicability in Chapter 9 honestly records two inference nodes that ran an unpinned serving image for six days. And the golden dataset of Chapter 20 includes 620 claims from the five groups the FRIA names, so a vulnerable-group slice passing at 0.903 against 0.90, with an interval crossing the threshold, is added to human review rather than declared safe.

What was hard

Contract leverage. Control over model versions, patches and incident information lives largely in the triage contract: Chapter 18 shows the patch window set by supplier release cycles, and the usage-mode register (AI Governance, Chapter 2) records the supplier-notice clause for ambient features as only partly met (73, Nordqvist, 2026).

Capacity, skills and cost. Keeping special-category data on its own hardware means the correspondence pilot waits for accelerators, so capacity, not policy, decides when a compliant placement becomes available. A small team must patch and upgrade models it would otherwise buy as a service (Chapter 14), and the register still records sandbox_fail_closed: missing for the coding agent (Chapter 2), the containment property Chapter 19 treats as non-negotiable. The Chapter 22 showback, finally, shows the eligibility-explanation route carrying 40 per cent of spend for 13 per cent of resolved enquiries.

A prioritised platform and security plan for the next 24 months

The sequence respects what each step depends on and the date from which Annex III high-risk obligations apply, 2 December 2027 since the Digital Omnibus on AI (23, European Union, 2026).

  1. Within six months, contain what already acts. Make the coding agent's sandbox fail closed, apply the Chapter 19 baseline, and add admission control that refuses unpinned serving images.
  2. Within six months, rehearse the incident path. Exercise the triage suspension switch and the incident runbook, including notification to TriageSoft.
  3. Before 2 December 2027, close the deployer evidence gap. Renegotiate at renewal for version notices, incident notification and patch service levels, and complete EU database registration.
  4. Within twelve months, install the accelerators and take UC-2026-017 through the self-hosting readiness gate of Chapter 14.
  5. Throughout, test the staff assistant's exit yearly and scale the Mode 2 pilot only once sensitivity labels are enforced.

The gate across the period is unchanged: no Mode 5 agent without containment, an independent stop path and evaluation evidence.

Hansa Mutual

Starting point

Hansa Mutual started with engineers, a group IT function in Hamburg and a data centre in Frankfurt. Its constraint was breadth: the platform serves insurers in Germany, the Netherlands, Sweden, Norway, the United Kingdom and Switzerland and a claims service centre in Poland, each with its own supervisor. Because it assembles compound systems on vendor models, Hansa provides those systems and deploys the general-purpose models inside them, and the life and health underwriting-support model counts as high-risk under Annex III point 5(c) (1, European Union, 2024). In the EU entities DORA adds ICT risk, incident and third-party duties (3, European Union, 2022). Where Nordvik steers through contracts, Hansa steers through the platform.

Platform and security decisions across the book

The claims assistant as platform pattern. AIDR-0021 chose retrieval over fine-tuning after keyword search found the right clause in 61 per cent of test questions against 88 per cent for retrieval (Chapter 5). The component manifest of Chapter 4 declares appliesIn: [DE, NL, SE, NO, UK, CH] and processedIn: [DE, PL], and the promotion gate of Chapter 7 slices results by product line and language and treats a provider's version notice as a change to Hansa's system. AIDR-0012 governs the DevSecMLOps loop of Chapter 8, under which a prompt release passed as a DORA Article 9 change, and risk entry HM-LOOP-04 of Chapter 9 records three of 41 build images still allowing install scripts.

Agents. The claims-triage agent of AIDR-0024 reaches the core claims system only through a registered MCP server that prohibits agent use of reserve.set and requires an acting user (Chapter 11). The IT-operations agent of AIDR-0027 followed a recommend-only pilot that proposed the right action in 91 per cent of cases but cut restore time by only six minutes; it now acts under a deny-by-default manifest, contained per Chapter 19 in a per-incident microVM with no cluster credentials and a stop contact per market. The claims triage assistant UC-2026-014 went live under AIDR-0034 as a conditional go, with expansion only after exceptions EXC-112 and EXC-113 close (Chapter 23).

Placement and operations. The capacity plan of Chapter 13 reserves eight accelerators in Frankfurt and four in an EU cloud region, and Chapter 14 chose a self-hosted baseline for claims-correspondence summarisation with cloud burst only for claims without health data. Every gateway log line records the affected entity, so the playbook of Chapter 17 can list the authorities to notify, and evaluation, traces and showback are partitioned by market (Chapters 20 to 22).

Usage-mode profile

Every row of Chapter 2's baseline applies to Hansa. The claims assistants and the high-risk underwriting-support model are Mode 4; the claims-triage and IT-operations agents are Mode 5; engineers use Mode 3 tools daily under classification routing; Mode 2 assistants are deployed group-wide, Mode 1 runs on enterprise tiers and Mode 0 comes with licensed software. For Hansa the modes therefore describe an estate to be contained rather than a set of options.

What it built first

Hansa Mutual proved the shared platform on the claims assistant, whose artefacts the golden path of Chapter 23 generalises. The market dimension was in the first manifest, not added later, and that choice made the rest of the multinational design possible.

Seven jurisdictions, one platform

The legal analysis of Hansa's footprint is concluded in AI Governance, Chapter 23 (73, Nordqvist, 2026); the platform needs only its consequences. Four EU entities answer to different supervisors, so evidence must be routable per supervisor. Norway takes EU law only once it is incorporated into the EEA Agreement, and the AI Act is still listed as under scrutiny (241, EFTA, n.d.), so its overlay carries a status field. The British and Swiss entities sit outside DORA (3, European Union, 2022) and, unless the output of their AI systems is used in the Union under Article 2(1)(c) (1, European Union, 2024), outside the AI Act, so their evidence is labelled as group policy over their own law. And German works councils co-determine the introduction and use of technical systems designed to monitor employees' behaviour or performance, as Section 87(1) no. 6 of the Works Constitution Act provides (207, Germany, 2001); the Federal Labour Court holds that a system is designed for that purpose if it is objectively suitable for collecting or recording such information, whatever the employer intends (249, Bundesarbeitsgericht (Federal Labour Court of Germany), 2024). The approval policy's record of approval speed per approver is such a system, so rollout gates run per entity.

Overlays and bindings as policy as code

Chapter 4 sets out the mechanism: a group baseline and a market overlay per entity that may tighten the baseline but never relax it. The later chapters added the binding that makes the overlays bite: the policy engine selects overlays from a system's appliesIn and checks every location in processedIn against them, so a change routing UK claims through Poland would fail before deployment. Each legal change therefore lands as a reviewed pull request against one overlay.

The Polish service centre as a control boundary

The platform's controls attach to the claim rather than to the building: confidential claims data is routed only to the self-hosted tier in Frankfurt (Chapter 15), the MCP server limits claim.get to claims assigned to the acting user (Chapter 11), and the claims adapter refuses a token whose entity does not match the claim's market (Chapter 12). This chapter's own conclusion is that the agent's permissions, log retention and notification route must follow the claim's market wherever the server stands. One gap follows: the agent also serves the Norwegian market (AI Governance, Chapter 16A), where the AI Act applies only once incorporated into the EEA Agreement, so its binding there must be recorded separately.

The United Kingdom, Switzerland and DORA

The UK overlay of Chapter 4 treats the AI Act as group policy and evidences the Data Protection Act 2018 (248, UK Parliament, 2018) and the PRA and FCA resilience regime. The Swiss equivalent, under the revised Federal Act on Data Protection (244, Swiss Confederation, 2020) and FINMA's guidance on AI governance (246, FINMA, 2024), exists so far only as gateway configuration. Transfers rest on the adequacy decisions for the United Kingdom (243, European Commission, 2025) and Switzerland (245, European Commission, 2000), which Chapter 13 treats as dependencies with an owner and a review date.

Because DORA binds four entities, its flag sits in each market overlay, not in the group baseline, and it appears on the platform as artefacts (3, European Union, 2022): Article 9 change management as the promotion gate, Article 28 third-party risk as exit strategies made real by the open-weight fallback, and Article 19 incident reporting as the per-entity runbook row.

What worked

Measured decision records held up best: the baselines in AIDR-0021 and AIDR-0027 replaced opinion with numbers, and AIDR-0027's rule that one out-of-manifest action suspends the agent makes the control, not the agent, carry the burden of proof. The market dimension worked because it was declared early: manifest, route, event, evaluation, traces and showback all carry it. And bounded autonomy worked as layers, with the MCP registration, manifest, approval policy and containment profile each enforcing something the others cannot.

What was hard

A shared attack surface. On a platform serving seven markets, an agent that exceeds its mandate can touch data held for several entities at once (Chapter 19), and one unpatched inference server or permissive build image has group-wide reach (Chapter 18).

One incident, several legal processes. Chapter 17 concludes that Hansa must route one incident within hours into DORA Article 19 for the EU entities, Article 73 of the AI Act where it provides a high-risk system (1, European Union, 2024), the lead data protection authority, and the UK and Swiss regimes.

Scaling market by market. Each new market is a new readiness review (Chapter 23), and a group average can hide failure in one market (Chapter 20): the language slices of the gate in Chapter 7 cover fewer languages than the six markets the assistant serves.

A prioritised platform and security plan for the next 24 months

  1. Within six months, contain and patch at group scale. Remove the remaining install-script exemptions under HM-LOOP-04, pass the EXC-113 production fallback drill before UC-2026-014 expands, and give the claims-triage agent a containment profile with per-market stop contacts.
  2. Within six months, complete the overlays as code. Write all seven market overlays, with dated triggers for EEA incorporation and adequacy, and make the appliesIn and processedIn checks blocking.
  3. Within six months, make the Polish service centre auditable per market, resolving the agent's Norwegian binding.
  4. Before 2 December 2027, bring underwriting support under the high-risk regime in every EU entity, with generated technical documentation, a change envelope and serious-incident reporting.
  5. Throughout, expand autonomy only on evidence of containment, per-market evaluation and drilled fallbacks.

Governance-side conclusions

The forums, portfolio, competence and procurement practices behind these decisions are concluded in AI Governance, Chapter 23. In brief, Nordvik Region's decision tiers end with an elected body, while Hansa Mutual's group AI governance board reports to the executive board in Hamburg; this chapter takes those structures as given.

The two roadmaps as code

Worked example: platform and security roadmaps for both organisations

Illustrative example. The roadmaps record the plans above as version-controlled artefacts that a pipeline can check against the inventory, registry and overlays. Decision records, exceptions and risk entries come from the chapters; item identifiers, owners and horizons are invented. Nordvik's roadmap is abridged to three items.

apiVersion: ai-architecture.example.org/v1
kind: PlatformRoadmap
metadata:
  organisation: Nordvik Region
  owner: head-of-platform
  period: 2026-11 to 2028-10
scope:
  overlay: architecture/overlays/nordvik-region.yaml   # AIDR-0002
  modesExcluded: [5]
items:
  - id: NR-PRM-01
    horizonMonths: 0-6
    action: Coding agent sandbox fails closed; containment baseline
    closes: usage-modes/nordvik-region.yaml#NR-UC-017.sandbox_fail_closed
  - id: NR-PRM-03
    horizonMonths: 0-6
    action: Rehearse triage suspension and supplier notification
    decisionRecords: [AIDR-0011]
    runbook: RB-AI-000
  - id: NR-PRM-04
    horizonMonths: 6-13
    deadline: 2027-12-02
    action: Supplier evidence, patch SLAs and incident notice in contract
    decisionRecords: [AIDR-0018]
gates:
  - No Mode 5 agent without containment, stop path and evaluation evidence

Hansa Mutual's roadmap uses the same schema, with items HM-PRM-01 to HM-PRM-06 referencing HM-LOOP-04, EXC-113, AIDR-0024, AIDR-0027 and AIDR-0034. Because the files share a schema, one pipeline can check that every referenced record exists and every deadline is met. The difference lies in the scope block: Nordvik names one overlay, whereas Hansa names a directory of them, jurisdictions: {eu: [DE, NL, SE, PL], eea: [NO], outsideEuEea: [UK, CH]}, and a legal basis per market group.

The two organisations compared

Theme Nordvik Region Hansa Mutual Why the answers differ
Role under the AI Act Deployer of a procured high-risk system Provider of compound systems Building carries provider duties
Main lever Contract and acceptance testing Platform and its gates Who owns the model and serving layers
Placement National; on premises for special-category data Self-hosted in Frankfurt, EU cloud burst Sovereignty against scale and continuity
Jurisdictions One overlay, one regime Group baseline plus seven market overlays One jurisdiction against several
Incident reporting One row per instrument One row per instrument per entity Number of supervisors
Cost frame Annual appropriations, hard caps Margins, internal market between entities Public budgeting against transfer pricing

Table 24.1: Platform and security answers compared.

Four causes explain the differences. First, Nordvik is mostly a deployer, so its platform holds evidence about a system it does not build, whereas Hansa's platform produces the system and its evidence together. Second, Nordvik's contract renews on the supplier's cycle, while Hansa's platform changes at the speed of a pull request but concentrates risk, because one gateway flaw reaches every market. Third, for Nordvik the depth of public-law duty is the hard part, for Hansa consistency across seven overlays, although the technique is the same. Fourth, and most consequential, Nordvik avoids Modes 3 and 5 outside its platform team, so containment is a narrow perimeter, whereas Hansa uses both daily and needs layered containment.

Each can learn from the other: Hansa's drilled fallbacks would serve Nordvik, which has no exit test for the triage supplier, and Nordvik's practice of postponing a placement until compliant capacity exists would serve Hansa in new markets. Both found that the artefacts that mattered most recorded a boundary in advance: a change envelope, a residency rule, a kill switch, an overlay that may not relax the baseline.

Across the usage modes

Mode Nordvik Region Hansa Mutual
Mode 0 – Ambient AI Supplier-enabled features; notice clause partly met Supplier-enabled features; notice clause missing for the service desk
Mode 1 – Conversational assistants Approved enterprise tool only Approved enterprise tiers
Mode 2 – Embedded workplace assistants Pilot; labels partly enforced Group-wide, rollout gate per entity
Mode 3 – Agentic work tools Platform team only; one self-hosted code model Daily across engineering; routed by class and entity
Mode 4 – Built AI applications Procured triage; staff and citizen-service assistants Claims assistants; high-risk underwriting support
Mode 5 – Autonomous production agents Excluded Claims-triage and IT-operations agents under containment

Table 24.2: The usage-mode profiles of the two organisations.

Summary

Nordvik Region's platform is small, deliberate and built around something it bought: a high-risk triage system under one legal regime, with few usage modes in play. Its reduced platform keeps the evidence in the Region's own hands, and AIDR-0002, AIDR-0007, AIDR-0011, AIDR-0018 and AIDR-0211 show a platform governed by recorded boundaries. Its next 24 months are about containing the one agent it runs, closing the deployer evidence gap before December 2027 and installing the capacity its compliant placements wait for.

Hansa Mutual's platform is large because its exposure is: it builds its own systems, runs all six modes and answers to seven legal regimes. Its answer is one group platform with market overlays as policy as code and tool calls bound to the market of each claim, and its hardest problems are the shared attack surface of its agents, routing one incident into several legal processes, and market-by-market scaling.

Chapter 25 therefore turns from the two cases to the book's consolidated argument and the order in which an organisation should act on it.

Sources

  1. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, 12 July 2024. (1, European Union, 2024)
  2. European Parliament and Council of the European Union. Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data (General Data Protection Regulation). Official Journal of the European Union, 4 May 2016. (2, European Union, 2016)
  3. European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). Official Journal of the European Union, 27 December 2022. (4, European Union, 2022)
  4. European Parliament and Council of the European Union. Directive 2014/24/EU on public procurement. Official Journal of the European Union, 28 March 2014. (9, European Union, 2014)
  5. European Parliament and Council of the European Union. Regulation (EU) 2026/1744 amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI). Official Journal of the European Union, 24 July 2026. (23, European Union, 2026)
  6. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, 27 December 2022. (3, European Union, 2022)
  7. Federal Republic of Germany (2001). Betriebsverfassungsgesetz (BetrVG) (Works Constitution Act), as last amended on 19 July 2024. Federal Ministry of Justice, Gesetze im Internet. (207, Germany, 2001)
  8. Bundesarbeitsgericht (2024). Beschluss vom 16. Juli 2024 – 1 ABR 16/23 (Technische Überwachungseinrichtung – Headset-System – betriebliche Mitbestimmung – Gesamtbetriebsrat). ECLI:DE:BAG:2024:160724.B.1ABR16.23.0. (249, Bundesarbeitsgericht (Federal Labour Court of Germany), 2024)
  9. European Free Trade Association. EEA-Lex factsheet 32024R1689: the Artificial Intelligence Act. EFTA. (241, EFTA, n.d.)
  10. United Kingdom (2018). Data Protection Act 2018 (c. 12), with the UK General Data Protection Regulation. (248, UK Parliament, 2018)
  11. Swiss Federal Assembly (2020). Federal Act of 25 September 2020 on Data Protection (Data Protection Act, FADP), SR 235.1. Fedlex, in force 1 September 2023. (244, Swiss Confederation, 2020)
  12. Swiss Financial Market Supervisory Authority (2024). FINMA Guidance 08/2024: Governance and risk management when using artificial intelligence. FINMA, 18 December 2024. (246, FINMA, 2024)
  13. European Commission (2025). Commission Implementing Decision (EU) 2025/2574 amending Implementing Decision (EU) 2021/1772 on the adequate protection of personal data by the United Kingdom. Official Journal of the European Union, 23 December 2025. (243, European Commission, 2025)
  14. European Commission (2000). Commission Decision 2000/518/EC on the adequate protection of personal data provided in Switzerland. Official Journal of the European Communities, L 215, 25 August 2000. (245, European Commission, 2000)
  15. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. The Transformed Architecture, Book 2, published at aig.geon.se. (73, Nordqvist, 2026)