How we work
AI agents and your data
An agent sees what its permissions allow, and those should be set as narrowly as the process permits. Everything we operate runs on infrastructure in the European Union. What matters more than any reassurance is what gets written down before the build: which data, which systems, how long, and who can read it.
By Gorden WübbeAutomation, agents and search visibilityUpdated 10 August 2026Narrow permissions are the whole of it
Most of what is sold as AI security is atmosphere. The part that actually decides your exposure is unglamorous: what the agent is allowed to read and write.
An agent that books appointments needs the calendar and the customer’s name. It does not need the full CRM, the finance folder or the shared drive. Giving broader access because it is simpler to set up is the most common avoidable mistake in this work, and it is invisible until it is not.
Practically: a dedicated account per agent, scoped tokens, and access limited to the systems the process touches. If a supplier asks for an administrator login because it is easier, that answer tells you how the rest of the project will go.
Permissions have to follow the person
For anything internal, the agent must answer according to the permissions of whoever is asking, not its own. An agent that can read a folder the asker cannot has become a way around your access controls, without anyone deciding to build one. This is straightforward at the start and awkward to retrofit.
Where the processing happens
Everything we operate runs on infrastructure in the European Union. Where a model provider is involved there are three concrete questions, each with a factual answer:
- Which region does the model run in?
- Are inputs retained, and if so for how long?
- Is training on your inputs contractually excluded?
On the third: under a business agreement with the major providers, training on customer inputs is excluded. That is a property of the agreement, not of the technology — which is exactly why it belongs in the contract you read rather than in a sentence on a website. Including this one.
What to write down before anything is built
This is the part that separates a project you can defend from one you cannot. Four things, agreed in week one:
| Question | Why it matters later |
|---|---|
| Which data does the agent touch, and which does it explicitly not? | The answer to every future question about scope |
| What is stored, and for how long? | Retention cannot be reconstructed retroactively |
| Who can read transcripts? | Usually the question a works council or a customer asks first |
| What happens on a deletion request? | Decides where the agent is allowed to write in the first place |
Recording calls is a legal question first
Transcripts make several use cases considerably stronger, particularly CRM upkeep. In the EU, recording a call requires consent from both parties, and many other jurisdictions have comparable rules.
Settle it before building. Where recording is not appropriate the agent works from written material instead and delivers less — which is a design constraint, not a blocker, and a much cheaper one to accept at the start than at launch.
People have rights over what the agent writes
Under GDPR, individuals can ask what you hold about them, have it corrected, and have it deleted. Anything the agent wrote is covered by that, exactly as if a colleague had typed it.
The practical consequence shapes the architecture: the agent writes into systems where those requests can already be served — your CRM, your ticket system — rather than into a separate store that nobody thinks to search when a request arrives. An agent with its own private database is a compliance problem waiting for its first letter.
Five questions for any supplier
- Which systems will the agent write to, and with what permissions?
- Where is the processing done, and under which agreement?
- What is stored, for how long, and who can read it?
- What happens when someone asks for their data to be deleted?
- What does the agent do when it is not sure — and who finds out?
Concrete answers to all five is a reasonable minimum. Reassurance in place of an answer to any of them is the useful signal.
The questions worth asking
- Where is our data processed?
- On infrastructure in the European Union for everything we operate. Where a model provider is involved, which region it runs in and whether inputs may be retained are questions with concrete answers, and they belong in the contract rather than in a reassurance.
- Will our data be used to train models?
- Not under a business agreement with the major providers, where training on customer inputs is contractually excluded. That exclusion is a property of the agreement, not of the technology — which is why it is worth reading rather than assuming.
- What does the agent actually see?
- Only what its permissions allow, and those are set per system and as narrowly as the process permits. An agent that books appointments needs the calendar and the customer name. It does not need the whole CRM, and giving it broader access because it is simpler is the most common avoidable mistake.
- What happens to conversation transcripts?
- That is a decision you make, and it should be written down before launch: what is stored, for how long, who can read it, and when it is deleted. Recording calls additionally requires consent from both parties in the EU. Settle it at the start — retrofitting a retention policy is far more work.
- What if the agent gets something wrong about a person?
- Under GDPR, people have rights to access, correction and erasure, and those apply to whatever the agent wrote. In practice that means the agent has to write into systems where those requests can already be served, rather than into a separate store nobody can search.
Read next
Want this in writing before deciding?
The data scope is part of the assessment, not an afterthought. Thirty minutes is enough to establish what an agent would and would not touch.
Book a scoping call