GDPR and data protection
Who is controller and who is processor, how to answer a data-subject request with the console's tools, and the retention, residency, masking and audit evidence a DPIA asks for.
- Explain the controller and processor roles in a Liyagent deployment
- Answer an access or erasure request across every store with a receipt
- Find the retention, residency and redaction controls and the evidence each leaves
Liyagent keeps people's data in more places than a ticket table: the email a ticket came from, the conversation with an agent, the agent's memory, the spend ledger, the audit log. This page is the map for answering the GDPR (and UK GDPR, India's DPDP Act and the CCPA) on a deployment of it.
Who is controller
| Deployment | Controller | Processor | Liyagent's role |
|---|---|---|---|
| Self-hosted, your own models | You | None needed from Liyagent | None: Liyagent never receives the data. The model providers, identity provider and connected systems you choose are your own processors. |
| Self-hosted, Liyagent support with access | You | Liyagent, for that access | Processor under the Data Processing Addendum |
| Hosted pilot | You | Liyagent | Processor under the Data Processing Addendum, using the sub-processors listed |
Your employees and customers are the data subjects. Your privacy notice tells them what the agents do with their data. Liyagent's own privacy policy covers only Liyagent's website, demo and sales.
Agents on Teams and the other chat channels tell people they are an AI assistant. On the HR desk, sensitive HR matters are refused by a seeded guardrail, sent to your HR team and recorded as metadata only. No agent makes a decision with legal or similarly significant effect on its own. If you configure one to, Article 22 safeguards are yours to provide.
Answer a data-subject request
The data-subject tools search, export and erase one person across every store Liyagent keeps, and name what they cannot reach on every result. The stores are tickets, pipeline runs, inbound email, attachments and their extracted text, knowledge articles, vectors, transcripts, sessions, agent-to-agent tasks, suspended runs, memory, answer records, the unanswered-question log, spans, the spend ledger, the audit log, the outbox, AI cases, policy samples and the public site's demo requests.
They need an administrator (admin.write) acting for every tenant, and a reason, which the audit row keeps with the person taken out of it.
- Search: where the person is, by email, full name, external id or UPN. Counts and ids per store, never the content, and the legal holds that would block erasing them.
curl -X POST https://ticketiq.example.com/api/privacy/search \ -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \ -d '{"email": "jane@example.com", "reason": "DSAR 2026-014"}' - Export: the access copy (Article 15) and portability copy (Article 20): every record that is theirs or names them, with content, as one JSON download.
POST /api/privacy/exportwith the same body. The export is itself audited as a disclosure. - Erase:
POST /api/privacy/erase. Their own records are deleted, mentions of them redacted to[erased], their tickets pseudonymised ("mode": "redact", the default) or deleted with everything derived from them ("mode": "delete"). Each store writes a receipt. A residual search runs from scratch and the job iscompletedonly when it finds nothing.
Legal holds outrank erasure: a hold covering any match refuses the whole job before anything is touched. With TICKETIQ_ERASURE_FOUR_EYES=true, an erasure waits for a second administrator's approval (POST /api/privacy/erasures/{id}/approve).
The erasure register (GET /api/privacy/erasures) names each person only by a keyed digest and a masked hint. Each receipt carries its own digest, the job a digest over them all, and that digest is in the hash-chained audit log, so a receipt can be shown to be the one written at the time.
What the tools do not reach
Every result lists it: sealed audit archive segments, backups, external knowledge sources, the source systems themselves, what webhooks and SIEM sinks already delivered, access records (console users, identity mappings, approvals, budgets and agent-registry entries naming a person, which you remove through access management), durable answer records, case-audit findings on tickets that were redacted rather than deleted, and the privacy requests the person sent through Liyagent's public site.
The public site's privacy requests
On the Liyagent website, people use the privacy request form. Each request is stored, its address confirmed by a signed emailed link (or by an administrator, when outbound mail is not configured), and given a due date one month out. The Privacy requests queue in the operator view (on the instance that serves the public site, for its owner) lists them with what is overdue, runs search, export and erase against the requester's address once it is confirmed, and closes each with the answer given, optionally mailed. Every step is written on the request and audited against its reference.
Retention
Each store has a window, set for the instance on PUT /api/retention and per tenant on the tenant, never below a floor (TICKETIQ_RETENTION_FLOOR_DAYS, 30 days by default) that the console can only raise. A daily purge applies them, and legal holds keep what they cover.
| Store | Default |
|---|---|
| Transcripts | 90 days (TICKETIQ_TRANSCRIPT_RETENTION_DAYS) |
| Pipeline runs | 365 days |
| Spans | 30 days (14 configured by TICKETIQ_SPAN_RETENTION_DAYS, held at the floor) |
| Answer records | 90 days |
| Tickets, attachments, memory | No age limit until you set one |
| Audit log | 365 days (TICKETIQ_AUDIT_RETENTION_DAYS), its own window and legal hold. Older rows move to sealed archive segments |
| Unanswered-question log | 90 days (TICKETIQ_KB_GAP_RETENTION_DAYS) |
| Demo requests (public site) | 730 days, with the client address blanked after 90 |
| Privacy requests (public site) | 1095 days after closing, with the client address blanked after 90 |
POST /api/retention/purge with "dry_run": true reports what a purge would delete and what holds keep.
Residency and transfers
A tenant with a residency_region (an ISO code such as DE, or EU) has every model call and embedding kept in that geography, or refused. The region is computed from what the call goes to (a Bedrock or Vertex region, or the region attested on a provider record), and unknown is refused. no_cross_geo also refuses cross-region routing inside the geography. The embedding model runs inside Liyagent, so embeddings stay wherever the instance runs.
For transfers outside the EEA or UK under a hosted pilot, the Data Processing Addendum incorporates the Standard Contractual Clauses (modules 2 and 3) and the UK Addendum.
Masking personal data
Guardrails check every model input and output. A Redact PII rule masks identifiers ([EMAIL]) or tokenises them ([EMAIL_1], stable for the whole conversation) so the model provider never sees them, and puts them back only in the answer the person reads and the tool calls made for them. See Redaction.
Transcript recording can be full, metadata only, or off, per agent.
Evidence for a DPIA or an audit
- The audit log records administrative writes and agent calls.
GET /api/audit/verifyproves the chain is intact andGET /api/audit/exportexports it. - Erasure receipts and the erasure register show each request was carried out in full.
GET /api/retentionshows the windows in force, and the last purge's report shows what it deleted and held.- Data handling lists the stores and how secrets and sensitive records are encrypted.