Custom AI for the DPO: how we ship AI that survives a DPIA, an audit, and a rights request.

Almost always, yes. AI systems that involve systematic large-scale processing, special-category data, profiling, or automated decisions with legal or similarly significant effects trigger Article 35 by default. We assume DPIA is in scope and draft the pack in Discovery, so by the time Build phase begins you have a DPIA your supervisory authority can review. Where the processing turns out not to trigger Article 35, the same document set serves as a written record of the analysis, which is itself best practice under the EDPB guidelines.

Every system we build is designed so that an SAR can be answered from the audit log without forensic archaeology. The log captures every interaction involving personal data, including the input, the retrieved context, the model version, and the output. For erasure, the system supports targeted deletion by data-subject identifier across the storage layers, with the foundation-model provider's no-retention posture documented. For rectification, the upstream system of record is the source of truth, and the AI re-runs against the corrected record. For Article 22 contestation, the human-review surface is exposed as a first-class workflow with the reasoning trail attached.

Our current sub-processor list is published at impetora.com/sub-processors and updated when it changes. For any specific engagement, you receive an engagement-specific sub-processor register at DPA signing, covering every party that processes personal data on the project, the data category each one processes, the residency, the legal basis, and the transfer mechanism (SCCs or adequacy). When the list changes during the engagement, you are notified under contract with sufficient lead time to object.

By default, we deploy on EU regions and contract with foundation-model providers on EU-resident inference where the provider supports it. Where personal data has to leave the EEA, we put SCCs in place, run a transfer impact assessment under Schrems II logic, and document the supplementary measures. Where adequacy is available (UK, Switzerland, several others), we use it. Cross-border posture is documented in the DPIA and refreshed when the regulator's guidance changes.

AI Act Article 10 requires high-risk systems to use training, validation, and testing datasets that are relevant, representative, free of errors, and complete to the extent possible, with documented data-governance practices covering design choices, data collection, annotation, and bias mitigation. Where we fine-tune or build retrieval pipelines on your data, we maintain the documentation Article 10 expects: provenance, processing operations, assumptions, availability, and known limitations. Where we use a foundation model, we rely on the provider's documented Article 10 posture and capture it in the regulator-pack.