The AI model inventory in finance

A usable record answers four things. Identity: a stable identifier, a name, a version, and for a bought system the provider and base model. Ownership: one accountable person or a defined role, plus who decides a change. Data reach: the training sources, the data the system sees at inference, and a flag where personal or otherwise regulated data is involved. Lifecycle: the stage the system is in, the date of the last validation, the risk tier, and the conditions that trigger a review.

MaRisk AT 4.3.1 is the German hook for the register itself, because it requires processes and responsibilities to be documented and kept current, and the ECB guide to internal models sets what a supervisor reads for a model used in the capital calculation. A field nobody uses for a decision is a field that will not be maintained, so the test for each column is which decision depends on it.

A model returns a prediction. An agent takes an action: it queries systems, calls tools and starts a workflow, sometimes with no person in the loop. The inventory has to hold both, and the agent needs fields a model does not: which actions it is authorized to take, which systems it may reach, the limit it cannot cross without a human, and the tested way to stop it.

Duplicates are the practical problem. A second agent built for the same task in another department, an orphaned model whose owner left, and a pilot still running in production months after the project closed all show up as separate risks in an honest register. AI governance in banking sets out who decides which of them stays.

For a high-risk system the AI Act turns parts of the register into a legal obligation. Article 11 of Regulation (EU) 2024/1689 requires technical documentation drawn up before the system goes on the market and kept up to date, with the content set out in Annex IV. Article 12 requires the system to log events automatically over its lifetime, and Article 18 requires a provider to keep the documentation for ten years after the system was placed on the market.

A deployer, which is what a bank usually is, keeps the logs under Article 26 for at least six months unless other law says longer. Credit scoring for natural persons and pricing in life and health insurance are the two Annex III uses that put a bank or insurer in this regime, which the AI Act in finance covers.

Three sources produce almost all of it. A spreadsheet model built by a business unit does real work and passed no governance. A purchased application has a model inside it that the contract never named, so nobody treats it as the bank's model. And a general-purpose AI assistant gets used on customer data by people who did not read it as a system decision.

BaFin's guidance on ICT risks in the use of AI systems from December 2025 places AI inside ICT risk management under DORA, which means an unregistered AI use is an unregistered ICT risk. Discovery works better from the outside in: procurement records, network traffic to AI services, and the data exports a unit requests tend to find more than a questionnaire does.

A model running at a provider appears twice, in two registers with different purposes. The AI and model inventory holds the model, its owner and its risk tier. The register of information under Article 28(3) of DORA holds the contract with the ICT third-party service provider, the function it supports and whether that function is critical or important.

The two have to agree. A model the inventory calls critical, supported by a contract the register of information does not list as supporting a critical function, is a finding in whichever one the examiner opens second. The DORA register of information sets out its fields and its yearly submission to BaFin.

A bought model gets tracked with the same rigor as a built one, and with one extra column: what the provider will and will not disclose. Where the provider gives no training sources and no performance history, the bank's own testing has to carry the whole evidential weight, and the record states that instead of leaving the gap implicit.

Retirement is the step that gets skipped. A decommissioned model has to be switched off everywhere it runs, which includes the copy a team kept for comparison, and its record stays in the register with an end date instead of being deleted. A register with no retired entries is usually a register that lost track of them.

One function owns the register, usually the second line next to model risk, and the entries are owned individually in the first line. Ownership of the list and ownership of the things on it are different jobs, and conflating them is how a register becomes a document nobody updates between examinations.

The control that keeps it current is a reconciliation against a source the register does not control: the process map, the application inventory from IT, the cost centers in the general ledger that pay for AI services, and the procurement contracts. Each mismatch is a question with an answer, and the answers are what a supervisor reads as evidence that the register is maintained and not compiled at short notice.

An AI model inventory is one register of every model and AI system a firm uses, with an identifier, an owner, the purpose, the data the system reaches, a risk tier, the lifecycle stage and the date of the last validation per entry. In a financial institution it also records whether the system is high-risk under the EU AI Act and which ICT provider runs it. It is the document a supervisor asks for before examining any single model.

Not under that name. The Act requires technical documentation and automatic logging per high-risk system under Articles 11 and 12, a record kept for ten years by a provider under Article 18, and logs kept by a deployer under Article 26. Meeting those duties for more than a handful of systems without one register is possible in theory and does not happen in practice, which is why banks build the inventory as the control that carries the obligations.

Continuously for events and at a fixed interval for the reconciliation. A new system, a version change, a new data source, a change of owner and a retirement each update the record when they happen, not at quarter end. The reconciliation against procurement, IT and the process map runs on a set cycle, and the reconciliation result is reported, because an inventory with no reported gaps has usually stopped being checked.

The NIST AI Risk Management Framework, NIST AI 100-1, is voluntary and not EU law, and it treats the inventory as part of its govern function: you cannot map, measure or manage what is not listed. German institutions use it as a checklist against their own control set and keep a mapping document that names, per control, which AI Act article and which MaRisk requirement it answers.