Own the Risk, Own the Evidence
Harvard Business Review put it plainly this summer: you outsourced the AI, but you still own the risk. The sentence corrects a comfortable assumption. When an enterprise buys a model, contracts a vendor or embeds a third-party agent into a regulated process, it can feel as though responsibility has moved with the work. Accountability stays with the firm running the process.
The model provider owns the model and the systems integrator owns the delivery. The firm running the process owns the outcome, the control and the regulatory position. When a supervisor asks who is accountable for an AI-embedded decision, the answer is the regulated entity, which is also why it is the one best placed to build the evidence.
That changes what Risk and Compliance functions can usefully build. The question shifts from whether you can trust the vendor to whether you can evidence control over the process the vendor now touches. The second question is the one an audit tests, and you can prepare for it.
The Regulatory Stack Is Taking Shape
For the past two years, AI regulation was treated as a distant horizon. Across jurisdictions, the obligations are now converging and the timelines are firming up.
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. For firms deploying AI in high-risk contexts, that means the detail of what deployers document and demonstrate is being written down now. The specifics of these instruments are source-attributed rather than settled law, and Risk functions should confirm current status with counsel. The direction is clear. For a deeper treatment of what the Act expects deployers to show, see our analysis of EU AI Act evidence requirements.
The UK picture points the same way. The FCA continues to emphasise operational resilience, product and process design and the supervision of Critical Third Parties. DORA-aligned scrutiny of third-party dependency, familiar to any financial services firm with EU exposure, is widening the set of relationships under formal resilience obligations. The AI a firm depends on is increasingly a third-party dependency in the regulatory sense, with what that implies for testing, documentation and impact tolerance.
Read together, 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. Supervisors reward firms that can show their work, so this is an opportunity to build that capability before the obligation is tested.
Governance Works Best on What You Can Describe
Every one of these regimes asks the same underlying question: can you demonstrate control over the AI-touched process? The process here means the sequence of steps, decisions and handoffs in which the AI participates and through which a business outcome is produced.
Governance-as-code enforces rules against a process, and it works on a process that has been described. AI observability tools monitor execution and flag drift, against a baseline of what execution was meant to look like. Both are valuable, and both work best on a documented, articulated process.
Many enterprises are still building that. Their processes live in 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 is often the least documented, because it started as a pilot on an existing workflow. Describing it closes the distance between the process on paper and the process in practice, and gives your governance layer something to enforce, your observability something to observe and your regulator something to review.
Process Articulation as Compliance Infrastructure
Articulation goes beyond documentation. A procedure manual documents intent. Articulation holds four things together: documentation of how the process 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.
IGX360 Insights supports that layer. Where governance tooling enforces and observability tooling watches, IGX360 Insights supplies the process knowledge both rely on, with ownership, provenance, confidence and freshness visible. 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.
The practical result is that the artefact you present to a regulator already exists and is current, in place of being assembled under deadline pressure. For Risk and Compliance leaders, that is the difference between a resilience posture that is asserted and one that is evidenced. IGX360 is built for risk leaders who answer for AI-embedded processes they did not design.
Evidence Builds Confidence
A vendor’s certification, a policy statement or a board attestation is valuable assurance, and a supervisor testing a control will also look for evidence: the articulated process, the enrichment that shows the controls and the record that shows they operated. That holds for compliance teams preparing for review as much as for the risk function that owns the exposure.
The obligations are finalising now, which makes this the right moment to articulate AI-embedded processes. The firms that answer supervisory questions calmly will be the ones who prepared before the review. What evidence will a regulator ask you for, and how much of it do you already hold?
Talk to IGX about making your AI-embedded processes auditable and defensible.