AI/ML engineering · Governance
AI model risk management, validation and monitoring
We build AI model risk management, validation and monitoring for banks and regulated firms: a model inventory with tiering, validation workflows and evidence, ongoing monitoring of performance, drift and fairness, evaluation for generative AI and a governance workflow that produces what supervisors and auditors ask for. It turns policy on paper into controls in the systems that run the models, and you own the platform and the code.
Checklist · AI readiness
Enterprise AI readiness and governance checklist
A checklist for enterprises planning machine learning, language model or agent projects: use case, data, hosting, security, evaluation, human oversight, governance, monitoring and cost.- 01Nine areas to settle before a model goes near production.
- 02The security items specific to language models and agents.
- 03Evaluation and monitoring questions that regulators and auditors ask.
- 04Seven questions to put to any vendor or development partner.
Free download
Get it on screen in a few seconds.
What the system does, module by module.
- 01
Model and AI use-case inventory
A register of every model, tool and generative AI use case, with owner, purpose, data, vendor, status and the decisions it influences. - 02
Risk tiering
Classification by materiality and risk, such as impact on customers, capital or compliance, which sets the depth of validation and monitoring. - 03
Development documentation
Templates and capture of model purpose, data, methodology, assumptions, limitations and testing, produced as part of development and not after it. - 04
Independent validation workflow
Assignment, scope, tests, findings and remediation, with conceptual soundness, outcomes analysis and benchmarking evidence stored and linked to the model version. - 05
Performance and drift monitoring
Automated tracking of accuracy, calibration, stability of inputs and outputs and business outcomes, with thresholds and alerts by tier. - 06
Fairness and conduct testing
Tests for unequal outcomes and proxy effects, with documented thresholds and mitigations, repeated on a schedule. - 07
Generative AI evaluation
Test sets, red-teaming results, grounding and hallucination measures, safety checks and monitoring of prompts and outputs in use. - 08
Change management and approvals
Gates for releasing a new model or version, with approvals by tier, and a record of what changed, why and who signed. - 09
Findings, issues and reporting
Tracking of validation findings and incidents to closure, and reports to the model risk committee, internal audit and supervisors.
Reference architecture.
Standards and interfaces
What we design against.
- SR 11-7 and OCC 2011-12
- US supervisory guidance on model risk management covering development, validation, governance and use, widely used as a reference outside the United States.
- PRA SS1/23
- The UK Prudential Regulation Authority's model risk management principles for banks, including AI and machine learning models.
- EU AI Act
- Risk-based obligations for AI systems, including high-risk uses in credit and employment, covering documentation, human oversight and monitoring.
- NIST AI RMF and ISO/IEC 42001
- Frameworks and a management system standard for AI governance, mapped to the platform's controls.
- HKMA and other supervisory guidance on AI
- Local expectations on governance, fairness, transparency and customer protection in the use of AI.
- OWASP Top 10 for LLM Applications
- Security risks for generative AI applications, included in evaluation and monitoring.
Data model
The core entities.
- Model and use case
- Identifier, owner, purpose, tier, data sources, vendor, status and decisions affected.
- Model version
- Code, data and parameters snapshot, documentation, approval and release date.
- Validation
- Scope, validator, tests, evidence, findings, rating and sign-off.
- Monitoring metric
- Metric, window, value, threshold, status and the model version observed.
- Fairness or evaluation result
- Test, group or task, result, threshold and mitigation.
- Finding and action
- Description, severity, owner, due date, status and closure evidence.
- Approval and change
- Change description, gate, approvers, decision and effective date.
When custom development is the right call.
Controls designed in, not added later.
Independence
Validators and developers are separate roles, and the system prevents self-approval of a model or a finding.Tamper-evident evidence
Validation evidence and approvals are stored with the version they relate to and cannot be altered.Access by role
Model data, including sensitive customer data used in testing, is restricted to those who need it.Controlled release
A model cannot be promoted to production without the approvals its tier requires.Retention and audit trail
Records are retained for the period supervisors expect, and every action is logged.
From discovery to a system you run.
- 01
Policy and landscape review
We review the model risk policy, the models and AI uses in place and the evidence supervisors have asked for, with risk, validation and model owners. - 02
Inventory and tiering
The inventory is built and models are tiered, which shows where validation and monitoring effort should go. - 03
Workflow and evidence capture
Documentation, validation and approval workflows are built, and evidence capture is connected to the modelling environment. - 04
Monitoring and evaluation
Automated monitoring and evaluation are added for the highest-tier models and generative AI uses first. - 05
Reporting and continuous improvement
Committee and supervisory reporting is generated from the platform, and the policy is refined from experience.
Relevant work
Where to see our work.
Related
Keep reading.
Common questions.
- Does model risk management apply to generative AI?
- Yes. Supervisors and standards bodies expect generative AI uses to be in the inventory, tiered and tested. The tests differ, with evaluation sets, red-teaming and monitoring of outputs in use, but the governance logic is the same.
- How much monitoring is enough?
- It depends on the tier. High-tier models need regular performance, stability and fairness checks with alerts. Lower tiers need lighter periodic review. The platform applies the policy by tier so effort follows risk.
- Can the platform work with the tools our data scientists use?
- Yes. Evidence such as parameters, data snapshots and test results is captured from the modelling and deployment tools through their interfaces, so developers do not retype it.
- Does it replace our model risk function?
- No. It gives the function an inventory, workflows, evidence and monitoring so that its time goes to judgement and challenge rather than chasing documents.
- Who owns the code?
- You do. The code, the workflows and the data stay yours.