A policy is a promise. Systems keep it.

Where your supervisor and your data protection officer can see it. The data plane is decided per system in the Define phase and recorded in the architecture register: a Swiss region, the European Union, an in-country facility in Jordan or the Gulf, a US region, or your own premises. Speech, language and extraction models run inside that plane; the control plane holds policy, identity and metrics but never policyholder or claims data. Health and claims data are treated as the most protected category under the revised Swiss FADP and the GDPR, and the proposal states which model options fit an on-premises footprint so the residency commitment is costed rather than assumed.

Every model has a named owner, a documented purpose and risk class, an evaluation set built from the insurer's own cases and scored by its underwriters and adjusters, a monitored baseline and a rollback version. The register records which decisions the model may influence, which it may not touch, and where a person must decide. It is written in the form state insurance regulators' guidance on the use of AI, FINMA's expectations and a Solvency II validation function work from, so the same document serves the actuarial function, the risk committee and the examiner. Where the insurer already has a model-risk framework, the register is mapped to it rather than duplicated beside it.

It may identify the caller to the level the policy requires, take first notice of loss in the structure the claims system expects, answer questions about cover from the policy wording, arrange the next step and hand the call to a claims handler with everything captured. It may not decide liability, quantum or coverage, and it may not describe cover the wording does not contain. Those limits are enforced outside the language model: the model proposes, a policy engine decides what may be executed, and anything beyond written authority becomes a handover with full context. Adversarial testing for social engineering over voice is part of every release gate.

One product line at a time, behind a compatibility layer, with the old and the new system running together through at least one renewal cycle before the old one is retired. Reserves, premiums and claims are reconciled before and after each tranche, and the reconciliation is signed by the actuarial function rather than by the engineering team. The rollback is rehearsed against production volumes before the first tranche moves. The distribution channel sees the same policy numbers, the same documents and the same renewal dates throughout, and the supervisor sees a change record that matches what happened.

The obligation register written in the Discover phase lists every requirement the arrangement touches: the insurer's right to audit, the supervisor's access, the location of data, business continuity and exit, and the full sub-processor chain. The proposal names every third party that could touch policyholder data, by role and location, each approved by the insurer before use, with changes notified in advance and a right to object. For a fully on-premises or Swiss-sovereign deployment the list can be reduced to Altuon itself. The agreement carries the terms the insurer needs to include Altuon in its own outsourcing register under FINMA's expectations, Solvency II and DORA.

The insurer owns the deliverables, the models trained on its data, the evaluation sets and the documentation, and the assignment is written into the agreement rather than promised in a meeting. Exit terms are negotiated at the start: notice periods, the handover of code, data and registers in usable form, and a transition period in which Altuon assists whoever takes over. Every engagement has a named lead and a named deputy, and the registers are kept so that the work is legible to someone who was not present when it was done. That is a supervisory expectation as much as a courtesy, and the insurer should test it before signing.