What GDPR, NIS2, DORA and the EU AI Act Ask of a System That Acts
Read the four regimes that matter to a UK or EU finance or legal firm for what they ask of a system that acts, not one that stores, and they converge on one demand: the record of what the workflow did, produced as it did it.
The regulatory landscape for AI looks like a stack of separate obligations: a data-protection regulation, a cybersecurity directive, an operational-resilience act, an AI act, a patchwork of national regimes. Read each one for what it asks of a system that acts, rather than a system that stores, and the stack collapses into a single demand. Explain the decision. Report the incident inside the window. Show the human could have stopped it. Say which version was running. None of these asks for a compliance score. Each asks for the record.
This is the regulatory strand of the wider argument in configured is not controlled. The point of reading the regimes this way is not to summarise them, which qualified counsel should do for your firm, but to derive the system properties they imply, so you can build the thing that satisfies them rather than document the thing that does not.
GDPR: the question is reconstruction, not permission
The General Data Protection Regulation remains the reference point, and the UK GDPR keeps its structure. For an agentic workflow the articles that matter are not the ones about storage and transfer, which the estate already handles, but the ones about automated decision-making.
Article 22 gives an individual the right not to be subject to a solely automated decision, and a right to human review. The estate's answer is a policy stating where human review applies. The workflow's answer is that human review is a step with authority to change the outcome, and the record shows it happened. Articles 15 to 22 give data subjects rights over their data; for an automated decision about a person, satisfying them means the firm can produce the basis of that decision: the inputs used, the options considered, the outcome and the human involvement. The 72-hour breach notification under Article 33 assumes the record can be filtered by input, source or time to say which decisions were affected, within the window.
The shift is from documenting that automated decisions are reviewed to being able to show, for this individual and this decision, what happened. A decision record emitted at execution satisfies both. A policy that says decisions are reviewed satisfies only the first.
NIS2 and DORA: resilience with a clock on it
NIS2 widens cybersecurity obligations and puts accountability on management bodies. DORA does the same for financial entities, with ICT risk management, incident reporting, resilience testing and third-party oversight as its pillars. Both come with reporting windows measured in hours: a twenty-four-hour early warning under NIS2, a one-month final report, and an initial notification for a major ICT-related incident under DORA by classification.
Those windows assume the firm can say, quickly and specifically, what happened. Incident classification under DORA depends on how many clients were affected and for how long, which means the record has to count affected cases, not merely detect that something happened. The final report cannot be written from telemetry alone; it has to say what the system decided. And both regimes treat a model provider, an orchestration layer and a monitoring tool as three suppliers whose versions in production on the day are facts the firm must be able to state. A workflow you own, with a swappable model pinned by version underneath, has a much shorter answer to the third-party question than one you rent.
The EU AI Act: Articles 10 to 15 as an engineering specification
The AI Act classifies systems by risk and imposes obligations on high-risk ones that read like a specification. The finance and legal use cases most likely to be classified high risk include creditworthiness assessment and life and health insurance pricing. Even where a workflow is not high risk, the obligations describe good practice, and a supervisor under another regime will recognise them.
- Article 10, data governance. Approved input sources named in the workflow contract; anything else is refused, not discouraged.
- Article 12, record-keeping. The decision record is emitted by the step that decides: question, options, distribution, confidence, model and option-set versions, approver, timestamp.
- Article 13, transparency. Typed decisions over a bounded option set, not free text someone has to interpret.
- Article 14, human oversight. Escalate and abstain are options in the set; thresholds route to a named reviewer with authority, and the record shows what the review changed.
- Article 15, accuracy and robustness. An evaluation gate against the process it replaces before the workflow runs alone, drift monitored after, and input filtering against manipulation.
Every article has a workflow property that satisfies it. Build the property, and the documentation follows.
The UK and the rest of EMEA arrive at the same place
The UK sits outside the AI Act, but its supervisors have reached similar expectations by another route, and most UK firms are in scope of the EU regimes through clients, group structures or services. The PRA's model risk management principles treat AI models as requiring inventories, validation and monitoring with senior accountability; a typed decision with an evaluation gate and drift metrics is a model with a validation record attached. The FCA's Consumer Duty asks whether outcomes were good, not whether a process was followed, which is answerable only from a record of what was decided for whom. The SRA expects a firm to supervise the work its systems produce as it would a person's. National regimes across EMEA, Saudi Arabia's PDPL, South Africa's POPIA, the UAE's federal law, follow the GDPR's shape with local residency expectations: for the workflow, that means the record of what was decided about a person has to exist, be retrievable, and stay in the jurisdiction the data belongs to.
One demand, many vocabularies
The reason this matters now is that regulation is moving in one direction across every regime that touches a UK or EU finance or legal firm: from documented controls to demonstrated ones, from periodic audits to continuous evidence, and from accountability for the system to accountability for what the system did in a specific case. A firm that can render its model cards, impact assessments and monitoring from a workflow's own state meets each new mandate as a reporting change rather than a rebuild.
Templates map the rule to a control. The rule is asking for the record. The mechanism that produces it, the typed decision, is in text is not a decision, and the record itself is in the decision record.
Regulatory summaries here are an engineering reading for the purpose of deriving system properties, not legal advice, and regulatory interpretation in any jurisdiction should be confirmed with qualified counsel. The framing is drawn from the Rob-otix Ai field note "Configured is not controlled" (2026).