Predictika · Breach Notification Check

Before an AI agent decides who to notify about a breach, the decision is checked

Kestrel Data Systems, a fictional cloud data vendor, lets an AI agent help run the response to a security incident. Before the agent decides who to tell, or whether to wait, the call goes to Predictika’s Breach Notification Check. It checks the region, whether the company is the controller or a processor, the kind of data, whether it was encrypted with the key kept safe, the risk to people, the hours since awareness, how many records are involved, and any approval on record. Then it returns one verdict: allow, needs approval, or block.

Not legal advice. Kestrel Data Systems is fictional. The scenarios are illustrative. The rules are a simplified model informed by GDPR, UK GDPR and California breach law; 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 notification decision after one security incident, judged against region, company role, data, risk, deadline and threshold rules in the EU, the UK and CaliforniaSee everything this validator covers

This validator decides one thing: whether one proposed notification decision after a breach may go ahead, given the facts of the incident. It is not a legal opinion or an incident management tool.

  • Decisions and regions — tell the controller, the authority, the individuals or both, make no notice, or hold; EU, UK and California.
  • Rules — notice required but none proposed, notice held past the deadline, processor going around its controller, controller notifying a controller, individuals told without the authority, California Attorney General threshold, late notice, individuals still to be told after a high-risk notice, undocumented decision not to notify, and large breaches needing counsel.

Within these rules the validator handles any combination of the listed facts, not just the seven scenarios on this page. It does not assess the risk itself, read the notice text, cover other countries or US states, or decide whether data is encrypted; those are taken as stated facts.

What the validator sees: facts about the incident and the decision, never the data or the peopleRead more

The validator takes facts as inputs: the region, the company role, the kind of data, whether it was encrypted and the key kept safe, the assessed risk to people, the hours since the company became aware, the number of records, the proposed decision, and the approval on record. These come from the incident response system at the moment of the call. The validator never sees the data, the people or the notice itself.

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

The AI agentProposes a notification decision, says why it is fine, then calls the validator before acting.
Predictika validatorReads the region, role and incident 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 incident response tools get it wrong
Click to expand
    
General statements about incident response 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
Who must be told, by company roleCannot do it
An incident tool tracks tasks. It does not know whether the company is controller or processor for a given dataset, so it cannot tell who the notice must go to.		Every rule is checked on every call and the verdict lists each finding.
Not letting the clock run out while an investigation continuesOnly if someone is vigilant
A tool can show a countdown. It does not stop an agent from choosing to wait past the deadline, or require a reason for a late notice.		Every rule is checked on every call and the verdict lists each finding.
Different thresholds in the EU, the UK and California in one decisionOnly with workarounds
A tool can hold separate checklists per region if someone builds them. It does not return one answer with every reason across regions, roles and data 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.

    
1A notice is required here and none is proposed. The data is sensitive and the risk is high (GDPR Art 33(1) and 34; Cal. Civ. Code 1798.82).
2Holding the notice at 80 hours is past the 72 hour deadline. Notify now (GDPR Art 33(1); company policy for processors).
3As a processor the company must tell the controller, not the authority or the individuals (GDPR Art 33(2)).
4As the controller the company has no one upstream to notify. It must decide on notice to the authority and the individuals itself (GDPR Art 33(1)).
5Telling the individuals only is not enough. The supervisory authority must be told too (GDPR Art 33(1)).
6A breach affecting 800 California residents must also be reported to the Attorney General (Cal. Civ. Code 1798.82(f)).
7The notice would go out 80 hours after awareness, past the 72 hour deadline. It must state the reasons for the delay (GDPR Art 33(1)).
8The risk is high, so the individuals must also be told without undue delay (GDPR Art 34). The privacy officer must confirm that plan.
9A decision not to notify must be documented with its reasons (GDPR Art 33(5)). The privacy officer must sign off.
10A breach of 50000 records needs counsel to review the notice before it goes out (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. Whether to notify: Decision to say nothing

    
The agent's request. I'm closing this incident without any notice. It has been 20 hours and the exposure looks contained.

    
Verdict: Blocked.

    
    
      
  • No notice proposed where one is required. A notice is required here and none is proposed. The data is sensitive and the risk is high (GDPR Art 33(1) and 34; Cal. Civ. Code 1798.82).
    • 
    

    
2. Whether to notify: Notify the authority and the individuals

    
The agent's request. I'm notifying the supervisory authority and the affected individuals. It has been 20 hours.

    
Verdict: Allowed.

    
3. Deadline: Hold the notice at 80 hours

    
The agent's request. I'm holding the notice for now. It has been 80 hours and the investigation is not finished.

    
Verdict: Blocked.

    
    
      
  • Notice held past the deadline. Holding the notice at 80 hours is past the 72 hour deadline. Notify now (GDPR Art 33(1); company policy for processors).
    • 
    

    
4. Deadline: Notify the authority at 80 hours

    
The agent's request. I'm notifying the supervisory authority now. It has been 80 hours since we became aware.

    
Verdict: Needs approval.

    
    
      
  • Notice going out late. The notice would go out 80 hours after awareness, past the 72 hour deadline. It must state the reasons for the delay (GDPR Art 33(1)).
    • 
    

    
5. Roles: Processor tells the authority directly

    
The agent's request. We run this platform for our customer. I'm reporting the breach to the supervisory authority directly, to save time.

    
Verdict: Blocked.

    
    
      
  • Processor going around its controller. As a processor the company must tell the controller, not the authority or the individuals (GDPR Art 33(2)).
    • 
    

    
6. Roles: Processor notifies the controller

    
The agent's request. We run this platform for our customer. I'm notifying the customer, who is the controller, at 10 hours.

    
Verdict: Allowed.

    
7. California: California breach, individuals only

    
The agent's request. I'm notifying the 800 affected California residents about the exposed credentials. That covers it.

    
Verdict: Blocked.

    
    
      
  • California Attorney General not told. A breach affecting 800 California residents must also be reported to the Attorney General (Cal. Civ. Code 1798.82(f)).
    • 
    

  

  

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

    
    
      
  1. Welcome to a demo of Predictika's Validator. Kestrel Data Systems, a fictional cloud data vendor, lets an AI agent help run the response to a security incident. Before the agent decides who to tell, or whether to wait, the call goes to Predictika’s Breach Notification Check. It checks the region, whether the company is the controller or a processor, the kind of data, whether it was encrypted with the key kept safe, the risk to people, the hours since awareness, how many records are involved, 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 closing this incident without any notice. It has been 20 hours and the exposure looks contained.
    4. 
      
  4. Before it goes out, the agent calls the validator.
    5. 
      
  5. Blocked, with one finding, all in one answer. A notice is required here and none is proposed. The data is sensitive and the risk is high (GDPR Art 33(1) and 34; Cal. Civ. Code 1798.82).
    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 different thresholds in the EU, the UK and California in one decision, a tool can do this only with workarounds.
    8. 
      
  8. Now the agent resubmits.
    9. 
      
  9. The corrected request.
    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.