Sovereign AI
On-Premise AI for Banks and Insurers
In short
On-premise AI for banks and insurers means running AI models on servers the institution operates, so prompts, documents and outputs never reach an external AI provider. Xinity is open-source software from Vienna, Austria, that gives IT teams a cloud-like experience to deploy, govern and audit open-weight models on that hardware.
Why do we say cloud-like? Because it works the way teams already use cloud AI platforms. A developer gets an API key and calls a model from an application. IT chooses models from a model hub, decides which teams might use them and follows usage in one dashboard. What changes is where it runs: on the institution's own servers, not in a provider's data centre.
DORA (Regulation (EU) 2022/2554) has applied since 17 January 2025. An external AI API is an ICT service from a third-party provider: it goes into the register of information (Article 28(3)) and needs contract terms under Article 30.
Under the EU AI Act (Regulation (EU) 2024/1689), credit scoring of natural persons and risk assessment and pricing in life and health insurance are high-risk (Annex III, point 5). Those obligations apply from 2 December 2027, after Regulation (EU) 2026/1744 moved the date from 2 August 2026.
The AI literacy duty in Article 4 of the AI Act has applied since 2 February 2025, for every AI use, high-risk or not. Since 27 July 2026, as amended by Regulation (EU) 2026/1744, it requires providers and deployers to take measures that support AI literacy, without guaranteeing a specific level.
Health data in life and health insurance claims is special category data under Article 9 of the GDPR.
Xinity is software. It is not a hardware vendor and not a model, and its code is public on GitHub.
Every prompt is a data transfer
A claims handler pastes a medical report into an AI assistant to summarise it. A credit analyst asks a chatbot to compare two loan files. Both tasks take seconds, and both send customer data to a server the bank or insurer does not run.
For most industries that is a procurement question. For banks and insurers it is an outsourcing, data protection and supervisory question, and the answer usually ends in "not with this tool". So teams either wait, or they use AI anyway without telling anyone.
Xinity gives financial institutions a third option: the convenience of a cloud AI platform, running on their own servers. Models, prompts, documents and logs stay inside the building.
What is on-premise AI for banks and insurers?
On-premise AI is a deployment model in which large language models run on hardware the bank or insurer operates, in its own data centre or private environment. The institution's IT team runs the models, and no external AI provider sees the prompts, the documents attached to them or the outputs.
It differs from an EU-hosted AI service, which keeps data in the EU but still sends it to a provider. It also differs from a private cloud tenancy, where the institution runs the model but the infrastructure belongs to a cloud provider.
Deployment | Where prompts are processed | Who runs the model | External party holding the data |
|---|---|---|---|
Public AI API | Provider's data centre, location set by the provider | AI provider | AI provider and its subprocessors |
EU-hosted AI API | Provider's data centre in the EU | AI provider | AI provider and its subprocessors |
Private cloud tenancy | Cloud infrastructure reserved for the institution | The institution, on rented infrastructure | Cloud provider |
On-premise with Xinity | The institution's own servers | The institution's IT team | None |
Which rules apply to AI in banks and insurers?
Financial services is one of the few sectors where several rulebooks apply to the same AI prompt at once. None of them bans AI. Each one adds work for every external party that sees customer data.
Rule | Who it applies to | What it means for AI |
|---|---|---|
EU banks, insurers, investment firms and other financial entities, since 17 January 2025 | An external AI API is an ICT service from a third-party provider. It needs due diligence, an entry in the register of information (Article 28(3)), contract terms under Article 30 and, where it supports a critical or important function, a documented exit strategy (Article 28(8)). For insurers, DORA replaced the EIOPA cloud outsourcing guidelines, which EIOPA withdrew from 17 January 2025. | |
Banks, investment firms, payment and e-money institutions | Supervisors expect access, audit and exit rights over outsourced functions. The EBA published replacement guidelines (EBA/GL/2026/09) on 18 September 2026; once they apply, they cover non-ICT services only, and ICT services such as AI APIs fall under DORA. | |
EIOPA Opinion on AI governance and risk management (6 August 2025) | Insurers, through national supervisors | Existing Solvency II and IDD rules apply to AI: data governance, record-keeping, human oversight, robustness and cybersecurity, in proportion to the risk. The Opinion covers AI systems that are not high-risk or prohibited under the AI Act. |
Any processing of personal data | An AI provider that processes prompts is a processor (Article 28). Transfers outside the EU fall under Chapter V. Health data is special category data (Article 9). | |
Banking secrecy (§ 38 BWG in Austria, Art. 47 Banking Act in Switzerland) | Banks | Client information may not be disclosed to third parties without a legal basis or the client's consent. |
Swiss supervised institutions | FINMA expects an inventory of AI applications, risk classification, documentation, testing and clear responsibilities, also when third-party providers are involved. | |
Providers and deployers of AI systems in the EU | AI literacy since 2 February 2025, as a duty to take supporting measures since 27 July 2026. Credit scoring and life and health insurance pricing are high-risk (Annex III, point 5) from 2 December 2027. Deployers of high-risk systems must keep the system's logs for at least six months (Article 26(6)). |
The common thread: every external provider adds a contract, a risk assessment and an audit trail the institution does not control. That makes AI on someone else's infrastructure slow to approve.
Key dates for AI in financial services
Date | What applies |
|---|---|
17 January 2025 | DORA applies to EU financial entities |
2 February 2025 | AI Act prohibited practices and the AI literacy duty (Article 4) |
2 August 2025 | AI Act rules for general-purpose AI model providers, governance and penalties |
27 July 2026 | Regulation (EU) 2026/1744 enters into force and rewrites the AI literacy duty |
2 August 2026 | General application of the AI Act, including most transparency duties under Article 50 |
2 December 2026 | Two new AI Act prohibitions added by Regulation (EU) 2026/1744; machine-readable marking (Article 50(2)) for generative AI systems placed on the market before 2 August 2026 |
2 December 2027 | High-risk obligations for Annex III systems, including credit scoring and life and health insurance pricing |
2 August 2028 | High-risk obligations for AI built into products covered by Annex I |
Is your AI use case high-risk under the EU AI Act?
Most AI use in banks and insurers is not high-risk. Annex III, point 5 of the EU AI Act names two financial cases: AI that evaluates the creditworthiness of natural persons or sets their credit score (fraud detection is excluded), and AI used for risk assessment and pricing of natural persons in life and health insurance.
Summarising a claim file, drafting a customer reply or searching internal policies is not on that list. A model that pre-reads a loan file for an analyst sits closer to the line. Article 6(3) of the AI Act can exclude systems that pose no significant risk and only perform a narrow procedural or preparatory task, but never systems that profile natural persons, so legal should assess each case.
High-risk or not, every use is covered by the GDPR, DORA and the AI literacy duty. Running the model on your own servers makes logging, oversight and documentation easier to evidence, because the records already sit with you.
What Xinity provides
Xinity is the control plane for running open AI models on your own servers: the cloud experience, on your premises. It is the layer that lets IT teams deploy, govern and audit AI the way they would with a cloud platform, without the data leaving.
A walk through the Xinity dashboard
This is the home screen your IT and risk teams could open first. Every figure on it comes from requests recorded on your own servers. Reading it from top left to bottom right:
Total API Calls. How many requests teams and applications have sent to your models, with today's count and the share of calls that were logged.
Avg Tokens / Call. The average size of inputs and outputs over the last hour, ten minutes and minute, so you can see how heavily the models are used right now.
Approval Rate. The share of rated answers that users approved, next to the average response time on your hardware.
Training Datapoints. Answers that users rated or edited, collected in the Training section.
Usage Trend (30 days). Total calls, logged calls, input tokens and output tokens per day. Peaks show when a team starts using a use case and how load develops.
Response Ratings. Liked, disliked and unrated answers: a direct quality signal from the people who use the models.
The sidebar holds the rest of the control plane: AI API Keys to give applications access, Data for recorded requests, Training, Model Hub to choose which models run, Organizations for teams, and Instance Settings for the installation itself.
Capability | What your team gets |
|---|---|
Deploy | Install open-weight models on your own hardware, in your data centre or private environment, and serve them to internal teams and applications |
Govern | Decide which teams and applications can use which models, and manage access from one dashboard |
Audit | Requests are logged on your side, so the risk team can see who used which model and when |
Version control | You choose which model version runs and when it changes |
Code review | The platform is open source on GitHub, so your security team can read the code before it runs in production |
Xinity does not sell servers and it is not a model. It runs on hardware you already own or buy from your preferred vendor, with open-weight models chosen for the task.
Because the models run on infrastructure you operate, the AI is not a new external data recipient. It sits inside the perimeter your existing controls already cover.
Where banks and insurers use on-premise AI
Team | Task | Data that stays in-house | EU AI Act note |
|---|---|---|---|
Claims (insurance) | Summarise claim files, medical reports and correspondence | Health data, policyholder details | Not listed in Annex III; health data is special category under Article 9 of the GDPR |
Underwriting | Extract key facts from applications and broker submissions | Risk profiles, financial statements | High-risk if the system assesses risk or sets prices for natural persons in life and health insurance |
Credit | Pre-read loan files and draft credit memos for the analyst | Income, collateral, account history | High-risk if the system evaluates creditworthiness or sets a credit score for natural persons |
Compliance and AML | Search internal policies, draft case notes, review alert narratives | Transaction data, case files | Not listed in Annex III, point 5 |
Customer service | Draft replies to customer emails and complaints | Account and contract details | If customers talk to an AI directly, Article 50 transparency duties apply |
Legal and contracts | Compare contract clauses and flag deviations | Counterparty agreements | Not listed in Annex III |
IT and engineering | Coding assistants on internal codebases | Source code, system configuration | Not listed in Annex III |
In each case a human stays responsible for the decision. The model drafts, sorts and summarises; the analyst, handler or advisor signs off.
What your risk, compliance and audit teams will ask
Question | With an external AI API | With Xinity on your servers |
|---|---|---|
Where is the data processed? | In the provider's data centre, sometimes outside the EU | On hardware you operate |
Who else can access prompts and outputs? | The provider and its subprocessors, under contract | Only the people you give access |
Does it add an ICT third-party provider under DORA? | Yes, and it sees customer data | No external party sees prompts. A Xinity support contract is a software service you register, but the data stays on your hardware |
What happens if the provider changes its model or terms? | Your application can behave differently overnight | You choose which model version runs and when it changes |
Can we show who used AI, and for what? | Depends on the logs the provider shares | Requests are recorded on your side |
Can we exit? | Requires a migration plan off the provider | Open models and open-source software, on your hardware |
These are the questions that stall AI projects in the approval phase. On-premise does not remove governance work, but it moves the answers back under your control.
How to start with on-premise AI
Pick one use case with sensitive data, a clear owner and a measurable outcome, such as the time it takes to summarise a claim file.
Check the EU AI Act classification with legal before the pilot, using Annex III, point 5 as the reference.
Run a 30-day pilot on your own hardware with Xinity and an open-weight model suited to the task.
Bring risk and compliance in early. Show them the dashboard, the access rules and the request records before the pilot ends, not after.
Add the use case to your internal AI inventory. Swiss institutions are expected to keep one under FINMA Guidance 08/2024.
Scale by team. Add use cases and models once the first one is approved.
Your engineers can look at the code on GitHub today. To plan a pilot for your bank or insurance company, book a call with the Xinity team at xinity.ai.
FAQ
What is on-premise AI for banks? On-premise AI means the language models run on servers the bank operates, so customer data in prompts and documents is not sent to an external AI provider. The bank's IT team runs and governs the models.
Does DORA allow banks and insurers to use AI? Yes. DORA does not ban AI, but an external AI service is an ICT service from a third-party provider, with register, contract and exit requirements under Articles 28 and 30. Running models on your own infrastructure keeps the AI inside your existing ICT controls.
Is on-premise AI outside the scope of DORA? No. DORA covers ICT risk as a whole, including your own systems. Running models in-house removes the external AI provider from the data path, but the hardware, the software and any support contracts stay within your ICT risk framework.
Is AI in insurance high-risk under the EU AI Act? Only some of it. AI used for risk assessment and pricing of natural persons in life and health insurance is high-risk under Annex III, point 5 of the EU AI Act. Claim summaries, correspondence drafts and policy search are not on that list.
Is credit scoring high-risk under the EU AI Act? Yes. AI that evaluates the creditworthiness of natural persons or sets their credit score is high-risk under Annex III, point 5 of the EU AI Act. AI used to detect financial fraud is excluded from that point.
When do the EU AI Act high-risk rules apply to banks and insurers? From 2 December 2027. Regulation (EU) 2026/1744, in force since 27 July 2026, moved the Annex III date from 2 August 2026.
Can a bank paste client data into a public AI chatbot? Usually not without a legal basis. Banking secrecy rules such as § 38 BWG in Austria and Art. 47 of the Swiss Banking Act restrict disclosure of client information to third parties. With on-premise AI, the data stays with the bank.
Does Xinity sell servers? No. Xinity is software. It runs on hardware you already own or buy from your preferred vendor.
Which models can banks run with Xinity? Xinity runs open-weight models on your own servers. The Xinity team helps you choose a model that fits the task and your hardware.
Is Xinity open source? Yes. The platform is available on GitHub, so security teams can review the code.
Where is Xinity based? Xinity is developed in Vienna, Austria, and built for regulated organisations across Europe.
Glossary
Term | Meaning |
|---|---|
Open-weight model | An AI model whose trained weights are published, so it can run on your own hardware |
Control plane | The software layer that deploys, governs and audits models, separate from the models themselves |
ICT third-party service provider | Under DORA, any undertaking that provides ICT services to a financial entity |
Register of information | The DORA record of all contracts with ICT third-party service providers (Article 28(3)) |
Deployer | Under the EU AI Act, an organisation that uses an AI system under its own authority |
Sources
EBA Guidelines on third-party risk regarding non-ICT services, EBA/GL/2026/09
EIOPA withdraws its cloud outsourcing guidelines to avoid overlap with DORA, 19 December 2024
EIOPA Opinion on AI governance and risk management, 6 August 2025
Bankwesengesetz (BWG), current version (RIS)
EU AI Omnibus enters into force, amending the AI Act (White & Case)
AI declaration
This article was drafted with the help of AI and reviewed and edited by the Xinity team. It is general information, not legal advice.