Main site

Support AI agent · Rights requests

Data-Subject Request Intake AI Agent

Recognise the rights request buried in an ordinary support ticket, stamp the hour it arrived rather than the hour it was noticed, and route it to the named privacy owner who answers it.

Typical delivery
4–6 weeks
Deployment
Your stack
Privacy owner
Receipt clock
After launch
Agent Care

What this agent does

Recognises the request, never answers it

In

  1. 01

    A request arrives inside a thread about something else, and it is read as a request and not as a line.

  2. 02

    A clock starts at the hour of receipt, and the days spent reaching the privacy team buy nothing.

Reason

  1. 03

    A request uses a channel the controller published, and EDPB Guidelines 01/2022 count it as effective.

  2. 04

    A request sent to a random or incorrect address carries no duty where a proper channel was provided.

  3. 05

    A request comes in off a designated method, and 11 CCR 7020(e) leaves two answers and no silence.

Decide

  1. 06

    A clock is extended, and Article 12(3) puts the notice and its reasons inside the first month.

  2. 07

    A request is logged with the manner it was made in, and 11 CCR 7101 keeps that for twenty-four months.

Out

  1. 08

    A request is recognised, and the ticket owner is told what was found, never what to do about it.

  2. 09

    Execute write actions only inside the approval boundaries agreed during implementation.

Product statement

Recognition, the hour of receipt and the clock belong to the agent. Validity, identity, disclosure, refusal and the answer belong to a named privacy owner.

Example workflow

One ticket, arrival to routing

  1. 1Support message receivedEmail, chat, web form, a social channel or a reply inside an open ticket
  2. 2Hour of receipt stampedThe channel it came in on, the hour it arrived and the thread it was sitting inside
  3. 3Rights request recognisedThe right invoked, the regime that applies, the clock and confidence
  4. 4Controls appliedChannel-duty checks, regime checks, extension-notice checks and confidence threshold

No human action required

Stages 1 to 4 run unaided, and none of them answers a request — the agent is recognising, and the privacy owner lane opens at the confidence gate.

5DecisionBranches at the confidence threshold
High confidence

Goes to the named privacy owner.

Low confidence

Adds a second reader first.

Privacy owner review

The request is held with the hour it arrived, the regime read on it and the clock it started.

Take ownership · Reclassify · Send to counsel review

Taken — by the named privacy owner

  1. 6Request register updatedOnly where write access and records policy allow it
  2. 7Outcome evaluatedRecognition accuracy, clock accuracy, extension notices and what review found

Corrections

Each privacy-owner correction is counted in the evaluation.

What should not run autonomously

Human approval stays in control

Outside the boundary — human approval required

8 items

  • Deciding that a request is valid.
    • Verifying who the requester is.
    • Deciding what is disclosed or erased.
    • Refusing a request, on any ground.

  • Automation boundary

    Agent acts unaided

    • ✓Read each inbound support message against the recognition rules in use.
    • ✓Stamp the hour of receipt and the channel that carried the request.
    • ✓Tell the ticket owner what the agent thinks it found.
    • ✓Track each clock against the regime that applies to it.

    Nothing is answered, refused or verified here; a named privacy owner does all of it.

    • Answering a rights request, in any form.
    • Taking the extension and writing its reasons.
    • Ruling a channel outside the duty.
  • Changes to recognition rules or clock settings.

Example output

One rights request, annotated

This serves a support team who may have to show when a clock started — one month under the GDPR, forty-five days under 1798.130(a)(2)(A); below is one request as the agent leaves it.

Recognition output · single ticket

Illustrative example
Ticket
Refund thread
Line recognised
and while you are at it, delete my account and everything you hold on me
Hour of receipt
14:20, 3 August 2026
Channel of record
Published support inbox
Confidence
Above threshold
Right invoked
Erasure, on the agent reading

As received

Taken from the ticket as it arrived — nothing on this side is written by the agent.

Signals used

  • Ticket text
  • Channel of record
  • Arrival timestamp

Why this flag

The clock ran from the hour it arrived, and a named person decides.

What the score decides

Below the configured threshold the flag picks up a second read before the owner sees it.

Action

Take ownershipReclassifySend to counsel review

Value

Where AI adds value

The same four claims, placed at the point in the workflow where each one applies.

Where the value lands

Value 01 – 04

Every inbound message

From the ticket as it arrived

03Recognition

Recognise, then hand over

The vehicle data-privacy consent agent captures consent in a car and the ticket-deflection agent answers the ticket; this one recognises what the ticket actually is, and when it arrived.

01Approved path

The clock started at the ticket

One month, or forty-five days in California — each extendable once, with notice inside the first period.

02Human review

What was checked, and not found

Checked across the regimes surveyed: no action anywhere names arrival through a published support channel rather than a portal as the failure mode. The closest located is an Estonian reprimand of 12 May 2025, where requests to a general address were inadvertently rejected by the privacy team through human error. Under the GDPR there is no request-log duty at all, only the accountability articles; the one record duty found is Californian, at 11 CCR 7101, and it contemplates a ticket.

04

Build an evidence trail

The request, the hour it arrived and the person who answered it stay together.

Integrations

Typical integrations

Five system groups connect to the same agent. Which of them are in scope is decided in discovery.

  • Ticketing and support desks

    • Zendesk
    • Freshdesk
    • Front
    • Salesforce Service Cloud
    • Gladly

  • Shared inboxes

    • Microsoft 365
    • Google Workspace
    • Support and legal aliases

  • Privacy and rights tooling

    • OneTrust
    • TrustArc
    • Transcend
    • Rights-request case and log records

Agent

Rights-request recognition and intake

  • Reads the ticket
  • Recognises the request
  • Holds for the privacy owner

  • Chat, social and voice

    • Live chat
    • WhatsApp
    • Messenger
    • Social inboxes and call summaries

  • Observability & evaluation

    • OpenTelemetry
    • Langfuse
    • Supported monitoring/evaluation sources

Integration availability depends on the client's existing systems and API access.

Agent controls

Six layers between the ticket and the answer

Six postmarks on one envelope, the last the latest. What still counts is drawn in the map below.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modeNarrow the agent to flagging only when evaluation or production signals degrade.Roll back
L5Version monitoringTrack model, prompt, recognition and regime-configuration changes.Track
L4TraceabilityRecord the message, the hour of receipt, the channel, the flag and the owner read.Record
L3Privacy owner reviewHold the flag for the named privacy owner; the hold governs routing, not whether the request is valid.Gate
L2Policy guardrailsTest each flag against the configured channel and regime rules; a failure returns the flag.Restrict
L1Confidence thresholdsRoute low-confidence flags to a second reader before the privacy owner sees them.Require review
Model coreRequest flagged — the right invoked, the hour of receipt, the channel and confidence
L1 – L2
Test whether a flag may stand
L3
Puts the routing in the hands of a privacy owner
L4 – L5
Keep the request and the hour behind it
L6
Flags the ticket and stops when signals degrade

How Nestack evaluates it

Evaluate the whole intake — not only the request that got recognised.

Coverage runs the whole depth of the workflow, and every layer is cut by slice.

Surface — the request a regulator would look for

  1. E1Final-output evaluationWas the request recognised, with the hour it arrived attached?
  2. E2Step-level evaluationDid the agent read the right thread, the right channel and the live regime rules?
  3. E3Tool evaluationDid it read the correct ticket and write the correct request record?
  4. E4Confidence calibrationDo low-confidence flags actually attract more privacy-owner corrections?
  5. E5Slice evaluationHow does recognition change across specific inbound channels?
  6. E6Business outcomeHow many requests were recognised late, and how many only on audit?

Floor — the deadline the controller answers for

Failure modes

Where each failure originates in the agent

Seven failure modes, each placed where the intake first goes wrong.

Agent lifecycle

Direction of processing →

  1. 01 · Retrieval

    1 mode

    • OX-03

      Channel of receipt missing

      The manner the request arrived in is not captured.

    Stage gathers

    The message, the channel, the hour and the thread

  2. 02 · Reasoning

    2 modes

    • OX-04

      Answered about something else

      The refund is settled and the ticket is closed.

    • OX-06

      Clock run on the wrong regime

      A Californian deadline is kept to a European one.

    Stage proposes

    The right invoked, the regime and the clock

  3. 03 · Tool / write

    2 modes

    • OX-02

      Extension taken, no notice sent

      The first month passes with nothing sent out.

    • OX-05

      Second request in the thread missed

      One flag stands, so the later ask is skipped.

    Stage writes

    Only where write access and approval policy allow it

  4. 04 · Output

    1 mode

    • OX-01

      Recognised late, clock backdated

      The hour recorded is not the hour it arrived.

    Stage returns

    The flag the owner reads and the clock it starts

  5. 05 · Change / Version

    1 mode

    • OX-07

      Silent recognition drift

      A rule change narrows what counts as a request.

    Stage tracks

    Model, prompt, channel rules and regime dates

  • Sev-1 · a request answered and closed
  • Sev-2 · a clock started at the wrong hour
  • Sev-3 · signals degrade, flag held back
See the complete Customer Support failure-mode catalogue

Affected slices

Erasure asks hide inside other threads

A right-level recognition figure can read clean while erasure asked for mid-thread carries most of the misses. Nestack reports the miss rate by right invoked, not only in total.

Slice performance — reported separately, not only in aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Erasure asked mid-thread12.9%3.7×Review
Access worded as a complaint9.2%2.6×Review
Requests arriving by voice5.8%1.7×Watch
Requests on the privacy form2.8%0.8×Normal

Bar: miss-rate lift vs. privacy-form baseline · scale 0–4.0× · tick marks the 2.0× review threshold

2 of 4 slices over threshold

Evidence-linked improvement

What an unrecognised sentence costs

A cycle ends when the request that sat unrecognised is a standing case. That suite is what the next ticket routed is measured against.

Improvement cycle · five stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Recognition misses rise on one inbound channel.

  2. 02

    Diagnose

    The sentence in the middle of a support thread asking for everything you hold, answered about the refund and closed, is worked backwards until one cause is left standing.

  3. 03

    Improve

    The change ships numbered, and the rights requests that forced it ride with it.

  4. 04

    Verify

    One rights-request case still failing is enough to hold the release back.

  5. 05

    Learn

    It is kept for good, and the recognition rules are amended in the same commit.

  6. Learn → Detect

    The return edge. The next ticket is read against a suite one case longer.

Typical build scope

Twelve workstreams across six weeks

The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, channels, recognition workflow, evaluation, integration, then production validation and handover.

Workstream

Week 1Week 2Week 3Week 4Week 5Week 6

  1. 01Rights-request discovery and automation-boundary work.Week 1
  2. 02Ticketing, inbox and chat source assessment.Week 1, Week 2
  3. 03Recognition-to-clock and multi-regime clock mapping.Week 1, Week 2
  4. 04Support-message ingestion.Week 2
  5. 05Recognition logic and channel-duty binding.Week 2, Week 3
  6. 06Confidence scoring and owner routing.Week 3
  7. 07Privacy owner review workflow.Week 3, Week 4
  8. 08Ticketing-and-inbox integration.Week 5
  9. 09Recognition and clock cases.Week 4, Week 5
  10. 10Guardrails and routing controls.Week 4
  11. 11Request-trail instrumentation.Week 5, Week 6
  12. 12Deployment, documentation and Agent Care handover.Week 6

12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel

Final scope and sequence confirmed in discovery

Engagement tiers

What each tier includes

Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.

Capability✓ in scope · — not at this tierPilotOne queue, one regimeProductionProduction support systemsAdvancedMultiple queues / regimes
Introduced at Pilot
Recognition to your channel rules✓✓✓
Privacy owner routing✓✓✓
Inbound-channel baseline✓✓✓
Introduced at Production
Reporting by right invoked—✓✓
Privacy review workflow in your systems—✓✓
Approved write-back—✓✓
Ticketing-and-inbox integration—✓✓
Introduced at Advanced
Multi-jurisdiction rule sets——✓
Multi-stage privacy approvals——✓
High ticket volume——✓
Multi-regime clock controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build price
Confirmed after discovery based on integrations, workflow complexity, ticket volume, approval controls and deployment requirements.
Separate from build
Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.

What we need from you

What you bring, and what we build with it

Each input maps to a piece of build scope and a week in the delivery timeline.

  1. 01Your inbound channels and the queues they land in

    Channel mapping and hour-of-receipt capture

    Week 1

  2. 02Representative tickets from each channel

    Message ingestion, recognition logic and the intake baseline

    Week 2

  3. 03The regimes you answer under and who owns each

    Channel-duty mapping, regime binding and the automation boundary

    Week 1

  4. 04Access to relevant APIs, feeds or exports

    Ticketing, inbox and chat assessment, then integration setup

    Week 2

  5. 05Tickets you would not want re-read

    Recognition cases and failure-mode testing

    Week 4

  6. 06What no ticket may postpone

    Confidence scoring, owner routing, guardrails and release controls

    Week 3

  7. 07A named privacy owner who takes the request

    Privacy owner routing, then pilot and production validation

    Weeks 5–6

Nothing else is required

Deployment, documentation and Agent Care handover are ours.

Delivery timeline

Four phases across six weeks

Every band below is measured; the fifth carries two phases because those two genuinely coincide.

Phase

W1

W2

W3

W4

W5

W6

  1. DiscoveryW1
  2. BuildW2 – W3
  3. EvaluateW4 – W5
  4. Pilot & LaunchW5 – W6

Week focus

W1Channel discovery, regime binding and the automation boundary

W2Ticketing and inbox integration and the intake baseline

W3Recognition workflow, clock logic and routing controls

W4Evaluation suite, recognition cases and failure-mode testing

W5Ticketing integration, pilot tickets and targeted corrections

W6One request cycle run under the privacy owner, then Agent Care handover

Reading the band
Each bar covers only the weeks its own work is named for, and week five is shared by design.
At the end of W6
When the request record validates, Agent Care takes the agent on.
Duration
Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.

Next step · Customer Support AI agent

Build a rights-request intake agent around the queue those requests actually arrive in.

Show us one week of closed tickets and the channel each arrived on. The clock started at the hour a request was received, not at the hour somebody in privacy read it. A request that reached a channel you published is a request you were given.

Typical delivery
4–6 weeks
Deployment
Your support queues
Privacy owner
Receipt clock
After launch
Agent Care available

Nestack Agents · Rights-request intake

AGT-SUP-01 · Agent Care available after launch

Build a rights-request intake agent

Four questions so the call starts from your actual setup — then pick a time that suits you.

About you
Your queues

No obligation. We’ll map the workflow, name the automation boundary and tell you if an agent is the wrong answer.