Can a Swiss fiduciary use public AI tools with client information?

Standfirst. The useful answer is neither a blanket yes nor a blanket no. It depends on the information, the fiduciary’s duties, the service configuration and contract, where processing occurs, and whether the organisation can retain control and evidence. This article provides a practical authorisation framework, not legal advice.

Direct operational answer

A fiduciary should not place identifiable or confidential client information into an AI service merely because the tool is convenient. Use may be possible only after the organisation has assessed the information, professional and contractual duties, purposes, data flows, access, retention, subprocessors, international transfers, safeguards and human review. Anonymous or genuinely non-confidential material presents a different risk profile. A business workspace or API may offer materially different terms from a consumer account, but the product name alone is not a control. Swiss hosting can reduce some exposure and simplify oversight. It does not by itself establish that a workflow meets every applicable obligation.

Who this applies to

This analysis is for Swiss fiduciary firms and multidisciplinary practices handling accounting, payroll, tax, company administration, estate, trust or related mandates. “Fiduciary” is a commercial description, not a single legal status. The duties applicable to a chartered accountant, auditor, lawyer, tax adviser, trustee, board member or financial intermediary can differ. The mandate, professional capacity, contractual promises and sector rules must therefore be identified before a workflow is authorised.

Why “public AI” is an inadequate category

“Public AI” often conflates a publicly accessible consumer chat service with a managed business workspace, an enterprise tenancy, an API, a self-hosted model, or a Swiss-hosted managed system. These can differ in whether submitted content is used for model improvement, how long it is retained, who administers access, what regions and subprocessors are involved, and whether audit and deletion controls exist.

Current vendor documentation illustrates the distinction. OpenAI says content from individual consumer services may be used to improve models depending on settings, while business offerings and the API are not used for training by default. Microsoft documents separate processing and storage behaviour by Azure deployment type and feature. These are vendor statements, not a finding that either service is suitable for a particular mandate. Terms and configurations change and must be reviewed for the exact product in use.

Information types and confidentiality levels

A practical classification should look at content and context, not only file labels.

1. Public: published company details, public legislation and approved marketing text.
2. Internal: procedures, templates and non-public operational information with limited harm if disclosed.
3. Confidential: identifiable client correspondence, contracts, accounts, tax files, payroll and beneficial-owner information.
4. Restricted: sensitive personal data, credentials, investigation material, privileged communications, health data or information whose disclosure could cause serious legal, financial or personal harm.

Replacing a name is not necessarily anonymisation. Dates, amounts, entity structures and uncommon events may permit re-identification. Pseudonymised data remain personal data where a party can reconnect them to a person.

Professional secrecy and contractual obligations

The first question is not “Does AI law allow this?” but “What permits this firm, in this capacity, to disclose or outsource this information?” Duties may arise from statute, a regulated profession, employment, a mandate, client instructions, a non-disclosure agreement or internal policy. Article 321 of the Swiss Criminal Code covers specified professions and auxiliaries; it should not be applied automatically to every fiduciary activity or every employee.

The FDPIC’s outsourcing guidance expressly warns that statutory or contractual confidentiality must be checked before outsourced processing. Client consent, where proposed, is not an automatic cure. Its validity, scope, necessity and effect on other duties require legal assessment. A firm should document the precise duty, information, recipient and processing purpose rather than rely on a generic “AI consent” clause.

Data-protection responsibilities under Swiss law

The Federal Act on Data Protection (FADP) is technology-neutral and applies when AI processing involves personal data. The FDPIC states that AI providers and users must respect transparency and give affected persons the greatest possible control consistent with the Act. Core questions include purpose, proportionality, accuracy, transparency, security, data protection by design and default, and the ability to respond to data-subject requests.

The organisation deciding why and how client data are used will commonly remain the controller even when a vendor processes data for it. Under Article 9 FADP, outsourcing does not transfer that responsibility. If planned processing is likely to create a high risk to personality or fundamental rights, Article 22 requires a data protection impact assessment. The assessment must describe the processing, evaluate risk and identify protective measures; high residual risk can trigger specialist consultation requirements.

These are legal facts at a general level. Whether a particular workflow has a sufficient basis, requires new information to data subjects, or reaches the DPIA threshold is a matter for the organisation’s legal or data-protection review.

Processors, subprocessors and international transfers

Before approval, establish whether the vendor acts only on documented instructions or also processes content for its own purposes. Obtain the data-processing agreement, subprocessor list, processing and support locations, retention schedule, deletion process, incident duties and audit evidence. Determine whether optional features, plug-ins, browsing, connectors or abuse monitoring introduce additional recipients.

For disclosure abroad, identify every relevant country rather than relying on the contracting entity’s address. The FADP framework distinguishes destinations with adequate protection from other transfers requiring an applicable safeguard or exception. The FDPIC notes that contractual clauses may need supplementary technical measures where foreign law permits disproportionate authority access. Transfer analysis is a legal task; a region selector is evidence, not the conclusion.

Service postures are materially different

• Consumer tool: individual terms, limited central administration and settings that may permit model improvement. Do not assume it is suitable for mandate data.
• Business workspace: organisational accounts and stronger defaults may exist, but verify administrator visibility, retention, connectors, support access and contract terms.
• Enterprise product: negotiated controls, identity integration, audit and region options may improve governance. They do not replace workflow assessment.
• API: enables application-level minimisation, logging and access design. Retention, abuse monitoring, hosting and subprocessors remain relevant.
• Self-hosted model: can reduce external disclosure, but the operator inherits security, patching, model, infrastructure and lifecycle responsibilities.
• Swiss-hosted managed system: can constrain storage or processing geography and support local oversight. Corporate control, remote support, subprocessors and foreign-law exposure still need examination.

Decision matrix

Minimum organisational controls

• An accountable owner and documented permitted-use catalogue.
• Information classification linked to approved service postures.
• Procurement review covering contract, privacy, security, exit and incident terms.
• A current inventory of AI workflows, owners, purposes, data and vendors.
• Role-based training using realistic fiduciary examples.
• A clear exception and escalation route.
• Periodic review after vendor, feature, law or workflow changes.
• Incident response that covers prompt, output and connector exposure.

Minimum technical controls

• Organisation-managed identities, multi-factor authentication and prompt access removal.
• Least privilege, tenant separation and controlled connectors.
• Data minimisation or approved redaction before submission.
• Encryption in transit and at rest, with key arrangements proportionate to risk.
• Configured retention and tested deletion where available.
• Logs sufficient for investigation without creating an uncontrolled copy of sensitive prompts.
• Output labelling, source traceability and deterministic checks for critical fields.
• Controls against prompt injection and unintended retrieval from connected repositories.

Six steps before authorising a workflow

1. Define the task. Record the purpose, users, affected people, expected benefit and prohibited actions.
2. Classify the information. Identify personal, sensitive, confidential, privileged and re-identifiable elements.
3. Map duties and flows. Confirm mandate restrictions, recipients, subprocessors, locations, retention and deletion.
4. Assess the posture. Review the exact product, plan, settings, contract and technical architecture.
5. Design controls and validation. Minimise inputs, restrict access, define authoritative sources, test failure modes and assign human decisions.
6. Approve and monitor. Record the owner, rationale, residual risk, review date, evidence and suspension triggers.

Escalate when

Seek legal, compliance, data-protection or security review where statutory secrecy may apply; contract terms prohibit or are silent on outsourcing; sensitive data or vulnerable people are involved; data leave an approved region; foreign authority access is material; large-scale profiling or automated individual decisions are proposed; residual risk may be high; the tool can execute transactions; or the firm cannot explain retention, deletion and subprocessors.

What Swiss hosting helps with

Swiss hosting can reduce the number of routine cross-border data movements, align operational oversight with local infrastructure, improve latency and incident coordination, and support a deliberate procurement posture. It can make some risks easier to understand and evidence.

What Swiss hosting does not establish

It does not establish a lawful purpose, proportionality, professional-authority to disclose, adequate access controls, output accuracy or human accountability. It does not reveal who owns the provider, who can support the service remotely, where backups or telemetry go, or which law may reach a provider. “Swiss-hosted” is therefore a deployment characteristic, not a compliance label.

Cytria’s operational interpretation

Cytria treats authorisation as a workflow decision rather than a model decision. The evidence package should connect a defined purpose and information class to a specific service posture, configuration, contract, human checkpoint and review date. Higher-risk content should move through more constrained environments. If the organisation cannot reconstruct why the workflow was permitted, the control is incomplete.

Limitations

This article provides general legal and operational information as reviewed on 14 July 2026. It is not legal advice and does not determine the duties of a particular firm, profession, mandate or product. Vendor features and terms can change. Obtain qualified advice for the concrete facts and verify current official materials before authorisation.

Recommended next step

Select one proposed workflow and complete the six-step review with its real contract, configuration and data flow. Do not begin with an organisation-wide yes/no policy. Begin with evidence about one bounded use case and use the result to build the control pattern.

Primary sources and review dates

• Federal Data Protection and Information Commissioner (FDPIC), AI and data protection, updated 24 September 2025; reviewed 14 July 2026.
• FDPIC, Outsourcing of data processing, current guidance; reviewed 14 July 2026.
• FDPIC, Data processing in the cloud, current guidance; reviewed 14 July 2026.
• FDPIC, Cross-border transfer of personal data, including SCC material updated 12 February 2025; reviewed 14 July 2026.
• FDPIC, Data protection impact assessment, current guidance; reviewed 14 July 2026.
• OpenAI, Business data privacy, security and compliance, current vendor documentation; reviewed 14 July 2026.
• OpenAI Help Center, Data Usage for Consumer Services FAQ, current vendor documentation; reviewed 14 July 2026.
• Microsoft Learn, Data, privacy and security for Azure Direct Models, current vendor documentation; reviewed 14 July 2026.