Predictika · Cross-Border Transfer Check

Before an AI agent moves personal data abroad, the transfer is checked

Tamarind Software lets AI agents prepare and run transfers of EU and UK personal data to vendors and group companies abroad. Before an agent sends anything, the call goes to Predictika’s Cross-Border Transfer Check. It decides whether the transfer is restricted at all, whether an adequacy decision covers it, and if not, whether the safeguard on file is the right one and complete: the contract form and module, the annexes, the transfer impact assessment, supplementary measures, onward-transfer terms, binding corporate rules or a derogation. Then it returns one verdict: allow, needs approval, or block.

Not legal advice. Tamarind Software and every vendor on this page are fictional. The scenarios are illustrative. The rules are simplified company policy informed by GDPR Chapter V and UK GDPR; the adequacy table is a dated snapshot. This is not legal advice and has not been reviewed by a lawyer.

Scope: one proposed transfer of personal data from the EU or UK to a recipient abroad, judged against GDPR Chapter V and UK GDPR rulesSee everything this validator covers

This validator decides one thing: whether one proposed transfer of personal data from an EU or UK exporter to a recipient in another country may go ahead, given facts about the transfer. It is not a general privacy review.

  • Mechanisms — adequacy decisions (including partial ones such as the US), standard contractual clauses (all four modules, with the UK Addendum or IDTA for UK transfers), binding corporate rules, and derogations.
  • Checks — whether the transfer is restricted at all, the module the roles call for, completed annexes, a transfer impact assessment and its age, supplementary measures, onward-transfer terms, approved binding corporate rules and their role, derogation conditions, special-category data, and the approval level needed.
  • Regimes and countries — EU GDPR and UK GDPR, against a dated table of ten destinations that can be extended.

Within these checks the validator handles any combination of the listed facts, not just the seven scenarios on this page. It does not decide the lawful basis for processing, answer data subject requests, cover other regimes such as Switzerland or China's outbound rules, or assess a destination's laws itself; it takes the result of the transfer impact assessment as a fact.

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

The validator takes facts as inputs: the regime, the destination, the data class, the roles of exporter and importer, the mechanism chosen, the contract form, module and annex status, the transfer impact assessment result and its age, binding corporate rules status, derogation details, onward-transfer terms and the approval on record. It holds only a dated table of destination countries and their adequacy status. It never sees a name, an address or a record.

Two honest limits. The validator judges the facts it is given: if the importer’s certification is recorded wrongly, the answer follows the record. 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 a transfer, names the mechanism it relies on, then calls the validator before sending.
Predictika validatorReads the facts, decides which route applies, checks the safeguard on file against it, 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 registers and checklists get it wrong
Click to expand
    
General statements about transfer registers, document checklists 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
Adequacy that depends on the importer, not just the countryOnly with workarounds
A register can hold “US: adequate”. Applying it needs the importer’s certification status as well, and a person who remembers to check it for every US vendor.		Every rule is checked on every call and the verdict lists each finding.
Choosing the clause module from the rolesOnly with workarounds
A document checklist ticks “clauses signed”. The module has to match who is exporting and who is importing, which a checkbox does not hold.		Every rule is checked on every call and the verdict lists each finding.
UK and EU transfers needing different contract formsOnly if someone is vigilant
A team can run two checklists and pick the right one each time, if someone is careful about it.		Every rule is checked on every call and the verdict lists each finding.
Approver level that depends on what was foundOnly with workarounds
Approval workflows usually route by amount or requester. Routing by “gaps found, measures in place” needs a custom rule kept up by hand.		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 request relies on adequacy, but United States is not covered for this transfer under EU GDPR. There is no adequacy decision, or the decision is partial and the importer is outside its scope (for example a US importer not certified under the Data Privacy Framework).
2No transfer mechanism is in place. India is not covered by adequacy for this transfer, so Chapter V needs standard contractual clauses, binding corporate rules or a derogation (GDPR Art 44 to 46 and 49).
3The contract on file is not the UK IDTA or the EU clauses with the UK Addendum. A transfer under UK GDPR needs one of them.
4The roles (controller to processor) call for SCC Module 2, but the contract on file uses Module 1.
5The contract annexes are not completed (parties and transfer description, security measures and, where processors are involved, sub-processors).
6The binding corporate rules are not approved by the competent supervisory authority, so they cannot be relied on (GDPR Art 47).
7The approved rules cover a different role. The exporter acts as a controller in this transfer, and rules for that role are needed.
8No transfer impact assessment is on file for India. The exporter must assess the laws and practices of the destination before relying on clauses or binding corporate rules (SCC Clause 14; CJEU C-311/18; EDPB Recommendations 01/2020).
9The transfer impact assessment found gaps and no supplementary measure is in place. The transfer must be suspended or ended until effective measures exist (EDPB Recommendations 01/2020).
10The importer plans onward transfers and no onward-transfer terms are in place. Any onward recipient must be bound to the same protection (SCC Clauses 8.7 and 8.8).
11The transfers are repeated or systematic. A derogation is for occasional transfers only (GDPR Art 49 and recital 111).
12Explicit consent counts only if the person was told of the risks of a transfer without adequacy or safeguards, and that is not on record (GDPR Art 49(1)(a)).
13The transfer impact assessment is 14 months old, older than the 12 months company policy allows. A manager must confirm it still holds (EDPB Recommendations 01/2020, step 6).
14The transfer impact assessment found gaps and the transfer relies on supplementary measures. The data protection officer must confirm the measures are effective.
15A derogation under GDPR Art 49 is a last resort. The data protection officer must sign off and the assessment must be recorded (Art 49(6)).
16Special-category data is leaving for a destination without adequacy. The data protection officer must sign off (company policy).

  

  

    
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. Relying on adequacy: Support tickets to a US vendor

    
The agent's request. I'm sending EU customer support tickets to our US analytics vendor so the team can see weekly trends. The United States has an adequacy decision, so no further safeguard is needed.

    
Verdict: Blocked.

    
    
      
  • Relied on adequacy that does not cover this importer. The request relies on adequacy, but United States is not covered for this transfer under EU GDPR. There is no adequacy decision, or the decision is partial and the importer is outside its scope (for example a US importer not certified under the Data Privacy Framework).
    • 
    

    
2. Relying on adequacy: Standard clauses and an assessment

    
The agent's request. Sending the same support tickets to the US vendor under signed EU standard contractual clauses, Module 2, with the annexes completed and a transfer impact assessment from two months ago.

    
Verdict: Allowed.

    
3. A transfer to India: Payroll records to India

    
The agent's request. I'm sending EU payroll records to our payroll processor in India under the standard contractual clauses we have signed. Module 1, annexes completed.

    
Verdict: Blocked.

    
    
      
  • No transfer impact assessment. No transfer impact assessment is on file for India. The exporter must assess the laws and practices of the destination before relying on clauses or binding corporate rules (SCC Clause 14; CJEU C-311/18; EDPB Recommendations 01/2020).
    • 
      
  • Onward transfers without terms. The importer plans onward transfers and no onward-transfer terms are in place. Any onward recipient must be bound to the same protection (SCC Clauses 8.7 and 8.8).
    • 
      
  • Wrong clause module for the roles. The roles (controller to processor) call for SCC Module 2, but the contract on file uses Module 1.
    • 
    

    
4. A transfer to India: Right module, gaps covered

    
The agent's request. Sending the payroll records to our India processor under Module 2 of the standard contractual clauses. The impact assessment is done and the supplementary measures are in place. Onward transfer terms are signed.

    
Verdict: Needs approval.

    
    
      
  • Transfer relies on supplementary measures. The transfer impact assessment found gaps and the transfer relies on supplementary measures. The data protection officer must confirm the measures are effective.
    • 
    

    
5. A transfer to India: The officer approves

    
The agent's request. Sending the payroll records to our India processor under Module 2 of the standard contractual clauses. The data protection officer's approval is attached.

    
Verdict: Allowed.

    
    
      
  • Transfer relies on supplementary measures. The transfer impact assessment found gaps and the transfer relies on supplementary measures. The data protection officer must confirm the measures are effective.
    • 
    

    
6. A UK transfer: UK customer data to Singapore

    
The agent's request. Sending UK customer data to our processor in Singapore under the signed EU standard contractual clauses, Module 2, with a transfer impact assessment from three months ago.

    
Verdict: Blocked.

    
    
      
  • Wrong contract form for a UK transfer. The contract on file is not the UK IDTA or the EU clauses with the UK Addendum. A transfer under UK GDPR needs one of them.
    • 
    

    
7. A UK transfer: With the UK Addendum

    
The agent's request. Sending the same UK customer data to Singapore under the EU standard contractual clauses, Module 2, with the UK Addendum attached.

    
Verdict: Allowed.

  

  

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

    
    
      
  1. Welcome to a demo of Predictika's Validator. Tamarind Software lets AI agents prepare and run transfers of EU and UK personal data to vendors and group companies abroad. Before an agent sends anything, the call goes to Predictika’s Cross-Border Transfer Check. It decides whether the transfer is restricted at all, whether an adequacy decision covers it, and if not, whether the safeguard on file is the right one and complete: the contract form and module, the annexes, the transfer impact assessment, supplementary measures, onward-transfer terms, binding corporate rules or a derogation. 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 EU customer support tickets to our US analytics vendor so the team can see weekly trends. The United States has an adequacy decision, so no further safeguard is needed.
    4. 
      
  4. Before it goes out, the agent calls the validator.
    5. 
      
  5. Blocked, with one finding, all in one answer. The request relies on adequacy, but United States is not covered for this transfer under EU GDPR. There is no adequacy decision, or the decision is partial and the importer is outside its scope (for example a US importer not certified under the Data Privacy Framework).
    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 adequacy that depends on the importer, not just the country, a tool can do this only with workarounds.
    8. 
      
  8. Now the agent resubmits.
    9. 
      
  9. The corrected request. It sets the contract to EU standard contractual clauses, Module 2 (controller to processor), the annexes to complete and the transfer impact assessment to no gaps, done 2 months ago. It removes the regime, destination, data class and roles.
    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.