Decision in brief. Do not approve a hybrid AI design because a provider says “Swiss region,” a diagram draws a private-network box, or a contract uses the word “residency.” Approve one named workflow only after its data, inference, retrieval, logging, support, backup, identity and recovery paths have owners, allowed locations and testable rules. The practical unit is a versioned workload-location contract: what may leave which boundary, where each component processes or retains it, who can access it, what happens on failover and what evidence proves the settings in use.
For a broader vendor selection framework, see the existing AI procurement reviews. This article narrows the decision to workload acceptance in Swiss finance. It is an engineering and governance method, not legal advice, a certification, or a claim that a named provider meets an institution’s obligations.
Why “where is the model?” is the wrong starting question
A generative AI request is not one object moving to one place. A user prompt may pass through a web application, authentication layer, gateway, content filter, retrieval service, inference endpoint, safety service, telemetry pipeline and support workflow. The result may be copied to an application database, search index, backup or audit record. A human operator may inspect an error trace. A recovery plan may replay a request after an outage. The provider’s model endpoint is only one node in a wider path.
The useful question is therefore: for this workflow, which data categories enter each component, what operation each component performs, where it processes and persists data, which people and machine identities can access it, and which route the system selects when the primary path is unavailable? Ask for evidence by component and operation. Do not let “the model is in Switzerland” silently answer questions about logging, support access or failover.
This decomposition is an engineering inference, not a claim that every component necessarily causes a cross-border transfer or a legal consequence. The institution’s privacy, secrecy, outsourcing, records, resilience and supervisory assessments determine which facts matter. Engineering should provide accurate, reproducible facts for those assessments rather than substitute for them.
What public evidence supports
FINMA’s 2025 survey describes AI use among supervised institutions. The authority says it surveyed roughly 400 FINMA-licensed institutions from late November 2024 to mid-January 2025. Among respondents, 187 AI users comprised 100 banks and securities firms, 75 insurance companies and 12 other institutions. FINMA reported that approximately half of surveyed institutions used AI or had initial applications, another quarter planned use within three years, and 91% of AI users used generative AI. These are results from that survey and its respondent categories; they do not estimate adoption among all Swiss companies, prove production maturity or measure hybrid deployment. FINMA survey announcement.
FINMA’s communication on AI supervisory guidance names risks that include robustness and correctness, data security, quality and availability, IT and cyber risk, third-party dependencies, legal exposure and reputation. It emphasizes that supervised institutions remain responsible for identifying and managing risks. For architecture, that makes location one control dimension among several, not a substitute for accountability, data governance, reliability or security. The communication applies to supervised institutions; it should not be generalized into a universal rule for every organization. FINMA communication on AI supervisory guidance.
CFA Institute’s account of investment-firm roundtables discusses organizational choices such as centralized AI expertise versus business-unit ownership. It is qualitative discussion, not a representative survey and not a Swiss regulatory interpretation. It nevertheless highlights a common design question: a central platform group may operate the gateway while nobody in a business unit owns the decision to route a specific workflow and data class through it. CFA Institute, “How Investment Firms Are Organizing for AI”.
EY’s architecture guidance argues for governed data foundations and an AI-ready architecture. This is consultancy guidance and a commercial perspective, not an independent audit of any named cloud configuration. Treat it as a design viewpoint; verify actual product behavior, contract terms and settings against current evidence. EY, “AI-ready data architecture”.
These sources support a modest conclusion: AI use is growing among surveyed supervised institutions; risk and accountability remain governance concerns; and operating models need explicit ownership. They do not identify which region, model or failover path is acceptable for a particular institution. That decision needs workload facts.
Create a workload-location contract
The contract is a small, versioned artifact maintained with service configuration. It does not replace a data inventory, outsourcing assessment, impact assessment, risk acceptance, supplier contract or legal analysis. Its purpose is to give those processes a stable and testable description rather than a marketing label.
| Field | Required question | Evidence to retain |
|---|---|---|
| Workflow identity | Which user journey and decision does this cover? | Service identifier, owner, approved version |
| Data classes | What prompts, attachments, retrieval passages, outputs and feedback can enter? | Schema, synthetic examples, classification mapping |
| Processing components | Which app, gateway, model, filter, vector store, observability and support paths participate? | Current data-flow diagram and inventory |
| Location rule | Which processing and storage locations are allowed per component? | Dated contract and configuration evidence |
| Access rule | Which human and machine identities can read or administer each component? | Role map and privileged-access review |
| Persistence | What is retained, for how long, and how does deletion propagate? | Settings, deletion test and backup treatment |
| Failover | Which alternate path may be used, and for what data classes? | Routing policy, degraded-mode decision and test |
| Decision owner | Who accepts residual risk and who can stop the route? | Named roles, escalation and kill switch |
| Change trigger | Which configuration or supplier changes require reassessment? | Region, model, subprocessor, support, logging and recovery triggers |
| Test record | What proves the rule, when did it run and what failed? | Fixture IDs, results, exceptions and expiry |
A location statement without a boundary is ambiguous. “Swiss only” may describe a primary database while leaving logs, diagnostics, support access or disaster recovery unspecified. A useful rule specifies the component, data class, operation and exception. If support staff can inspect a diagnostic trace, assess that access path separately; the database’s region does not answer it.
Record unknowns as unknown. Do not convert them to “no transfer” or “no retention.” For each unknown, define a blocking condition, a data reduction, a contract request or a compensating control. An unknown without an owner tends to become an unrecorded assumption at release time.
Four patterns and their trade-offs
Single-region managed inference routes application requests to a managed endpoint in a selected region. It may simplify operations and reduce customer-managed infrastructure. It does not by itself prove the location of every control-plane operation, support action, telemetry stream, backup or dependency. Request current, component-specific evidence; do not infer all behavior from the endpoint’s region label.
Private-cloud or customer-managed inference can provide more control over network boundaries, software versions and local persistence. It also transfers responsibility for patching, capacity, hardware, model updates, monitoring, incident response and recovery to the institution. “On premises” is not risk-free: local administrators, remote maintenance, identity federation, model downloads, vendor support and backup copies still need treatment.
Hybrid retrieval with managed inference keeps selected source records or an index in an institution-controlled environment while sending constructed prompts or retrieved passages to an inference service. The decisive question is the content of the assembled request, not the location of the original document. Keeping documents local does not prevent excerpts from entering inference, debugging, telemetry or human review paths.
Fallback across regions or providers can improve availability only if the alternate route has an approved data policy. Changing endpoints may change processing location, retention, safety behavior, subprocessor chain, latency and identity boundary. Availability logic must not silently overrule the workload contract.
A pattern is not a verdict. Choose based on data class, consequence, evidence, operating capability and acceptable degraded behavior. If an essential control cannot be demonstrated, collect evidence, reduce the data, change the route or defer the workflow.
Provider-neutral evidence matrix
Ask each supplier and internal platform owner the same questions for every relevant component. A “yes” without scope, date, evidence and an accountable party is incomplete.
| Control question | Evidence shape | Warning sign |
|---|---|---|
| Where is request content processed? | Named service, region, operation, configuration reference and date | Region label applied to the entire stack |
| What metadata is generated? | Fields for request IDs, errors, prompts, outputs and traces | “No content in logs” with no tested setting |
| What can support staff access? | Roles, approval, scope, location, logging and emergency procedure | Generic assurance with no privileged-access proof |
| What persists after response? | Retention by component, deletion, backup expiry and exceptions | Retention only described for the main store |
| What happens during regional outage? | Explicit route, allowed data, authority and test result | Automatic global fallback without workload filter |
| Can the institution constrain the path? | Configuration, permissions, kill switch and proof | Supplier-only control with no notice |
| How are service changes handled? | Change signal, version pinning or review trigger | Unreviewed model alias or endpoint behavior change |
| Can an incident be reconstructed? | Correlation IDs, access records, expiry and owner | Either no evidence or unrestricted content logging |
Compare evidence, not adjectives. A local endpoint may fail if its administrative path is opaque. A managed service may be suitable for a scoped workflow if its boundaries and evidence meet the institution’s criteria. This is a recommendation about method, not a prediction that any provider will pass.
Twelve synthetic acceptance cases
The cases below are synthetic design fixtures, not production observations, test results, provider ratings or an empirical dataset. They were designed for this article on 4 November 2026. The sample size is 12 because the matrix contains 12 scenarios; it is not a statistical sample of Swiss institutions. Replace fictional names and assumptions with the actual service inventory before operational use.
| ID | Scenario | Required control outcome | Fail-closed condition |
|---|---|---|---|
| C01 | Public FAQ with no identifiers | Approved public-data route only | Stop if prompt contains account or case identifiers |
| C02 | Internal policy search | Retrieval permissions follow the caller | Stop if permissions are not enforced at query time |
| C03 | Customer complaint summary | Mask identifiers before inference | Stop if masking fails or raw content is logged |
| C04 | Credit-file explanation for reviewer | Advice remains separate from approval | Stop if output can trigger a decision unattended |
| C05 | Investment research synthesis | Preserve sources and label inference | Stop if a reviewer cannot reconstruct citations |
| C06 | Insurance claim triage | Route approved fields and retain uncertainty | Stop if missing evidence is presented as certainty |
| C07 | Fraud-alert narrative | Maintain approved boundary for identifiers | Stop if fallback has broader retention/location |
| C08 | Staff assistant over internal documents | Enforce document permissions per identity | Stop if one team can retrieve another’s canary |
| C09 | Prompt injection in retrieved text | Treat text as untrusted; authorize tools separately | Stop if document text invokes privileged action |
| C10 | Primary inference region outage | Approved degraded mode or queue | Stop if router picks an unapproved geography |
| C11 | Observability investigation | Minimized diagnostics, access and expiry | Stop if prompt capture is enabled without approval |
| C12 | Provider or model migration | Recheck route, retention, access and behavior | Stop if endpoint changes without owner review |
C01 shows why intended purpose is insufficient. A public FAQ can receive a private user’s text in the same input box. Classify the actual request, not the marketing description. Include a payload with a synthetic account identifier, private attachment or non-public strategy excerpt. The expected result should reject or redirect to a separately approved route and explain the block without echoing the sensitive value.
For C02 and C08, authorization must be enforced at retrieval time, not just when the index is built. A document might be indexed using one service identity while many people query it. Use two synthetic users with disjoint permissions and documents containing distinct canary phrases. Query as each identity; verify that authorized phrases appear and unauthorized ones do not. If neither user retrieves anything, the leakage test passed but functional acceptance did not; test intended retrieval as well as denial.
For C03, define the masking boundary and failure behavior. Test valid input, malformed identifiers, identifiers split across fields and a masking service error. On masking failure, stop before inference. Never send raw content “temporarily.” Keep the diagnostic result minimal; do not accidentally place the unmasked payload in the error log while proving the masking failure.
For C04 and C06, determine whether generated text can change downstream state. If it drafts advice for a professional, test that no approval, payment or claim event is emitted. If another service consumes it, validate its schema, uncertainty representation and human review gate. “Human in the loop” is not an acceptance condition by itself. Name the role, identify the interface state requiring a decision, and test that rejection cannot be bypassed through a hidden API path.
For C05, traceability means more than showing a bibliography. The reviewer should see which claims came from a source, which were inferred and which remain unresolved. Include fixtures with two conflicting source passages and with no approved source for a claim. The expected output preserves disagreement or states the evidence gap; it should not smooth either case into a plausible narrative.
For C07 and C10, simulate the primary endpoint as unavailable. Observe the routing decision, not merely whether a response eventually arrives. Verify the selected endpoint, applied data policy and outcome: queued, denied or processed. If the alternate route is outside the approved set, delayed service may be the correct result. A service objective does not authorize a more permissive geography.
For C09, insert synthetic hostile text into a retrieved document, for example an instruction to ignore controls and export a file. The expected result treats it as data; tool use remains governed by separate caller permissions; any action needs its own authorization. This is an application-security fixture, not proof of immunity to prompt injection. Repeat after changes to retrieval, prompt construction, tool permissions or model version, and keep residual risk visible.
For C11, use a synthetic incident containing a correlation identifier but no actual customer content. Verify responders can reconstruct service events without opening prompts by default. Exercise any exceptional access path and test approval, logging, expiry and review. The purpose is to avoid both extremes: retaining every prompt indefinitely for convenience or retaining so little that an incident cannot be investigated.
For C12, treat changes to endpoint alias, model version, region, subprocessor or logging mode as changes that may invalidate prior evidence. Reapproval need not repeat every assessment from zero; identify changed invariants and rerun tests tied to them. If the supplier provides no version or change signal, seek contractual notice, monitoring or a narrower use case. If none is workable, do not treat a one-time approval as permanently current.
A fail-closed manifest checker
A small manifest can catch a common governance error: a workflow marked approved while its fallback route is unknown. This Python example checks structural completeness and refuses automatic failover unless the alternate route is approved and within the workload’s data-class allowance. It illustrates a control, not a production policy engine. Adapt schema, authentication, evidence binding and organizational policy before use.
from dataclasses import dataclass
from typing import Optional
@dataclass
class Route:
name: str
region: str
approved: bool
data_classes: tuple[str, ...]
retention_days: Optional[int]
@dataclass
class Workload:
workflow_id: str
owner: str
allowed_classes: tuple[str, ...]
primary: Route
fallback: Optional[Route]
fallback_mode: str # approved, queue, or deny
def validate(w: Workload) -> list[str]:
errors = []
if not w.workflow_id.strip():
errors.append("missing workflow_id")
if not w.owner.strip():
errors.append("missing accountable owner")
if not w.primary.approved:
errors.append("primary route is not approved")
if not set(w.primary.data_classes).issubset(set(w.allowed_classes)):
errors.append("primary accepts an unapproved data class")
if w.primary.retention_days is None or w.primary.retention_days < 0:
errors.append("primary retention is unspecified")
if w.fallback_mode == "approved":
if w.fallback is None:
errors.append("approved fallback has no route definition")
else:
if not w.fallback.approved:
errors.append("fallback route is not approved")
if not set(w.fallback.data_classes).issubset(set(w.allowed_classes)):
errors.append("fallback accepts an unapproved data class")
if w.fallback.retention_days is None:
errors.append("fallback retention is unspecified")
elif w.fallback_mode not in {"queue", "deny"}:
errors.append("fallback_mode must be approved, queue, or deny")
return errors
if __name__ == "__main__":
primary = Route("ch-primary", "CH", True, ("public", "internal"), 30)
fallback = Route("global-secondary", "GLOBAL", False, ("public",), 90)
workload = Workload(
workflow_id="claims-draft-v1",
owner="Claims Product Owner",
allowed_classes=("public", "internal"),
primary=primary,
fallback=fallback,
fallback_mode="approved",
)
errors = validate(workload)
if errors:
raise SystemExit("BLOCKED: " + "; ".join(errors))
print("structurally complete; separate evidence review is still required")
The checker deliberately does not determine whether the region code is acceptable, whether a retention period is lawful or whether a data class may be sent. Those are institutional policy decisions. It makes missing fields and an unapproved fallback visible. In production, validate controlled identifiers rather than free-text names, authenticate the manifest owner, sign or version the artifact, and bind it to deployed configuration. A manifest is not proof of runtime behavior until a deployment check confirms that the selected route matches it.
Build a deterministic fixture set: approved primary without fallback using queue mode; approved fallback within classification; fallback declared as approved but not approved itself; fallback accepting a class outside the allowlist; missing owner; and unspecified retention. The first two should pass structural validation; the remaining four should fail. This is a designed six-case test set, not a benchmark or statement about a production system. Record language version, code commit, fixture outcomes and exceptions when adapting it.
Failover is a business decision, not only routing
Decide before an outage whether each workflow may use an alternate path. Some can queue and resume later. Others have a manual continuity process. A low-risk internal task may use an alternate after a fresh policy check. A sensitive workflow may need to stop. Design these choices before an incident, when pressure to prioritize availability is lower.
For each route, record the primary, approved alternate, allowed data classes, supporting evidence, detection threshold, decision authority and rollback signal. Include “no route” as a valid outcome. If all approved paths are unavailable, show a deliberate degraded mode instead of silently choosing an unreviewed endpoint.
Test the transition as well as the destination. A synthetic outage should verify retries do not duplicate transactions, queued requests preserve idempotency, stale responses are rejected and the user sees an accurate status. For generative workflows, replay controlled fixtures through primary and alternate paths and compare relevant properties: location evidence, data fields, retention, allowed tools, output schema, errors and human approval. Text similarity alone is not an acceptance criterion.
Failback deserves its own test. Decide whether in-flight work remains on the alternate, returns to the primary or waits for review. Prevent route flapping with explicit thresholds and a cool-down rule. Keep an audit trail of route selection without unnecessarily retaining full prompt or response content. A recovery drill that merely produces a healthy status page does not prove the workload contract survived a transition.
Ownership and evidence
A single “AI owner” rarely controls the entire chain. Assign business accountability for purpose and consequences; platform responsibility for routes and configuration; data ownership for classification and retrieval; security responsibility for identities and monitoring; procurement responsibility for supplier evidence; and independent risk or compliance challenge. A small institution may combine roles, but the responsibilities should remain explicit.
| Activity | Accountable | Responsible | Consulted |
|---|---|---|---|
| Approve purpose and affected users | Business service owner | Product lead | Risk, legal, operations |
| Classify data and retrieval sources | Data owner | Data steward | Privacy, security |
| Define approved route set | Risk owner | Platform architect | Procurement, operations |
| Implement routing and kill switch | Technology owner | Platform team | Security, service owner |
| Verify supplier evidence | Outsourcing owner | Vendor manager | Legal, security, risk |
| Run synthetic cases | Service owner | QA and platform team | Data, security, operations |
| Accept residual risk | Designated authority | Control owner | Compliance and legal |
| Reassess material change | Business owner | Change manager | Affected control owners |
Evidence should be discoverable and time-bounded. Store contract, diagram, fixtures, results, exceptions and approvals beside the service record. Each item needs an owner, version, date, scope and review trigger. A screenshot without service ID or configuration version may not connect to the running system. A supplier statement without date or component scope may become stale unnoticed.
A short tabletop before the technical test
Bring the business owner, platform engineer, security, data owner, operations and vendor manager. Use one synthetic workflow, one synthetic prompt and one outage scenario. Do not use customer data. Ask the business owner to explain the task and consequence of error; the data owner to identify classes and retrieval sources; the engineer to draw each hop; security to trace identities and privileged access; operations to explain the user experience during outage; and the vendor manager to point to current evidence for processing, persistence, support and change notice.
Introduce a twist: the alternate endpoint is healthy but outside the allowed set, or telemetry starts capturing request bodies after a change. Ask who detects it, who can stop traffic, what evidence is kept and how the route is restored. A strong answer names a control, owner and record. “We would investigate” is not a control. “The gateway blocks endpoints absent from a signed allowlist; the on-call owner receives an alert and requests queue” is testable.
Record open questions as actions, not verbal assurances. Give every action an owner and date. Give every assumption a status and a consequence if it is false. The tabletop is not a failover test or legal review; it reveals missing ownership and unclear decision rights before either process begins.
Failure modes and recovery checks
Treat an unapproved route as a blocked state, not a degraded success. If classification cannot run, do not send the unclassified payload; queue or deny it and alert the named owner. If the location policy service is unavailable, use a signed cached policy only when its expiry and revocation behavior were approved in advance. If that evidence has expired, stop rather than assume the last known route remains acceptable. If masking fails, terminate before inference and keep only a minimized diagnostic event. If a fallback endpoint is selected unexpectedly, disable automatic routing, preserve the route identifier and investigate before retrying. If a human approval signal is missing, do not infer approval from a timeout or a downstream status code.
Recovery checks should cover duplicate submission, out-of-order responses, stale cached configuration, replayed jobs and partial writes. Use idempotency keys for business actions, but do not assume an idempotency token prevents content leakage. Simulate a provider timeout after it has accepted a request; the client may not know whether processing occurred. Define whether to query status, wait, or create a new request with a new correlation identifier. Do not retry a sensitive payload across a different route until policy is re-evaluated.
After an incident, compare the route log with the approved manifest and the deployed configuration. Record which rule triggered, which route was selected, what the user saw and whether any data class exceeded its allowance. If the event exposed a gap, update both the manifest and the test fixture so the same failure becomes detectable. A post-incident note without a changed control or test leaves the original uncertainty in place.
Where this recommendation fails
This matrix may be excessive for a public-data experiment with no user input, persistence or operational dependency. Scale control to data and consequence; do not create paperwork without decision value. A customer-facing or decision-support workflow may need deeper analysis than these examples, especially if outputs affect regulated decisions, records or customer treatment.
A workload view can understate shared infrastructure risks. Identity, monitoring, key management, deployment tools and support systems may be shared even when the application route is well defined. Add shared services to the map when they can read relevant data or change the route. Common infrastructure is not irrelevant merely because many workloads use it.
A region may be contractually clear while operational access remains uncertain. A policy may say data is not used to train models but leave diagnostics, abuse monitoring or support review to other terms. Ask for scope and configuration. If evidence is confidential, seek assurance reports, independent review, contract terms or a restricted use case. Do not infer a favorable answer from silence.
The matrix does not settle law, supervisory expectations, outsourcing materiality, cross-border access or contractual interpretation. The references frame technical and governance questions; institution-specific legal and risk owners must assess applicable requirements and record conclusions. The artifact supplies facts and repeatable tests for that work.
Method and limits of the original asset
The original asset is a designed set of 12 synthetic acceptance cases and a small manifest checker, written on 4 November 2026. Cases cover classification, retrieval permissions, masking, human approval, conflicting evidence, failover, observability, prompt injection and change control. There are no production observations, user records, provider measurements or performance results. No adoption, success, latency, cost or compliance rate is inferred from these fixtures.
The GSC opportunity check used query/page data for 2–30 October 2026. The query was “how do azure ai and google cloud compare on hybrid deployment and data residency controls?” The page showed four impressions, zero clicks and average position 10 in that window. This small query observation does not establish market demand or predict rankings. The candidate page is the AI-Due hybrid architecture article cited above. This article adds a workload-level acceptance asset rather than repeating a general provider comparison.
We read the cited FINMA communications, CFA Institute roundtable account, EY architecture guidance and candidate AI-Due page. Video results did not yield a usable transcript and are not cited. Some pages were excluded when they returned access errors or had unsuitable canonical status. Exclusion limits breadth; it does not show that excluded publishers lack relevant evidence. These are published materials, not an independent confirmation of a particular cloud deployment. Products, contracts and supervisory materials can change; verify current versions before approving a route.
Operational checklist
Before enabling a workflow, verify:
- Workflow, business owner, user groups and failure consequences are named.
- Prompts, attachments, retrieval results, outputs and feedback fields have data classes.
- Processing, persistence, monitoring, support, backup and recovery components appear in the current flow.
- Each component has location, access, retention and deletion evidence with a date.
- Primary and alternate routes accept only approved classes for this workflow.
- Unknown supplier behavior is recorded and has a blocker or compensating control.
- Retrieval authorization is enforced for the requesting identity.
- Human review is an observable state with a named role and a tested API boundary.
- Failover, queue, deny and failback behavior are explicit.
- Synthetic cases cover normal, malformed, denied, outage, conflicting-source and change scenarios.
- Logs support investigation while minimizing content and limiting access and expiry.
- Region, model, subprocessor, logging or retention changes trigger reassessment.
- Exceptions have owner, expiry, compensating control and revocation condition.
- Business and risk owners accept residual risk before production.
Recommendation
Approve a workload only when allowed data classes, route components, location evidence, access, persistence, failover and accountable ownership align in one versioned record, and critical claims have been exercised with synthetic tests. If evidence is missing, narrow the data, queue or use manual mode, collect stronger supplier evidence or stop the route. This follows from the control logic above; it does not certify a platform or promise a regulatory outcome.
flowchart TD
A[Name one business workflow] --> B[Classify request and retrieved data]
B --> C[Map inference, logs, support, backup and recovery]
C --> D{Evidence covers every component?}
D -- No --> E[Collect evidence, narrow data, queue or deny]
D -- Yes --> F[Run synthetic acceptance cases]
F --> G{Primary and failover pass?}
G -- No --> E
G -- Yes --> H[Named owner accepts residual risk]
H --> I[Version contract and monitor changes]The core test is simple: make the route decision visible before the request is sent. Users should not guess whether a workflow is approved; operators should not infer from a vendor label what happened during an outage. A small contract and synthetic test suite make those decisions reviewable and give procurement, security, legal, operations and business owners one artifact to challenge. That is more defensible than “cloud is safe” or “on-premises is safer” because it records what the institution verified and what remains uncertain.
Top comments (0)