The Default Is Wrong
The default architecture for most SaaS AI platforms is: your data goes to our servers, our models see it, we retain it for training and improvement, you agree to this in paragraph 47 of the terms of service.
This is the wrong default for serious AI deployments. Especially for AI that operates on business-critical data: customer records, internal research, financial data, security events, proprietary workflows.
The Sovereignty Protocol takes the opposite default. Your data stays on your infrastructure unless you explicitly choose otherwise.
Self-Hosted Architecture
The platform is built on PocketBase + Go — a stack chosen specifically because it can run on a single machine with no external dependencies.
When you deploy the Sovereignty Protocol, everything runs inside your infrastructure:
- PocketBase database — all your data, your agent memories, your cascade runs, your reports — stored in SQLite on your server
- Go API — the backend logic runs on your machine, not on our servers
- Cascade runtime — all cascade execution, agent processing, and automation runs locally
- Spectre crawler — web crawling originates from your server with your IP, not a shared crawl infrastructure
The only external calls are to the AI providers you configure (which are necessary for model inference) and any webhooks or integrations you explicitly set up. Everything else is local.
What This Means for GDPR
Under GDPR, the data controller (you) is responsible for ensuring personal data is processed appropriately. Self-hosting substantially reduces the surface area of this obligation:
Data minimisation — Data does not leave your system except to AI providers for inference (which you select and control). No third-party analytics, no background telemetry, no data brokering.
Data subject rights — Because the database is yours, you can respond to subject access requests, deletion requests, and portability requests directly — no waiting for a vendor to process them on your behalf.
Data transfer — Self-hosted means no international data transfers to our infrastructure. AI provider transfers are yours to manage, with the provider of your choice, under the agreements you have with them.
Audit trail — The platform maintains a complete audit trail of all data access and modification. Nexus Reports provide an immutable record of every agent action. This is not configurable — it is how the system works.
Retention control — You control retention policies. There is no minimum retention period imposed by the platform, no retention for model improvement, and no opaque retention policies you are subject to without knowing it.
BYOK and Data Processing
When you use Bring Your Own Key, the data flow is:
Your server → AI provider (your key, your account, their DPA)
↑
You negotiated this agreement
When you use the platform's pooled keys (the default before BYOK is configured):
Your server → Our infrastructure → AI provider
↑
This is where our DPA with you applies
The difference matters. BYOK means the AI provider's data processing agreement is between you and them. Pooled keys means it is between us and the provider, and you rely on our processing agreement. For regulated industries, BYOK is the right choice.
Data Residency
Self-hosting gives you full data residency control. Deploy in any region, in any data center, on-premises or in a cloud VPC of your choosing.
This is not a paid feature or a compliance tier. It is inherent to the self-hosted architecture. If you need EU data residency, deploy in an EU data center. If your security policy requires on-premises deployment, deploy on-premises. The platform does not impose residency restrictions.
For organisations with strict data residency requirements (healthcare, finance, government), this is often the deciding factor. Other platforms offer "EU hosting" as a premium tier. We offer "your server, your choice" as the base model.
What We Do Collect
Transparency requires naming what we do collect and why:
Licence validation — When you activate a licence key, we validate it against our licence server. This involves your instance sending a licence check request with your key. We store that a licence was activated, not what you are using it for.
Error reporting (opt-in) — If you enable error reporting, stack traces from crashes are sent to our error tracking system. This does not include your data — only the error context (file, line number, error message). Disabled by default.
Version checking (opt-in) — If you enable update notifications, your instance pings our update server to check for new releases. This involves sending your current version number. Disabled by default.
That is the complete list. There is no telemetry, no usage tracking, no analytics collection, no training data extraction — none of it.
The Right to Know
You have the right to know exactly what an AI system is doing with your data. Most platforms make this difficult — abstract privacy policies, vague "improvement" language, and opaque model training clauses.
The Sovereignty Protocol's answer is: the code is inspectable, the architecture is documented, and the data stays on your server. If you want to know what happens to your data, you can read the source, audit the network traffic, or simply observe that your data never leaves the server you deployed on.
Privacy is not a setting. It is an architecture decision. We made it at the beginning and it shapes everything downstream.
For Regulated Industries
The Sovereignty Protocol has been deployed in:
- Healthcare — Agent-assisted clinical research workflows, patient data stays on-premises
- Legal — Document analysis and research pipelines, client confidentiality maintained
- Finance — Market intelligence automation, trading signals never leave internal infrastructure
- Government — Operational automation within classified or restricted environments
For each of these, the self-hosted architecture was the prerequisite. No amount of compliance certification from a cloud vendor is equivalent to the data simply not leaving the building.
Your data. Your infrastructure. Your compliance.