Does Xinity see your data?

No. Xinity does not see your data, and the architecture makes it impossible for us to change our minds about that later. The platform runs entirely on your own hardware, on your own network, under your own access controls. Your prompts, documents, model outputs, and fine-tuning data never touch a Xinity server, because there is no Xinity server in the loop.

That is a big claim, and you should not take it on faith. So this post walks through exactly how it works, what you can verify yourself, and how we handle security when something does go wrong.

Where does my data actually go when I use Xinity?

During inference, nowhere. Once your models are downloaded, every request stays on your infrastructure.

When your application sends a request to a Xinity deployment, the entire path lives inside your environment. The request hits the Xinity gateway running on your server, which routes it to a daemon running on your GPU nodes, which runs inference using an open model stored on your disks. The response travels back the same way. Usage logs, audit trails, and recorded LLM calls land in a PostgreSQL database that you host.

The architecture diagram in our repository ends with a line we mean literally: nothing leaves this box. The honest footnote is that "nothing" refers to your data. The initial model download is an outbound request, and so is pulling updates when you choose to. But no prompt, document, or output ever crosses your network boundary, and a deployment can run fully air-gapped once models are in place.

This is the structural difference between Xinity and cloud AI APIs. With a cloud provider, your data leaves your building by definition, and your protection is a contract. With Xinity, your data cannot leave, because the software has no external endpoint to send it to. Sovereignty by architecture, not by contract.

Can Xinity access our systems remotely?

No. There is no phone-home mechanism, no remote management backdoor, and no telemetry pipeline reporting back to us. And you do not have to take that sentence on faith, which is the point: because the source code is public, the absence of telemetry is something your team can verify by reading the code, not a policy statement you have to trust. Xinity deployments run air-gapped if you want them to. Many of our customers in regulated industries require exactly that, and the platform works fully offline once models are downloaded.

We cannot log into your deployment. We cannot read your usage data. We cannot see which models you run or what you ask them. If you invite us to help with a deployment, that access is something you grant, scope, and revoke like any other vendor access, but it is never built in.

How can we verify these claims instead of trusting them?

Read the code. The entire Xinity codebase is public at github.com/xinity-ai/xinity-ai, and the core engine, meaning the gateway, daemon, CLI, infoserver, and database layer, is licensed under Apache 2.0. You can audit every network call the software makes. Your security team can grep for outbound connections. Your compliance auditors can trace the data flow line by line.

This matters more than any certification we could show you. A closed-source vendor asking you to trust their privacy policy is asking you to trust paper. An open-source platform running on your hardware lets you verify the claim directly, and keep verifying it with every release.

Three things worth checking yourself:

1. The data path. Follow a request from the gateway through the daemon and back. There is no branch that exits your network.

2. The dependencies. Xinity uses Ollama and vLLM as inference engines under the hood, both open source and both running locally.

3. The license. Apache 2.0 means you can fork the engine and run it forever, even if Xinity the company disappeared tomorrow. Continuity is part of security.

What security controls does Xinity provide?

Keeping data on-premise removes the biggest risk category, but it does not remove the need for controls inside your perimeter. Xinity ships with enterprise security features as standard, not as add-ons:

• Role-based access control in the dashboard, so teams only see what they should

• SSO, SAML, and 2FA for enterprise authentication

• Multi-org tenant isolation, so separate business units or clients stay separated

• mTLS for encrypted communication between components

• Audit trails with a dashboard UI for filtering, export, and per-instance review, built for GDPR accountability and the documentation duties emerging under the EU AI Act and NIS2

• API key management for all programmatic access

Because all of this runs on your infrastructure, it composes with the controls you already have: your firewalls, your SIEM, your network segmentation, your backup policies. Xinity fits into your security posture instead of asking you to adopt ours.

What happens if a vulnerability is found in Xinity?

We follow coordinated disclosure, and the process is public in our SECURITY.md. Researchers report vulnerabilities privately through GitHub's private vulnerability reporting or by email to security@xinity.ai. The published policy commits to acknowledging reports within five business days, with an initial assessment targeted within fourteen days, and confirmed vulnerabilities are published as GitHub Security Advisories once a fix is available.

This is the honest version of security. No software is free of vulnerabilities, including ours. The question is whether a vendor has a transparent process for handling them, and whether you can see the advisories yourself rather than learning about incidents from the news. With Xinity, the advisory history is public on the repository, permanently.

There is one more advantage of the self-hosted model here: when a fix ships, you decide when to apply it, on your schedule, through your change management process. No vendor pushes updates into your production environment without your knowledge.

Security work is also visible between advisories. Every release ships with a public changelog, and hardening lands there continuously, from SSRF protections in the gateway to stricter permission checks in the dashboard. You do not have to wonder whether security is being worked on. You can read the release notes and watch it happen.

Why does this matter for GDPR and regulated industries?

Because for many organizations, sending data to a cloud AI provider is not a preference question. It is prohibited. Banking secrecy, attorney-client privilege, journalistic source protection, medical confidentiality, and trade secret law all impose limits that no cloud contract fully resolves. The CLOUD Act problem does not go away because a US provider opened a European region.

When AI runs on your own hardware, most of these questions collapse into questions you have already answered. Where does the data live? On your servers. Who can access it? The people you authorize. Which jurisdiction applies? Yours. What happens to prompts after processing? Whatever your retention policy says, because you hold the database.

That is what we mean by sovereign AI infrastructure. Not a marketing label, but a specific architectural property: the ability to answer every data protection question by pointing at hardware you control.

Frequently asked questions

Does Xinity store or train on our prompts? No. Prompts and outputs are processed and stored only on your infrastructure. If you enable request logging for your own fine-tuning, that data stays in your database and is used only by you.

Does Xinity send telemetry or usage analytics back to Xinity? No. There are no hidden network calls and no third-party telemetry in the platform. You can verify this in the source code.

Can Xinity run fully offline? Yes. Once models are downloaded, a Xinity deployment operates without any internet connection.

Is the code really auditable? Yes. The full codebase is public on GitHub. The engine is Apache 2.0 licensed, and the dashboard source is available under the Elastic License v2.

How do we report a security issue? Through GitHub private vulnerability reporting on the repository, or by email to security@xinity.ai. Please do not open a public issue.

Who is behind Xinity? Xinity is built in Vienna, Austria, and developed openly. The company works with regulated enterprises across the DACH region, including media companies, manufacturers, and public institutions.

Want to see the data flow for yourself? The source is at github.com/xinity-ai/xinity-ai. Questions about a deployment in your environment: contact@xinity.ai.