k0nsult.cloud / ai-truth / ipIII / legal-board / en

Legal Board — Legal & Regulatory Case Board

The Legal/Compliance layer of the system. Every incident that carries active legal flags (AI Act, GDPR, NIS2) starts reporting clocks toward the competent authorities. This board shows the cases, their flags, the applicable deadlines, the owner (Legal/DPO/AI Safety Officer) and the status of the legal decision — from open to reported/closed.

Executive Overview Cyber Map AI Risk Map Evidence Board Legal Board Response Board

SIMULATION / demonstration data. The cases, owners and deadlines in the table are illustrative (demo) — they do not reflect real proceedings. The normative frameworks below (AI Act art.73, NIS2 24h/72h/1 month, GDPR art.33/34) are based on the publicly known text of the regulations and are framework/educational references, not a description of any actual incident and not a certification. They do not constitute legal advice.

A legal flag is a clock. A clock is a deadline. A deadline is proof of compliance.

Setting the NIS2_RELEVANT, GDPR_BREACH or AI_SERIOUS_INCIDENT flag is not an informational label — it starts a counted reporting obligation. The system tracks the running deadline and requires an artefact confirming that notification was filed.

Cases with legal flags SIMULATION

case	flags	authority deadline	owner	decision status	prio
`LGL-3011` customer data leak	GDPR_BREACHPERSONAL_DATANIS2_RELEVANT	GDPR 72h → 18h left NIS2 24h → sent	Legal/DPO	GDPR art.33 IN PROGRESS	P0
`LGL-3009` serious AI system incident (scoring)	AI_HIGH_RISKAI_SERIOUS_INCIDENTLAW_ENFORCEMENT?	AI Act art.73 → without undue delay	AI Safety Officer	QUALIFICATION ANALYSIS	P0
`LGL-3006` ransomware — essential service	NIS2_RELEVANTCRITICAL_INFRAKSC_RELEVANT	NIS2 early 24h → sent 72h report → 44h left	Operator + Legal	24h FILED	P0
`LGL-3002` phishing → mailbox takeover	PERSONAL_DATAAI_ACT?	GDPR risk assessment → in progress	Legal/DPO	ASSESSING IF BREACH	P1
`LGL-2998` voice deepfake — fraud attempt	FALSE_IDENTITYLAW_ENFORCEMENT	notification to law enforcement	Legal + CISO	REPORTED	P1
`LGL-2990` misconfig — log exposure	PERSONAL_DATA?	art.34 assessment (notifying individuals)	Legal/DPO	NO PROOF OF SCOPE	P2

The "decision status" column inherits evidentially from the Evidence Board — a case cannot be marked "REPORTED as breach" while the data scope is still in GAP status.

Normative frameworks — reporting deadlines

Below: obligation frameworks derived from the publicly known text of the regulations. Character: norm / framework, not a description of an incident. Always verify against the current text of the act and its national implementation.

AI Act — art. 73: reporting of serious incidents

Providers of high-risk AI systems report a serious incident to the market surveillance authority of the state in which the incident occurred, without undue delay after establishing a causal link (or the reasonable likelihood of one) between the AI system and the incident.

Causal link established→without undue delay→market surveillance authority→cooperation / corrective action

Triggering flags: AI_HIGH_RISK + AI_SERIOUS_INCIDENT. Note the specific deadlines that depend on the type of effect (e.g. fatal events — shorter). Subject to the AI Act's entry into force and transitional provisions.

NIS2 — notification obligation (3 stages)

24h early warning→72h incident notification (assessment)→1 month final report

Early warning ≤ 24h from becoming aware of a significant incident — indicating, among other things, whether unlawful/malicious action is suspected and whether cross-border impact is possible.
Incident notification ≤ 72h — update + initial assessment (severity, impact, IOCs if available).
Final report ≤ 1 month from the notification — detailed description, root cause, mitigation measures, cross-border effects.

Addressee: the competent CSIRT / national authority. In PL this is linked to KSC_RELEVANT (the National Cybersecurity System Act). Flag: NIS2_RELEVANT; for essential services also CRITICAL_INFRA.

GDPR — art. 33 and art. 34: personal data breach

Breach detected→art.33 · ≤72h to the DPA→risk assessment for individuals→art.34 notify individuals (high risk)

Art. 33 — notification to the supervisory authority (DPA) ≤ 72h from becoming aware of the breach, unless the breach is unlikely to result in a risk to the rights and freedoms of individuals. A late notification requires an explanation of the delay.
Art. 34 — communication to the data subjects, without undue delay, when the breach is likely to result in a high risk to their rights and freedoms. Exceptions include effective encryption / measures that eliminate the high risk.

Flags: GDPR_PERSONAL_DATA, GDPR_BREACH. Maintain a breach register (art.33(5)) regardless of whether notification was required.

Matrix: flag → obligation → addressee

flag	obligation (framework)	deadline	addressee	owner
AI_SERIOUS_INCIDENT	report a serious AI incident	without undue delay	market surveillance authority	AI Safety Officer
NIS2_RELEVANT	3-stage notification	24h / 72h / 1 month	CSIRT / national authority	Operator + Legal
KSC_RELEVANT	KSC obligations (PL)	per the KSC Act	national-level CSIRT	Operator + Legal
GDPR_BREACH	art.33 notification	≤ 72h	Data Protection Authority	Legal/DPO
PERSONAL_DATA + high risk	art.34 communication	without undue delay	the data subjects	Legal/DPO
LAW_ENFORCEMENT	notification of a crime	promptly	law enforcement	Legal + CISO

Principles of the legal board

1. The clock starts from knowledge, not from will. The deadline runs from becoming aware of / establishing the breach — the system timestamps that moment as immutable.

2. A decision not to report is also a decision. A "no risk" justification must be documented and pinned evidentially (Evidence Board), otherwise the case stays open.

3. Proof of scope before breach qualification. Without a confirmed data scope, a case does not move into "breach reported" — it stays GAP.

4. This is a framework, not advice. The board supports deadline discipline; the final legal qualification belongs to Legal/DPO against the current state of the law.

Related boards

Evidence Board →

The legal decision status inherits from the evidence — a GAP blocks breach qualification.

Response Board →

Notifying an authority is an action with a due_at deadline and proof of filing.

Compliance & reporting →

Templates and a register of letters to authorities (DPA, CSIRT, market surveillance).

AI Act Playbook →

The path for qualifying a serious AI incident and filing the art.73 report.

GDPR breach assessment — not just "the 72h clock"

The art.33 clock starts from establishing the breach, but whether to notify depends on the risk assessment. DPO decision checklist:

Question	Consequence
Is this a personal data breach?	No → outside GDPR art.33/34
Is there a risk to the rights and freedoms of individuals?	Yes → notify the DPA ≤72h (art.33)
Is the risk high?	Yes → communicate to individuals (art.34)
When did "establishing the breach" occur?	Start of the 72h clock
Was the data encrypted / unreadable?	May lower the duty to notify individuals
Who made the decision (DPO)?	Register entry + justification
Is the data retention justified?	Verify the legal basis and period

NIS2 / KSC — entity classification and notification path

Field	Values
Covered sector	yes / no / undetermined
Entity size	medium / large / other
Essential entity	yes / no / undetermined
Important entity	yes / no / undetermined
Competent CSIRT	NASK / GOV / MON / sectoral
Registration obligation	yes / no / undetermined
Notification status	early warning (24h) / notification (72h) / final (1 month)
Responsible	board / manager / security owner

Normative framework, not legal advice. Classifying the entity is up to the organisation and its advisors. See Law Change Watch.