OperativeOps and the EU AI Act
OperativeOps is self-hosted software that runs inside your own boundary, which makes you the operator of the AI system in the sense the AI Act uses. It provides the technical surfaces that role needs: AI disclosure in the interface, per-action human approval gates, and an append-only audit ledger of every model decision.
- OperativeOps is self-hosted only — on your servers, in your own cloud tenancy, or air-gapped. There is no hosted or managed offering, so the jurisdiction of the deployment is simply the jurisdiction you deploy into.
- You are the operator (deployer) of the AI system. The obligations that follow from your risk classification sit with you, and the software gives you the logs, approval gates and configuration records to discharge them.
- Bring your own model: the AI Act obligations attaching to a general-purpose AI model fall on whoever provides that model. You choose it — OpenAI, Anthropic, a local Ollama or vLLM backend — and that choice determines which upstream provider is in the picture.
- An append-only audit ledger records every model decision, tool invocation and human approval, which is the evidence base for post-market monitoring and incident reconstruction.
- This page is not legal advice. It describes the deployment posture so your DPO and counsel can make their own determinations.
What the EU AI Act requires
The EU AI Act is the European Union's comprehensive regulation on artificial intelligence, with phased enforcement beginning 2 August 2025 (general-purpose AI provider obligations) and the bulk of rules entering into force 2 August 2026.
Obligations vary by risk class: prohibited practices (banned outright), high-risk systems (substantive conformity assessment, technical documentation, post-market monitoring), limited-risk systems (transparency to end users), and minimal-risk systems (voluntary codes).
The Act also distinguishes the provider of an AI system from its deployer. When you run self-hosted software on your own infrastructure and configure the agents, the model backend and the actions they may take, you are the deployer — and, depending on how substantially you configure it, you may take on provider obligations for the system you have assembled.
For most business deployments of OperativeOps, the relevant obligations are Article 50 transparency (people must know they are interacting with AI) and the documentation and oversight requirements that apply when the deployer classifies its own use case as high-risk under Annex III.
How OperativeOps maps to the requirements
| Requirement | Our control | Where |
|---|---|---|
| Article 50 — disclose AI interaction to users | Agents identify themselves as AI in the interface; system messages mark non-human authorship. Configurable per deployment. | self-hosted |
| Record-keeping for the deployer's technical file | The configuration that defines the system — agent roles and permission boundaries, connected tools, retrieval sources, and which model backend each agent routes to — is declared in your own deployment and versioned with it. | self-hosted |
| Logging and post-market monitoring | Append-only audit ledger of every model decision, agent action, tool invocation, and human approval, retained in your own database for as long as you configure. | self-hosted |
| Data residency / sovereignty | Your infrastructure, your jurisdiction. Nothing in the software calls out on its own; any egress to an external model provider passes through a gate you configure. | self-hosted |
| Human oversight (Art. 14) | Per-action approval gates for tool use, with approval scopes configurable per role. Agents are read-and-recommend unless you explicitly grant an action. | self-hosted |
| Accuracy and traceability of outputs | Retrieval answers carry source citations back to the documents in your own vector store, so an output can be traced to the material it was drawn from. | self-hosted |
What self-hosting changes under the AI Act
Self-hosted deployment places OperativeOps inside your VPC, data centre, or air-gapped network. You control the network boundary, the model backend, and the data plane end-to-end. That is the cleanest path to demonstrating data minimisation and purpose limitation, and it means the AI system whose risk you are assessing is one you can actually inspect — the agent definitions, the permission boundaries and the audit ledger are all in front of you rather than described to you by a vendor.
It also means you are unambiguously the deployer. There is no hosted operator standing between you and the system, so the classification decision, the oversight arrangements and the post-market monitoring are yours to design. That is more work than adopting a vendor's compliance package, and it is also the reason the evidence is yours to produce rather than yours to request.
The one obligation that does not sit wholly with you is the general-purpose AI model itself. If you route an agent to a hosted model API, the provider of that model carries the GPAI provider obligations under Chapter V, and prompt content leaves your network to reach it. If you route to a local Ollama or vLLM backend, inference stays inside your boundary and the upstream provider relationship falls away — but you take on more of the model-level documentation burden yourself. Both are supported; the trade is deliberate.
What you are responsible for
- Classifying your use case (prohibited / high-risk / limited-risk / minimal) under Annex III, and re-checking that classification when you add agents or connect new systems.
- Assessing whether your configuration is substantial enough to make you a provider as well as a deployer of the assembled system.
- Conducting your own Data Protection Impact Assessment, and a fundamental rights impact assessment under Art. 27 where that applies to you.
- Maintaining your records of processing under GDPR Article 30.
- Choosing the model backend and understanding what that choice means — which upstream provider carries GPAI obligations, and whether prompt content leaves your network.
- Configuring agent permission boundaries, approval gates, and audit log retention to match your obligations.
- Engaging counsel for legal interpretation. This page documents the technical surface; you make the legal call.
Frequently asked questions
Is OperativeOps EU AI Act compliant?
Compliance under the AI Act attaches to a system in a use context, not to a software package on its own. OperativeOps is designed to be deployed in compliance with it: AI disclosure in the interface, role-scoped agents, per-action approval gates, and an append-only audit ledger. Your DPO and counsel make the final determination for your deployment.
When does the EU AI Act take effect?
Phased: prohibited-practice rules entered into force 2 February 2025; general-purpose AI provider obligations 2 August 2025; the bulk of rules including high-risk system requirements and Commission enforcement powers 2 August 2026.
Does OperativeOps qualify as a high-risk system?
Not by default. OperativeOps is general-purpose business tooling. Whether your specific deployment is high-risk depends on Annex III categorisation and the use case you build on top — for example, using it in employment screening or in critical infrastructure typically triggers high-risk obligations on the deployer.
Who is the provider and who is the deployer?
You run the software yourself, so you are the deployer of the AI system. Depending on how substantially you configure the agents, the retrieval sources and the actions they may take, you may also take on provider obligations for the system you have assembled. The provider obligations for the underlying general-purpose model sit with whoever supplies that model — which is a choice you make at configuration time.
Can OperativeOps be deployed entirely within the EU?
Yes, and further than that: it can be deployed entirely inside a single network with no external dependency at all. Docker Compose, on-premises Kubernetes and air-gapped installations are all supported, and with a local model backend there is no outbound inference call to place anywhere.
What documentation comes with a release?
Release artefacts and their accompanying notes. We do not claim to publish a conformity assessment, a CE marking, or a third-party evaluation on your behalf — those attach to a system in a use context, and the deployment is yours. What the software gives you instead is first-hand evidence: the agent and permission configuration you set, the model routing you chose, and an append-only ledger of what the system actually did.
Will OperativeOps be CE-marked or third-party certified?
Conformity assessment depends on the risk classification of a deployed system, which is a property of your deployment rather than of the software. There is no third-party certification to point to. Where a conformity assessment is required of you, the controls and records described above are what you would draw on to perform it.