Regulation is often treated as a paperwork layer sitting on top of the “real” system. In practice, the systems that pass audits comfortably are the ones where the requirements were understood by the people who built them. My work in this field is to translate law into architecture — and to make sure the evidence the regulator wants is produced automatically by the way the system operates.
Why this matters now
The Digital Operational Resilience Act has applied to financial entities and their critical ICT providers since January 2025, and the supervisory focus has moved from policies to demonstrable practice: contract registers, tested recovery, incident timelines, concentration risk. At the same time, the EU AI Act phases in obligations for providers and deployers, and the question of where European data may legally and practically live has become a board-level topic rather than an IT preference.
Organisations outside financial services feel this too. Public bodies, research institutions and Mittelstand companies face procurement rules, funding conditions and customer contracts that increasingly demand sovereign hosting and provable data integrity.
How I approach it
I read the regulation and I read your architecture, then I map one onto the other. For each obligation we decide whether it is met by design, by a control, or by documentation — and we prefer them in that order. Sovereignty is treated as an engineering property: data flows are inventoried, jurisdictions are made explicit, exit paths are designed before a contract is signed.
Data integrity gets specific attention because AI systems amplify it: a corrupted or manipulated source document does not just produce a wrong record, it produces confident wrong answers at scale. Lineage, verification and immutability controls are therefore part of every AI architecture I recommend.
Where it typically starts
A gap assessment of one system or one domain, four weeks, with a prioritised remediation plan. Many clients then keep me on an advisory basis for vendor evaluations, contract reviews and the recurring questions that come with every new AI use case.
Questions I am usually asked
- We use a US hyperscaler for our AI workloads. Is that still defensible, and what are the alternatives?
- What does DORA actually require from our engineering teams, beyond the policy documents?
- How do we prove that the data our models were trained on and answer from has not been tampered with?
- Which of our AI use cases fall under the AI Act, and what do we need to document?
- How do we avoid vendor lock-in without building everything ourselves?
Typical deliverables
- Gap analysis mapped to DORA articles and AI Act obligations
- Sovereignty and hosting target picture with exit strategies
- Data integrity control design and evidence architecture
- Documentation set that engineers maintain and auditors accept
- Register of third-party ICT dependencies with risk classification