Why Model Provenance Is Becoming as Important as Data Residency

Data residency has a decade-old compliance playbook. For the AI model that just made - or denied - a regulated decision, most institutions still cannot answer a simpler question: which model, which version, and whose, produced this output? Through October 2026, regulators and plaintiffs' lawyers on three continents are converging on that exact question.

Key Takeaways

• Three independent regulatory threads - UAE technology-provider licensing, Hong Kong's GenAI governance expectations, and US claims-litigation discovery into AI development records - all push toward one requirement: reconstructing which model and version produced a specific regulated decision.

• Model provenance is distinct from data residency. Residency answers "where does the data sit?"; provenance answers "which model, version and vendor touched this decision, and can we prove it?"

• US banking's model risk overhaul this year (SR 26-2, April 2026) explicitly excludes generative and agentic AI - a documentation gap, not an exemption.

• Technical research (Cisco/VAIL, August 2026) shows "knowing the vendor" understates the problem: models inherit weights, data and behaviour from other organisations' models.

• The counterargument - expensive new build, especially for smaller institutions - has merit, but mature MLOps shops already hold much of the raw material; the gap is usually integration and decision-level binding, not a ground-up system.

Introduction

This publication argued on 29 September 2026 that data residency should be treated as a product decision, not a retrofit (Read more: The Case for Treating Data Residency as a Product Decision, Not a Legal One). That argument still holds. But a second, distinct question is now arriving on the same desks - the CDO's and the Chief Risk Officer's - without the same institutional muscle memory behind it. It is not "where does our data live?" It is: when an AI system declines a claim, prices a policy, flags a transaction or recommends a credit decision, can the institution say - months or years later - exactly which model, which version, and whose weights produced that output?

Most institutions cannot answer that with the confidence they bring to a residency question. That gap is now being tested from three directions at once, in the same month.

Three Regulatory Signals Converging in October 2026

The UAE: licensing follows the activity, not the location of the data

Federal Decree-Law No. 6 of 2025 took effect in the UAE on 16 September 2025, consolidating banking and insurance oversight under the Central Bank (CBUAE) and extending its licensing authority under Article 62 to "anyone who engages in, offers, issues, or facilitates a licensed financial activity," regardless of the technology or channel used (Manfredi et al., 2025; Savastano, 2025). Read in isolation, this looked like it might sweep in pure technology vendors. The CBUAE's own FAQ, issued in early 2026, narrowed that: a provider serving only a licensed institution is not itself carrying out a licensed activity unless it performs one directly, or presents itself as doing so (Pinsent Masons, 2026).

The practical effect for a CDO is not "our AI vendor now needs a banking licence." It is that the law is activity-based, not infrastructure-based - so the burden of proof about what performed a regulated activity sits with the institution, not the vendor. Regulated entities have until 16 September 2026 to reconcile their positions, extendable at the CBUAE's discretion (Manfredi et al., 2025). Showing which system component executed which licensed activity is now a live documentation requirement.

Hong Kong: governance expectations are rising faster than formal rules

The Hong Kong Monetary Authority's 2024 guidance on generative AI in customer-facing applications treats a lack of explainability as a consumer-protection risk potentially more serious than that of conventional big-data analytics, and expects boards to ensure GenAI models are "properly validated," with human-in-the-loop controls early on (Gibson Dunn, 2024; Moody's, 2024). The HKMA's GenAI Sandbox, run with Hong Kong Cyberport, has since reported that participating banks found "comprehensive documentation" of data handling necessary to make pilots reproducible for a second cohort (Rowena, 2025).

To be precise: the HKMA has not published a codified "model documentation standard" the way the EU has. What it has done is signal, consistently, that governance and explainability expectations for GenAI sit above those for traditional models - and institutions are finding, in practice, that they need documentation discipline to meet that bar. The expectation runs ahead of the formal rule, usually the more useful early warning.

The United States: litigation is doing what regulation has not yet done

While US banking regulators have been narrowing the scope of formal AI model risk rules (see below), US courts have been widening it through discovery. In The Estate of Gene B. Lokken v. UnitedHealth Group, Inc. (D. Minn.), plaintiffs alleged a health insurer used an AI tool - nH Predict - to deny post-acute care claims without adequate human review. The court compelled discovery into the tool's development and use in full, including how it was built, its design goals, and whether it was intended to supplant physician decision-making, while narrowing adjacent categories such as financial-benefit data (Bracken and Niczky, 2026). The legal analysis notes the reasoning is not confined to health insurance - it applies to any claims-handling AI.

This is the sharpest version of the provenance question: a court did not ask where the claimant's data was stored. It asked what the model was, how it was built, and what it was for - months after the decision it made.

Why "Which Vendor" Is No Longer a Sufficient Answer

A natural first response to all three signals is: maintain a register of which AI vendor and product powers which decision. That is necessary, but recent technical research suggests it is not sufficient.

An August 2026 study by researchers at Cisco and VAIL, bluntly titled Models Don't Have Passports, shows commercial AI models routinely inherit base weights, distillation sources and training data from organisations in other countries - the public "publisher" label describes who released the artefact, not everything that went into it (Chang et al., 2026). Using fingerprinting methods applied to NVIDIA's Nemotron family, the authors trace clear ancestry links back to Alibaba's Qwen base weights - "provenance entanglement," not simple vendor attribution. Their conclusion: "Models do not have passports; they have supply chains." They recommend separating five distinct questions - publisher, weight lineage, data sources, operational control, and observed behaviour - rather than assuming one answers the rest. Self-reported model cards, they note, are "incomplete and uneven" - useful, but not a substitute for an institution's own record of what it deployed, when, and why.

Meanwhile, the US scaffolding that might have forced vendors to close this gap was just narrowed, not widened, at exactly the point AI model risk became material. On 17 April 2026, the Federal Reserve, OCC and FDIC rescinded the 2011 SR 11-7 model risk guidance and replaced it with the principles-based SR 26-2 (and OCC Bulletin 2026-13) - but the new guidance explicitly places generative and agentic AI models "outside its scope," deferring them to a future request for information with no published timeline (Cerda, 2026; Elevate Consult, 2026). Traditional statistical models remain covered; the newest, highest-impact models now carry the least prescriptive guidance. Interagency third-party risk guidance still applies to vendor-delivered AI, and the Cyber Risk Institute's Financial Services AI Risk Management Framework (v1.0, February 2026) is the main sector reference in the interim (Elevate Consult, 2026) - but neither substitutes for a bank's own provenance records.

The EU AI Act shows what a fuller standard looks like: Article 11 requires providers of high-risk AI systems to prepare technical documentation before deployment and keep it current, with Annex IV specifying - among nine sections - design and architecture, training data and algorithmic logic, and a version history updated whenever the model, data or intended purpose changes (EU AI Act Service Desk, n.d.; Openlayer, 2026). Annex III high-risk systems carry an August 2026 deadline, with ten-year documentation retention under Article 18. The EU has written into law roughly what the UAE, Hong Kong and US litigation are each pressuring institutions toward through different mechanisms.

The Counterargument: Is This Just More Compliance Overhead?

The case against treating model provenance as a new, dedicated discipline deserves a fair hearing.

The cost argument. Commentary on India's draft AI risk guidance for banks and NBFCs makes the point plainly: board-approved governance frameworks, independent validation, audit trails and specialist staff are real, front-loaded costs, and smaller institutions without mature risk functions will feel them disproportionately more than large banks that already run model risk teams (CAalley, 2026). This is a genuine equity concern - a community bank or mid-tier insurer matching a tier-one bank's documentation regime faces a materially different cost-to-asset ratio.

The "we already have this" argument. A more targeted objection is that mature MLOps environments already maintain model registries tracking version history, training data lineage, approval status and performance drift - the raw material of provenance (Alation, 2026). The more candid version of this argument, even from vendors selling into the space, is that the gap is not absent records but fragmentation: registries, data catalogues and lineage tools rarely connect to each other, so an institution could answer a provenance question in principle, but not quickly, and not for every model - particularly third-party and embedded AI it did not build itself.

Both points describe a real spectrum, not a binary. For institutions with disciplined MLOps practice, the incremental work is mostly integration and extending scope to vendor and agentic AI, not a ground-up build. For institutions without that baseline, the cost argument is real, and a phased, risk-tiered approach - starting with customer-facing, regulated-decision models - is a legitimate response to resource constraints, not a failure of ambition.

What the counterargument does not survive is a "deal with it when asked" posture. The Lokken discovery ruling (Bracken and Niczky, 2026) shows that once a regulator or plaintiff asks, reconstruction happens under far worse terms than building the capability in advance.

The Model Custody Chain: A Five-Link Standard for Provenance

To make "architect it, don't reconstruct it" actionable, it helps to have a concrete standard. We propose the Model Custody Chain - five links that, together, let an institution answer the provenance question for any regulated decision, on demand.

1. Identity. Every production model - vendor-built, fine-tuned, or internal - has a unique identifier, a version tag, and a named accountable owner, matching the ownership assignment expected under US model-registry norms and the EU's Annex IV version-history requirement (Openlayer, 2026).

2. Lineage. The model's ancestry is documented one layer deeper than the vendor label: base model, fine-tuning or distillation sources, training data provenance - acknowledging, per the Cisco/VAIL findings, that "which vendor" and "what it inherited" are different questions (Chang et al., 2026).

3. Binding. Every regulated decision is stamped, at the moment it is made, with the exact model identifier and version that produced it - not "which model do we currently use" but "which model version produced decision #X on date Y." Without this link, the other four exist but cannot be connected to the specific case a regulator or claimant asks about.

4. Retrieval. The institution can reconstruct, within a defined service level (we suggest no more than 30 days for a single case, faster under litigation hold), the full custody record for any past decision.

5. Attestation. A named governance owner periodically attests the chain is intact - via a tested retrieval drill, not a policy document - with gaps (vendor models with restricted internals, legacy decisions predating the chain) explicitly logged, not assumed away.

The chain is only as strong as its weakest link. In most institutions, that is Binding: they can describe which model they use for a process, but not which version touched a specific past decision.

What This Means for the Buying Committee

For the Chief Data Officer, model provenance is a lineage problem before it is a compliance problem - which is why it belongs with the CDO, not solely with model risk or legal. The CDO's existing data lineage and metadata discipline is the natural chassis for the Model Custody Chain; the gap is almost always extending that discipline from datasets to model versions and decision-level binding, and from internal models to vendor and embedded AI.

For Risk and Compliance leaders, treat the absence of a Binding link as an open risk item now, not a future audit finding. SR 26-2's explicit exclusion of generative and agentic AI (Cerda, 2026) means no US regulator will currently tell a bank its provenance gap is unacceptable - precisely why a leader who waits for that instruction will be building under litigation-style time pressure, on the Lokken pattern, rather than on their own schedule.

For heads of AI and engineering, treat model-version binding as a logging requirement at decision time, not a registry lookup after the fact - a small build-time decision that is expensive to retrofit once a system has run across thousands of historical decisions.

The sourceCode’s Perspective

sourceCode has spent more than two decades inside BFSI delivery teams across Australia, Malaysia and Vietnam, working through an insourcing model: embedding engineers, business analysts, QA and project managers directly into a client's existing workflows rather than running work at arm's length. That vantage point shapes how we think about provenance.

The practical reality we see is that provenance gaps are rarely a tooling failure. Most institutions running AI in production already have some version control, some model registry, some data lineage capability - the elements in the Model Custody Chain usually exist in fragments, inside different teams, built at different times. What is missing is Binding specifically: stamping a model version onto a decision the moment it is made, so nobody has to reconstruct, from logs and institutional memory, which model was live on a given date.

This is exactly the kind of gap insourcing is structured to close, because it sits at the intersection of engineering practice and governance requirement - neither a compliance exercise an external audit team can bolt on, nor a feature a vendor can ship. It needs people who understand both the client's delivery pipeline and the regulatory shape of the problem, working inside that pipeline rather than around it. We would rather see a CDO or Risk leader build this into how models are deployed from the outset than have it designed under time pressure, after a regulator's letter or a discovery request.

We do not have a published case study to cite here, and we are not going to invent one. What we can say is that the Model Custody Chain is designed to be buildable inside an institution's existing engineering environment - the only place it will actually get maintained once the regulatory attention that prompted it moves on. Contact us here!

Conclusion

Data residency earned its compliance playbook because regulators asked a clear, bounded question - where is the data? - long enough and consistently enough that institutions built durable answers. Model provenance now faces the same pressure from three independent directions in the same month: UAE licensing that is activity-based rather than infrastructure-based, Hong Kong governance expectations running ahead of codified rules, and US litigation that treats AI development records as discoverable evidence.


None of these, individually, amounts yet to a single codified global standard - which is exactly why institutions that wait for one will be reconstructing records under the worst conditions, the way the defendant in Lokken is now having to do in a Minnesota courtroom. Institutions that treat Binding as a build-time decision, not a retrieval exercise, will be the ones who can answer the question calmly when it arrives from a regulator, an auditor or a plaintiff's lawyer.

>> Learn more about sBrain here!

>> Read more: What US AI Claims-Denial Litigation Is Previewing for APAC and Gulf Insurers

A practical next step: map your current AI estate against the five links above - Identity, Lineage, Binding, Retrieval, Attestation - and identify, honestly, which link would fail first if a regulator or plaintiff asked tomorrow. For most institutions we have seen, it is Binding.

FAQ

Is model provenance the same thing as data residency? No. Residency governs where data physically sits and under which jurisdiction's law. Provenance governs which specific model, version and vendor produced a specific output, and whether that can be proven after the fact. An institution can have perfect residency and no provenance capability at all.

Does any single regulation currently require full model provenance tracking? Not as one global standard. The EU AI Act's Article 11 and Annex IV come closest for high-risk systems (Openlayer, 2026). In the US, SR 26-2 explicitly excludes generative and agentic AI for now (Cerda, 2026) - a gap, not a safe harbour; US courts are filling part of it through discovery (Bracken and Niczky, 2026).

Isn't this just a bigger version of AI vendor due diligence? Due diligence answers "is this a reputable vendor?" once, at procurement. Provenance answers "which model version touched this decision, on this date" - an ongoing, per-decision question. Vendor identity alone can mislead, since models inherit weights and data from other organisations' models (Chang et al., 2026).

Where should a resource-constrained institution start? With the Binding link for customer-facing, regulated-decision models only - the smallest scope that answers a regulator's or plaintiff's most likely question - rather than full tracking across the whole estate on day one.

Reference List

Alation (2026) What Is an AI Model Registry? How Enterprises Track, Version, and Govern Every AI Asset, 20 July. Available at: https://www.alation.com/blog/ai-model-registry/ (Accessed: 12 October 2026).

Bracken, L.J. II and Niczky, J.T. (2026) 'Court Allows Discovery Into Insurer's Use of AI to Deny Claims', National Law Review / Hunton Insurance Recovery Blog, 23 March. Available at: https://natlawreview.com/article/court-allows-discovery-insurers-use-ai-deny-claims (Accessed: 12 October 2026).

CAalley, reproducing The Business Standard (2026) 'Indian Banks May Face an AI Compliance Bill: Who Will Bear the Cost?', 29 June. Available at: https://caalley.com/news-updates/indian-news/indian-banks-may-face-an-ai-compliance-bill-who-will-bear-the-cost (Accessed: 12 October 2026).

Cerda, C. (2026) 'Banking Agencies Revise Model Risk Management Guidance', Schneider Downs, 21 April. Available at: https://schneiderdowns.com/our-thoughts-on/banking-agencies-revise-model-risk-management-guidance/ (Accessed: 12 October 2026).

Chang, A., Garg, A., Shah, M. and Leshin, J. (2026) Models Don't Have Passports: AI Lineage Crosses Organizational and Geographic Borders. Cisco Systems / VAIL, August. Available at: https://www.cisco.com/c/dam/en/us/products/security/models-dont-have-passports.pdf (Accessed: 12 October 2026).

Elevate Consult (2026) 'SR 11-7 Is Rescinded: What the New Model Risk Guidance Means - and the AI Gap It Leaves', 24 September. Available at: https://elevateconsult.com/insights/sr-11-7-rescinded-model-risk-guidance-ai-gap (Accessed: 12 October 2026).

EU AI Act Service Desk (n.d.) 'Article 11: Technical Documentation', European Commission. Available at: https://www.euaiact.com/article/11 (Accessed: 12 October 2026).

Gibson Dunn (2024) 'Hong Kong Monetary Authority Guidance on Gen AI Use in Customer-Facing Applications and Use of AI in AML/CFT', 19 September. Available at: https://gibsondunn.com/wp-content/uploads/2024/09/hong-kong-monetary-authority-guidance-on-gen-ai-use-in-customer-facing-applications-and-use-of-ai-in-ml-tf.pdf (Accessed: 12 October 2026).

Manfredi, R. et al. (2025) 'UAE Central Bank Issues New Central Bank Law Consolidating Financial Sector Regulation', Gibson Dunn, 13 November (updated 18 November). Available at: https://www.gibsondunn.com/uae-central-bank-issues-new-central-bank-law-consolidating-financial-sector-regulation/ (Accessed: 12 October 2026).

Moody's (2024) 'HKMA Announces Strategic Initiatives to Facilitate GenAI Adoption', 28 August. Available at: https://www.moodys.com/web/en/us/insights/regulatory-news/hkma-announces-strategic-initiatives-to-facilitate-genai-adoptio.html (Accessed: 12 October 2026).

Openlayer (2026) 'EU AI Act Technical Documentation Requirements: Complete Guide for April 2026', 16 April. Available at: https://www.openlayer.com/blog/post/eu-ai-act-technical-documentation-requirements (Accessed: 12 October 2026).

Pinsent Masons (2026) 'CBUAE Guidance Clarifies Scope of Technology Firms' Regulation Shift', Out-Law, 14 April. Available at: https://www.pinsentmasons.com/out-law/news/cbuae-guidance-technology-firms-regulation-shift (Accessed: 12 October 2026).

Rowena, A. (2025) 'HKMA GenAI Sandbox Report', Fintech News Hong Kong, 26 November. Available at: https://fintechnews.hk/36534/ai/hkma-genai-sandbox-report/ (Accessed: 12 October 2026).

Savastano, G. (2025) 'The New UAE Central Bank Law: Expanding the Regulatory Perimeter for a Digital Era', CMS Law, 13 October. Available at: https://cms.law/en/are/legal-updates/the-new-uae-central-bank-law-expanding-the-regulatory-perimeter-for-a-digital-era (Accessed: 12 October 2026).

source[code] (n.d.) Homepage. Available at: https://www.sourcecode.com.au/ (Accessed: 12 October 2026).