Compliance and data privacy for AI agents in production

Putting an AI agent in production means deciding where its data lives, what leaves to model providers, and what your monitoring can see. Here are the questions a security review will ask, and how to answer them.

The moment an AI agent touches real customer data, it stops being a model question and becomes a data question. Where does the data live, what leaves your walls, who can see it, and how long is it kept. These are the questions a security review asks, and "we use OpenAI" is not an answer to any of them. Here is the checklist, and the honest way to answer it.


Where does the data live

The first question is hosting and region. If you process personal data for EU or UK users, where your stack physically runs matters, and "somewhere in us-east" is a real finding in a review. Know the region of your agent infrastructure and of every tool in the path, including your monitoring. An EU-hosted observability layer is one less cross-border transfer to justify.

What leaves to model providers

Every model call sends content to a provider. That is the unavoidable transfer, and it is worth being precise about: which provider, in which region, under what data terms, and crucially whether they train on data submitted through their API. The major providers do not train on API submissions, but you should be able to state that, with the contract behind it, rather than assume it.

What your monitoring can see

Here is the part teams get wrong by accident: monitoring does not have to see content at all. Cost, reliability and structural quality run on metadata alone: agent name, run status, model, tokens, latency, and your own tags. No prompt, no output. Content only needs to leave your systems if you turn on the flavour of quality evaluation that reads it, and that should be an explicit, per-team switch you opt into, not a default that ships on. The right posture is: monitor everything on metadata, send content to a model only when you decide the quality signal is worth it.

Subprocessors, retention, access

The unglamorous three that every DPA cares about:

  • Subprocessors. Keep a current list of every third party that processes data on your behalf and why. When it changes, the list changes. A stale subprocessor list is a broken promise.
  • Retention. Know how long each class of data is kept, and make sure deletion actually deletes, with backup copies ageing out on a schedule rather than living forever.
  • Access. Who, on the vendor side, can see your data, and under what circumstances. "Support, when you ask, and only then" is a defensible answer. "Everyone, always" is not.

Make it answerable, not perfect

You do not need SOC 2 on day one to run an agent responsibly. You need to be able to answer the questions: where it runs, what leaves, what is seen, who can access it, how long it is kept. Most of the risk in early AI deployments is not a sophisticated breach; it is not knowing the answers, and discovering during a customer's security review that the data went somewhere nobody decided it should.


AgentPing runs entirely in the EU, monitors on metadata by default, makes content evaluation an explicit per-team switch that is off for new teams, keeps a current subprocessor list, does not train on your data, and lets you export everything on every plan. See the security page and the privacy policy, or get started free.

What data does AI agent monitoring need to see?
Less than people assume. You can monitor cost, reliability and structural quality on metadata alone: agent name, run status, model, token usage, latency and your own tags, with no prompt or output content. Content only needs to leave your systems if you switch on the kind of quality evaluation that reads it, and that should be an explicit choice, not a default.
Does running AI agents create GDPR obligations?
If the agent processes personal data, yes, the usual controller and processor obligations apply, including where data is hosted, who your subprocessors are, retention, and a data processing agreement. The practical levers are choosing an EU-hosted stack where that matters, keeping a current subprocessor list, and being able to export and delete data on request.
Does my monitoring tool train models on my data?
Ask the question directly and get it in writing. A monitoring vendor should not train on your data, and any model provider it sends content to for evaluation should not train on API submissions. AgentPing does not train on your data, sends content to a model only when you enable evaluations, and runs in the EU.