The Risk You Can’t Outsource
Harvard Business Review put it plainly this summer: you outsourced the AI, but you still own the risk. The sentence lands because it corrects a comfortable assumption. When an enterprise buys a model, contracts a vendor, or embeds a third-party agent into a regulated process, it feels as though responsibility has moved with the work. It has not.
Accountability does not transfer with a procurement contract. The model provider owns the model. The systems integrator owns the delivery. But the firm running the process owns the outcome, the control failure, and the regulatory finding. When a supervisor asks who is accountable for an AI-embedded decision that went wrong, the answer is the regulated entity, not its supplier.
This is the reframe that changes what Risk and Compliance functions must build. The question is no longer “can we trust the vendor?” It is “can we evidence control over the process the vendor now touches?” Those are different questions, and only one of them will be tested in an audit.
The Regulatory Stack Is Hardening, Now, Not Later
For the past two years, the prevailing narrative treated AI regulation as a distant horizon: a delay to plan around, a window that stayed open. That framing is now out of date. Across jurisdictions, the obligations are converging and the timelines are contracting.
In the EU, legal analysts at firms including Pinsent Masons and Wilson Sonsini report that the high-risk system guidelines and the transparency code of practice are finalising rather than slipping. Firms deploying AI in high-risk contexts should read this as the obligations moving from principle to specification: the detail of what deployers must document and demonstrate is being written down now. We treat the specifics of these instruments as source-attributed rather than settled law, and Risk functions should confirm current status with counsel. The direction of travel, however, is not ambiguous. For a deeper treatment of what the Act expects deployers to be able to show, see our analysis of EU AI Act evidence requirements.
The UK picture reinforces the point rather than diverging from it. The FCA continues to emphasise operational resilience, product and process design, and the supervision of Critical Third Parties. The DORA-aligned scrutiny of third-party dependency, familiar to any financial services firm with EU exposure, is widening the set of relationships that fall under formal resilience obligations. The AI a firm depends on is increasingly a third-party dependency in the regulatory sense, with everything that classification implies for testing, documentation, and impact tolerance.
Read together, these developments describe a single shift. Regulators across the EU and UK are moving from asking whether firms have policies to asking whether firms can demonstrate that controls operate as described, on processes that now include AI. This is not a reason for alarm. Supervisors reward firms that can show their work. It is a reason to build the capability to show it before the obligation is tested.
The Common Denominator: You Can’t Govern What You Can’t Describe
Strip the jurisdictions and the acronyms away, and every one of these regimes asks the same underlying question. Can you demonstrate control over the AI-touched process? Not the model in isolation. The process: the sequence of steps, decisions, and handoffs in which the AI participates and through which a business outcome is produced.
This is where a great deal of governance investment quietly rests on an unstated assumption. Governance-as-code enforces rules against a process, but only a process that has been described. AI observability tools monitor execution and flag drift, but only against a baseline of what execution was supposed to look like. Both capabilities are valuable. Neither creates its own object of control. They presuppose a documented, articulated process to govern and to observe.
Most enterprises do not have that. Their processes live in a mixture of policy documents that describe intent, system logs that capture fragments of execution, and the tacit knowledge of the people who run the work. The AI-embedded process, in particular, is often the least documented of all, because it was deployed as a pilot, bolted onto an existing workflow, and never formally modelled. The gap between the process on paper and the process in practice is exactly where operational risk lives. Introduce an AI agent into that gap and you have both an execution liability and a compliance exposure in the same place.
An undocumented process cannot be governed, because there is nothing for the governance layer to enforce against. It cannot be observed meaningfully, because there is no articulated baseline to observe against. And it cannot be defended to a regulator, because there is no artefact to present. The articulated process is the precondition for all three.
Process Articulation as Compliance Infrastructure
Articulation is not the same as documentation. A procedure manual documents intent. Articulation, in the sense that matters here, means four things held together: documentation of how the process actually executes, the governance metadata that shows who owns each step and what controls apply, the provenance that records where the process model came from and how it has changed, and the audit-readiness that turns all of it into evidence a supervisor will accept.
This is the layer IGX360 Insights provides. Where governance tooling enforces and observability tooling watches, IGX360 supplies the substrate both require: the articulated, enriched process against which control can be demonstrated. Our Insights lenses apply risk, compliance, and resilience views over the process model, so a Risk function can see where AI participates, which controls sit at each point, and where human authority is preserved. An opaque AI-embedded workflow becomes an auditable, defensible control surface.
The practical consequence is that the artefact you present to a regulator already exists, enriched and current, rather than being assembled under deadline pressure during a review. For Risk and Compliance leaders, this is the difference between a resilience posture that is asserted and one that is evidenced. IGX360 is built for risk leaders who have to answer for AI-embedded processes they did not design and cannot fully see.
Closing: Evidence Beats Assurance
Assurances do not survive an audit. A vendor’s certification, a policy statement, a board attestation that the AI is well governed: these are assurances, and a supervisor testing a control does not accept assurance in place of evidence. Evidence is the articulated process, the enrichment that shows the controls, and the record that shows they operated. This is as true for compliance teams preparing for review as it is for the risk function that owns the exposure.
The obligations are finalising now, not later. The firms that will answer supervisory questions calmly are the ones that articulate their AI-embedded processes before the obligation bites, not during the review that follows a failure. Are you building the evidence a regulator will ask for, or preparing to explain why you cannot produce it?