Data Protection Impact Assessment (DPIA)

1. Controller

• Legal entity: <lender legal name>
• Data Protection Officer: <DPO name + email>
• Establishment: <EU member state of main establishment>
• Processor: Marvin (vendor) — see Article 28 data-processing agreement on file.

2. Description of the processing

Marvin assists the controller's credit officers in producing an affordability assessment for consumer-credit applicants. The processing covers:

• Categories of data: applicant identifiers (name, contact); financial information (income, existing debt, credit-bureau records); employment status; loan request; uploaded supporting documents (payslips, contracts, ID copies as configured by the controller).
• Sources: applicant submission via the controller's intake; ЦКР (national credit registry); НОИ (Bulgarian social-security income); sanctions / PEP screening lists; the controller's internal corpus (policies, methodology, product matrices).
• Operations: structured analysis by five AI agents (Compliance, Underwriter, Quant, Orchestrator, Marvin meta-observer) producing four dossiers and a draft affordability memo, all reviewed by a named human officer before any communication to the applicant.
• Retention: <retention period set by controller, default 7 years> for decision records; immutable hash chain ondecision_audit_log beyond the deletion date for forensic reproducibility.

3. Purpose & lawful basis

• Purpose: compliance with the controller's affordability-assessment obligations under CCD2 / EBA-GL-2020-06, and the controller's legitimate interest in efficient, explainable credit decisions.
• Lawful basis (Article 6): performance of a contract or pre-contractual measures requested by the data subject (Art. 6(1)(b)); compliance with a legal obligation to which the controller is subject (Art. 6(1)(c)); and the controller's legitimate interest where applicable (Art. 6(1)(f)).
• Special-category data: none processed directly. If documents uploaded by the applicant inadvertently contain special-category data, the controller's intake flow redacts on receipt before any AI processing.

4. Necessity & proportionality

Each agent operates under a published runtime-tunable allowlist that restricts the corpus passages it can read; the system cannot consult information outside its allowlist. Field-level data minimisation is enforced: the orchestrator passes only summary verdicts between agents, not full applicant records. The deterministic conflict tree resolves disagreements mechanically; the LLM cannot override the tree.

5. Risks identified

• Erroneous decision: the system produces a wrong outcome that materially affects the applicant.
• Bias / discrimination: systematic skew across protected attributes the controller's data captures or proxies.
• Hallucinated reasoning: the LLM cites a regulation or policy section that doesn't exist or is mischaracterised.
• Confidentiality breach: applicant data leaks via prompt logging, third-party model providers, or a compromised admin account.
• Inability to reproduce a decision: a regulator asks "show me how this March-2026 case was decided" and the version pins or audit trail are insufficient.

6. Mitigations

• Human-in-the-loop: every Marvin outcome is reviewed by a named officer; conditioned approvals require four-eyes sign-off. See the Article 22 statement.
• Citation grounding: every chunkId a Marvin agent cites is verified to exist in the controller's knowledge corpus before the dossier is persisted; hallucinated references reject the dossier.
• Per-decision version pinning: every decision row carries model_id, prompt_set_hash, retrieval_index_version, and methodology_version — regulator can reproduce the exact context of any historical decision.
• Append-only audit log with per-session SHA-256 hash chain. UPDATE / DELETE / TRUNCATE blocked by Postgres trigger.
• Kill switch: the controller's admin can roll back the prompt set with one click; rollbacks are themselves audit-logged with hash chain.
• Backtest calibration: Brier score, expected calibration error, and reliability diagram measured on every eval run — the controller can detect drift before regulators do.
• Sub-processor disclosure: Marvin uses <LLM provider> and <embedding provider>; the data-processing agreement enumerates them and the contract terms.

7. Residual risk & sign-off

• Residual risk rating: <low | medium | high> after mitigations.
• DPO opinion: <DPO consultation outcome — Article 35(2)>
• Supervisory authority consultation: <required if residual risk is high (Article 36); document outcome>
• Approved by: <controller-side approver name + role>
• Date: <YYYY-MM-DD>
• Review schedule: annually, or upon any material change to the system documented in MODEL_CARD.md.

This template is a starting point, not legal advice. The controller is responsible for the DPIA's content and adoption. Update the highlighted blanks, have the DPO review, and retain the executed copy in the controller's compliance file.