# Satisfying EU Data, Liability, and Algorithmic Regulations with `calibrated_explanations`

> [!WARNING]
> **LEGAL DISCLAIMER — NO COMPLIANCE GUARANTEE**
>
> This document and this library do not constitute legal advice and carry no
> guarantee that any regulatory authority or legal entity will regard the
> library's outputs as satisfying any statutory obligation under the GDPR,
> Product Liability Directive, AI Liability Directive, DSA, Equal Treatment
> Directives, or any other law. Compliance determinations require qualified
> legal counsel. The library is provided "as is" under the BSD 3-Clause licence.
> **The authors and maintainers expressly disclaim all liability arising from
> reliance on this document.**

> **Document scope:** This guide targets practitioners and compliance officers who
> deploy machine learning models subject to EU regulations beyond the AI Act.
> It covers the General Data Protection Regulation (GDPR), the revised Product
> Liability Directive, the proposed AI Liability Directive, the Digital Services
> Act, and the EU Equal Treatment Directives. Each regulation is mapped to the
> concrete capabilities of `calibrated_explanations`, with a per-provision
> implementation checklist and code examples.
>
> **Read alongside:** [eu-ai-act-compliance.md](eu-ai-act-compliance.md) -- the
> companion document covering Regulation (EU) 2024/1689 (the EU AI Act). In
> practice, high-risk AI systems are subject to **both** the AI Act and the
> regulations in this document simultaneously.

---
## 1. Executive Summary

The EU AI Act receives the most attention in the AI compliance discourse, but it is
one layer of a broader regulatory stack. Any organisation deploying machine learning
models that process personal data, influence consumer decisions, or carry potential
for harm faces obligations under at least four further bodies of EU law.

**GDPR** (Regulation (EU) 2016/679) applies whenever personal data is used to train
or run a model. Its Art. 22 imposes strict conditions on solely automated decisions
that produce legal or similarly significant effects, and Arts. 13-15 require that
affected individuals receive *meaningful information about the logic* behind such
decisions. The accountability principle (Art. 5(2)) requires demonstrable compliance,
which means per-decision evidence -- not aggregate statistics.

**The revised Product Liability Directive** (Directive (EU) 2024/2853, applicable
from December 2026) treats AI software as a *product*. A flawed or opaque AI
decision that causes measurable damage makes the provider potentially liable. The
Directive introduces a **rebuttable presumption of defect** when a provider cannot
disclose the technical documentation related to the AI system. Explanation and
uncertainty records generated by `calibrated_explanations` constitute that
documentation.

**The proposed AI Liability Directive** (COM/2022/496, in legislative process)
adapts tort law to AI by introducing a disclosure obligation for evidence and a
rebuttable presumption of causality when a provider refuses to disclose relevant
technical evidence. Proactively retaining per-decision explanation payloads removes
the adversarial risk of disclosure disputes.

**The Digital Services Act** (Regulation (EU) 2022/2065) requires very large online
platforms (VLOPs) and very large online search engines (VLOSEs) to explain the
parameters of their recommender systems to users. `calibrated_explanations` can
supply the per-user, per-item explanation content these obligations demand.

**Equal Treatment Directives** (Directives 2000/43/EC, 2000/78/EC, 2006/54/EC)
prohibit direct and indirect discrimination in employment, credit, education, and
services on protected grounds. Mondrian conditional calibration in
`calibrated_explanations` provides quantitative, group-specific evidence of
differential model behaviour, essential both for internal fairness auditing and
for defending against indirect discrimination claims.

---

## 2. Regulatory Landscape Map

| Regulation | Official citation | Applicability trigger for ML systems | Status (Feb 2026) |
|---|---|---|---|
| GDPR | Regulation (EU) 2016/679 | Any processing of personal data in the EU | In force |
| Product Liability Directive | Directive (EU) 2024/2853 | AI software causing physical or material damage | Adopted Oct 2024; Member States implement by Dec 2026 |
| AI Liability Directive | COM/2022/496 (proposed) | AI-caused harm in tort claims | In legislative process |
| Digital Services Act | Regulation (EU) 2022/2065 | Recommender systems on VLOPs / VLOSEs | In force; VLOP obligations from Aug 2023 |
| Equal Treatment Directives | 2000/43/EC, 2000/78/EC, 2006/54/EC | Employment, credit, or service decision touching protected characteristics | In force |

---
## 3. GDPR -- General Data Protection Regulation

### 3.1 Art. 5 -- Principles Relating to Processing

**a) Title (verbatim):** Article 5 -- Principles relating to processing of personal data

**b) Core obligation:** Personal data must be processed lawfully, fairly, and
transparently; limited to what is necessary; accurate; stored no longer than
necessary; and processed with appropriate security. The controller is accountable
for demonstrating compliance with all these principles (Art. 5(2) -- the
**accountability principle**).

**c) How `calibrated_explanations` contributes:** Accountability requires *demonstrable*
compliance. `as_json()` produces a per-decision serialisable record encoding the
input features, prediction, calibrated probability, and explanation weights. When
a regulator or data subject asks "how was this decision made?", the stored JSON
payload is the answer. Venn-Abers calibration also directly supports the **accuracy
principle** (Art. 5(1)(d)): calibrated probabilities are empirically valid, reducing
the risk of systematically over- or under-confident model outputs.

**d) Code:**

```python
import json, datetime, pathlib, uuid
import calibrated_explanations

audit_log = pathlib.Path("gdpr_audit") / "decisions.jsonl"
audit_log.parent.mkdir(exist_ok=True)

explanation = explainer.explain_factual(X_query)
probs, (low, high) = explainer.predict_proba(X_query, uq_interval=True)

with audit_log.open("a", encoding="utf-8") as f:
    for i, exp in enumerate(explanation):
        record = {
            "record_id": str(uuid.uuid4()),
            "data_subject_ref": subject_ids[i],   # pseudonymised identifier
            "timestamp": datetime.datetime.utcnow().isoformat() + "Z",
            "ce_version": calibrated_explanations.__version__,
            "probability": float(probs[i, 1]),
            "probability_interval": {
                "low": float(low[i, 1]),
                "high": float(high[i, 1])
            },
            "factual_explanation": exp.as_json(),
        }
        f.write(json.dumps(record) + "\n")
```

**e) Audit documentation:** The accountability log must be accessible to the Data
Protection Officer. Define a retention schedule proportionate to the purpose
(Art. 5(1)(e)); credit decisions commonly require >= 5 years.

---

### 3.2 Arts. 13 and 14 -- Transparency Information to Data Subjects

**a) Title (verbatim):** Article 13 -- Information to be provided where personal data
are collected from the data subject; Article 14 -- Information to be provided where
personal data have not been obtained from the data subject

**b) Core obligation:** At the time of data collection the controller must inform
the data subject about the existence of automated decision-making (including
profiling) and provide *meaningful information about the logic involved*, the
significance, and envisaged consequences (Arts. 13(2)(f), 14(2)(g)).

**c) How `calibrated_explanations` contributes:** The privacy notice required by
Arts. 13/14 must describe the system's logic in a way a layperson can understand.
`print_rules()` from `explain_factual` demonstrates the concrete form that logic
takes per instance. Organisations can use the factual rule table structure
(feature -> direction -> weight +/- uncertainty interval) as the template for the
"logic description" in their privacy notices.

**d) Code:**

```python
# Generate representative description for privacy notices
sample_factual = explainer.explain_factual(x_cal[:10])

print("Features used in decisions and their typical influence range:")
for exp in sample_factual:
    exp.print_rules()
    print("---")
```

**e) Audit documentation:** Maintain a version-controlled copy of the privacy notice
alongside the model version it describes. Re-generate the logic description and
update the notice whenever the model or feature set changes.

---

### 3.3 Art. 15 -- Right of Access

**a) Title (verbatim):** Article 15 -- Right of access by the data subject

**b) Core obligation:** The data subject has the right to receive *meaningful
information about the logic* of any automated processing, as well as the significance
and envisaged consequences (Art. 15(1)(h)).

**c) How `calibrated_explanations` contributes:** When a data subject submits a
Subject Access Request (SAR), the stored explanation records keyed on
`data_subject_ref` enable retrieval of all payloads for that individual.
`print_rules()` renders those payloads in plain language suitable for the SAR
response letter.

**d) Code:**

```python
import json, pathlib

def get_records_for_subject(subject_ref: str) -> list:
    audit_log = pathlib.Path("gdpr_audit") / "decisions.jsonl"
    records = []
    with audit_log.open(encoding="utf-8") as f:
        for line in f:
            rec = json.loads(line)
            if rec["data_subject_ref"] == subject_ref:
                records.append(rec)
    return records

records = get_records_for_subject("subject-xxxx")
for rec in records:
    pi = rec["probability_interval"]
    print(f"Decision on {rec['timestamp']}: P = {rec['probability']:.2%} "
          f"[{pi['low']:.2%}, {pi['high']:.2%}]")
    # Render rec["factual_explanation"] for the SAR letter
```

**e) Audit documentation:** Implement a SAR workflow that verifies identity,
retrieves records, renders them in plain language, and logs the SAR response event.
The one-month response deadline (Art. 12(3)) must be tracked per request.

---

### 3.4 Art. 17 -- Right to Erasure

**a) Title (verbatim):** Article 17 -- Right to erasure (right to be forgotten)

**b) Core obligation:** Data subjects have the right to obtain erasure of their
personal data without undue delay where the data are no longer necessary, consent
is withdrawn, or processing was unlawful (Art. 17(1)).

**c) How `calibrated_explanations` contributes:** The explanation payloads produced
by `as_json()` contain the input feature vector, which may constitute personal data.
The `data_subject_ref` field enables targeted deletion of all inference-time records
for a specific individual. Note: erasure of explanation records does not affect the
trained model -- model unlearning is a separate requirement (see Section 9.1).

**d) Code:**

```python
import json, pathlib, shutil

def erase_subject(subject_ref: str) -> int:
    """Remove all records for subject_ref. Returns count of erased records."""
    audit_log = pathlib.Path("gdpr_audit") / "decisions.jsonl"
    tmp = audit_log.with_suffix(".tmp")
    erased = 0
    with audit_log.open(encoding="utf-8") as src, \
         tmp.open("w", encoding="utf-8") as dst:
        for line in src:
            rec = json.loads(line)
            if rec["data_subject_ref"] == subject_ref:
                erased += 1
            else:
                dst.write(line)
    shutil.move(tmp, audit_log)
    return erased
```

**e) Audit documentation:** Log erasure events (requester, timestamp, count of
records deleted) in a separate erasure register that must not contain the erased
personal data.

---

### 3.5 Art. 21 -- Right to Object

**a) Title (verbatim):** Article 21 -- Right to object

**b) Core obligation:** Where processing is based on legitimate interests
(Art. 6(1)(f)), the data subject has the right to object. The controller must
discontinue unless it can demonstrate compelling legitimate grounds that override the
data subject's interests (Art. 21(1)).

**c) How `calibrated_explanations` contributes:** The factual rule table and
calibrated probability provide the *specific grounds* a controller can use to
document the compelling legitimate basis. Wide intervals or irrelevant dominant
features would undermine the legitimate interest claim and strengthen the objection.

**d) Code:**

```python
factual = explainer.explain_factual(X_query)
probs, (low, high) = explainer.predict_proba(X_query, uq_interval=True)

interval_width = high[0, 1] - low[0, 1]
if interval_width > 0.30:
    print("High uncertainty: legitimate interest claim may not override objection.")
else:
    print(f"Compelling grounds documented: {factual[0].as_json()}")
```

**e) Audit documentation:** Log Art. 21 objection events alongside the explanation
payload and the controller's documented decision. Decisions to continue despite an
objection require explicit legal review.

---

### 3.6 Art. 22 -- Automated Individual Decision-Making Including Profiling

**a) Title (verbatim):** Article 22 -- Automated individual decision-making,
including profiling

**b) Core obligation:** A data subject has the right not to be subject to a decision
based *solely* on automated processing that produces legal or similarly significant
effects (Art. 22(1)). Where permitted, the controller must implement safeguards
including the right to obtain *human intervention*, to *express their view*, and to
*contest the decision* (Art. 22(3)).

**c) How `calibrated_explanations` contributes:** Art. 22 is the single most
operationally demanding GDPR obligation for ML deployers. `calibrated_explanations`
addresses all three statutory safeguards:

- **Human intervention:** The uncertainty-based escalation gate prevents solely
  automated decisions in uncertain cases by routing them to a human reviewer.
- **Express their view:** The factual rule table renders the model reasoning in plain
  language, giving the individual something concrete to react to.
- **Contest the decision:** `explore_alternatives` generates actionable counterfactuals
  showing what the individual could change to obtain a different outcome.

**d) Code:**

```python
# Three-safeguard implementation for GDPR Art. 22(3)

# 1. Human intervention gate -- route uncertain decisions
probs, (low, high) = explainer.predict_proba(X_query, uq_interval=True)
boundary = 0.5
straddles = (low[:, 1] < boundary) & (high[:, 1] > boundary)
if straddles.any():
    escalate_to_human_reviewer(X_query[straddles])

# 2. Individual can express their view -- factual explanation in decision notice
factual = explainer.explain_factual(X_query)
factual[0].print_rules()

# 3. Individual can contest -- counterfactual alternatives in decision letter
alternatives = explainer.explore_alternatives(X_query)
alternatives[0].print_rules()
```

**e) Audit documentation:** The Art. 22 record must contain the factual rule table,
the alternative rules, the probability and interval, whether human review was
triggered, and (if triggered) the reviewer's decision and rationale.

---

### 3.7 Art. 25 -- Data Protection by Design and by Default

**a) Title (verbatim):** Article 25 -- Data protection by design and by default

**b) Core obligation:** Controllers must implement technical measures to give effect
to data protection principles by design. By default, only personal data necessary
for each specific purpose shall be processed (Art. 25(1)-(2)).

**c) How `calibrated_explanations` contributes:** Feature importance explainability
is a tool for **data minimisation by design** (Art. 5(1)(c)). Examining which
features consistently carry low or negligible weight across a validation set
identifies features that add no predictive utility and therefore have no legitimate
reason to be processed.

**d) Code:**

```python
import numpy as np

factual = explainer.explain_factual(x_val)
all_weights = np.array([
    list(exp.as_json()["feature_weights"].values())
    for exp in factual
])
mean_abs_weights = np.abs(all_weights).mean(axis=0)

print("Feature utility analysis (mean |weight|):")
for name, w in zip(feature_names, mean_abs_weights):
    flag = "  <- consider removing" if w < 0.01 else ""
    print(f"  {name}: {w:.4f}{flag}")
```

**e) Audit documentation:** Record the feature utility analysis in the DPIA (see
Section 3.8) as evidence of the data minimisation measure taken. Document the
decision to retain or remove each feature, with justification.

---

### 3.8 Art. 35 -- Data Protection Impact Assessment

**a) Title (verbatim):** Article 35 -- Data protection impact assessment

**b) Core obligation:** Where processing is likely to result in a high risk to
rights and freedoms -- including systematic profiling -- the controller must
carry out a DPIA before processing begins. The DPIA must describe the processing,
assess necessity and proportionality, identify risks, and document measures to
address them (Art. 35(1), (7)).

**c) How `calibrated_explanations` contributes:** A DPIA requires a description of
the processing logic (Art. 35(7)(b)). The factual rule table format, the empirical
coverage statistics, per-group interval widths (Mondrian), and the uncertainty-based
escalation thresholds are all concrete technical inputs to the DPIA's risk assessment
and mitigation sections.

**d) Code:**

```python
import numpy as np

probs, (low, high) = explainer.predict_proba(x_val, uq_interval=True)
widths = high[:, 1] - low[:, 1]

print("=== DPIA Technical Annex: Prediction Uncertainty Summary ===")
print(f"  n_instances              : {len(x_val)}")
print(f"  mean interval width      : {widths.mean():.3f}")
print(f"  p95 interval width       : {np.percentile(widths, 95):.3f}")
print(f"  fraction flagged (> 0.25): {(widths > 0.25).mean():.2%}")

group_labels = x_val[:, protected_feature_idx]
for group in np.unique(group_labels):
    mask = group_labels == group
    print(f"  Group {group!r} mean width: {widths[mask].mean():.3f}")
```

**e) Audit documentation:** Include the DPIA technical annex in the DPIA document.
Review the DPIA when the model or data pipeline changes materially (Art. 35(11)).

---
## 4. Product Liability Directive -- Directive (EU) 2024/2853

### 4.1 Core Obligations

**Status:** Adopted 23 October 2024. Member States must transpose by 9 December 2026.

The revised PLD explicitly includes AI software as a **product** (Art. 4(1)).
Key obligations for ML systems:

- **Defective product (Art. 6):** A product is defective when it does not provide
  the safety the public is entitled to expect, taking into account its presentation,
  reasonably foreseeable use, and applicable safety regulations (including the AI Act).
- **Rebuttable disclosure presumption (Art. 9(4)):** Unjustified refusal to disclose
  technical evidence leads to a **presumption of defect**.
- **Damage categories (Art. 4(6)):** Includes material economic loss (>= EUR 1 000)
  and loss of data processed for personal rather than professional purposes.

### 4.2 How `calibrated_explanations` Contributes

An organisation that can produce, on demand, the serialised explanation payload
(`as_json()`), calibration evidence (empirical coverage vs. nominal), and per-group
uncertainty analysis (Mondrian) is in a substantially stronger legal position than
one relying solely on aggregate accuracy metrics:

- The **factual rule table** refutes a claim that the system was a black box.
- The **calibrated probability interval** demonstrates accurately represented
  confidence, countering overconfidence claims.
- The **counterfactual alternatives** demonstrate identifiable conditions under which
  the outcome would differ, relevant to causation analysis.
- The **Mondrian per-group uncertainty** documents that no group was systematically
  disadvantaged through reduced reliability.

### 4.3 Code

```python
import calibrated_explanations

def generate_pld_disclosure_package(subject_ref: str,
                                    empirical_coverage: float) -> dict:
    """Produce on-demand disclosure package for PLD Art. 9(4) requests."""
    records = get_records_for_subject(subject_ref)  # from Section 3.3
    return {
        "subject_ref": subject_ref,
        "decision_records": records,
        "system_metadata": {
            "ce_version": calibrated_explanations.__version__,
            "calibration_set_size": len(x_cal),
            "nominal_confidence": 0.90,
            "empirical_coverage": empirical_coverage,
        },
    }
```

### 4.4 Audit Documentation

Retain explanation payloads for at least 10 years from the product placement date
(Art. 14 limitation period). Implement a cryptographic integrity mechanism
(e.g., append-only hash chain) so stored records cannot be retroactively altered.

---

## 5. AI Liability Directive -- COM/2022/496 (Proposed)

### 5.1 Status and Core Obligations

**Status as of February 2026:** In legislative process; final adoption not confirmed.
Practitioners should monitor the Official Journal for adoption.

Key proposed provisions relevant to ML:

- **Disclosure of evidence (Art. 3):** Courts may order providers of high-risk AI
  systems to disclose relevant evidence. Non-compliance triggers a **rebuttable
  presumption of causality** -- the court presumes the AI system caused the harm.
- **Rebuttable causal link presumption (Art. 4):** Where the defendant has failed to
  comply with an AI Act obligation and non-compliance likely caused the damage, the
  court *presumes* causality. AI Act compliance therefore **directly reduces tort
  liability exposure**.
- **Fault-based liability only:** Unlike the PLD (strict liability), claimants must
  show a negligence standard was not met.

### 5.2 How `calibrated_explanations` Contributes

Because the causality presumption is defeated by AI Act compliance, the entire
compliance framework in [eu-ai-act-compliance.md](eu-ai-act-compliance.md) applies.
Additionally:

- Retaining `as_json()` payloads proactively satisfies the Art. 3 disclosure
  obligation *before* litigation arises, removing the court's ability to draw an
  adverse inference.
- The calibrated probability interval as a **legitimate uncertainty representation**
  makes it difficult to argue the system was recklessly overconfident -- a
  standard-of-care argument central to fault-based liability.
- Per-group Mondrian analysis documents that discriminatory impact was examined,
  countering negligence claims based on failure to detect disparate outcomes.

### 5.3 Audit Documentation

Maintain the same audit log as the GDPR accountability log (Section 3.1). Document
the date each model version entered and left service, as the limitation period is
expected to run from the date the damage occurred.

---

## 6. Digital Services Act -- Regulation (EU) 2022/2065

### 6.1 Art. 26 -- Transparency of Recommender Systems

**a) Title (verbatim):** Article 26 -- Transparency of recommender systems

**b) Core obligation:** Online platforms that use recommender systems must set out,
in plain and intelligible language in their terms and conditions, the main parameters
used to determine recommended content and their relative importance (Art. 26(1)).

**c) How `calibrated_explanations` contributes:** `explain_factual` identifies the
main parameters (features) and their relative importance (feature weights with
uncertainty intervals) for each recommendation. Aggregating over a large sample
provides the system-level parameter importance distribution suitable for disclosure
in terms and conditions.

**d) Code:**

```python
import numpy as np

factual = explainer.explain_factual(x_val)
all_weights = np.array([
    list(exp.as_json()["feature_weights"].values())
    for exp in factual
])
mean_weights = all_weights.mean(axis=0)
std_weights = all_weights.std(axis=0)

print("Recommender system main parameters (DSA Art. 26 disclosure):")
for name, mean, std in sorted(
    zip(feature_names, mean_weights, std_weights),
    key=lambda x: abs(x[1]), reverse=True
):
    direction = "increases" if mean > 0 else "decreases"
    print(f"  {name}: on average {direction} score by "
          f"{abs(mean):.3f} +/- {std:.3f}")
```

**e) Audit documentation:** Publish the parameter importance summary (updated with
each model version) in the public-facing terms and conditions. Retain version history.

---

### 6.2 Art. 27 -- Per-User Explanations

**a) Title (verbatim):** Article 27 -- Online platforms' recommender systems

**b) Core obligation:** Platforms must ensure users can access, at the time of
recommendation, information about the main parameters used for the specific
recommendation served to them (Art. 27(2)).

**c) How `calibrated_explanations` contributes:** `explain_factual(X_query)` for a
specific user-item pair provides the per-instance parameter breakdown Art. 27(2)
requires. `print_rules()` output can be rendered directly in a "why am I seeing
this?" user interface component.

**d) Code:**

```python
import numpy as np

def get_recommendation_explanation(user_features: np.ndarray) -> str:
    factual = explainer.explain_factual(user_features.reshape(1, -1))
    lines = []
    for rule in factual[0].as_json()["rules"]:
        direction = "increases" if rule["weight"] > 0 else "decreases"
        weight_pct = f"{abs(rule['weight']):.0%}"
        lines.append(
            f"Because {rule['feature']} = {rule['value']}, "
            f"this recommendation {direction} in relevance by {weight_pct}."
        )
    return "\n".join(lines)
```

**e) Audit documentation:** Log which explanation template version was displayed to
which user and when. For VLOPs, this log may be subject to independent audit by a
Digital Services Coordinator (Art. 37).

---

### 6.3 Art. 35 -- Systemic Risk Mitigation (VLOPs and VLOSEs)

**a) Title (verbatim):** Article 35 -- Mitigation measures

**b) Core obligation:** VLOPs and VLOSEs must put in place proportionate mitigation
measures for specific systemic risks identified in their risk assessment, including
measures targeting algorithmic amplification of harm (Art. 35(1)(d)).

**c) How `calibrated_explanations` contributes:** Mondrian conditional calibration
measures per-user-segment whether model confidence and output distributions differ
between groups -- a quantitative basis for both the risk assessment and the mitigation
evidence documentation.

**d) Code:**

```python
import numpy as np

group_labels = user_segment_labels   # e.g., age group, region, platform tenure

probs, (low, high) = explainer.predict_proba(
    X_users, uq_interval=True, bins=group_labels
)
widths = high[:, 1] - low[:, 1]

print("Systemic risk indicator: per-segment prediction interval widths")
for group in np.unique(group_labels):
    mask = group_labels == group
    print(f"  Segment {group!r}: mean width = {widths[mask].mean():.3f}, "
          f"n = {mask.sum()}")
```

**e) Audit documentation:** Include the per-segment uncertainty analysis in the
annual systemic risk assessment document (Art. 34). Publish a summary in the
transparency report required by Art. 42.

---

## 7. Equal Treatment Directives

### 7.1 Applicable Directives

| Directive | Protected grounds | Domain |
|---|---|---|
| Directive 2000/43/EC (Race Equality) | Racial or ethnic origin | Employment, education, social protection, housing, goods and services |
| Directive 2000/78/EC (Employment Equality) | Religion, belief, disability, age, sexual orientation | Employment and occupation |
| Directive 2006/54/EC (Gender Equality) | Sex, including gender reassignment | Employment and occupation |

All three directives prohibit both **direct discrimination** and **indirect
discrimination** -- an apparently neutral criterion that puts a protected group at
a particular disadvantage without objective justification (Art. 2(1)(b) in each).

### 7.2 How `calibrated_explanations` Contributes

Mondrian conditional calibration provides the primary analytical tool:

- **Per-group prediction distributions:** `predict_proba(bins=group_labels)` reveals
  whether predicted probabilities are systematically different across groups.
- **Per-group uncertainty:** Wider intervals for a protected group indicate reduced
  reliability -- a direct quantitative indicator of indirect adverse impact.
- **Per-group feature importance:** `explain_factual(bins=group_labels)` identifies
  whether different features drive predictions across groups, the first step in
  detecting proxy discrimination.

### 7.3 Code

```python
import numpy as np
from scipy import stats

protected_labels = x_val[:, protected_feature_idx]
probs, (low, high) = explainer.predict_proba(x_val, uq_interval=True)

# Step 1: Compare outcome distributions across protected groups
for group in np.unique(protected_labels):
    mask = protected_labels == group
    print(f"Group {group!r}: mean P(positive) = {probs[mask, 1].mean():.3f}")

# Step 2: Statistical test for differential impact
groups = np.unique(protected_labels)
if len(groups) == 2:
    g0 = protected_labels == groups[0]
    g1 = protected_labels == groups[1]
    _, p = stats.ttest_ind(probs[g0, 1], probs[g1, 1])
    if p < 0.05:
        print(f"WARNING: significant outcome disparity (p={p:.4f}) -- "
              "indirect discrimination risk.")

# Step 3: Per-group interval width as reliability disparity metric
widths = high[:, 1] - low[:, 1]
for group in np.unique(protected_labels):
    mask = protected_labels == group
    print(f"Group {group!r}: mean interval width = {widths[mask].mean():.3f}")

# Step 4: Mondrian factual explanation -- identify proxy features per group
factual = explainer.explain_factual(x_val, bins=protected_labels)
# Review factual[i].as_json() for group-specific feature importance patterns
```

### 7.4 Objective Justification Documentation

If disparate outcomes are detected, the Equal Treatment Directives permit the
practice only if *objectively justified by a legitimate aim* and the means are
*appropriate and necessary*. The factual rule table demonstrates:

- **Necessity:** The feature has meaningful predictive weight (the rule table weight
  and its uncertainty interval are both substantial and non-zero).
- **Proportionality:** The feature contribution is bounded and does not overwhelm all
  other relevant features in the rule table.

Document this justification in the DPIA (Art. 35 GDPR) and, for employment contexts,
in the AI Act technical documentation.

### 7.5 Audit Documentation

Run the indirect discrimination analysis (a) before model deployment,
(b) after every model update, and (c) annually as part of ongoing monitoring.
Retain results alongside the model version, calibration set, and Mondrian bin
definitions. The burden of proof shifts to the defendant in a discrimination claim
once the claimant establishes a *prima facie* case of disparate impact.

---
## 8. Cross-Regulation Compliance Checklist

| Regulation | Provision | CE feature / method | Status |
|---|---|---|---|
| GDPR | Art. 5(2) Accountability | `as_json()` per-decision audit log | **Covered** |
| GDPR | Arts. 13-14 Logic description in privacy notice | `explain_factual` / `print_rules()` | **Covered** |
| GDPR | Art. 15 Right of access | Accountability log + `data_subject_ref` retrieval | **Covered** |
| GDPR | Art. 17 Right to erasure | `data_subject_ref` deletion from log | **Partially covered** -- model unlearning requires separate tooling |
| GDPR | Art. 21 Right to object | Factual explanation as compelling-grounds documentation | **Covered** |
| GDPR | Art. 22 Automated decision safeguards (human intervention, express view, contest) | `predict_proba` gate + `explain_factual` + `explore_alternatives` | **Covered** |
| GDPR | Art. 25 Data protection by design | Feature utility analysis for data minimisation | **Covered** |
| GDPR | Art. 35 DPIA technical annex | Uncertainty summary + per-group Mondrian analysis | **Covered** |
| PLD 2024 | Art. 9(4) On-demand technical disclosure | `as_json()` payloads + disclosure package function | **Covered** |
| AI Liability Dir. (proposed) | Arts. 3-4 Disclosure and causality presumption | `as_json()` retention; AI Act compliance defeats presumption | **Covered** |
| DSA | Art. 26 System-level parameter transparency | Aggregated feature-weight statistics from `explain_factual` | **Covered** |
| DSA | Art. 27 Per-user explanation at time of recommendation | `explain_factual` per user-item pair + `print_rules()` | **Covered** |
| DSA | Art. 35 Systemic risk mitigation | Mondrian per-segment interval analysis | **Covered** |
| Equal Treatment Dirs. | Art. 2(1)(b) Indirect discrimination analysis | Mondrian group-prediction analysis + statistical tests | **Covered** |
| Equal Treatment Dirs. | Objective justification documentation | Factual rule table as necessity / proportionality evidence | **Covered** |

---

## 9. Limitations and Gaps

### 9.1 Model Unlearning / Right to Erasure of Training Data (GDPR Art. 17)

GDPR Art. 17 may require erasure not only of inference-time records but also of the
contribution of a specific individual's data to the trained model.
`calibrated_explanations` operates solely at inference time and has no mechanism for
model unlearning. **Required:** Machine unlearning tooling (selective retraining,
certified data removal algorithms) combined with a data lineage system that tracks
which training instances influenced which model version.

### 9.2 Legal Basis for Processing (GDPR Art. 6)

`calibrated_explanations` does not determine whether processing has a valid legal
basis. **Required:** Legal counsel review of GDPR Art. 6 conditions (consent,
contract, legitimate interests, legal obligation) for each use case, documented in
the DPIA.

### 9.3 Data Subject Request Workflow Infrastructure (GDPR Arts. 15, 17, 21)

Retrieving, rendering, and delivering records within the one-month deadline requires
workflow infrastructure beyond a log file. **Required:** A SAR management system
(ticketing, identity verification, deadline tracking, and secure delivery).

### 9.4 Medical Device Regulation (MDR, Regulation (EU) 2017/745)

AI systems embedded in medical devices are additionally subject to the MDR, which
requires clinical evaluation, a post-market clinical follow-up plan, and notified
body certification for class IIb/III devices. `calibrated_explanations` provides
explanation and uncertainty artefacts for the technical file, but MDR compliance
requires a certified quality management system (ISO 13485) and regulatory affairs
processes.

### 9.5 Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554)

Financial entities subject to DORA must manage ICT risk, including AI model risk,
within a formal ICT risk management framework. `calibrated_explanations` provides
model-level uncertainty quantification relevant to the risk tolerance assessment, but
DORA requires institution-level ICT governance, incident reporting, and third-party
risk management that are organisational responsibilities.

### 9.6 Systemic and Emergent Risk (DSA Art. 34)

Per-instance explainability does not directly reveal emergent phenomena such as
recommendation monocultures, filter bubbles, or adversarial content amplification at
scale. **Required:** Population-level simulation studies and external auditor access
under DSA Art. 37.

### 9.7 Data Governance Act and Data Act

The Data Governance Act (Regulation (EU) 2022/868) and Data Act (Regulation (EU)
2023/2854) impose obligations on data intermediaries and data sharing that may affect
training data provenance. **Required:** Data governance tooling covering data lineage,
consent management, and contractual data-sharing obligations.

### 9.8 Cybersecurity and Adversarial Robustness

Neither GDPR's security obligation (Art. 32) nor the PLD defect standard are
satisfied by explanation quality alone. **Required:** Adversarial robustness testing
(e.g., Adversarial Robustness Toolbox) and network / access controls protecting the
model serving endpoint.

---

## 10. References

### GDPR

- Regulation (EU) 2016/679 of the European Parliament and of the Council of
  27 April 2016 on the protection of natural persons with regard to the processing
  of personal data (General Data Protection Regulation).
  <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679>
- European Data Protection Board (EDPB), Guidelines 05/2020 on consent under the
  GDPR, Version 1.1.
- Article 29 Working Party, Guidelines on Automated individual decision-making and
  Profiling for the purposes of Regulation 2016/679 (WP251rev.01).

### Product Liability Directive

- Directive (EU) 2024/2853 of the European Parliament and of the Council of
  23 October 2024 on liability for defective products.
  <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202402853>

### AI Liability Directive (Proposed)

- European Commission, Proposal for a Directive on adapting non-contractual civil
  liability rules to artificial intelligence (AI Liability Directive),
  COM/2022/496 final.
  <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52022PC0496>

### Digital Services Act

- Regulation (EU) 2022/2065 of the European Parliament and of the Council of
  19 October 2022 on a Single Market for Digital Services.
  <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022R2065>

### Equal Treatment Directives

- Council Directive 2000/43/EC of 29 June 2000 implementing the principle of equal
  treatment between persons irrespective of racial or ethnic origin.
  <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32000L0043>
- Council Directive 2000/78/EC of 27 November 2000 establishing a general framework
  for equal treatment in employment and occupation.
  <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32000L0078>
- Directive 2006/54/EC of the European Parliament and of the Council of 5 July 2006
  on the implementation of the principle of equal opportunities and equal treatment
  of men and women in matters of employment and occupation.
  <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32006L0054>

### Calibrated Explanations

- Lofstrom, H., Lofstrom, T., Johansson, U., and Sonstrod, C. (2024).
  Calibrated Explanations: with Uncertainty Information and Counterfactuals.
  Expert Systems with Applications. DOI: 10.1016/j.eswa.2024.123154
- Lofstrom, T., Lofstrom, H., Johansson, U., Sonstrod, C., and Matela, R. (2024).
  Calibrated Explanations for Regression.
  Machine Learning. DOI: 10.1007/s10994-024-06642-8
- Lofstrom, H., Lofstrom, T., Johansson, U., Sonstrod, C., and Bostrom, H. (2024).
  Conditional Calibrated Explanations: Finding a Path Between Bias and Uncertainty.
  DOI: 10.1007/978-3-031-63787-2_17
- Repository: https://github.com/Moffran/calibrated_explanations