If you're deploying AI in financial services, you've likely encountered questions about governance and compliance. The HKMA has introduced the Accountability, Resilience, and Trust (ART) framework, providing clear guidelines for responsible AI governance in banking. These questions stem from real discussions with GRC teams bridging the gap between AI ambitions and regulatory expectations.
Q1: We're not in Hong Kong. Why does this framework matter to us?
The ART framework is a detailed guide on what regulators expect for responsible AI governance.
The HKMA's three pillars, effective governance and accountability, proportionate management of AI risks, and building trust and transparency, reflect themes you're already encountering with your regulators. The EU AI Act categorizes systems by risk, and the NIST AI Risk Management Framework emphasizes trustworthiness. Your board is likely asking about accountability.
The ART framework is operationally specific. It requires clear ownership and decision-making authority, not just a general call for governance. If you're developing an AI governance program, this framework offers a defensible structure that aligns with global expectations. Your regulator might not mention the HKMA, but they're asking similar questions about model ownership, testing, and decision explanations.
Q2: What does "effective governance and accountability" mean for a machine learning model?
It means you can answer these questions: Who approved this model? Who's accountable if it fails? How do you ensure it's performing as intended?
Accountability under the ART framework involves clear ownership and authority. For example, with a credit decisioning model, you need someone accountable for design choices, performance monitoring, and authority to remove it from production if issues arise.
This aligns with ISO/IEC 42001 requirements for AI management systems, which outline roles and responsibilities. The HKMA specifies that governance structures must match the AI system's risk level. A chatbot needs lighter governance than a loan approval model.
Your governance documentation should outline decision rights at each stage, development, validation, deployment, monitoring, and decommissioning. Listing "the AI team" as accountable doesn't meet the standard.
Q3: How do we make AI systems "resilient" when they're probabilistic?
Resilience in the ART framework means secure adoption that operates safely, fails safely, and recovers effectively. It's about designing systems that degrade gracefully and maintain safety even when predictions are wrong.
Start with safe failure. If your fraud detection model fails, does your system block or allow all transactions? Neither is safe. Resilient design includes fallback logic, like reverting to a rule-based system or manual review, maintaining continuity without unacceptable risk.
Recovery effectiveness requires knowing when a model fails. This involves continuous monitoring, automated alerts for performance degradation, and documented rollback procedures. Your incident response plan should treat model performance issues like security incidents, with defined severity levels and recovery objectives.
The NIST Cybersecurity Framework 2.0 includes AI-specific considerations in its Recover function. Apply those principles: define recovery for each AI system, test procedures, and document lessons from failures.
Q4: Our vendor says their model is explainable. How do we verify that claim?
Test it with real decisions, not vendor demonstrations.
The ART framework's trust pillar emphasizes transparency and explainability. Explainability varies by use case and regulatory context. A vendor might offer feature importance rankings, but can your compliance team use those explanations for customer complaints or regulatory inquiries?
Here's a test: Take five actual decisions, three approvals and two denials. Ask the vendor to explain each decision in terms your staff can understand. If the explanation is "the model assigned a risk score based on 47 factors," you lack explainability. If it's "the application was denied due to a high debt-to-income ratio and recent credit inquiries," you're closer.
For high-risk applications, you need decision-specific explanations on demand, not just summaries. Document the explainability level each AI system provides, map it to your regulatory obligations (like the General Data Protection Regulation's right to explanation), and identify gaps before regulators do.
Q5: We're already doing model risk management. Is this just MRM with different terminology?
No. Traditional model risk management focuses on validation, monitoring, and documentation. The ART framework adds governance accountability, operational resilience, and stakeholder trust as core requirements.
Your MRM program likely includes backtesting and sensitivity analysis. But does it specify who can override a model's recommendation? Does it include procedures for communicating model limitations? Does it address maintaining customer trust when a model's decision seems unfair?
The ART framework's accountability pillar requires governance structures with clear authority. The resilience pillar requires safe failure and effective recovery, beyond monitoring. The trust pillar demands transparency and fairness, often secondary in traditional MRM.
Think of MRM as necessary but not sufficient. You need technical rigor plus the governance clarity, resilience, and transparency the ART framework specifies.
Q6: How do we implement this proportionately? We have dozens of models.
Start by categorizing your AI systems by risk, then apply governance intensity accordingly.
The HKMA calls for proportionate AI risk management. You don't need the same governance for a marketing engine as for an anti-money laundering system.
Create a risk classification scheme based on impact and autonomy. High-impact, high-autonomy systems need full ART implementation: board-level accountability, comprehensive resilience testing, detailed explainability documentation. Lower-risk systems can use lighter governance.
Your classification criteria should include regulatory significance, financial impact, customer impact, and human oversight. Document your rationale because regulators will ask why systems are treated differently.
Build your implementation roadmap starting with high-risk systems. You don't need full ART compliance across your AI portfolio at once, but you do need a defensible plan and progress.
Where to go from here
Review the HKMA's Supervisory Guidance for Responsible Adoption of Artificial Intelligence for complete framework requirements. Cross-reference with ISO/IEC 42001 for AI management structure and the NIST AI Risk Management Framework for trustworthiness. If subject to the EU AI Act, map high-risk systems against both frameworks to identify common requirements.
The questions your team is asking won't disappear. The ART framework provides a structure for answering them with specificity.
