Building Trusted Decision Intelligence

Regulatory status in this article is as of 17 August 2026. This is general information, not legal advice.

A sound model is not the same as a trusted decision

In March 2021 the New York State Department of Financial Services closed its investigation into the Apple Card, issued by Goldman Sachs, after public allegations that the card's credit decisions discriminated against women. Having analysed roughly 400,000 applications, the regulator found no fair lending violation. For the customers who complained, the evidence showed decisions that were explainable, lawful and consistent with the bank's credit policy.

The same report still concluded that poor customer service and a perceived lack of transparency had undermined consumer trust in the fairness of those decisions. The model was defensible. The decision, as experienced by the people it affected, was not trusted.

That gap is the subject of this article. Most enterprises approach trustworthy analytics and AI by governing models: validate them, document them, monitor them. That remains necessary. But a business decision is rarely just a model output. It combines data, business definitions, one or more models, deterministic rules and thresholds, sometimes a generative AI summary, and often a person who accepts or overrides the result.

Our argument: trust attaches to decisions, not models. The architecture for trusted decision intelligence should be organized around a durable, replayable decision record that ties every one of those components together, with model risk management as one layer inside it rather than the whole of it.

Why model risk management alone no longer covers the decision

For fifteen years the reference point for model governance in banking, and well beyond it, was the US Federal Reserve's SR 11-7 guidance of April 2011. On 17 April 2026 the Federal Reserve, OCC and FDIC replaced it with revised interagency guidance, issued by the Fed as SR 26-2.

The new guidance keeps the core ideas: validation of conceptual soundness, outcomes analysis, ongoing monitoring, a model inventory, documentation, and "effective challenge" by people with the expertise, independence and organizational standing to force change. It adds a stand-alone section on vendor models, stating that the principles still apply when a bank cannot see the vendor's code or data. It also becomes explicitly risk-based. Model risk is now assessed as inherent risk in the context of materiality, defined by exposure and purpose, and the agencies say non-compliance with the guidance will not by itself lead to supervisory criticism.

Two changes matter for decision architecture:

• A narrower definition of model. The guidance now covers complex quantitative methods grounded in statistical, economic or financial theory. It excludes simple spreadsheet arithmetic and deterministic rule-based processes.
• Generative and agentic AI are out of scope. A footnote describes them as novel and rapidly evolving and leaves their governance to each organization's broader risk management.

Both are reasonable for a model risk document. But consider what a typical automated credit or fraud decision actually contains: a statistical score (in scope), business rules and cut-offs that turn the score into an action (out of scope), a large language model that drafts the customer explanation or the analyst summary (out of scope), and a human override (governed elsewhere, if at all). The parts most likely to change between validation cycles, the thresholds and rules, are the parts the guidance now explicitly leaves out.

Meanwhile the obligations aimed at decisions are tightening. In February 2025, in Dun & Bradstreet Austria (C-203/22), the EU Court of Justice held that a person refused a contract on the basis of an automated credit score is entitled to an intelligible explanation of the procedure and principles actually applied, and that handing over the algorithm itself does not satisfy that right. The EU AI Act gives affected people a right to an explanation of the role an Annex III high-risk AI system played in a decision (Article 86), and requires deployers to keep the system's logs for at least six months (Article 26). The July 2026 Digital Omnibus moved the Annex III obligations, which include creditworthiness assessment, to 2 December 2027. Deferred, not removed.

The supervisory question has shifted from "is the model sound?" to "can you show why this decision was made?" Only a decision-level architecture answers it.

The architecture: six layers and a spine

Trusted decision intelligence needs six layers. Most enterprises already have parts of each. What is usually missing is the spine that joins them.

1. Governed data with lineage. Every input to a decision should be traceable to its source and to the transformations it passed through. Open standards such as OpenLineage, an LF AI & Data graduate project, model this as jobs, runs and datasets, so lineage can be collected across tools rather than reconstructed by hand.
2. A semantic layer. "Active customer", "days past due" and "exposure" must mean one thing across the dashboard, the model's features and the rule engine. When those definitions drift apart, a decision can be technically correct and still indefensible. Our guide to data architecture patterns explains why governed definitions, not storage, are now the bottleneck.
3. Models and rules, registered together. A model registry is not enough. Thresholds, cut-offs, policy rules and prompt templates are decision logic too, and they need versioning, owners and approval in the same inventory.
4. A decision service. The component that combines inputs, models and rules into an outcome should be a distinct, versioned service, not logic scattered across a BI tool, a notebook and an application.
5. Human accountability. Named owners, defined oversight modes, and override rights with limits.
6. Monitoring and feedback. Input drift, output drift, outcome performance and override behavior, fed back to owners with authority to act.

The spine is the decision record: one immutable entry per decision that references the exact version of everything above.

The decision record: what to log so you can explain, replay and defend

A decision log is often treated as an application log: a timestamp, a score, an outcome. That is enough to count decisions, but not to explain one a year later to a customer, an auditor or a court.

The test is replay. Given only the record, could you reconstruct what the system knew, what logic it applied, who acted and what happened next? The Dun & Bradstreet judgment makes this concrete. The Court indicated that explaining how a change in the personal data taken into account would have led to a different result could satisfy the right to an explanation. You can only generate that kind of counterfactual explanation if you kept the inputs as they were at decision time, and the exact model and rule versions that processed them.

Three design choices make the difference:

• Point-in-time inputs. Store the feature values used, or immutable references to versioned data, not pointers to tables that will be overwritten tonight.
• Versions, not names. "Credit model" is a name. "Credit model 4.3.1, cut-off table 2026-09, policy rule set 17" is a version that can be replayed.
• Human actions as first-class events. Who reviewed, what they saw, whether they overrode, and the reason code. An override recorded without a reason cannot be analysed later, and the reason cannot be reconstructed after the fact.

Retention should follow regulation and litigation risk rather than storage cost. The AI Act's six-month minimum is a floor for logs of high-risk systems, not a target; sector record-keeping rules and limitation periods can require much longer, so set retention with legal review.

Explainability that survives scrutiny

Explainability is usually discussed as a modeling technique. For trust, it is a product that different audiences consume. A data scientist needs feature attributions. A validator needs conceptual soundness evidence. A customer needs to know which of their data mattered and what they could change. A supervisor needs to see that the explanation given to the customer matches the logic that actually ran.

The Central Bank of the UAE's February 2026 guidance note on AI in financial services points the same way: clear disclosures for significant AI-assisted decisions and mechanisms for clarification, challenge and redress. Its 2022 Model Management Standards already require that a chosen model produce outcomes that can be explained easily and support decision-making.

Monitoring: drift, outcomes and overrides

SR 26-2 frames ongoing monitoring around changes in products, exposures, clients, data relevance and market conditions, and outcomes analysis as comparing model outputs with real-world results. Two public cases show what happens when those signals are missed or measured too late.

In November 2021 Zillow announced it would wind down Zillow Offers, its algorithmic home-buying business. It recorded a write-down of about $304 million on homes bought at prices above its own revised estimates of resale value, and announced a cut of roughly a quarter of its workforce. Its chief executive said the unpredictability in forecasting home prices "far exceeds what we anticipated". Price models were acting on a market that was shifting faster than outcome feedback arrived.

In June 2021 researchers at Michigan Medicine published an external validation of the Epic Sepsis Model, a proprietary prediction model in wide use in US hospitals. They measured an area under the curve of 0.63, against 0.76 to 0.83 reported by the developer. The model alerted on 18% of hospitalized patients yet missed 67% of the patients who developed sepsis. A vendor model, deployed widely, performed very differently once someone measured outcomes locally. SR 26-2's vendor section exists for exactly this reason.

The fourth signal is the one most organizations ignore: overrides. The CBUAE Model Management Standards are unusually direct here. Overrides of model inputs and outputs must be documented, justified and approved; they must be tracked and reported to the model oversight committee, senior management and the board; models whose outputs are frequently and materially overridden must not be considered fit for purpose. And once a model is approved, its outputs must not be ignored simply because they do not meet commercial expectations.

That is a two-sided test, and a useful one outside banking. A falling override rate can mean the model is improving, or that reviewers have stopped reviewing. A rising one can mean drift, or a business line routing around a model it dislikes. Only a decision record with reason codes tells you which.

Human accountability that is real

"Human in the loop" is often written into policies without saying what the human can see, decide or change. Three frameworks now set more concrete expectations:

• EU AI Act, Article 26: deployers must assign oversight to people with the necessary competence, training and authority, and the support to exercise it.
• CBUAE AI guidance (2026): distinguishes human in the loop (full approval authority), human on the loop (monitoring with power to intervene) and human out of the loop, the last reserved for low-risk, non-material processes. Accountability for AI outcomes stays with the institution even when functions are outsourced.
• SDAIA AI Ethics Principles: automated decisions whose impact is irreversible or difficult to reverse should trigger human oversight and final determination, and critical design decisions should be signed off by named stakeholders.

The practical step is to tier decisions by two dimensions, impact on the affected party and reversibility, and assign an oversight mode to each tier before the system goes live. The enterprise AI operating model covers how to allocate those decision rights across business, risk and technology.

Two warnings from practice. First, a human who approves hundreds of recommendations an hour is not exercising oversight; measure review time and disagreement rates, not just whether a click occurred. Second, oversight needs authority. If the reviewer cannot pause the model, change a threshold or escalate without penalty, the loop is decorative.

The Gulf view

The UAE has the most specific framework in the region. The CBUAE Model Management Standards and Guidance, attached to Notice 5052/2022 and dated November 2022, apply to all licensed banks. The Standards set minimum requirements across governance, data management, development, implementation, usage, performance monitoring and independent validation. Their scope explicitly lists fraud, AML, marketing and artificial intelligence models alongside credit and capital models, and the inventory must cover models used in the past as well as those in production. Combined with the February 2026 AI guidance note, UAE banks already have most of the elements of a decision-level architecture in their rulebook: inventory, override governance, explainability and defined oversight modes.

In Saudi Arabia, SDAIA's AI Ethics Principles set cross-sector expectations on accountability, transparency and human oversight, and the NDMO standards require data governance, lineage and quality controls that a trusted decision architecture depends on; our NDMO implementation guide covers them. We could not verify a published Saudi Central Bank standard dedicated to model risk comparable to the CBUAE's, so Saudi institutions should confirm current SAMA expectations directly and, in the meantime, treat the decision record and model inventory as controls they will need to evidence.

For groups operating in both countries, and with exposure to EU or US supervisors, the efficient design is one decision-record standard that satisfies the strictest requirement, rather than separate logging regimes per regulator.

What to do in the next 90 days

1. Pick three high-impact decisions (for example a credit approval, a fraud block and a pricing change) and map every component: data, definitions, models, rules, generative AI, humans.
2. Run the replay test. For one decision taken six months ago, try to reconstruct inputs, logic versions, reviewer and outcome. Record what you could not recover.
3. Extend the model inventory to decision logic. Register thresholds, rule sets and prompt templates with owners and versions alongside models, including those SR 26-2 no longer classes as models.
4. Define the decision record schema and implement it in the decision service for the three pilot decisions, with immutable storage and retention set by legal review.
5. Add override monitoring with reason codes, and report override rates by model and business line to the committee that owns model risk.
6. Tier decisions by impact and reversibility and assign an oversight mode to each, with named owners who have authority to pause.
7. Align explanations to the record. Generate customer and auditor explanations from logged versions, never from the current model.

Frequently asked questions

What is the difference between model risk management and decision governance?

Model risk management asks whether a model is conceptually sound, validated and performing as expected. Decision governance asks whether a specific decision can be explained, replayed and defended, including the data, definitions, rules, thresholds and human actions around the model.

Has SR 11-7 been replaced?

Yes. On 17 April 2026 the Federal Reserve, OCC and FDIC issued revised model risk management guidance, published by the Fed as SR 26-2, which supersedes SR 11-7 and SR 21-8. It narrows the definition of a model, takes a risk-based approach and excludes generative and agentic AI.

What should a decision log contain?

At minimum: a unique decision ID, point-in-time inputs or versioned references, the versions of every model, rule set and prompt used, the output and reason codes, the oversight mode, any human review or override with reason, the action taken and, later, the observed outcome.

Do UAE banks have specific model risk requirements?

Yes. The Central Bank of the UAE's Model Management Standards and Guidance, dated November 2022, apply to all licensed banks and cover AI, fraud and AML models as well as credit models. A February 2026 guidance note adds expectations for responsible AI and consumer protection.

Sources and further reading

• SR 26-2: Revised Guidance on Model Risk Management, Federal Reserve Board, OCC and FDIC, 17 April 2026; SR 11-7, 4 April 2011 (superseded).
• Agencies Overhaul Model Risk Management Guidance for Banks, Orrick, April 2026.
• Model Management Standards and Model Management Guidance, Central Bank of the UAE, November 2022.
• Guidance Note on Responsible Adoption and Use of AI and ML, Central Bank of the UAE, 11 February 2026; summary, Pinsent Masons.
• AI Ethics Principles, SDAIA.
• CJEU press release on Case C-203/22, Dun & Bradstreet Austria, 27 February 2025; analysis, Arthur Cox.
• EU AI Act Article 26 and Article 86; Digital Omnibus changes, Orrick, July 2026.
• Apple Card investigation report, NYDFS, 23 March 2021.
• Zillow Group third-quarter 2021 results, 2 November 2021.
• External validation of a proprietary sepsis prediction model, Wong et al., JAMA Internal Medicine, June 2021.
• OpenLineage documentation, LF AI & Data Foundation.