Configured Is Not Controlled: The Workflow Is Where the Audit Question Lands

Regulated firms across the UK and the EU have spent a decade moving security and compliance from policy to platform. Identity is enforced by an identity provider, not a handbook. Endpoints are protected by an agent, not an instruction. Retention is a rule the system applies, not a guideline staff remember. Control mapping has become a dashboard: a score that says whether the estate is arranged the way the regulation expects. That work was necessary, and for most firms it is substantially done.

Then the same firms started putting agents on that estate. Cloud-connected systems now read client files, choose categories, draft communications, call tools and route cases. The consequential decision has moved inside the workflow, at runtime, into a component that composes its own actions from what it is given. And a compliance score cannot see it.

A score is a measure of configuration. It answers whether the estate is set up correctly. It cannot answer what a workflow did: which source an agent relied on, which rule fired and which version of it, what the option set was and what the model chose, what the confidence was and where the threshold sat, who approved the consequential step and whether they could have refused. Those are the questions GDPR, the NIS2 Directive, DORA and the EU AI Act each ask in their own vocabulary, and the questions a supervisor asks after an incident.

You can download the full field note as a PDF, or read the argument below.

Configuration is a solved problem. Behaviour is the one you are about to be asked about.

There are two layers, and they are different kinds of thing. The estate is the platform: identity, endpoint protection, data classification, residency, control mapping. It is procured, configured and scored, owned by security and IT, and it changes on the vendor's cadence. The workflow is what runs on top: the approved inputs, the typed decisions, the deterministic checks, the human checkpoints, the escalation paths. It is owned by the business function whose process it is, built rather than bought, and it changes when the business changes.

A control-mapping dashboard can tell you the identity provider was configured correctly when the agent ran. It cannot tell you what the agent did with the access. That is not a gap in any product; it is a different kind of thing, and it has to be built into the workflow by whoever builds the workflow, from the first run, because it cannot be added to a decision after the decision was made.

The rule is asking for the record, not the score

Read each regime for what it asks of a system that acts, rather than one that stores, and they converge. GDPR already gives an individual the right to an explanation of, and to object to, an automated decision. NIS2 shortens incident reporting to a twenty-four-hour early warning and puts accountability on management bodies. DORA makes ICT risk a board matter and requires model and third-party dependencies to be identified and reportable. The EU AI Act's Articles 10 to 15 read, to an engineer, like a specification: data governance, record-keeping, transparency, human oversight, robustness.

None of them ask for a compliance score. Each asks, in its own words, for evidence of what the system did, produced at the time it did it, by a process someone is accountable for. We translate the four regimes into workflow properties, article by article, in what GDPR, NIS2, DORA and the EU AI Act actually ask of a system that acts.

Text is not a decision

Most AI in a workflow is asked to write. Most of the value in a workflow comes from choosing. Those are not the same operation and should not be the same component. A model that writes hands you prose to interpret. A model that decides should hand you a choice from options you defined, with a probability on each and a confidence on the answer, as a record rather than a paragraph in a log.

The most important property is the one the model never sees: the application decides what the allowed answers are. A model update cannot add a fifth option to a four-option decision. Abstain and escalate are options in the set, not error states, so an agent that is unsure has somewhere defined to send the case. This is the spine of the controlled workflow, the eight stages that make a method repeatable, and we set it out in text is not a decision: the typed decision and the controlled workflow.

Evidence as a side effect of running

The handoffs in regulated work do not wait for judgement. They wait for evidence that the upstream step was done correctly, by an authorised person, against an approved source, at a known time. We call it the proof tax, and it is the same tax we describe from the workflow side in who owns the wait?. An agent dropped into that workflow without a record does not remove the tax; it moves it, and makes the wait longer, because the reviewer now has a paragraph to go on instead of a colleague to ask.

The fix is to design for verification, not generation. Every consequential step emits its record as a side effect of executing: source, rule, option set, distribution, confidence, approver, versions, timestamp. Nobody writes it up afterwards, and nobody can forget to. On our harness, Fulcrum, those records collect into an Ed25519-signed evidence bundle an auditor verifies offline, on a laptop with the wifi off. That is also how you report an incident inside a seventy-two-hour window instead of reconstructing it for a month. The record, the delegation envelope that applies Zero Trust to the agent's actions, and the provenance graph underneath are in the decision record: evidence as a side effect of running.

Where to start

You do not ban shadow AI; you outcompete it. The sanctioned route has to be better than the browser tab: faster, on the firm's own documents, with the record attached. Keep every decision and anything touching client-identifiable data inside the perimeter; let the token-heavy drafting run on a pinned, no-training endpoint; send only public material to general tools, and let the workflow do the routing by data class rather than asking a person to choose.

Then build one workflow end to end, prove it against the process it replaces on real volume, and leave the foundation behind for the next. This is the same embedded applied-AI shape as stop buying agents: assess in a fortnight, build inside your stack, prove through an evaluation gate, and hand over software you own.

Have an AI workflow the compliance dashboard is green on? Bring it. We will show you what the dashboard cannot see, build the controlled version inside your stack with the record attached, and leave you owning it. Download the field note, or send us the workflow.

The framing, the regulatory readings and the engineering properties are drawn from the Rob-otix Ai field note "Configured is not controlled: a blueprint for cyber resilience and evidence in the agentic era" (2026). Regulatory summaries are an engineering reading for the purpose of deriving system properties, not legal advice.