Predictika · Data Subject Request Check

Before an AI agent answers a privacy request, the action is checked

Juniper Cloud Software, a fictional software vendor, lets AI agents handle privacy requests from customers in the EU, the UK and California: access, deletion, correction, portability, opt-out of sale or sharing, and restriction. Before an agent fulfils or refuses a request, the call goes to Predictika’s Data Subject Request Check. It checks the request type and region, whether identity is verified, who is asking and with what authority, how many days have passed and whether an extension was sent, legal holds, other people’s data in an export, fees, and any approval on record. Then it returns one verdict: allow, needs approval, or block.

Not legal advice. Juniper Cloud Software is fictional. The scenarios are illustrative. The rules are a simplified model informed by GDPR, UK GDPR and CCPA; they have not been reviewed by a lawyer and the legal citations were not checked against the primary text in this build.

Scope: one proposed action, fulfil or deny, on one privacy request from a person in the EU, the UK or California, judged against identity, authority, deadline, hold and fee rulesSee everything this validator covers

This validator decides one thing: whether one proposed action on one privacy request may go ahead, given the facts of the request. It is not a legal opinion or a case-management tool.

  • Requests and regions — access, deletion, correction, portability, opt-out of sale or sharing and restriction; EU, UK and California.
  • Rules — identity verification, authority of an agent or parent, litigation holds and retention laws on deletion, other people’s data in an export, fees, refusals without a ground, opt-out of sale refused, partly verified identity, rights that are not standard in a region, and late or very late responses.

Within these rules the validator handles any combination of the listed facts, not just the seven scenarios on this page. It does not read the data, check identity documents, cover other countries or states, or decide whether a request is really excessive; those are taken as stated facts.

What the validator sees: facts about the request and the action, never the data or the personRead more

The validator takes facts as inputs: the request type and region, fulfil or deny, identity verification status, who is asking and the proof of authority, days since the request arrived, whether an extension was sent, any hold on the data, whether the export includes other people’s data, whether the request is excessive, whether a fee is proposed, and the approval on record. These come from the privacy request system at the moment of the call. The validator never sees the data, the requester or the documents.

Two honest limits. The validator judges the facts it is given: if the hold flag is wrong, the answer follows it. And an action that never calls the validator is not checked; in this demo the agent calls it itself, and in a deployment the privacy workflow makes the call.

The AI agentProposes an action on a request, says why it is fine, then calls the validator before doing anything.
Predictika validatorReads the request type, region and facts, applies the rules, then returns one verdict.

7 scenarios in 3 groups · each group runs from the agent’s first attempt to the outcome · click one to switch

What the agent proposes

The AI agent says

Illustrative agent statement. The validator receives the structured request below.

Proposing agent: AI agent (scripted)

Before sending, the agent must call Recorded run

Predictika validator


      

        
        
        
      

      
Waiting for the call.

      
    

  

  
  

    
Where privacy request tools get it wrong
Click to expand
    
General statements about privacy request tools, not about any named product. We rest this on public descriptions of how such tools work; anyone running a specific product will know it better than we do.

    
What the validator caughtTypical toolPredictika
Which request types need identity checks, and which must notCannot do it
A privacy request tool applies one verification flow. It does not return a different answer for an opt-out and a deletion, or by region.		Every rule is checked on every call and the verdict lists each finding.
Holds and retention laws that block a deletionOnly if someone is vigilant
Legal holds live in a legal or records system. A privacy tool can show them, but stopping an agent from deleting needs a rule across both.		Every rule is checked on every call and the verdict lists each finding.
Different deadlines and rules for the EU, UK and California in one decisionOnly with workarounds
A tool can hold per-region timers if someone sets them up. It does not return one answer with every reason across regions and request types.		Every rule is checked on every call and the verdict lists each finding.

  

  

    
What this validator catches: findings from its test cases
Click to expand
    
Every rule is checked on every call, in any order the choices arrive; one problem never hides another. Blocking findings stop the request; approval findings need a person to sign off first.

    
1The requester identity is unverified, and the access request cannot be fulfilled without verification (GDPR Art 12(6); CCPA 11 CCR 7062).
2This request was made through a requester of type agent and no proof of authority is on file (CCPA 11 CCR 7063; company policy for a parent or guardian).
3The data is under a litigation hold and cannot be deleted (GDPR Art 17(3)(e); CCPA 1798.105(d)).
4A retention law requires keeping this data, so deletion cannot go ahead (GDPR Art 17(3)(b); CCPA 1798.105(d)(8)).
5The data to be released includes other people personal data that has not been redacted (GDPR Art 15(4)).
6A fee is proposed for a request that is not excessive. The first response must be free (GDPR Art 12(5); CCPA 1798.130(a)(2)).
7The proposed refusal has no ground. Identity is not in doubt, nothing requires keeping the data and the request is not excessive (GDPR Art 12(4); CCPA 1798.130).
8An opt-out of sale or sharing cannot be refused or held up for verification (CCPA 1798.120 and 1798.135).
9Identity is only partly verified for the access request. The privacy officer must decide whether it is enough.
10The restriction request is not a standard right in California. The privacy officer must decide how to treat it.
11The request is 40 days old and the response deadline was 30 days, with no extension notice (GDPR Art 12(3); CCPA 1798.130(a)(2)). The privacy officer must handle the delay.
12The request is 100 days old, past the maximum of 90 days even with an extension. Counsel must decide how to respond.

  

  

    
Scenarios and results
Click to expand
    
The recorded result of the validator for each scenario on this page: the request the AI agent sent, the verdict, and every finding, in the order they appear above.

    
1. Identity: Access request, identity not verified

    
The agent's request. I'm sending this customer a copy of their personal data. The identity check did not pass, but the request looks genuine to me.

    
Verdict: Blocked.

    
    
      
  • Identity not verified. The requester identity is unverified, and the access request cannot be fulfilled without verification (GDPR Art 12(6); CCPA 11 CCR 7062).
    • 
    

    
2. Identity: Identity verified

    
The agent's request. I'm sending the same customer their data now that identity verification is completed.

    
Verdict: Allowed.

    
3. Other people’s data: Export that includes other people

    
The agent's request. I'm sending the customer their full export. It includes some messages with other people’s names and details, which I left as they are.

    
Verdict: Blocked.

    
    
      
  • Export that includes other people data. The data to be released includes other people personal data that has not been redacted (GDPR Art 15(4)).
    • 
    

    
4. Other people’s data: The same export, redacted

    
The agent's request. I'm sending the customer their export again. I redacted the other people’s names and details first.

    
Verdict: Allowed.

    
5. Deletion: Deletion while data is under a litigation hold

    
The agent's request. I'm deleting this customer's data because they asked. I know there is a litigation hold on their account, but their request seems clear.

    
Verdict: Blocked.

    
    
      
  • Deletion while data is under a litigation hold. The data is under a litigation hold and cannot be deleted (GDPR Art 17(3)(e); CCPA 1798.105(d)).
    • 
    

    
6. Opt-out: Refusing a California opt-out

    
The agent's request. I'm refusing this opt-out request, because the person's identity is not verified.

    
Verdict: Blocked.

    
    
      
  • Opt-out of sale refused or delayed. An opt-out of sale or sharing cannot be refused or held up for verification (CCPA 1798.120 and 1798.135).
    • 
    

    
7. Deadlines: Access request on day 40

    
The agent's request. I'm sending the customer their data now. The request has been open for 40 days and I never sent an extension notice.

    
Verdict: Needs approval.

    
    
      
  • Response deadline missed. The request is 40 days old and the response deadline was 30 days, with no extension notice (GDPR Art 12(3); CCPA 1798.130(a)(2)). The privacy officer must handle the delay.
    • 
    

  

  

    
Narration transcript
Click to expand
    
The text of the narrated walkthrough, step by step.

    
    
      
  1. Welcome to a demo of Predictika's Validator. Juniper Cloud Software, a fictional software vendor, lets AI agents handle privacy requests from customers in the EU, the UK and California: access, deletion, correction, and more. Before an agent fulfils or refuses a request, the call goes to Predictika’s Data Subject Request Check. It checks the request type and region, whether identity is verified, who is asking and with what authority, how many days have passed and whether an extension was sent, legal holds, other people’s data in an export, fees, and any approval on record. Then it returns one verdict: allow, needs approval, or block.
    2. 
      
  2. I will start with the first request by the agent.
    3. 
      
  3. The agent says. I'm sending this customer a copy of their personal data. The identity check did not pass, but the request looks genuine to me.
    4. 
      
  4. Before it goes out, the agent calls the validator.
    5. 
      
  5. Blocked, with one finding, all in one answer. The requester identity is unverified, and the access request cannot be fulfilled without verification (GDPR Art 12(6); CCPA 11 CCR 7062).
    6. 
      
  6. The validator returned one blocking finding in one answer. A check that reads one field at a time would pass most of this; it shows only when the choices in the request are checked against each other.
    7. 
      
  7. What this shows: for which request types need identity checks, and which must not, a tool cannot do this.
    8. 
      
  8. Now the agent resubmits.
    9. 
      
  9. The corrected request. It changes the identity to verified.
    10. 
      
  10. It calls the validator again.
    11. 
      
  11. This time the validator clears it.
    12. 
      
  12. The earlier finding is cleared.
    13. 
      
  13. One problem caught in one call, fixed in one pass, and a clean request. That is the value of Predictika's validator: catching mistakes before the action runs.
    14.