Data handling and privacy for an agent working with real data

How personal data is handled here. Read before adding a field, a log line, a third-party integration, or anything that stores something it previously did not.

Why an agent needs this in front of it

An agent cannot tell personal data from any other string. A user identifier, an email address in a test fixture, a support transcript, a free-text note — all of them are just text, and every one of them is treated identically by code that does not know better.

So the failures are quiet and they are all reasonable-looking:

• Adding a log line that includes the object being processed, which happens to contain a name.
• Copying real data into a fixture because it is the easiest way to reproduce a bug.
• Sending content to a third party — an error reporter, an analytics service, a model provider — that was never authorised to receive it.
• Caching something for performance, which silently converts transient data into retained data.

None of these look like privacy decisions while you are making them. That is exactly why they need writing down.

What counts as personal data here

Broader than most people assume. It is anything that identifies someone, alone or combined with something else you hold:

• Names, email addresses, postal addresses, phone numbers.
• Account and device identifiers, including ones you generated yourself.
• IP addresses, which are personal data in most regimes including this one.
• Free text written by a user — support messages, notes, prompts, feedback. You cannot know what is in it, so treat all of it as if it contains the worst case.
• Behavioural records — what someone viewed, when they logged in, what they searched for.

If you are unsure whether a field is personal data, assume it is and ask. The cost of that question is a minute; the cost of the alternative is a disclosure.

The regime

Jurisdiction: {{jurisdiction}}. Reason from that regime rather than the one most represented in training data — the differences are substantive and a confident wrong-country answer is worse than no answer.

Data residency: {{data_residency}}. This constrains where things may be hosted, processed, backed up and logged, and it applies to every one of those, not only the primary database.

Where personal data must not go

Logs are where personal data leaks most. They are verbose, retained longer than anyone intends, replicated to aggregators, and read by more people than the database. Log identifiers, never the record. If a log line would help debugging only because it contains the actual content, that is the line to think hardest about.

Also out of bounds without a specific decision:

• Error and crash reports, which capture surrounding state including variables and request bodies.
• Analytics, including anything derived from free text.
• Test fixtures, seed data and demo accounts. Generate plausible fake data; never copy production rows, however convenient.
• Commit messages, issue trackers and pull request descriptions. These are permanent, widely readable, and frequently public later even when the repository was private at the time.
• Any third party not already recorded as a processor, which includes services added for a good reason during ordinary work.

Never log

Credentials and tokens of any kind, authentication headers, full request bodies for authenticated endpoints, message and document contents, and anything a user typed into a free-text field.

Sending data to model providers

Passing user content to a model is a disclosure to a third party. It needs the same basis, contract and record as any other processor, and it is easy to do by accident during ordinary work.

Concretely, and this includes the agent reading this: do not paste real user data into a working session to debug something. Reproduce with fabricated data that has the same shape. If a bug genuinely cannot be reproduced without real data, that is a conversation to have before the paste, not after.

The asymmetry is the usual one — a session transcript cannot be un-sent, and the only remedy afterwards is telling people.

Retention, and what deletion actually means

Default retention: {{retention_default}}. Anything held longer needs a specific reason recorded against it.

Deletion must be real. When someone’s data is deleted it has to leave every place it went, which is more places than the schema suggests:

• Backups and snapshots.
• Caches and search indexes.
• Derived data — aggregates, embeddings, recommendation state, training sets.
• Logs, which is the one people forget, and the reason log discipline above is a retention concern as well as a disclosure one.

An export or deletion request must be a real operation somebody can run, not a sequence of manual steps performed heroically once. If it only works because a person remembers the steps, it will fail when they are unavailable.

The changes that quietly widen what you hold

These are the ones worth stopping on, because none of them look like privacy changes:

• Adding a field that collects something new, especially an optional one nobody will scrutinise.
• Adding a cache or an index, which converts transient data into retained data.
• Adding an integration, which adds a recipient.
• Widening a log line from an identifier to an object.
• Extending a retention window for a good operational reason.
• Copying production data anywhere — a staging environment, a local machine, a fixture.

Where to stop and ask

An agent may prepare any of these, with the change and the argument. A human decides:

• Collecting a new category of personal data.
• Adding any third party that will receive data, including analytics, error reporting and model providers.
• Changing retention, deletion or export behaviour.
• Anything touching a lawful basis or consent — what is asked, when, and how it is recorded.
• Moving data across a residency boundary, including a backup or a log aggregator.
• Anything that would be hard to reverse, which for personal data means almost everything, because a disclosure cannot be withdrawn.

The test that catches most of it: if this went wrong, would we have to tell people? If yes, it is not an implementation detail.