Confidentiality did not disappear. Its boundary became harder to see.
A private bank can have encrypted storage, disciplined access control and carefully drafted confidentiality clauses while client context continues to travel through meeting transcripts, collaboration channels, support tickets, analytics platforms, personal devices and AI tools. None of those movements needs to look dramatic. The boundary shifts one apparently reasonable workflow at a time. The conventional model asks where confidential information is stored and who can open it. The operating model must ask more: who can receive fragments, who can combine them, which providers can retain them, what administrators can recover, what a model can infer, and which outputs can cause action elsewhere. That is the first uncomfortable conclusion. The confidentiality boundary is no longer the edge of a database. It is the outer limit of possible reconstruction and use.
Disclosure is no longer the only failure
Traditional confidentiality analysis is built around disclosure: a document was sent to the wrong person, an account was compromised, or a provider exposed data. Those remain serious events. But systems can now create consequential knowledge without disclosing the original record. A relationship manager may place a client’s portfolio concern into one tool, a family event into another and a transaction timetable into a third. Each fragment may look permissible in isolation. The combination can identify the client, expose intent or reveal pressure. A model with access to several sources may assemble the same conclusion without ever reproducing a protected document. This is reconstruction risk. It matters because controls usually follow documents while consequence follows meaning. The same problem appears in vendor support. A provider may not have routine access to client files, yet support logs, telemetry, ticket descriptions and administrator privileges can reveal which systems matter, when activity changed and where an exception occurred. Metadata can carry operational truth even when content remains encrypted.
AI changes the handling surface
The Swiss Federal Data Protection and Information Commissioner has made the relevant starting point clear: existing data-protection law applies to AI-supported processing. Purpose, functionality and data sources cannot become invisible merely because a model sits between the organization and the output. For a private bank, however, legal compliance is only the floor. Client confidence can be damaged by a use of information that is technically defensible but inconsistent with the discretion the relationship implies. The practical questions are therefore sharper than “Is this AI tool approved?”
- Can the provider use prompts, files, outputs or telemetry to improve a service or model?
- Which humans or subprocessors can access retained material?
- Can the system combine data across users, teams, tenants or purposes?
- Can a user retrieve information they could not locate in the source systems?
- What happens to embeddings, indexes, caches and logs when a source record is deleted?
- Can an administrator, vendor or compromised integration export the derived knowledge layer?
- Can the output trigger communication, advice, approval or execution without an independent authority check?
An approved tool with an undefined answer to those questions is not a controlled capability. It is an unmeasured extension of the confidentiality boundary.
Map the real boundary
A useful map begins with a client matter, not a software inventory. Select a live workflow—preparing a client review, analysing a transaction, answering a cross-border question—and follow the information from origin to consequence.
- Origin — where the information first becomes available and under what duty or expectation.
- Transformation — where it is summarized, translated, enriched, embedded, scored or combined.
- Transit — every API, collaboration channel, device and provider through which it moves.
- Persistence — primary storage, backups, logs, caches, indexes and model-side retention.
- Authority — the people and systems permitted to read, change, approve or act.
- Reconstruction — the combinations that reveal more than any single record.
- Exit — how the organization deletes, exports, verifies or replaces the capability.
The result should not be a decorative data-flow diagram. It should show where confidentiality changes character: from document control to inference, from client instruction to model context, from internal record to vendor dependency.
A control model for the moved boundary
The control response has five parts.
- Minimize context before transmission. Do not send a complete story when the task requires only a fragment.
- Preserve provenance. Every important output should retain enough source information for a human to understand where it came from.
- Enforce permission at answer time, not only at document-ingestion time.
- Separate preparation from authority. A system may draft or compare without being permitted to advise, approve, contact or execute.
- Test deletion and exit. Contractual rights are not equivalent to demonstrated removal of records, indexes, logs and derived access.
The point is not to eliminate modern tools. It is to prevent convenience from silently redefining a duty that the institution still carries.
The decision
A bank should not ask whether its confidential information is “in the cloud” or “in AI.” Those labels are too broad to guide a serious decision. It should ask whether client context can travel, accumulate, be reconstructed or acquire authority outside the conditions the bank intended. Once framed that way, the work becomes concrete. Map one consequential workflow. Identify the points where meaning expands. Remove context that does not need to move. Place explicit authority around what the resulting system may do. Confidentiality has not become obsolete. It has become architectural.