Data Classes, Processing Lanes and Controller/Processor Roles for AI

This paper is not legal advice. It is a technologist’s design proposal for how a platform can carry legal and supervisory constraints. Deciding who is a controller, a processor or a joint controller under data-protection law, and who is a provider or a deployer under the EU AI Act, is a decision for the firm’s data protection officer and its counsel, taken arrangement by arrangement. Where this paper names a role, read it as the starting hypothesis an architect brings to that conversation.

1. The problem

In most enterprise software, data classification is settled once per application. The application sits in a known data centre, it holds a known set of tables, and the classification of those tables fixes the controls. An AI application breaks all three assumptions.

First, the unit that carries the data is the request, not the application. One assistant may summarise a published product brochure at nine o’clock and a disability claim with medical evidence at ten past. If the control is attached to the application, it is either too strict for the brochure or too weak for the claim.

Second, the processing often happens outside the firm. A prompt sent to a model is disclosed to whoever operates the inference, and possibly retained by them for abuse monitoring. Where that inference physically runs is frequently a deployment option with a price attached, not a fixed property of the service (Section 6.2).

Third, AI systems manufacture copies. A document that enters a retrieval pipeline becomes chunks, embeddings, an index, cache entries, prompt logs, traces, evaluation examples and sometimes agent memory. Each copy is the same information in a new place, and none of them appears in the application’s original data inventory.

The consequence is that classification and processing location have to be decided when the system is designed and enforced on every call. The component that enforces them is the AI gateway: the single point through which every model call leaves an application, where the caller is authenticated, the request is classified and routed, and the call is logged. Working Paper 01 of this series describes the gateway as a pattern [25]. This paper defines the rules it enforces.

2. Scope, method and the standing of the claims

The subject is a regulated financial institution — a bank, an insurer or an asset manager — in the EU, the UK or Switzerland. The regulatory frame is EU-first: the General Data Protection Regulation (GDPR), the Digital Operational Resilience Act (DORA) and the EU AI Act. The UK and Swiss regimes are treated as named parallels in Sections 9.2 and 9.3.

The paper contains two kinds of statement and I have tried to keep them apart.

Design proposal. Sections 3 to 6, the “design consequence” columns in Section 7, the minimum terms in Section 8.1 and the right-hand column of the table in Section 9.5 are my proposal. They describe how I would build the scheme. They are not drawn from a survey, they have not been validated by an independent study, and they do not describe any particular firm’s classification policy. A firm’s own information-classification policy takes precedence over every table here.

Evidence. Statements about what a regulation, a supervisory text or a vendor’s documentation says are cited to that text. Each cited source was opened on 10 November 2026 by an AI research agent working under my direction, and the statement was compared with the page as it stood that day. That is machine-assisted verification, not peer review and not legal review. Points that still need a legal reader are listed under Limitations. All regulatory statements are as of November 2026.

Four terms from the sibling papers are used. An agent is an AI system in which the model decides the next step in a loop, inside an envelope of permitted tools, budgets and escalation rules. The agency class (A0 to A4) describes the shape of a design, from a single model call to several separately owned agents. The action scope says what a system may do with its result: read-only, draft, act with approval, or act autonomously within a defined envelope [25]. An AI factory is the delivery organisation and shared platform through which a firm builds, approves and runs its AI applications.

3. Data classes

This section is a design proposal.

3.1 Four confidentiality classes

The class answers one question: how much harm follows if this information reaches someone who should not have it. Four levels are enough. More than four and people stop being able to tell neighbours apart.

Most firms already have a scale of this kind. The codes C1 to C4 should be mapped to the firm’s existing levels and not introduced beside them.

3.2 Five category flags

Confidentiality is not the only property that matters. Some information is regulated because of what it is about, whatever its confidentiality level. Five flags sit on top of the class. A flag can tighten the handling of the class it sits on. It can never loosen it.

The sensitive-personal-data flag deserves a word, because it is where a framing built around asset management falls short. An insurer handles health information as raw material: underwriting questionnaires, medical reports in life, health and disability claims, injury descriptions in motor and liability claims. A bank meets special-category data less obviously but just as certainly: trade-union dues and donations to religious or political bodies in payment narratives, criminal-offence data in fraud and financial-crime files, voice biometrics in authentication. An AI system that reads free text will meet this data whether or not anyone planned for it, which is why the flag is set by a classifier at the gateway and not by the application’s designer.

The client-identifying flag exists because data-protection law stops at natural persons. A corporate borrower’s facility terms are not personal data, yet their disclosure may breach a confidentiality duty. The flag carries that duty into the routing decision. Which statutory secrecy provisions apply, and to which entities, is a question for counsel in each jurisdiction.

3.3 Why two scales and not one

It is tempting to fold the flags into the classes and declare, say, that all personal data is C3. I keep them apart for a practical reason. The class drives where data may go; the flags drive what else has to be true when it gets there: a contract, a barrier, a retention schedule, an impact assessment. A customer’s published testimonial is C1 and personal. A deal team’s working list is C4 and inside information and may contain no personal data at all. A single scale cannot express both.

4. Processing lanes

This section is a design proposal.

4.1 Three lanes

A processing lane is the route a request takes to a model. It is defined by two facts: who operates the infrastructure on which inference runs, and who can see the data.

“An approved region” means a region inside the firm’s approved jurisdictions. Which jurisdictions those are is the firm’s decision, taken with its data protection officer and recorded once: an EU bank may approve the European Economic Area, a Swiss insurer may approve Switzerland alone or Switzerland together with named other states, and a UK asset manager may approve the United Kingdom. The lane scheme does not care which; it cares that the list exists and that the gateway can test a deployment against it.

One qualification on Lane B. “Inside the firm’s own tenancy” describes how the model is contracted, addressed and secured. It does not always describe where the weights run. Amazon’s documentation, for example, states that models on its managed service are deployed in accounts “owned and operated by the Amazon Bedrock service team” to which model providers have no access [15]. The inference runs in the cloud provider’s service environment and is reached from the firm’s tenancy. That is still Lane B, because the two defining facts hold: the cloud provider operates it and the model developer cannot see the data.

4.2 A lane is assigned per model deployment, not per vendor or per console

The most common mistake I see is to assign the lane by where the model was bought. A model selected in a cloud provider’s portal is assumed to be Lane B. That is not safe.

Anthropic’s documentation makes the point explicitly for its own models. It states that on its own API, and on certain offerings reached through cloud marketplaces, “Anthropic is the data processor”, whereas on Amazon Bedrock and on the Google-managed offering “the cloud provider is the data processor” [21]. The same model family therefore sits in Lane A through some routes and Lane B through others, and the route is not obvious from the console. Microsoft draws the equivalent line from the other side: for the models it designates as sold by Azure, prompts and completions “are NOT available to OpenAI or other providers” of those models [13]. That statement is limited to that designation; it should not be read across to every model in the same catalogue.

The rule that follows is simple. Each model deployment in the firm’s model catalogue carries a lane, and the lane is assigned by answering the two defining questions from the vendor’s current terms: who operates inference, and who can see the data. The answer is re-checked when the model version changes, because retention terms can change with the model (Section 8.2).

5. The permission matrix

This section is a design proposal. It is a default, to be aligned with the firm’s own policy.

5.1 The matrix

Four notes on reading it.

The agent actions row sets a ceiling on action scope, not an entitlement. A system still earns each scope on recorded behaviour, starting at read-only or draft. The row says that data of class C4 caps the scope at draft however good the record is.

The flags tighten the column they sit in. Sensitive personal data moves a request to the C4 column whatever its confidentiality level. Inside information adds a barrier check to whichever column applies. Client-identifying data adds pseudonymisation before Lane A or B.

The Lane A exception for C3 is narrow. It applies only after an approved redaction or pseudonymisation service has run (rule 4 in Section 5.3), and what then leaves the firm is the redacted request. The exception exists because some tasks need a model that is only available as a vendor API, and the honest alternative to a controlled exception is an uncontrolled one.

The Lane B exception for C4 is a decision I would take to the risk committee and not delegate to a platform team. Customer-managed keys protect data at rest; they do not hide a prompt from the party running inference.

5.2 Routing by classification

flowchart TD
    R["Request + context"] --> CL["Classify: highest class<br/>of all inputs, plus flags"]
    CL --> RD{"Approved redaction or<br/>pseudonymisation possible<br/>for this task?"}
    RD -->|Yes| DN["Apply approved<br/>masking service;<br/>service sets the new class"]
    RD -->|No| LN{"Lane allowed for<br/>the resulting class?"}
    DN --> LN
    LN -->|A| LA["Vendor API"]
    LN -->|B| LB["Private tenancy"]
    LN -->|C| LC["Controlled infrastructure"]
    LN -->|None| BL["Block and log"]

The gateway classifies each request by the highest class among all its inputs — the user’s text, the retrieved passages, the tool results, the memory entries — applies approved masking where the task allows it, and routes to a permitted lane or blocks. Blocking is a legitimate outcome and has to be visible to the user as one, with a reason, or people will route around the gateway.

Because the gateway sees raw prompts and responses, it is itself classified at the highest class it handles, and its logs follow the trace-retention row for that class [25].

5.3 Four inheritance rules

The matrix would be easy to defeat without these. They are the part of the scheme I would defend hardest.

1. Derived artefacts inherit the highest class of their sources. This covers embeddings, indexes, caches, prompt logs, traces, memory entries, evaluation sets and fine-tuned adapters. An embedding of a C4 document is C4. A model adapter trained on C3 data is C3 and may only be served where C3 may go.
2. An output is classified at least at the class of its inputs until a human or an approved classifier lowers it. A summary of a confidential file is confidential by default.
3. Mixing classes in one context window raises the whole request to the highest class. There is no such thing as a mostly-C2 prompt. This rule is what makes retrieval design matter: an agent that pulls one strictly confidential passage into its context has changed the lane for everything else in it.
4. Down-classification happens only through approved redaction, pseudonymisation or aggregation services, never inside an agent’s own prompt. An instruction such as “remove any personal data before answering” is not a control. The model that is asked to forget the data has already received it, on whatever lane it runs on. The approved service runs before the lane decision, is itself tested and versioned, and records what it removed.

Rule 4 has a legal echo worth knowing. GDPR defines pseudonymisation as processing after which data can no longer be attributed to a specific person without additional information that is kept separately and protected (Article 4(5)), and names pseudonymisation and encryption among security measures (Article 32(1)(a)) [1]. Pseudonymised data remains personal data in the hands of whoever holds the key. So pseudonymisation may lower the class of a request for routing purposes, but it does not remove the personal-data flag for the firm, and whether it changes the position for the recipient is a legal question I leave to counsel.

6. Store isolation and residency

6.1 Isolation models for grounding stores

The three models are taken from Microsoft’s guidance; the mapping to classes is my proposal.

A grounding store is any index or database from which an AI system retrieves facts to put in a prompt. In a financial institution a “tenant” of such a store is any boundary that must not leak: a client for whom the firm acts as processor, a legal entity, a business domain, or an information barrier.

Microsoft’s guidance on multitenant retrieval describes these three models and recommends an API in front of the stores so that code which needs tenant data “shouldn’t be able to query the back-end stores directly”. The API layer routes the query to the right store, selects only the caller’s tenant in a multitenant store, uses the caller’s identity, enforces security trimming and stores access logs of grounding information for audit [14]. The same guidance says the filter must apply to every retrieval, “whether the application retrieves grounding data before it calls a model or an agent retrieves data during its execution loop” [14]. The article is written for Azure but states that most of its principles apply on any platform.

I treat that grounding-data API as a shared platform service and as the natural place to implement the processor duties in Section 7.4. It is also where inheritance rule 1 is enforced: the API knows the class of the store it served from, and stamps it on the result.

6.2 Where inference runs

Residency has two parts that vendors price and document separately: where data is stored at rest, and where a prompt is processed. The second is the one most often misread. The statements below are from each vendor’s documentation as accessed on 10 November 2026.

Microsoft Azure. Microsoft’s deployment-type documentation states that data stored at rest remains in the designated Azure geography for every deployment type, and that inference differs. Global deployments may process prompts in any Azure region. Data Zone deployments process them only within the Microsoft-specified zone (US, EU or Asia Pacific). Standard and Regional Provisioned deployments process them within the customer-specified geography [12]. The EU data zone follows Microsoft’s EU Data Boundary, which the same page says “can include European Free Trade Association (EFTA) countries and regions such as Norway and Switzerland”, and Microsoft “can add regions to either data zone without prior notice” [12]. Microsoft’s data-privacy page for the same service is worded more narrowly: a Data Zone deployment created in an EU member state may process prompts “in that or any other European Union Member Nation” [13]. The two pages do not say quite the same thing about the edge of the EU zone. Working Paper 01 records a similar looseness in Microsoft’s gateway guide [25]. I rely on the deployment-type page, as that paper does, and I would like Microsoft to align them.

Amazon Web Services. Amazon Bedrock offers cross-Region inference profiles of two kinds. A geographic profile routes a request to a commercial Region “within that geography”, such as the US or the EU. A global profile may route it to any supported commercial Region worldwide, and the documentation recommends the geographic kind for data-residency requirements [17]. Where a model requires retention and cross-Region inference is enabled, retained inputs and outputs “are stored in destination Regions”, that is, where the request was processed [16].

Google Cloud. Google’s data-governance page for its generative AI platform states that with a regional or multi-regional endpoint the durable cache stays within the selected location, while with the global endpoint requests and cached data can be served from any region [18].

Anthropic. Anthropic’s API offers an inference-location parameter with two values, global (the default) and us, and a storage location set per workspace for which us is the only value available; the documentation lists both under current limitations [22]. For a European firm this means that the direct API, on the access date, offers no option to keep either inference or storage in Europe. Whether such a transfer can be approved is a question for the data protection officer. Reaching the same models through a cloud provider’s regional endpoint is a different lane with different answers.

For lane assignment the consequence is the same on every platform. A global deployment is cross-border processing without a fixed destination. A zone or geographic-profile deployment is cross-border processing within a named area whose membership the vendor may change. Only a deployment bound to one geography keeps inference in one jurisdiction. Each has to be checked against the firm’s approved jurisdictions and against the location commitments it has made to supervisors and clients, and the check belongs in the model catalogue entry, not in a slide.

I have verified this level of detail only on the pages cited. Product behaviour changes faster than papers do.

7. Roles under data-protection law and under the AI Act

The legal texts are cited as evidence. The allocation of roles to parties is an architect’s working hypothesis. See the notice at the head of this paper.

7.1 The data-protection roles

GDPR defines a controller as the body that, alone or jointly with others, determines the purposes and means of processing personal data, and a processor as a body that processes personal data on behalf of the controller (Article 4(7) and (8)) [1]. Where two or more controllers jointly determine purposes and means they are joint controllers and must set out their respective responsibilities in an arrangement (Article 26) [1]. The Swiss Act uses the same two terms with materially the same definitions (Article 5(j) and (k)) [2].

Three propositions organise the rest of this section. They are my reading, and the first two are the ones I would ask counsel to confirm before building on them.

• An agent is never a party. It has no legal personality. What it does is the firm’s processing, and accountability sits with the named person who owns it.
• Every vendor that sees personal data needs a role, and the default hypothesis is processor or sub-processor. A vendor that uses the data for a purpose of its own steps out of that role: GDPR Article 28(10) provides that a processor which determines the purposes and means of processing is to be considered a controller in respect of that processing [1]. This is why “no training on our data” is a role-defining term and not merely a confidentiality preference.
• The roles shift one level when the firm acts on a client’s instructions. Where the firm processes personal data on behalf of a client — an outsourced administration service or a white-label offering, for example — the firm may be the processor and its AI vendors sub-processors that the client must accept. Whether a given mandate makes the firm a processor, a controller in its own right or a joint controller is frequently contested and is exactly the kind of decision the notice above reserves.

flowchart LR
    CL["Client<br/>controller for its data"] -->|mandate| F["Financial institution<br/>controller, or processor<br/>for the client"]
    F -->|instructions| AG["Agent / AI system<br/>= the firm's own processing"]
    AG --> H["Cloud provider<br/>processor"]
    AG --> MV["Model vendor API<br/>processor or sub-processor"]
    AG --> TV["SaaS or tool vendor<br/>processor"]
    MV --> SP["Vendor's own<br/>sub-processors"]
    OW["Open-weight model developer<br/>receives no data"] -.->|weights only| AG

Solid arrows carry personal data, and each one needs a contractual basis. The dotted arrow carries only model weights, so on these facts the open-weight developer receives nothing to process.

7.2 Roles by party

7.3 Obligations when the firm is controller

The table gives the EU text and the Swiss parallel side by side, because the article numbers do not line up and the duties are not identical. The right-hand column is my proposal.

Three differences in that table change designs, and each should be confirmed with counsel before it is relied on.

The Swiss text on automated decisions is built as a duty to inform and a right to human review on request, where the EU text is built as a right not to be subject to the decision. A human decision point satisfies the design intent of both, which is why I put one in every design that approaches such a decision.

The Swiss conditions for using a processor include one that GDPR Article 28 does not state in the same way: processing may be assigned only if no statutory or contractual duty of confidentiality prohibits it (Article 9(1), as rendered in the unofficial English translation) [2]. For client-identifying data this condition can decide the lane before any other analysis starts.

The notification thresholds differ. A firm operating under both regimes should build the incident process to the stricter clock and let the legal team decide which notifications are actually due.

7.4 Obligations when the firm is processor for a client

GDPR Article 28(3) lists what the contract with a processor must require [1]. Translated into platform rules, with the letter of the provision each rule serves:

• Process the client’s data only on the client’s documented instructions; no reuse for the firm’s own purposes (28(3)(a)).
• Never use one client’s data to fine-tune a shared model, populate shared memory or enrich a shared index. This follows from (a) and from the risk under 28(10) of becoming a controller by pursuing a purpose of one’s own.
• Isolate each client’s data in retrieval indexes, memory and traces, with tenant-scoped storage and keys (28(3)(c); Section 6.1).
• Flow the same obligations down to every AI vendor, and obtain the client’s authorisation before adding a model or tool vendor as a sub-processor (28(2), 28(3)(d), 28(4)).
• Support the client with data-subject requests, incidents and audits, including evidence from AI traces (28(3)(e), (f) and (h)).
• Delete or return the client’s data at the end of the service, including embeddings, caches and memory (28(3)(g)).

The last rule is where inheritance rule 1 earns its keep. A firm that cannot list the derived artefacts of a client’s data cannot delete them.

7.5 Roles and duties under the EU AI Act

The AI Act allocates duties by a different pair of roles. A provider develops an AI system or a general-purpose AI model, or has one developed, and places it on the market or puts it into service under its own name or trademark. A deployer uses an AI system under its authority (Article 3(3) and (4)) [3]. “Putting into service” includes supplying a system for the provider’s own use (Article 3(11)) [3]. A financial institution is therefore a deployer of the systems it buys and, on the wording, a provider of the systems it builds for itself. What that second role costs depends almost entirely on whether the system is high-risk.

Six points matter for the design, all as of November 2026.

The Act regulates models as well as systems. It is common to say that the AI system is the unit the Act regulates. That is incomplete. Chapter V places obligations directly on providers of general-purpose AI models, including technical documentation and information for downstream providers who integrate the model (Article 53(1)(a) and (b)) [3]. The firm should obtain that downstream documentation from its model vendors and keep it with its own system documentation.

The heavy requirements bind high-risk systems only. Articles 9 to 15 — risk management, data and data governance, technical documentation, record-keeping, transparency to deployers, human oversight, and accuracy, robustness and cybersecurity — sit in a section headed “Requirements for High-Risk AI Systems”, and Article 8(1) applies that section to high-risk AI systems [3]. They are not general obligations on every AI system. Many firms adopt them voluntarily as a design standard, and I think that is sensible, but it should be recorded as a choice.

Two high-risk uses are specific to finance. Annex III, point 5(b), lists AI systems used to evaluate the creditworthiness of natural persons or establish their credit score, with an exception for systems used to detect financial fraud. Point 5(c) lists systems used for risk assessment and pricing in life and health insurance. Point 4 lists employment uses such as recruitment and decisions on promotion or termination, which apply to any employer [3]. Under Article 6(3) an Annex III system is not high-risk where it poses no significant risk of harm, for instance because it performs a narrow procedural task, but that derogation never applies to a system that profiles natural persons [3]. Classification is per use case. The same data class and the same lane can serve a high-risk use and a minimal-risk one.

A deployer can become a provider. Under Article 25(1) a deployer is treated as the provider of a high-risk system if it puts its name on one, substantially modifies one, or modifies the intended purpose of a system that was not high-risk — a general-purpose AI system included — so that it becomes high-risk [3]. Pointing a general-purpose assistant at credit decisions is the obvious way for a bank to walk into this.

Deployers of high-risk systems have duties that touch this paper directly. Article 26 requires, among other things, human oversight by competent people (26(2)), relevant and sufficiently representative input data where the deployer controls it (26(4)), and retention of automatically generated logs for at least six months (26(6)). Paragraphs 5 and 6 contain specific provisions for financial institutions, under which the monitoring duty is deemed met by compliance with financial-services governance rules and logs are kept as part of the documentation those rules require [3]. Article 27 requires deployers of the systems in Annex III points 5(b) and 5(c) to carry out a fundamental-rights impact assessment before first use, and allows it to build on a data protection impact assessment (27(1) and (4)) [3].

The dates moved in 2026. Under Article 113 as amended, the Act applies generally from 2 August 2026, the general-purpose AI model chapter has applied since 2 August 2025, the high-risk rules for Annex III systems apply from 2 December 2027 and those for Annex I products from 2 August 2028 [3][4]. The transparency duties of Article 50 fall under the general date; the amending regulation gives systems placed on the market before 2 August 2026 until 2 December 2026 to comply with the marking duty in Article 50(2) [4]. Article 4, as replaced by the same regulation, requires providers and deployers to take measures to support AI literacy among their staff [3][4].

The Act reaches beyond the EU. It applies to providers and deployers established in a third country “where the output produced by the AI system is used in the Union” (Article 2(1)(c)) [3]. A Swiss or UK firm serving EU clients should not assume it is outside.

8. Vendor terms that decide a lane

8.1 Minimum terms

This list is a design proposal. It is not a contract checklist and does not replace one.

8.2 What the vendors’ own documentation says

The statements below are taken from each vendor’s public documentation as accessed on 10 November 2026. Documentation is not the contract. The contract and the data-processing addendum govern, and they were not reviewed for this paper.

Three things follow, and they are my conclusions.

Zero data retention is a property of a configuration, not of a vendor. On every platform it depends on features switched off, an approval obtained, or a mode set. The lane entry in the model catalogue should record the configuration that makes the claim true and a test that proves it is still set.

Retention terms can change with the model version. Two of the four vendors document models that require retention and, in one case, human review as a condition of access [16][21]. A firm that upgrades a model for quality reasons can change its retention position without anyone having decided to. Model lifecycle and lane assignment therefore have to be reviewed together.

The two Anthropic pages are not worded identically. The privacy-centre article states deletion within 30 days [20]; the developer documentation states that conversation content “is not retained by default”, with the 30-day models as the exception [21]. I report both and draw no conclusion about which governs; the contract does.

9. A short regulatory map

Sections 9.1 to 9.4 are evidence, cited to the texts. The right-hand column of the table in 9.5 is my proposal. All statements are as of November 2026.

9.1 European Union

GDPR and the AI Act are covered in Section 7.

DORA is the third leg. For this paper three of its provisions matter: the register of information on all contractual arrangements for ICT services provided by third parties (Article 28(3)), exit strategies for ICT services that support critical or important functions (Article 28(8)), and the key contractual provisions that such arrangements must contain (Article 30) [5]. The Regulation has applied since 17 January 2025 (Article 64). On my reading, every model deployment in Lane A or Lane B is an ICT third-party arrangement that belongs in the register, and the minimum terms in Section 8.1 overlap with what Article 30 requires. I have not mapped them clause by clause, and that mapping is legal work.

9.2 United Kingdom

The UK GDPR keeps the structure and numbering of the EU text for the provisions this paper relies on. Article 28 in the version in force still requires a binding contract, processing only on documented instructions, and prior written authorisation for sub-processors [9]. One provision does not carry over: Article 22 has been replaced by a new section inserted by the Data (Use and Access) Act 2025, fully in force from 5 February 2026 [9]. A firm operating under both regimes should not assume the EU and UK rules on automated decisions are the same; I have not analysed the substituted provisions.

On the prudential side, the Prudential Regulation Authority’s supervisory statement SS2/21 sets expectations on outsourcing and third-party risk management for banks, building societies, designated investment firms and insurers, with chapters on data security and on business continuity and exit plans; the current version took effect on 31 December 2024 and a further version takes effect on 18 March 2027 [10]. SS1/23 sets model risk management principles for banks [11]. This paper maps no UK counterpart to the AI-specific layer of Section 7.5. I did not check whether UK AI legislation has been enacted or proposed, so read that as a gap in the paper and not as a statement about UK law.

9.3 Switzerland

The Federal Act on Data Protection of 25 September 2020, often called the revFADP, is covered article by article in Section 7.3 [2].

FINMA Circular 2018/3 “Outsourcing” applies, in the version last amended on 4 November 2020, to banks and securities firms, insurance companies, managers of collective assets, fund management companies and self-managed SICAVs (margin nos. 5 to 6.2) [7]. The circular’s list of modifications shows that the margin numbers covering managers of collective assets, fund management companies and SICAVs were added by amendments that entered into force on 1 January 2021. Its addressee grid does not mark portfolio managers or trustees. “Asset managers” is therefore too loose a description of its scope: it covers managers of collective assets and fund management companies, not every firm that manages assets.

Outsourcing in the circular’s sense exists where a firm mandates a provider to perform, independently and on an ongoing basis, all or part of a function that is significant to its business (margin no. 3) [7]. For such functions the circular requires an up-to-date inventory that names the provider and its subcontractors (14); attention to concentration risk and to the orderly transfer or insourcing of the function (17, 18.1); contractual rights of inspection and audit for the firm, its audit firm and FINMA (26); and, for outsourcing abroad, that those rights can be enforced and that the information needed to restructure or resolve the firm is accessible in Switzerland at all times (30, 31). The firm “remains accountable to FINMA in the same way as it would if it performed the outsourced function itself” (23) [7]. Whether a given AI service performs a significant function is the firm’s own assessment. Where it does, the inventory and the location requirement in margin no. 31 bear directly on lane approval.

FINMA Guidance 08/2024 of 18 December 2024 sets out the supervisor’s observations on governance and risk management when using AI. It names model risks such as lack of robustness, correctness and explainability, and bias; data-related risks; IT and cyber risks; increasing third-party dependencies; and legal and reputational risks [8]. It is a supervisory lens on the same controls, not a separate rulebook.

9.4 Voluntary standards

ISO/IEC 42001:2023 is the international standard for an AI management system [24]. The NIST AI Risk Management Framework 1.0 (NIST AI 100-1, 26 January 2023) is intended for voluntary use and is organised around four functions: Govern, Map, Measure and Manage [23]. Neither is law in any of the three jurisdictions. Both are useful as structure for the control framework, and neither changes anything in the matrix.

9.5 Where the obligations land

Most of these obligations land on the gateway, the grounding-data API and the model catalogue. A firm that implements them once as platform services meets them for every application composed from those services. That is the argument for building the scheme into the platform and not into each project, and it is an argument, not a measured result.

10. How this plugs into the sibling papers

The classification code of Working Paper 01. That paper gives every AI asset and application a six-field code: layer / pattern | agency class | action scope | risk tier | data class | reuse generation [25]. The fifth field is defined here. I propose it be written as the class followed by any flags, for example C3+P for confidential personal data or C4+S for sensitive personal data, using P, S, K, I and R for personal, sensitive, client-identifying, inside information and regulated records. The suffix notation is new in this paper and is a suggestion; Paper 01’s own example shows the class alone.

The lane is deliberately not a field in the code. It is derived: the gateway computes the permitted lanes from the data class and flags, and the model catalogue says which deployments sit in which lane. Storing the lane on the application would recreate the per-application control this paper argues against. Two other fields interact with the data class. The matrix caps the action scope by class (Section 5.1). The risk tier is independent of the data class: a credit-scoring model on pseudonymised data can be high-risk under the AI Act, and a summariser of strictly confidential board papers need not be.

The archetype cards of Working Paper 02. Each of that paper’s ten solution archetypes has a row headed “Data classes and lanes” [26]. Those rows state the default lanes for the archetype’s typical data, for instance C3 on Lane B or C and C4 only on Lane C. They are the matrix of Section 5.1 read without its two exception routes, which is the right default for a card. A team that needs the Lane A exception for C3 or the Lane B exception for C4 is asking for something the card does not grant, and should expect to justify it. The cards’ statement that “no archetype owns a lane” is this paper’s rule that the class of the data, and nothing else, opens a lane.

Limitations

• This is not legal advice, and it has not had legal review. The allocation of controller, processor and joint-controller roles, and of provider and deployer roles, is the decision of the firm’s data protection officer and counsel. Section 7 states working hypotheses.
• The classes, flags, lanes, matrix and inheritance rules are a proposal by one author. They have not been validated by an independent study or tested against a firm’s incident history. The cell values in Section 5.1 are judgements.
• Verification was machine-assisted. Sources were opened and compared by an AI research agent on 10 November 2026. This is not peer review. The fetch tool returns a summary of each page, so wording inside quotation marks was checked against that summary and, for the FINMA circular and most of the vendor pages, against the full text. Paraphrases of the Swiss Act follow the tool’s summary of the unofficial English translation and are not quotations.
• Texts consulted in republished form. GDPR was read in the text as adopted, republished at legislation.gov.uk, because EUR-Lex returned empty pages. The AI Act was read in the consolidated text published by the European Commission’s AI Act Service Desk, which states that it reflects the EUR-Lex consolidation as at 27 July 2026. The Swiss Act was read in the unofficial English translation on Fedlex, status as of 1 September 2023, which has no legal force; later amendments were not checked.
• Relied on a sibling verification pass. The content of Regulation (EU) 2026/1744 [4], the date of FINMA Guidance 08/2024 and the existence and status of PRA SS1/23 [11] were verified for other papers in this series on the same day and were not all re-opened here.
• Vendor documentation is not the contract. Section 8.2 reports public documentation. Enterprise agreements, data-processing addenda and product terms were not reviewed. Vendor pages change without notice.
• Coverage of vendors is uneven. Four vendors were checked. Other model providers, sovereign-cloud offerings and on-premises licensing terms were not.
• National law is absent. Member-state implementations, sectoral secrecy statutes, employment law and supervisory guidance below the level cited are not covered. Nor are the EBA, EIOPA and ESMA guidelines on outsourcing, or the European Data Protection Board’s guidance on controller and processor concepts, any of which may change a conclusion.

Needs a browser pass before publication. A legal reviewer should work from this list.

1. DORA, Regulation (EU) 2022/2554 — resolved. Articles 28(3), 28(8), 30 and 64 were read in the Official Journal text on EUR-Lex on 10 November 2026.
2. ISO/IEC 42001:2023 — resolved. Title, edition and publication date were read on the publisher’s page in a browser on 10 November 2026. The paper makes no claim about certification.
3. GDPR in the Official Journal — confirm the articles cited against EUR-Lex. Articles 10, 14, 24, 45 and 46 were not opened and are not relied on by number, except that Article 10 is named through the wording of Article 35(3)(b).
4. Swiss FADP — confirm that the consolidation of 1 September 2023 is current, and check the German, French or Italian authentic text for Articles 9, 16, 17, 21 and 24.
5. UK — the provisions substituted for UK GDPR Article 22 were not read; the body of SS2/21 was not read beyond its landing page; the UK transfer regime, the critical-third-parties regime and any UK AI legislation were not examined.
6. FINMA Guidance 08/2024 — the news page was read, not the guidance document itself.
7. Google Cloud — resolved. The cited address now redirects; reference [18] gives the page title, address and date as read in a browser on 10 November 2026.
8. AI Act — Articles 9 to 15 were confirmed by heading and by Article 8(1), not read individually; Article 111(4) as inserted in 2026 was not re-opened here.

References

All web sources were accessed on 10 November 2026.

1. Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation), OJ L 119, 4.5.2016, p. 1. Articles 4(1), 4(5), 4(7), 4(8), 5, 6(1), 9(1), 13, 22, 26, 28, 30, 32(1), 33, 35 and 44. Consulted in the text as adopted by the EU, republished at https://www.legislation.gov.uk/eur/2016/679/article/28/adopted and the corresponding pages for each article.
2. Swiss Confederation. Federal Act on Data Protection (Data Protection Act, FADP) of 25 September 2020, SR 235.1, status as of 1 September 2023. Articles 1, 2(1), 5(c), 5(j), 5(k), 6, 9, 12, 16, 17, 19, 21, 22 and 24. Unofficial English translation published on Fedlex. https://www.fedlex.admin.ch/eli/cc/2022/491/en
3. Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act), OJ L, 2024/1689, 12.7.2024. Articles 2(1), 3, 4, 6, 8, 25, 26, 27, 50, 53 and 113, and Annex III points 4 and 5. Consulted in the consolidated text published by the European Commission, AI Act Service Desk, which states it is based on the EUR-Lex consolidated version as at 27 July 2026. https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-3 and the corresponding pages for each article and annex.
4. Regulation (EU) 2026/1744 of the European Parliament and of the Council of 8 July 2026 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), OJ L, 2026/1744, 24.7.2026. Amendments to Articles 4, 111 and 113 of Regulation (EU) 2024/1689. https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202601744
5. Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector (DORA), OJ L 333, 27.12.2022, p. 1. Articles 28(3), 28(8), 30 and 64. https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng Read in the Official Journal text on EUR-Lex, 10 November 2026.
6. Regulation (EU) No 596/2014 of the European Parliament and of the Council of 16 April 2014 on market abuse (market abuse regulation). Article 7(1)(a). Consulted in the text as adopted by the EU, republished at https://www.legislation.gov.uk/eur/2014/596/article/7/adopted
7. FINMA. Circular 2018/3 “Outsourcing – banks, insurance companies and selected financial institutions under FinIA”, dated 21 September 2017, in force 1 April 2018, last amended 4 November 2020. Margin nos. 3, 5–6.3, 14, 17, 18.1, 23, 26, 30 and 31, and the list of modifications. https://www.finma.ch/en/~/media/finma/dokumente/dokumentencenter/myfinma/rundschreiben/finma-rs-2018-03-01012021_de.pdf?la=en
8. FINMA. “FINMA guidance on governance and risk management when using artificial intelligence” (FINMA Guidance 08/2024), 18 December 2024. https://www.finma.ch/en/news/2024/12/20241218-mm-finma-am-08-24/
9. legislation.gov.uk. Regulation (EU) 2016/679 (United Kingdom General Data Protection Regulation), latest revised version: Article 28, https://www.legislation.gov.uk/eur/2016/679/article/28 ; Article 22, with the annotation recording its substitution by the Data (Use and Access) Act 2025 (c. 18), section 80(1), https://www.legislation.gov.uk/eur/2016/679/article/22
10. Prudential Regulation Authority. “SS2/21 – Outsourcing and third party risk management”. Supervisory Statement, first published 29 March 2021; current version published 15 November 2024, effective 31 December 2024. https://www.bankofengland.co.uk/prudential-regulation/publication/2021/march/outsourcing-and-third-party-risk-management-ss
11. Prudential Regulation Authority. “SS1/23 – Model risk management principles for banks”. Supervisory Statement, first published 17 May 2023. https://www.bankofengland.co.uk/prudential-regulation/publication/2023/may/model-risk-management-principles-for-banks-ss
12. Microsoft Learn. “Understanding deployment types in Microsoft Foundry Models”. Page dated 6 August 2026. https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/deployment-types
13. Microsoft Learn. “Data, privacy, and security for Foundry Models sold by Azure in Microsoft Foundry”. Page dated 18 May 2026. https://learn.microsoft.com/en-us/azure/foundry/responsible-ai/openai/data-privacy
14. Microsoft Learn. “Design a Secure Multitenant RAG Inferencing Solution”, Azure Architecture Center. Page dated 19 August 2026. https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/secure-multitenant-rag
15. Amazon Web Services. “Data protection”, Amazon Bedrock User Guide. https://docs.aws.amazon.com/bedrock/latest/userguide/data-protection.html
16. Amazon Web Services. “Data retention”, Amazon Bedrock User Guide. https://docs.aws.amazon.com/bedrock/latest/userguide/data-retention.html
17. Amazon Web Services. “Route model inference requests across AWS Regions with cross-Region inference”, Amazon Bedrock User Guide. https://docs.aws.amazon.com/bedrock/latest/userguide/cross-region-inference.html
18. Google Cloud. “Gemini Enterprise Agent Platform and zero data retention”. Google Cloud Documentation, last updated 9 November 2026. https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/zero-data-retention (the earlier address https://docs.cloud.google.com/vertex-ai/generative-ai/docs/data-governance redirects here).
19. Anthropic. “Is my data used for model training?”, Anthropic Privacy Center. Page dated 18 August 2026. https://privacy.claude.com/en/articles/7996868-is-my-data-used-for-model-training
20. Anthropic. “How long do you store my organization’s data?”, Anthropic Privacy Center. Page dated 1 July 2026. https://privacy.claude.com/en/articles/7996866-how-long-do-you-store-my-organization-s-data
21. Anthropic. “API and data retention”, Claude developer documentation. https://platform.claude.com/docs/en/manage-claude/api-and-data-retention
22. Anthropic. “Data residency”, Claude developer documentation. https://platform.claude.com/docs/en/manage-claude/data-residency
23. National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, 26 January 2023. https://www.nist.gov/itl/ai-risk-management-framework
24. ISO/IEC 42001:2023, Information technology — Artificial intelligence — Management system, edition 1, December 2023. https://www.iso.org/standard/42001
25. DEIXEI Research Series, Working Paper 01. AI Reference Architectures and Design Patterns: A Taxonomy for a Reuse-Driven AI Factory. November 2026.
26. DEIXEI Research Series, Working Paper 02. Ten Solution Archetypes for Regulated Finance. November 2026.