Privacy

Last updated: 13 October 2026

Agent Control Room is a policy decision point for organisations that run software agents. It receives a proposed action, a hash of the payload and supplied context facts, evaluates the organisation's rules, and returns a decision. It never receives the payload itself. Most of the data processed in the service belongs to the customer organisation using it, not to the individual reading this notice. This notice separates the two: what we decide ourselves as a controller, and what we handle strictly on a customer's instructions as a processor.

The providers we rely on are named on our sub-processors page, and the controls around them on our security page.

This page is an information notice, not legal advice. Where it differs from a signed customer agreement or data processing agreement, those documents govern.

Who we are

Agent Control Room is operated by Complyee AB, a company registered in Sweden with organisation number 559161-6452, at Kvarndammsringen 11, 134 39 Gustavsberg, Sweden.

For anything in this notice, including access, deletion and other data subject requests, write to privacy@complyee.ai.

We have not appointed a data protection officer, and as an EU-established company we do not require an EU representative. Requests are handled directly at the address above.

The two roles we play

We are the controller for the marketing site, the workspace request form, sign-in, account and role records, billing, and our correspondence with you. We decide why and how that data is processed.

We are a processor for everything inside a customer workspace: the action vocabulary the customer declares, the policy rules and context contracts the customer writes, the agent registry, the context facts supplied with each decision request, the decisions recorded, the approval records and the audit trail. The customer organisation is the controller for that data, and we act only on its instructions.

If you work for an organisation that uses Agent Control Room to govern its agents, your organisation decides which actions are governed, which context facts are sent with each request, who may approve, and how long records are kept. Start with your own organisation for requests about that content.

Data we handle as controller

  • Site visits — request metadata such as IP address, user agent and page requested, used to serve the site and protect it against abuse. Legal basis: legitimate interest.
  • Workspace requests — the name, work email, company, requested subdomain, allowed email domains and any message you send us through the request form, used to respond and to set up a workspace. Legal basis: steps taken at your request prior to a contract.
  • Sign-in — your work email address and a short-lived one-time code, or the identity your organisation's single sign-on returns. Legal basis: performance of the contract with the customer organisation.
  • Account records — workspace membership, role, workspace settings and administrative actions, used to operate the service. Legal basis: performance of the contract.
  • Support, feedback and sales correspondence — what you write to us and our replies. Legal basis: legitimate interest in running and improving the service.
  • Billing — for paid plans, billing name, email address, country and order metadata. Card details are entered in our payment provider's own checkout and never reach us. Legal basis: performance of the contract and legal obligations such as accounting.

Data we handle as processor

Inside a workspace we process the action vocabulary the customer declares, the policy rules and per-action context contracts the customer writes, the agent registry (agent keys, display names and the email of the person recorded as responsible for an agent, used to enforce separation of duties), the context facts supplied with each decision request, the decisions recorded, approval records and who acted on them, and the audit trail of who did what and when.

We process this only to deliver the service to the customer and on that customer's documented instructions. We do not sell it, do not use it for advertising, and do not use it to train models. Access by our staff is limited to what is needed for support and incident handling, and is logged.

What a decision request contains — and what it does not

Each decision request identifies the agent and the action, carries a cryptographic hash of the payload the agent intends to act on, and includes context facts supplied by the customer — discrete typed values such as an amount, a region, a document class or a count, optionally with who asserted them and when. An enforced contract validates declared facts, but extra context fields are accepted and may be recorded.

The payload itself — the document, the record, the message — never leaves the caller's own systems. Agent Control Room cannot read it, does not store it, and could not reconstruct it from the hash. Grants are bound to that same hash, so a decision applies to exactly the payload that was evaluated and nothing else.

How much personal data appears in context facts is the customer's design choice, made when the customer declares each action's context contract. We recommend keeping facts minimal and avoiding direct identifiers where a category or count will do.

Deterministic decisions, not generated content

Agent Control Room evaluates requests against the customer's declared rules deterministically and does not generate policy outcomes with a model. No customer data is used by Agent Control Room to train foundation models.

A customer may optionally pair the supported Complyee Policy Library integration for selected actions. In advisory mode its assessment is recorded after the Agent Control Room decision and cannot change it. In gate mode it can preserve a local allow only when it supports the step, or tighten that allow to a human hold or refusal; it cannot create permission, loosen a refusal or replace a human approval required by an Agent Control Room rule.

For customers who must register or describe their AI systems — for example under EU AI Act Article 26 deployer duties or a NIST AI RMF GOVERN review — the decision evidence records provide a verifiable trail of what was proposed, which rules applied, what was decided, by whom and when. The records state facts about configuration and events; they are not an assessment of the customer's compliance.

Optional Complyee Policy Library review

Complyee Policy Library pairing is off unless a workspace administrator configures its gateway and API key and enables consultation for an action. It is a specific integration between Agent Control Room and the Complyee Policy Library, not a general facility for sending data to arbitrary policy-library endpoints.

For each consultation, Agent Control Room sends the Complyee Policy Library the action key, a bounded plain-language action description, the agent key, a caller reference and up to 40 context facts supplied with the request. Extra context fields may be included. The payload hash and the underlying document, prompt, message or other payload are not sent. Customers should therefore minimise all context values and avoid personal data unless it is necessary for both the Agent Control Room decision and the configured Policy Library review.

Agent Control Room receives and stores the Complyee Policy Library's structured assessment, reasons, citations, timing and consultation status with the decision evidence. A matching recent reading may be reused for the same step rather than calling the Policy Library again. If a human approval is open, that recorded reading is reused so the eventual grant reflects what the approver saw rather than a later reassessment.

The customer enables and configures this transfer on its own instructions and must have an appropriate agreement with Complyee AB. The Complyee service acts as the customer's provider, not as our sub-processor; its own privacy and retention terms govern its processing after the data reaches it.

Where data is stored

Operational control-plane data — member accounts and roles, workspace settings, hashed API keys, network allow-lists, the agent registry, active approval records, rate-limit counters and a lightweight decision index — lives in the application database, hosted in the EU.

Each workspace also has its own dedicated evidence bucket on Google Cloud Storage, in a dedicated EU or US region fixed for the lifetime of the workspace. It holds the active rule set, context contracts, the full JSON record of every decision, and the workspace audit log.

A workspace can instead place its evidence bucket in the customer's own cloud storage (Google Cloud Storage today). In that case the customer's cloud is its own provider rather than our sub-processor, the full evidence records never rest on our storage, and we hold only a scoped credential the customer issues and can revoke.

Grants are short-lived and single-use: a direct allow grant expires within minutes, and a grant from a human approval must be claimed within a bounded window, after which the request must be made again.

Sub-processors

We use a small number of third parties to run the service — hosting, database and authentication, evidence-bucket storage, network protection, email delivery and payments. Each is named, with what it does and where it runs, on our sub-processors page, which is the authoritative list.

The optional Complyee Policy Library integration is configured by the customer under its own arrangement with Complyee AB and is therefore described separately rather than listed as our sub-processor.

International transfers

Each workspace's evidence bucket is provisioned in a dedicated EU or US region and stays there for the lifetime of the workspace; for a bucket in the customer's own cloud, the customer chooses and controls that region. The application database that holds accounts, membership and roles, workspace settings, hashed API keys, approval state and the limited decision index is EU-hosted.

Some supporting services — edge network protection, email delivery and payments — operate globally, and a workspace whose evidence bucket is provisioned outside the EEA keeps its policy rules, decision evidence and audit trail there. Where a provider processes personal data outside the EEA, transfers rely on the European Commission's standard contractual clauses together with the provider's own safeguards. For a workspace with a US evidence bucket, decision evidence and audit trail stay in the US; the standard contractual clauses govern the supporting services and any EU-hosted operational data.

How long we keep data

  • Policy rules, context contracts and the action vocabulary: the active versions until the customer replaces them; superseded versions are kept so that recorded decisions remain explainable against the rules that produced them.
  • Decision evidence and the workspace audit trail: written to the workspace's evidence bucket and kept for the lifetime of the workspace unless a shorter lifecycle is configured on that bucket. For workspaces hosted in our cloud, we apply the lifecycle rules agreed with the customer and can change them on request to privacy@complyee.ai; there is no self-service control in the product. Where the workspace runs in the customer's own cloud, the customer's cloud administrator sets the lifecycle. The evidence is deleted with the bucket when the workspace is deleted.
  • Approval records, rate-limit counters and the operational decision index: kept in the application database for the life of the workspace and deleted with it.
  • Residual copies in storage: workspace storage keeps non-current object versions for up to 90 days and soft-deleted objects for up to 7 days, after which they expire automatically. They are never restored to recover deleted customer data.
  • Residual copies in backups: application database records are removed from the live database immediately, and any residual copies persist only in the automated daily backups taken by our managed platform provider, expiring with that normal backup cycle. Residual copies are used only for disaster recovery of the service as a whole, never to restore deleted customer data. Our security page describes the backup and recovery arrangement in more detail.
  • Account and membership records: for the life of the customer agreement, then deleted. Sign-in accounts that exist only for that workspace are deleted with it.
  • Sign-in codes: valid for a few minutes and discarded after use.
  • Billing and accounting records: kept for the period Swedish law requires.
  • Workspace requests we do not proceed with: deleted once the conversation is closed.

Deletion when a workspace closes

Deleting a workspace removes its rule sets, context contracts and action vocabulary, the evidence bucket and everything in it including every recorded decision and the audit trail, the sign-in accounts that exist only for that workspace, and every database record belonging to the workspace — members, roles, settings, API keys, the agent registry, approval state and the operational decision index.

A workspace administrator can request deletion from workspace settings or by writing to privacy@complyee.ai. We complete a deletion request within 30 days of receiving it. After that, the only data we retain is what law requires: billing and accounting records for the period Swedish accounting law prescribes.

When a workspace administrator removes a member, we replace that person's name and email in the records they left behind — approval actions and feedback — with an anonymous placeholder, and delete their sign-in account unless they belong to another workspace. Audit events already written to your workspace's evidence bucket keep the identifier of the person who performed the action until the whole audit trail is deleted — with the workspace, or under the retention period your administrator has set on the bucket. That is a record of actions taken in the workspace, kept for security and traceability. If a data processing agreement requires those historical entries to be pseudonymised individually, contact privacy@complyee.ai and we will handle it as a documented request.

Where a workspace's evidence bucket runs in the customer's own cloud, deletion is performed with the credential the customer issued. If the credential has already been revoked, the customer's own cloud administrator completes the removal in their tenancy.

One record survives deletion by design: a deletion receipt. It is stored outside the workspace and lists what was removed — the workspace name and identifier, the resources deleted, who requested it and when. It contains no decision content and no personal data beyond the identifier of the administrator who performed the deletion, and exists so that a completed deletion stays provable after the workspace and its audit trail are gone.

Security

Each workspace has its own isolated evidence bucket and decision index. Access is controlled per workspace and role, transport is encrypted, and administrators can restrict API access to approved networks with per-key allow-lists and require single sign-on. Our security page describes the controls in more detail.

Your rights

Where we are the controller, you can ask for access to your personal data, correction of it, erasure, restriction of processing, a portable copy, or object to processing based on legitimate interest. Where consent is the basis, you can withdraw it at any time. Write to privacy@complyee.ai and we will respond within one month.

Where we act as processor for a customer workspace, requests belong to that customer as controller. If you contact us directly we will forward the request to the customer without delay and support them in answering it, rather than acting on the content ourselves.

Cookies and similar technologies

We use only what the service needs to work: a session and authentication token so you stay signed in, and a browser-stored preference that remembers the workspace you last signed into. Payment pages load our payment provider's script when you are checking out.

We do not use advertising cookies and we do not track you across other sites.

Data processing agreement

For every customer, a data processing agreement forms part of the customer agreement and governs our processing of workspace data. It sets out the subject matter, duration, nature and purpose of processing, the categories of data and data subjects, and our obligation to act only on documented instructions.

It also covers confidentiality of our personnel, the technical and organisational security measures we maintain, the use and authorisation of sub-processors, assistance with data subject requests and with data protection impact assessments, notification of personal data breaches without undue delay, audit and information rights, international transfer safeguards, and deletion or return of data on termination.

Where a notice period for new sub-processors matters to you, we are happy to agree one in the agreement. For customers under US state privacy laws, the agreement can incorporate the corresponding state privacy terms. Request the current version at privacy@complyee.ai.

Changes to this notice

This page carries the date it was last updated and is the authoritative version. When a change materially affects how we handle customer data, we tell workspace administrators as well as updating this page.

Contact and complaints

Privacy questions, data subject requests and data processing agreement requests: privacy@complyee.ai. Vulnerability reports and security questionnaires: security@complyee.ai.

Complyee AB, organisation number 559161-6452, Kvarndammsringen 11, 134 39 Gustavsberg, Sweden.

If you believe we have handled your personal data incorrectly, you can lodge a complaint with the Swedish Authority for Privacy Protection (Integritetsskyddsmyndigheten, IMY), or with the supervisory authority in your own country.

Ask us about privacy

Data subject requests, privacy questions and data processing agreement requests go to privacy@complyee.ai.