Sovereign AI
Generative AI in Banking Without Breaking Bank Secrecy
Short answer: the only approach that removes the confidentiality question rather than managing it is to run the model on infrastructure the bank controls, and then to enforce need-to-know inside that deployment as strictly as the bank already enforces it everywhere else. Everything short of that is a disclosure to a third party that has to be justified, and justifying it is harder than most AI vendors suggest, because client confidentiality is not the same obligation as data protection.
This article is about that distinction and what follows from it. It is not legal advice, and the position differs by jurisdiction!
Client confidentiality is a separate obligation from GDPR
Most AI vendor material treats "GDPR compliant" as the finish line for European banks. It is not even the right race.
Data protection law gives you a well-worn route for involving an external party. You establish a lawful basis, you appoint the vendor as a processor, you sign a data processing agreement, you handle international transfers, and the arrangement stands up. That construct is what makes the entire cloud industry workable.
Banking secrecy does not offer the same route, and it is worth understanding why. It was largely left out of EU harmonisation, so it remains national law and varies considerably. In Austria it is codified in section 38 of the Banking Act, with criminal liability attached under section 101. Swiss banking secrecy sits in Article 47 of the Federal Banking Act and carries a custodial sentence of up to three years. Luxembourg treats breach of professional secrecy in the banking sector as a criminal offence. German Bankgeheimnis works differently again, arising principally from the contractual relationship and data protection law rather than a distinct statutory privilege.
What these regimes have in common is the shape of the duty: information obtained through the client relationship is not to be passed to third parties. There is no general provision that converts a third party into an extension of the bank the way a processor agreement does under data protection law. The usual gateways are narrow, and the most reliable of them is the client's own express consent.
Austrian case law illustrates how firm this is. The Supreme Court has held that a bank's assignment of a claim was not valid, on the basis that the transfer necessarily involved disclosing information about the debtor, which banking secrecy prohibits. The recipient had a contract. The contract was not the answer.
Apply that reasoning to an AI deployment and the question changes usefully. The question is not whether the vendor is trustworthy, certified, or contractually bound. It is whether any client information left the bank at all.
Four options, and only one of them avoids disclosure
A public API. Client content is transmitted to an external provider and processed on their infrastructure. Whatever the terms say about training and retention, a third party received the information. Under data protection law this is a processor arrangement. Under secrecy law it is a disclosure that needs its own justification.
An enterprise agreement with retention disabled. Better, and materially so for data protection purposes. But zero retention is a commitment about what the recipient does with the data, not a statement that no recipient existed. The disclosure analysis is unchanged.
A private endpoint in a European cloud region. This answers residency. It does not answer disclosure, because the operator is still a third party, and if that operator is subject to a foreign jurisdiction, the bank has added a second question to the first rather than resolving either.
The model running on the bank's own infrastructure. No third party receives the content, because the computation happens on hardware the bank controls, inside its own network. There is no disclosure to justify, because there was no disclosure.
That is the whole structural argument, and it is worth stating plainly rather than dressing up. The first three options manage a confidentiality problem. The fourth removes it. For use cases touching identifiable client information in a jurisdiction where secrecy is criminally enforced, that difference is not a preference.
Then the problem moves inside the bank
This is the part that gets under-planned, and it is where deployments go wrong after the sovereignty box has been ticked.
Once the model runs internally, external disclosure stops being the risk and internal need-to-know becomes it. Banks already know this. The information barriers between advisory and trading exist precisely because "we are all one institution" is not an adequate confidentiality position. An AI assistant that can retrieve across departments is capable of moving information across a barrier that took years to design, without anything ever leaving the building.
Three specific failure modes are worth naming:
Retrieval that ignores existing permissions. If the assistant can search document stores that individual users could not open themselves, it has become a permission escalation tool. Retrieval scope has to inherit the user's own entitlements, not the service account's.
A shared credential in front of the model. If every application calls with one key, the deployment cannot distinguish between the compliance officer and the intern, and it cannot evidence that it did. Need-to-know is a per-person control. It cannot be enforced by a system that never learns who the person is.
Prompts in the logging stack. A relationship manager pastes a named client's situation into a prompt. If full prompt content is written to logs, that client's information now sits in an operational system with an entirely different access model from the banking platform, readable by people who have no client relationship at all. This is one of the most common findings in internal AI pilots, and it is created by a default rather than a decision.
Ask what actually needs to be in the prompt
A surprising share of banking AI value does not require client identifiers at all. Drafting internal policy, summarising regulation, answering process questions, generating code, preparing training material, explaining a product to a colleague. None of it needs a name or an account number, and confidentiality obligations do not attach to information that was never in the prompt.
For the use cases that genuinely do need client context, the useful discipline is to decide deliberately which fields go in and to scope retrieval to what the requesting user is already entitled to see. Pseudonymisation at the application layer helps in some workflows, though it should not be oversold: a sufficiently detailed description of a client's circumstances can be identifying even without a name, and secrecy obligations cover facts about the relationship, not only identifiers.
A workable shape
Run the model on infrastructure the bank controls. This removes the disclosure question rather than arguing it.
Bind every request to a real identity through the bank's existing identity provider, not a shared key.
Scope retrieval to the user's own entitlements, so the assistant cannot see what the person could not.
Draw hard separations at the deployment boundary where information barriers require it, because inside a single serving instance the separation is logical rather than physical.
Decide what is logged, explicitly. Then decide who can read it, and treat prompt content in logs as client information, because it is.
Keep a record you can produce. Which person, which model, when. An internal system with no attribution cannot demonstrate need-to-know, only assert it.
Document the responsibility split between the platform, the infrastructure team and the application owner before the first audit rather than during it.
Frequently asked questions
Can a bank use ChatGPT or a similar public service with client data? Transmitting client information to an external provider is a disclosure to a third party. In jurisdictions where banking secrecy is criminally enforced, that requires a specific justification, most reliably the client's express consent. Enterprise terms and retention settings change what the recipient does with the data, not the fact that a recipient existed.
Is GDPR compliance enough for client confidentiality in banking? No. They are separate obligations. Data protection law provides a processor construct that legitimises involving a vendor. Banking secrecy is national law with narrower gateways and no general equivalent, so a bank can satisfy GDPR and still have a secrecy problem.
Does an EU cloud region solve the problem? It addresses data residency. The cloud operator remains a third party receiving client information, and if that operator is subject to a foreign jurisdiction, the bank has two questions rather than one.
Does running AI on our own servers make us confidential by default? It removes the external disclosure question. It does not address internal need-to-know, retrieval that crosses information barriers, or prompt content written into logs. Those are the risks that remain, and they are the ones to design for.
What is the lowest-risk way to start? Use cases that need no client identifiers at all. Policy drafting, regulatory summarisation, internal process questions, code. The value is real and the confidentiality analysis is short.
Where this leaves you
The banking question is not "which AI provider is compliant", but "did anything leave, and can we show who saw what". The first half is answered by architecture. The second half is answered by the controls around the model, and by whether the bank can attribute a request to a person rather than to an application.
Xinity runs open models on the bank's own infrastructure, with access tied to real identities through single sign-on and role-based access control, and a record of every inference request attributable to the person who made it. The computation stays inside the institution. So does the evidence.
AI declaration
This article was drafted with AI assistance and reviewed, fact-checked and edited by the Xinity team before publication.
Sources referenced
Section 38 of the Austrian Banking Act (BWG) and the scope of Austrian banking secrecy, including the Supreme Court decision on assignment of claims: https://www.taylorwessing.com/en/insights-and-events/insights/2020/03/austrian-banking-secrecy
Comparative note that German Bankgeheimnis arises primarily from contract and data protection law rather than a separate statutory privilege: https://practiceguides.chambers.com/practice-guides/comparison/1132/17912/27952-27954-27956-27958-27962-27964-27966-27968-27970-27972-27974
Banking secrecy as largely unharmonised national law in the EU, and the written-consent exception under section 38(2) no 5 BWG: