1. Why a DPIA
ABN performs automated analysis of business processes and produces agent-generated proposals. A DPIA is conducted under Article 35 GDPR because the processing involves systematic evaluation of personal aspects and automated decision support. This DPIA documents that — by architecture — the residual risk to data subjects is low.
2. Description of the processing
- Nature: the Observer Layer ingests business events; the Process Graph Engine discovers process structure; the Agent Engine runs the OPERA loop and produces findings/proposals.
- Scope: runs entirely inside the customer's local Node.
- Context: ABN is a processor; the customer is the controller.
- Purposes: detect deviations, gaps and savings; deliver reports.
3. Necessity and proportionality
- Lawful basis: determined by the controller (typically legitimate interest, Art. 6(1)(f)).
- Data minimisation (Art. 5(1)(c)): per-(connector, resource) field allowlists discard everything not strictly needed; direct identifiers are blocked before memory.
- Storage limitation: retention is controller-configured.
- Purpose limitation: data is used only for the configured agents.
4. Automated decision-making (Art. 22)
V1 is propose-only. TIER 1 outputs are read-only insights. TIER 2 ("PROPOSE_CHANGE") proposals require approval by a named human employee before any effect — this is enforced in the product (human-in-the-loop). TIER 3 ("EXECUTE_CHANGE") is disabled in V1.
Therefore ABN does not carry out a decision "based solely on automated processing" producing legal/similarly significant effects on data subjects within the meaning of Art. 22(1). The human approval step is a genuine, documented, reversible control.
5. Risk assessment
| # | Risk | Likelihood | Severity | Mitigation |
|---|---|---|---|---|
| R1 | Personal data leaks to an LLM provider | Low | High | No-Data LLM Gateway — PII scrub → tokenise → abstract; only schema/tokens leave; reverse map stays on the Node |
| R2 | Personal data leaves the customer environment | Very low | High | Local execution — every engine runs on the Node; ABN holds no copy; audit log proves sent_outside = 0 |
| R3 | Re-identification from stored data | Low | Medium | SHA-256 pseudonymisation; direct identifiers never stored; fingerprints are one-way |
| R4 | An agent acts wrongly on a deviation | Low | Medium | Human-in-the-loop approval (Art. 22); Culture Rules; max 2 retries |
| R5 | Unauthorised access to the Node | Low | High | mTLS, RBAC, write-guard, Firecracker sandbox, encryption at rest |
| R6 | Untraceable processing | Very low | Medium | Customer-owned transparency tables + HMAC-signed cycle attestations — every action is independently verifiable |
| R7 | Excessive data collected | Low | Medium | Data Minimizer allowlists; DPIA reviewed when a connector is added |
6. Residual risk and conclusion
After mitigations, residual risk to data subjects is assessed as low. The dominant controls — local execution, the No-Data LLM Gateway and human-in-the-loop approval — are enforced by architecture, not policy, and are therefore not bypassable by configuration error. Prior consultation with the supervisory authority (Art. 36) is not required. This DPIA is reviewed when processing materially changes (new connector, new agent tier, or V2 EXECUTE_CHANGE).
7. Sign-off
| Role | Name | Date |
|---|---|---|
| Data Protection Officer (or equivalent) | […] | […] |
| Controller representative | […] | […] |