OperativeOps and GDPR
OperativeOps is self-hosted software. It runs on infrastructure you control, and the personal data your agents touch stays inside your environment — which leaves your organisation as the sole controller and keeps the runtime out of the controller/processor question entirely.
- OperativeOps is self-hosted only. There is no hosted, managed or SaaS deployment — the software runs on your servers, in your cloud account, or air-gapped.
- Your organisation is the sole controller for everything the deployment processes. No runtime personal data is transmitted to the makers of OperativeOps.
- Because no personal data reaches us at runtime, an Article 28 processor agreement is generally not needed for the deployment itself. Confirm that against your own facts — a support engagement in which you send us logs or diagnostics is a separate question.
- Data residency is simply wherever you deploy. Run it in an EEA region and OperativeOps engages no Article 44–49 transfer mechanism of its own.
- If you point an agent at a hosted model API (OpenAI, Anthropic), that provider is your processor and personal data in prompts leaves your network. Running Ollama or vLLM locally avoids that entirely.
- Append-only audit logs record access events, tool invocations and human approvals, which supports the Article 5(2) accountability obligation.
- This page is not legal advice. It describes the deployment posture so your DPO and counsel can make their own determinations.
What GDPR requires
The General Data Protection Regulation (GDPR) is the EU's comprehensive data protection law, directly applicable across all EU Member States since 25 May 2018. It sets rules for any organisation that processes personal data of EU/EEA residents, regardless of where the organisation is based.
Article 6 requires a lawful basis for every processing operation. For internal business tooling the most common bases are legitimate interest (Art. 6(1)(f)) — for example, processing employee data to operate business systems — and contract performance (Art. 6(1)(b)). Special category data (Art. 9) requires an additional explicit condition.
Articles 4 and 28 draw the critical controller/processor distinction. The controller determines the purposes and means of processing; the processor acts on the controller's instructions. Where a vendor processes personal data on behalf of a customer, a binding Data Processing Agreement (DPA) is legally required between the parties. Where no personal data reaches the vendor at all — the ordinary case for software you run yourself — that relationship does not arise for the runtime.
Data subject rights under Articles 12–22 give individuals the right to access (Art. 15), rectification (Art. 16), erasure (Art. 17), restriction (Art. 18), portability (Art. 20), and objection (Art. 21). Controllers must respond to Data Subject Access Requests (DSARs) within one calendar month.
Articles 44–49 regulate transfers outside the EEA. Where no adequacy decision exists, transfers require appropriate safeguards such as Standard Contractual Clauses (SCCs) approved by the European Commission. Intra-EEA processing requires no transfer mechanism.
Article 30 requires controllers and processors to maintain written Records of Processing Activities (RoPA). For AI agent deployments, this includes documenting agent workflows, data categories processed, retention periods, and recipient categories — including any external model provider you route prompts to.
How OperativeOps maps to GDPR requirements
| Requirement | Our control | Where |
|---|---|---|
| Lawful basis support (Art. 6) | Purpose and scope are configured per agent inside your own deployment. That configuration is visible to you and can be cited directly in your legitimate interest assessment. | self-hosted |
| DSAR fulfilment (Art. 15–22) | Audit logs and conversation history sit in your own database, so you locate and extract personal data with your existing tooling. Deletion follows the retention policy you configure. | self-hosted |
| Processor relationship (Art. 28) | The software runs entirely on your infrastructure and sends no runtime personal data to us, so no Art. 28 processor relationship arises from operating it. Any third party you connect — a hosted model API, an MCP-connected SaaS tool — is your processor, not ours. | self-hosted |
| Data residency / EEA transfers (Art. 44–49) | Determined by where you deploy. Nothing in the software moves personal data out of your environment on its own; egress to an external model provider is explicit configuration that passes through the egress gate you control. | self-hosted |
| Encryption at rest and in transit | TLS between components in transit. Encryption at rest is provided by the storage layer and key management you operate — your KMS, your keys, your rotation policy. | self-hosted |
| Retention controls (Art. 5(1)(e)) | Configurable retention policies per workspace, with automated deletion at the end of each period. You set the periods; the data never leaves your database. | self-hosted |
| Audit logging (Art. 5(2) accountability) | Append-only audit log of every model decision, agent action, tool invocation, and human approval. It is stored in your deployment and readable with your own tooling. | self-hosted |
| Data minimisation in agent prompts (Art. 5(1)(c)) | Agents are role-scoped: each one can only read the sources and call the tools its permission boundary allows, which limits what personal data can enter its context in the first place. | self-hosted |
| Article 30 records of processing | Agent scopes, connected tools, retention settings and model routing are all declared in your own configuration, which is the source material your RoPA entry is built from. | self-hosted |
What self-hosting changes for GDPR
OperativeOps only exists as software you run yourself — on-premises, in your own cloud tenancy, or air-gapped. There is no hosted tier and no managed operation, so there is no scenario in which your runtime personal data sits in somebody else's infrastructure. Your organisation is the sole controller of everything the deployment processes, and the data plane never leaves the boundary you already defend. For EU-regulated organisations this is a materially simpler GDPR position than a SaaS purchase: there is no sub-processor list to review, no transfer impact assessment to run against a vendor, and no third-party retention schedule to reconcile with your own.
The Article 28 consequence follows from that, and is worth stating carefully. A processor agreement is required where a party processes personal data on your behalf. In an ordinary self-hosted deployment no personal data reaches us at all, so there is nothing for such an agreement to govern and it is generally not required. That conclusion is yours to confirm, not ours to assert — it depends on facts specific to your deployment. If you buy a support engagement and send diagnostic bundles, log excerpts or reproduction data that contain personal data, that is a distinct processing activity and should be papered on its own terms. Your DPO should make that call against what you actually intend to share.
Self-hosting does not make the obligations disappear; it moves them. You own the full stack, which means encryption, key management, backup, patching, access control and breach detection are yours. It also means the model routing decision is yours: an agent pointed at a hosted model API sends prompt content — potentially including personal data — to that provider, who becomes your processor and whose location determines whether Articles 44–49 are engaged. Pointing the same agent at a local Ollama or vLLM backend keeps the entire inference path inside your network. Lawful basis, DPIA, RoPA and DSAR fulfilment remain your responsibility in every configuration.
What you are responsible for
- Operating the deployment — encryption, key management, backups, patching, access control and breach detection. There is no operator behind a self-hosted install other than you.
- Conducting a Data Protection Impact Assessment (DPIA) under Art. 35 where your use of OperativeOps involves high-risk processing — for example, large-scale processing of employee data or systematic monitoring.
- Maintaining your Records of Processing Activities (RoPA) under Art. 30, including the agent workflows that process personal data and any external model provider in the path.
- Selecting and documenting the lawful basis (Art. 6) for each processing purpose in your deployment.
- Choosing the model backend and assessing it. A hosted model API is a recipient of whatever your prompts contain; a local model backend is not. That choice is configuration, and its GDPR consequences are yours.
- Responding to Data Subject Access Requests (DSARs) within the statutory one-month period. The data surfaces are in your own database; fulfilment is your obligation as controller.
- Appointing a Data Protection Officer (DPO) if required by Art. 37 — for example, if you are a public body or your core activities involve large-scale systematic monitoring.
- Configuring agent permission boundaries, data retention periods, and audit log settings to match your legal obligations.
- Engaging qualified legal counsel for interpretation of your GDPR obligations. This page documents the technical surface; you make the legal call.
Frequently asked questions
Is OperativeOps GDPR-compliant?
Compliance is a property of how a system is deployed and operated, not of software on its own. OperativeOps is designed to be deployed in compliance with GDPR: it runs on your infrastructure, keeps personal data inside your environment, scopes each agent's access, and writes an append-only audit log. Your DPO and counsel make the final determination for your specific deployment.
Who is the controller and who is the processor?
Your organisation is the sole controller. Because OperativeOps is self-hosted, no runtime personal data reaches us, so we are not a processor for the deployment. If you connect an external service — a hosted model API, or a SaaS tool over MCP — that service processes personal data on your instructions and is your processor, governed by whatever agreement you already hold with it.
Where is data stored?
Wherever you put it. Documents, embeddings, conversations and audit logs live in the database and vector store you provision, in the region and jurisdiction you choose. There is no OperativeOps-operated storage in the architecture, so there is no second copy to account for.
Do you sign a Data Processing Agreement?
In an ordinary self-hosted deployment there is generally nothing for a DPA to cover, because no personal data reaches us. Whether that holds for your deployment is your determination to make. Where a support engagement would involve sending us diagnostic data that contains personal data, treat that as a separate processing activity and agree terms for it before sharing anything.
Do you transfer data outside the EEA?
OperativeOps transfers nothing — it is software running in your environment. The transfer question applies to the services you connect it to. If you configure an agent to call a model API hosted outside the EEA, that is a transfer you are making, and Articles 44–49 apply to it. A local model backend (Ollama, vLLM) keeps inference inside your network and avoids the question.
How do I fulfil a data subject access request through OperativeOps?
As controller, DSAR fulfilment is yours. The relevant surfaces — audit log, conversation history, ingested documents and their embeddings — are all in your own database, so you can query them directly or through the admin interface and API. Deletion can be triggered per record or left to the retention policy you configured.
How long is data retained?
Retention periods are configurable per workspace by your administrators. There is no fixed default — you set the period that matches your legal obligations and internal policies, and automated deletion runs at the end of each configured period.
Who do I contact about privacy?
OperativeOps is a product, not an organisation that operates your data. For questions about the personal data handled by this website and the licensing process — the only personal data that reaches us — contact privacy@operativeops.com. Whether your own organisation needs to appoint a DPO is a question about your activities under Art. 37.
What do you provide for our Article 30 records?
The material for your RoPA entry comes from your own deployment: the agent definitions and their permission boundaries, the connected tools and document sources, the configured retention periods, and the model backend each agent routes to. Because you hold the configuration, you can describe the processing accurately without depending on a vendor's disclosure. Maintaining the record remains your obligation.
What personal data does OperativeOps itself process?
None from your deployment. The software processes your data on your infrastructure under your control — you are the controller and you identify the lawful basis. Separately from the software, this website and the licence purchase process handle a small amount of contact data; that is covered by the privacy policy.