The five AI governance artifacts every Canadian FSI needs.
Regulators, auditors, and enterprise bank clients ask for evidence of AI governance. Five artifact classes — Model Cards, Agent Cards, HITL architecture, AIRSA, and the Governance Operating Model — together satisfy the full evidence demand across OSFI E-23, SR 11-7, NIST AI RMF, and the EU AI Act. This page is the definitional source.
Artifacts, not framework documents.
AI governance consulting historically produced slide decks — principle statements, governance framework overviews, maturity models. Regulators and 2LOD reviewers do not examine slide decks. They examine structured artifacts: version-controlled documents with defined fields, referenced by your deployment pipeline, attributable to named owners, reviewed on a documented cadence.
The five artifacts below are not aspirational. Each is a production-grade output we have delivered inside Canada's Big 5 banks. Each has a specific role in the evidence surface regulators assess.
Model Cards.
The documentation class for an AI/ML model — purpose, data, validation, limits, monitoring.
A Model Card is a structured document describing a single AI or ML model. The format originated at Google / Partnership on AI circa 2019 and has become the de-facto documentation standard across regulated FSI.
In an OSFI E-23 context, the Model Card answers: what is this model, what does it decide, what are its known limits, who validated it, who monitors it. The fields to the right reflect what Big 5 bank 2LOD teams examine — not the public Model Card template with creative-writing padding.
When to use
One Model Card per production model. Applies to statistical models, ML classifiers, deep learning systems, and foundation-model use cases.
Model Card — required fields
- Intended use
- Decision type, materiality, affected population, known off-label uses
- Training data
- Sources, time range, provenance attestation, known biases in training set
- Methodology
- Model family, key hyperparameters, feature list at a level appropriate for validation
- Performance
- Metrics by segment, calibration, benchmarking against baselines
- Known limitations
- Edge cases, failure modes, constraints, discriminatory risk
- Monitoring program
- Metrics tracked, thresholds, review cadence, escalation
- Owner + reviewer
- Named accountable individuals for development and 2LOD validation
- Version + approval history
- Semantic version, approval signatures, deployment date
Agent Cards.
The documentation class for an AI agent — rationale, constraints, escalation, decision boundaries.
Agent Cards are a newer artifact class specific to agentic AI — systems that plan, reason, call tools, and take actions. A single agent may use multiple underlying models (each with its own Model Card), but the agent itself has decision logic, constraint checks, tool affordances, and escalation behavior that the Model Card does not capture.
For any fintech or FSI deploying a customer-facing agent, trading agent, or compliance agent, the Agent Card documents how the agent behaves at the decision boundary — what it will do autonomously, where it escalates to a human, and what constraints apply.
When to use
One Agent Card per deployed agent. Complements, not replaces, the Model Cards of the underlying models.
Agent Card — required fields
- Agent purpose
- What the agent is authorized to do; what it is not
- Constraint set
- Hard limits, soft preferences, explicit prohibitions
- Tool affordances
- External systems the agent can read/write; scope of each tool
- Decision boundaries
- Conditions requiring escalation to a human-in-the-loop
- Fallback behavior
- What happens on uncertainty, constraint violation, or tool failure
- Escalation logic
- Who receives the escalation, with what context, in what SLA
- Logging and audit trail
- What is captured per decision; where it persists; retention period
- Owner + reviewer
- Named accountable individuals
Human-in-the-Loop Architecture.
The system design artifact that documents where humans gate decisions, how pending_approval states work, and what the audit trail captures.
HITL Architecture is a system-design artifact. It documents where in your AI pipeline a human approves, reviews, or overrides a decision before the decision is committed to a downstream system. OSFI E-23 Principle 3, EU AI Act Article 14, and SR 11-7 Section V all require meaningful human oversight of high-materiality AI decisions — but meaningful oversight is an architectural property, not a policy.
The concrete pattern: a pending_approval state persisted between model inference and action commit. The model produces a proposed decision. The decision enters pending_approval. A named human reviews the proposed decision, accompanied by the model's rationale, the relevant Agent Card constraints, and any confidence metrics. The human approves or rejects. Only an approved decision commits. Every step is logged with timestamps, user identity, and decision evidence.
HITL is not a policy document saying “a human will review.” It is a runtime state machine enforced by your production systems, with observable evidence generation. Regulators and 2LOD reviewers examine the logs and the state machine — not the policy statement.
What the HITL Architecture artifact documents
- Decision classes requiring HITL
- Materiality thresholds, risk categories, mandatory-review cases
- State machine
- Model inference → pending_approval → human review → commit or reject
- Reviewer profile
- Who reviews, based on what role, with what training
- Review SLA
- Maximum time in pending_approval before escalation
- Evidence capture
- What is logged at each transition; where it persists
- Override protocol
- Emergency override conditions, additional documentation, post-hoc review
AIRSA — AI Use Case Inventory.
The organizational inventory of every AI use case, with risk ratings, governance status, and ownership.
AIRSA — AI Risk Scoring and Assessment — is the organizational inventory artifact. It enumerates every AI use case in your organization, classifies inherent risk, tracks governance status, identifies owners, and schedules reviews. Regulators asking “what AI do you have in production” expect to see the AIRSA.
A complete AIRSA typically lives in your GRC platform (OpenPages at the Big 5) and is the master reference for the AI Governance Operating Model. Each AIRSA entry points to the Model Cards, Agent Cards, HITL architecture, and validation reports for that use case.
When to use
One AIRSA per organization. Each AI use case has one entry. AIRSA is the spine connecting all other artifacts.
AIRSA — record fields
- Use case identification
- Name, purpose, business owner, IT owner
- Inherent risk classification
- Materiality, affected populations, decision criticality
- Regulatory mapping
- OSFI E-23, SR 11-7, EU AI Act, PIPEDA + Law 25 (AIDA withdrawn Feb 2025) — which apply
- Governance status
- Approved / in review / retired; last review date
- Artifact links
- Pointer to Model Cards, Agent Cards, validation reports, HITL docs
- Monitoring status
- Active monitoring, cadence, latest review outcome
- Next review due
- Scheduled next review; scheduled next validation
Governance Operating Model.
The living document describing who owns what, when reviews happen, how escalations work, and how the whole system is maintained.
The Governance Operating Model is the artifact that ties the other four together. Model Cards, Agent Cards, HITL architectures, and AIRSA entries exist; the Operating Model describes how they are created, reviewed, updated, retired, and reported.
It documents: the 1LOD / 2LOD / 3LOD split for AI risk. The cadence of model revalidation. The escalation paths for incidents. The board reporting format. The AI Governance committee membership and decision rights. The regulator relationship management. The process by which a new AI use case enters AIRSA and exits through decommissioning.
Without an Operating Model, the other artifacts drift. Model Cards go stale. AIRSA entries become inaccurate. HITL architectures are updated in code but not in documentation. Regulators discover the gap through a routine inspection.
Core components
- Governance committee
- Membership, decision rights, meeting cadence, minutes retention
- Three-lines-of-defence map
- 1LOD owns, 2LOD reviews, 3LOD audits — clearly assigned
- Review cadence
- Model revalidation schedule, HITL review, AIRSA refresh frequency
- Incident response
- Classification, escalation, regulator notification, root-cause review
- Board reporting
- Format, frequency, key metrics, escalation thresholds
- Regulatory engagement
- Ongoing monitoring, proactive disclosure protocol, examination response
- Training and capability
- Who is trained on what, recertification schedule
How the five artifacts connect.
AIRSA is the index. Each AIRSA entry references one or more Model Cards (the models used), an Agent Card (if agentic), the HITL architecture document (how humans gate decisions), and the monitoring outputs for the specific use case.
The Governance Operating Model describes the process by which all four are kept current. A change to any one — a model retrain, an agent policy update, a HITL threshold adjustment, a new use case — triggers an operating-model-defined review and updates the affected artifacts.
How the five artifacts map to regulations.
| Regulation | Model Cards | Agent Cards | HITL | AIRSA | Operating Model |
|---|---|---|---|---|---|
| OSFI E-23 | ✓ | · | ✓ | ✓ | ✓ |
| SR 11-7 | ✓ | · | · | ✓ | ✓ |
| NIST AI RMF | ✓ | ✓ | ✓ | ✓ | ✓ |
| EU AI Act | ✓ | ✓ | ✓ | ✓ | ✓ |
| ISO/IEC 42001 | ✓ | ✓ | ✓ | ✓ | ✓ |
| Quebec Law 25 | · | ✓ | ✓ | ✓ | · |
✓ = primary evidence; · = supporting evidence. Specific regulator emphasis varies; this is a practitioner summary of typical review expectations.
Frequently asked about these artifacts.
Do I need all five if my AI footprint is small?
Yes. AIRSA with one entry is still AIRSA. Model Card for your single model. Governance Operating Model — short, but written. The number of artifacts doesn't scale; their depth does.
Where do Agent Cards stop and Model Cards begin?
Model Card describes the model. Agent Card describes how the agent uses the model plus constraints, tool affordances, and escalation logic. An agent using 3 models has 1 Agent Card and 3 Model Cards.
Is a GRC platform the same as AIRSA?
AIRSA is the artifact; the GRC platform is where it lives. AIRSA entries can live in OpenPages, ServiceNow, a custom database, or even a structured git repository for small organizations. The platform is plumbing; the artifact is the content.
Who writes these artifacts — engineers or compliance?
Both. Model Cards and Agent Cards are authored by the engineering team, reviewed by 2LOD compliance. HITL architecture is co-designed by engineering and risk. AIRSA is owned by a governance function. The Operating Model is written at the governance-leader level.
Do these satisfy EU AI Act technical documentation requirements?
The five artifacts together map to the majority of the EU AI Act's Annex IV technical documentation obligations for high-risk AI. Additional regulation-specific fields (conformity assessment outputs, notified body interactions) layer on top.
How long does it take to produce the full set for a new AI system?
Model Card: 1–2 weeks. Agent Card (if agentic): 1 week. HITL architecture: 2–3 weeks if engineering capacity is available. AIRSA entry: 1 day. Operating Model sections specific to the new system: days to weeks. For an organization producing these for the first time, expect 4–8 weeks end-to-end.
Build the five artifacts for your organization.
Every RegCore.AI engagement produces the five artifact classes for the systems in scope — engineered to your pipeline, reviewed by your 2LOD, delivered in weeks, not quarters.