Predictika · Agent Data-Use Gate

Before an AI agent touches data, the use is checked

Northwind Health lets AI agents work with customer, care and internal data: reading records, sending them to vendors, calling outside tools. Before an agent acts, the call goes to Predictika’s Agent Data-Use Gate. It checks the data class, the purpose the data was collected for against the purpose now stated, the lawful basis on record, where the data is going, the retention period, the agent’s clearance, what the agent already did in the session, and the approval on record. Then it returns one verdict: allow, needs approval, or block.

Not legal advice. Northwind Health and every vendor on this page are fictional. The scenarios are illustrative and the policy is example company policy informed by GDPR / UK GDPR; it is not legal advice and has not been reviewed by a lawyer.

Scope: six kinds of agent action on data (read, send, store, share, train, tool call), judged against GDPR / UK GDPR-style data protection rulesSee everything this validator covers

This validator decides one thing: whether an AI agent may take one proposed action on data, given facts about that data, that agent and that destination. It is not a general “AI governance” check.

  • Actions — read, send, store, share, train and tool_call.
  • Rules — purpose limitation, lawful basis, special-category and children's data, processor agreements, third-party sharing, transfers outside the EEA, agent clearance, read-then-send patterns, retention, minimization, vendors that train on inputs, and the approval level needed.
  • Regions — EU, UK, US and other. Region-specific rules cover the EU and UK; the US and other regions carry the company policy only.

Within these actions the validator handles any combination of the listed facts, not just the seven scenarios on this page. It does not read the data itself, collect or record consent, answer access requests, cover US state privacy laws one by one, or decide outbound marketing messages (a separate validator).

What the validator sees: facts about the request, never the personal data itselfRead more

The validator takes facts as inputs: the data class, the purpose collected and stated, the lawful basis on record, the destination, the region, the retention days left, the fields requested and needed, the session history and the approval. These come from the company's own records and classification tools at the moment of the call. The validator never sees a name, an address or a diagnosis.

Two honest limits. The validator judges the facts it is given: if the classification says a field is internal when it is personal, the answer follows the facts. And an agent that never calls the validator is not checked; in this demo the agent calls it itself, and in a deployment the gateway the agent reaches its tools through makes the call.

The AI agentProposes an action on data, says why it is fine, then calls the validator before running it.
Predictika validatorReads the facts for the role, data class, purpose, destination and region, 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 role-based access and content scanners get it wrong
Click to expand
    
General statements about role-based access control, content-scanning (DLP) tools and approval workflows, 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
Reading data for a purpose it was not collected forCannot do it
Role-based access control grants a role access to a table. It has no field for the purpose the data was collected for, and neither does a content scanner. The check needs both purposes side by side.		Every rule is checked on every call and the verdict lists each finding.
Reading health data, then sending a harmless-looking note outsideOnly with workarounds
A content scanner can only match what is in the message, and a reworded note passes. A stateful rule over the session history can be written, but one per tool, and kept up by hand.		Every rule is checked on every call and the verdict lists each finding.
An approver level that depends on the kind of dataOnly with workarounds
Approval workflows usually route by amount or requester. Routing by data class is possible with a rule per class and a person who keeps them in step.		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.

    
1Purpose limitation. The data was collected for customer support but this action states analytics, a different kind of use, and no consent for the new use is recorded (GDPR Art 5(1)(b) and 6(4)).
2No lawful basis is recorded for this personal data (GDPR Art 6(1)).
3Health data needs a qualifying legal basis (explicit consent, vital interest, legal obligation or health care provision). The recorded basis is legitimate_interest, which does not qualify (GDPR Art 9).
4Data about children needs parental consent or a legal-obligation or vital-interest basis. The recorded basis is legitimate_interest (GDPR Art 8).
5Meadow Mail (processor - agreement not signed) is a processor and no data processing agreement is signed. Personal data cannot be sent to it (GDPR Art 28).
6Orchid Retail ad network (independent third party) is an independent third party and the recorded basis is none_recorded. Sharing personal data with it needs consent from the people concerned.
7Quill Transcription (US - no transfer mechanism) is outside the EEA and no transfer mechanism is in place for data subjects in EU / EEA (GDPR Art 44 to 46).
8Partner agent via MCP is not cleared for personal data.
9Earlier in this session the agent read special-category data and it is now sending data to Brightline AI endpoint (EU region - no training on inputs), outside the company. This read-then-send pattern is treated as possible exfiltration.
10The retention period for this record ended 12 day(s) ago. Expired personal data must not be used (GDPR Art 5(1)(e)).
11The request asks for 30 fields but only 8 are needed. Asking for more than twice what is needed is excessive (GDPR Art 5(1)(c)).
12Public assistant app (may train on inputs) may use submitted content to train its models, and this content is confidential information. It must not be sent there.
13The data was recalled from the agent memory of an earlier session. A person must confirm it may be used for the purpose stated now.
14The request asks for 14 fields but only 9 are needed. A person must confirm the extra fields.
15Brightline Cloud (US region - standard clauses) is outside the EEA and relies on standard contractual clauses. A transfer impact check must be signed off.
16Special-category data is leaving the company for Brightline Cloud transcription (EU region). The data protection officer must sign off.

  

  

    
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. Using data for another purpose: Churn model from support tickets

    
The agent's request. I'm pulling last quarter's support ticket history, 6 fields per ticket, to build a churn model for the analytics team. It stays in our own systems.

    
Verdict: Blocked.

    
    
      
  • Used for a different purpose than it was collected for. Purpose limitation. The data was collected for customer support but this action states analytics, a different kind of use, and no consent for the new use is recorded (GDPR Art 5(1)(b) and 6(4)).
    • 
    

    
2. Using data for another purpose: The aggregated table instead

    
The agent's request. I'm running the churn model on the aggregated ticket-volume table instead, 6 fields, with no customer-level records. It stays in our own systems.

    
Verdict: Allowed.

    
3. Read, then send: Visit note to an outside AI tool

    
The agent's request. I'm drafting the visit note for the care team. I'll call the Brightline AI endpoint to tidy the wording, 3 fields.

    
Verdict: Blocked.

    
    
      
  • Read special-category data, then sent data outside. Earlier in this session the agent read special-category data and it is now sending data to Brightline AI endpoint (EU region - no training on inputs), outside the company. This read-then-send pattern is treated as possible exfiltration.
    • 
    

    
4. Read, then send: Same note, kept inside

    
The agent's request. I'm drafting the visit note for the care team. I'll tidy the wording with the company's internal note service, 3 fields.

    
Verdict: Allowed.

    
5. Sending health data outside: Discharge record to a vendor

    
The agent's request. I'm sending the discharge record to our transcription vendor, Brightline Cloud, so the care team gets the letter back today. The request covers 14 fields.

    
Verdict: Needs approval.

    
    
      
  • More fields requested than needed. The request asks for 14 fields but only 9 are needed. A person must confirm the extra fields.
    • 
      
  • Special-category data leaving the company. Special-category data is leaving the company for Brightline Cloud transcription (EU region). The data protection officer must sign off.
    • 
    

    
6. Sending health data outside: A manager approves

    
The agent's request. Sending the discharge record to Brightline Cloud for transcription, 14 fields. The manager's approval is attached.

    
Verdict: Needs approval.

    
    
      
  • More fields requested than needed. The request asks for 14 fields but only 9 are needed. A person must confirm the extra fields.
    • 
      
  • Special-category data leaving the company. Special-category data is leaving the company for Brightline Cloud transcription (EU region). The data protection officer must sign off.
    • 
    

    
7. Sending health data outside: The officer approves

    
The agent's request. Sending the discharge record to Brightline Cloud for transcription, 14 fields. The data protection officer's approval is attached.

    
Verdict: Allowed.

    
    
      
  • More fields requested than needed. The request asks for 14 fields but only 9 are needed. A person must confirm the extra fields.
    • 
      
  • Special-category data leaving the company. Special-category data is leaving the company for Brightline Cloud transcription (EU region). The data protection officer must sign off.
    • 
    

  

  

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

    
    
      
  1. Welcome to a demo of Predictika's Validator. Northwind Health lets AI agents work with customer, care and internal data: reading records, sending them to vendors, calling outside tools. Before an agent acts, the call goes to Predictika’s Agent Data-Use Gate. It checks the data class, the purpose the data was collected for against the purpose now stated, the lawful basis on record, where the data is going, the retention period, the agent’s clearance, what the agent already did in the session, and the 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 pulling last quarter's support ticket history, 6 fields per ticket, to build a churn model for the analytics team. It stays in our own systems.
    4. 
      
  4. Before it goes out, the agent calls the validator.
    5. 
      
  5. Blocked, with one finding, all in one answer. Purpose limitation. The data was collected for customer support but this action states analytics, a different kind of use, and no consent for the new use is recorded (GDPR Art 5(1)(b) and 6(4)).
    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 reading data for a purpose it was not collected for, a tool cannot do this.
    8. 
      
  8. Now the agent resubmits.
    9. 
      
  9. The corrected request. It changes the data class to internal information (aggregated counts, no customer-level fields). It removes the collected for.
    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.