
By Devendra Bhudia, Chief Product Officer – EDM at Gresham.
The use of artificial intelligence in financial data operations is moving quickly from experimentation into production. Firms are increasingly looking to AI to identify anomalies, compare vendor feeds, prioritise exceptions and resolve operational breaks.
Data operations teams are under pressure to manage greater volumes, more complex datasets and tighter control requirements without simply adding more people. AI offers the potential to reduce manual intervention and accelerate decision-making across data operations. But the governance challenge changes once AI moves beyond flagging issues and starts deciding which issues matter, which data to trust and when no further intervention is required.As firms become more comfortable allowing AI to make those operational decisions, can they still demonstrate how those decisions were reached?
Much of the debate around AI governance in financial services has focused on the front office. Firms have spent considerable time thinking about model risk in trading, explainability in lending decisions and bias in fraud detection. These are important issues, but the same level of scrutiny has not always been applied to the systems sitting further down the data chain.
Decisions made within the EDM layer can have consequences across the organisation. If an AI system determines that one vendor price is more reliable than another, decides that a reconciliation exception does not require investigation, or automatically corrects a data quality issue, that judgement can feed into multiple downstream processes. It may ultimately influence valuations, reporting, risk management or investment decisions.
Logging a Decision Is Not The Same As Explaining It
This is where many current approaches risk falling short. It is relatively easy to record that an AI system made a decision. It is much harder to demonstrate why the decision was made, what information informed it, what alternatives were considered and whether a human could reasonably have challenged the outcome.
An activity log tells a firm what happened. A meaningful AI audit trail should also show why it happened, on what evidence and under whose authority. That means auditability cannot simply be attached to an AI model after the fact. It needs to be part of the workflow architecture itself. Regulators have already set this bar for risk data more broadly. BCBS 239 requires banks to demonstrate accurate, complete and auditable lineage for risk reporting.For every automated decision, firms should be able to reconstruct the context in which it was made. What data was available at the time? What rules or thresholds were applied? Did the model operate within an agreed confidence level? Was human review required? If the result was subsequently challenged, what happened next?
Without that information, firms risk creating a new kind of operational black box. They may have automated the process successfully, but weakened their ability to demonstrate control over it.
Human-In-The-Loop Needs to Mean More
The concept of “human-in-the-loop” is often presented as the answer to this problem. But there is a danger that it becomes little more than a governance checkbox.
A human approval step can create the appearance of oversight while adding very little real control if the operator lacks the information needed to interrogate the system’s recommendation. Human involvement therefore needs to be designed into the workflow rather than added as a final approval step.
That means identifying where human judgement genuinely adds value. A routine exception with a known resolution pattern may be suitable for full automation. A pricing discrepancy involving conflicting vendor data may require the system to surface its rationale and supporting evidence before an operator accepts the recommendation.
More ambiguous cases should be presented with enough context for an operator to understand and challenge the outcome. Decisions should also be reversible, with a clear record of both the original action and any subsequent intervention.
The objective is not to force humans to review every automated decision. Doing so would defeat much of the purpose of automation. It is to ensure that humans retain effective control over the process, particularly where judgement, uncertainty or material downstream consequences are involved.
Start With Explainability, Not Automation
Firms may therefore be asking the wrong question when they begin applying AI to EDM. The first question should not be “what can we automate?” It should be “what will we need to explain?”
That change in emphasis has practical consequences. It encourages firms to define decision rights, escalation paths and evidence requirements before introducing automation. It also forces teams to distinguish between where AI should make a decision, where it should make a recommendation and where human judgement should remain decisive.
The point is not to slow the adoption of AI in data management. There are clear opportunities to process information more quickly, reduce repetitive manual work and make routine operational decisions more consistently. But the ability to automate more decisions should not come at the expense of understanding, challenging or reversing them.
Financial institutions have spent decades building auditability into their core operational processes. AI should not be an exception. As intelligent systems take on more responsibility within the data layer, explainability, challengeability and reversibility will become as important as the sophistication of the algorithm itself, a principle now written into regulation itself. For example, the EU AI Act’s human oversight requirements for high-risk systems specifically require that a human can override or reverse an automated output.
The advantage will not come simply from deploying more advanced AI. It will come from being able to automate more decisions without losing control of how those decisions are made. In enterprise data management, the audit trail may ultimately matter as much as the algorithm.
Subscribe to our newsletter


