Inventory update: new version detected on agent Explainable Credit Scoring (v2.1.3 → v2.2.0). Prompt updated. KB unchanged. Risk tier: high. Inventory updated.
AGENT · MODEL RISK INVENTORY AND TIERING
The agentic systems inventory stays current with risk tiering.
Model Risk Inventory and Tiering maintains the registry of every agentic system deployed in the bank: active agents, current version, prompt and knowledge base in use, risk tier (low, medium, high). It updates automatically on version changes. Aligned with ECB/EBA model risk management guidelines as transposed nationally.
Model Risk Inventory at work.
Confirmed. Add note: update approved by the risk committee on 14 May.
Note recorded in the inventory registry. Evidence available for regulatory inspection.
Why it exists.
Banks face mandatory model risk management obligations. ECB and EBA guidelines — transposed into national supervisory frameworks — require an inventory of models used for material decisions, risk tiering for each model, and lifecycle governance. For banks running agentic AI systems, each agent falls within that perimeter: it must be inventoried and assigned a tier.
How it keeps the registry current.
For every agent deployed in the bank's Polyant runtime, the agent records the current version, the versioned prompt, the knowledge base in use, and the assigned risk tier. On any version change — prompt modification, knowledge base update, new agent deployment — the inventory updates automatically. The output is a registry inspectable in real time by the risk team, the compliance team, and internal auditors.
Validation stays with the committee.
The agent classifies and updates the registry. Validation by the model committee on version changes stays with the model risk team. The agent sets the table: it updates the registry, flags material changes, prepares the evidence for inspection.
The functions that govern model risk for AI in banking.
Head of model risk
Has a real-time, current inventory — without depending on manual updates from development teams. Material version changes arrive flagged with the tier classification already proposed.
fnol.receive 09:14:22 ALLOW
triage.classify 09:14:25 ALLOW
idd.check 09:14:31 WARN
liquidation.propose 09:15:02 ALLOW
SELECT * FROM audit_log WHERE claim_id = '2024-0847'
Internal and external auditors
Find structured evidence ready for regulatory inspection: versions, prompts, tiering, rationale. The registry is inspectable with a standard SQL client — no manual evidence reconstruction at each audit.
Proposal no. 2024-081 In review
Missing disclosure
MiFID II art. · regulated financial instrument
Alt. 1 …in compliance with MiFID II and applicable supervisory provisions.
Alt. 2 …with full disclosure attached to the offer document.
Audit trace recorded · 14:31
Compliance officer
Sees, in a single registry, coverage of agentic systems against model risk management obligations. Inventory gaps become visible before the inspection, not during it.
KYC case KYC-2024-091 In verification
ID document VERIFIED
Biometrics · SCA PSD2 LINKING OK
Beneficial owner BUSINESS REGISTRY
Case forwarded to AML Screening
A version change that enters the registry without manual intervention.
Wednesday morning: new deployment on the credit scoring agent.
For the model risk function at a bank with fifteen active AI agents, a version update to the LLM underlying the credit scoring agent is deployed on a Wednesday morning by the IT team. At deployment, Model Risk Inventory activates. It reads the new version: updated prompt, same LLM, unchanged knowledge base.
Tier high for material prompt variation.
The agent compares with the previous version and identifies the material change in the prompt. It classifies the change: tier high, given the impact on credit decisions and a prompt variation that requires model committee validation. The head of model risk receives a notification on the work channel with the change detail, the tier classification, and the validation request.
The head validates. The registry records.
The head opens the internal approval process. The committee's validation is recorded in the inventory registry changelog. The full event — deployment, detection, classification, validation — stays in the runtime audit registry for regulatory inspection.
Declarative tiering criteria written by the bank's model risk team.
Model Risk Inventory's rules are declarative. The bank's model risk and compliance team defines in readable format the tiering criteria (decision on natural person, value thresholds, regulated sectors), the registry format, and the notification rules for version changes. Rules live in the bank's repository, versioned, and validated at agent startup. Integration is native with the Polyant runtime: the agent reads the deployed agents registry directly, with no dependency on manual reporting from development teams. For banks with existing model risk systems (SAS Model Risk Management, proprietary systems), the agent can feed them in parallel via a dedicated adapter built during delivery.
- Language
- TypeScript (Node.js)
- LLM model
- customer's choice: Anthropic, OpenAI, Mistral, open source models hosted internally, AWS Bedrock for a private model
- Built-in controls used
- pii-detector, credential-detector, tool-rate-limit
- Native notification channels
- Slack, Telegram, OpenAI-compatible HTTP
- Polyant runtime integration
- native, direct read of the deployed agents registry
- External model risk systems
- dedicated adapter built during delivery (SAS Model Risk Management, proprietary bank systems)
- Memory
- persistent per instance, pgvector + PostgreSQL FTS
- Registry
- append-only, queryable with a standard SQL client (regulatory audit-ready)
Frequently asked questions about the agent.
No. Model Risk Inventory integrates with existing model risk systems (SAS Model Risk Management, proprietary bank systems) via a dedicated adapter built during delivery, or operates as a dedicated registry for agentic systems only if the bank has no centralised tool. The goal is to close a coverage gap: traditional model risk systems are not designed to track prompt versioning and knowledge base changes in AI agents.
Tiering criteria are declarative and written by the bank's model risk team, based on ECB/EBA guidelines: decision on natural person, value threshold, regulated sector, decision reversibility. Criteria are written in the bank's repository in readable format, validated at startup, and updated whenever guidelines evolve.
The typical pattern is 8-14 weeks. Discovery 2-3 weeks (mapping existing agents, tiering criteria), registry and declarative rules configuration 3-4 weeks, optional integration with existing model risk systems 2-4 weeks, hand-off to the model risk team 1-2 weeks. Actual duration depends on the number of active agents and the presence of pre-existing model risk systems.
From a 30-minute conversation to the squad in production.
A 30-45 minute conversation to understand how Model Risk Inventory and Tiering would configure to the bank. How many agents in the runtime, which tiering criteria, which registry format.