Data and AI sovereignty
Sovereignty is architecture, not a setting.
NeuralSeek is a container you run inside your own boundary — your cloud, your region, your keys, your hardware if that is what your regulator requires. None of that is a promise about how we will behave with your data. It is a statement about where the software runs. The test is simple: unplug it from the internet, and it keeps working.
Deployment
It runs where your data already lives.
Most AI asks you to send your data out to it. NeuralSeek goes the other way: one container, placed inside a boundary you already control — and the same software whether that boundary is a cloud account or a locked room. No sovereign edition, and no feature held back.
Can we see it working before we commit?Managed SaaS
Start on the managed service, run by NeuralSeek on GCP, Azure, AWS or IBM Cloud. It is the same software you would run yourself, with nothing held back — so when residency becomes the requirement, you move the container inside your own boundary and nothing has to be rebuilt.
Can it run in our own cloud account, under our own keys?Private cloud
The same container in your own account, under your network policy and your key management, with GovCloud-eligible topologies. Retrieval, logging and the audit trail run in your region with it, and you decide which model it calls: one you host for the sensitive work, a cloud model for the rest, switched task by task.
Our government requires our data to stay inside our borders.Sovereign cloud
Deploy it from your own registry into a region or operator your regulator already recognises. Everything stays local — production and non-production, high availability and disaster recovery included — so there is no cross-border transfer to explain, because there is none.
Will it fit the platform we already run?OpenShift
NeuralSeek is containerised end to end and runs on Red Hat OpenShift, alongside the rest of your regulated workloads. Your admission, network and secret-management rules apply to it exactly as they do to everything else on the cluster: no special handling, and no exception to approve.
What happens if we unplug it from the internet?Air-gapped on-prem
It keeps working. Behind your firewall — or as a single appliance on IBM Fusion, hardware and software delivered together — it runs with no internet connection and no cloud model at all: open models on your own GPUs, your own vector database, nothing leaving the building. And with the model running locally, there are no per-token charges for it either.
Inside the perimeter
What ships with every deployment, wherever it runs.
The isolation, audit and redaction primitives are not a sovereign-tier upgrade. SaaS or air-gapped, it is the same set.
Encrypted in transit and at rest
Data residency
Where does our data actually go?
Where you put it. NeuralSeek runs in your tenant, in the region you choose, or on hardware inside your own building — and retrieval, orchestration, logging and the audit trail run there with it. There is no egress path to negotiate away, because the data does not travel. The logs are written to a store you own. The one boundary crossing left is the model call itself, and that is a choice: point it at a model you host and nothing leaves at all.
A forensic audit trail
AI sovereignty
Sovereign data is half of it. The other half is the model.
Data residency does not help much if the intelligence itself belongs to someone else, on someone else's terms. In NeuralSeek the model is one layer of the container — a layer you choose, and can change.
Model-agnostic by design
Swap the underlying model whenever you want, with no rebuild. Your data, your guardrails and the applications built on top do not move when it changes. Route by task, too: the sensitive work to a model you host, the rest to a hosted one — the best model is rarely one model, because speed, cost and quality differ by job.
Your own provider keys
Bring your own keys to a model provider, so the commercial relationship — and the entitlement that comes with it — is yours rather than something you rent through us.
Open models on your own GPUs
Run open-source models on hardware you own, inside the same boundary as everything else. At that point no call leaves your network at inference time either.
The questions buyers ask next.
Each one is a fear with a name. None has a satisfying answer from a vendor that runs your AI on its own infrastructure; each has one architectural answer here.
What if the model we depend on is withdrawn or restricted?
Then you change a setting. The model is one layer inside the container, not the foundation under it: your data, your guardrails and the applications on top do not move when it changes. Run open models on your own GPUs and the question does not arise at all — nothing outside your boundary can be pulled, throttled or re-licensed.
What if a court or agency demands our data from a provider?
A hosted model provider keeps its own record of your queries, under a retention policy you did not write. Run the model inside your boundary and the only copy is the one in your log store, kept for as long as your policy says — seven years or an hour — and there is no third party to be asked for it. Your data never leaves your world, so nobody else can be compelled to hand it over.
Will the answers change when a provider changes its model?
Not unless you decide they should. A hosted model can change underneath you — updated, retuned, or slower under load — so the answer you get today may not be the one you got yesterday. A model on your own hardware stays the version you tested; when a new one comes out, you test it on your schedule and switch when it passes.
We already have AI bolted onto half our products. Why is this different?
Every bolt-on is its own data path, its own agreement and its own review — and when something goes wrong, nobody can say which one lost what. One platform inside one boundary is one review, one audit trail and one place to look. Approve it once and every application built on it inherits the approval, instead of starting the review again for each vendor.
If we lock AI down, won't people just use their own?
They will, and many already do. Blocking tools does not stop it; giving people an approved one does. Because NeuralSeek runs inside your boundary with guardrails, logging and governance on every answer, it can be the tool you hand everyone on day one — and the one you point everybody else to.
Where do our meeting notes end up?
A meeting assistant that runs as someone else's service sends the conversation to wherever that service runs. NeuralWorks, the assistant built on NeuralSeek, prepares for your meetings and follows up on them inside your own boundary, with the models you provide — so the conversation comes back to your servers instead of leaving them.
Do you train on our data?
No. Your prompts, your documents and your interaction logs are not used to train models — not ours, not a provider's, not a shared one. Keys are separated per tenant and nothing co-mingles across them. This is not a tier or a contract option; it is how every deployment works.
Compliance comes from where it runs.
Drop the container into an environment that is already authorised and it inherits that boundary. The audit you have already passed is the audit it operates under: your network controls, your key management, your logging, your incident process. That is why the honest answer to “is it certified?” is a question about your tenant, not about our infrastructure.
Attested
SOC 2 Type II
Attested at the vendor level and audited annually. The report is available under NDA.
The frameworks below are not certifications NeuralSeek holds. They are requirements it is built to meet inside your environment, where your own controls and your own audit apply.
Control mappings, not compliance claims. Validate your posture against your own obligations, with your own counsel.
See it running inside your own boundary.
Talk to a NeuralSeek expert about how it fits your stack, where your data has to live, and the governance your auditors already expect.