OCC AI Risk Management Guidelines: What National Banks Must Do

What OCC-aligned AI risk management means in practice

A defensible AI compliance program should show how each AI system is governed from intake through production use, monitoring, change, and retirement. The control depth should be commensurate with materiality, customer impact, autonomy, data sensitivity, and whether the system supports a critical activity.

Core control domains for national bank AI programs

1. Inventory and risk tiering

   Maintain a centralized AI inventory that records the business owner, provider, deployment environment, data sources, connected tools, access permissions, risk tier, and production status. Risk tiering should consider regulatory exposure, customer impact, criticality, data sensitivity, and autonomy level.

2. Model risk management

   Where AI functions as a model or decision-support system, apply model risk controls for development, implementation, use, validation, monitoring, and governance. Validation should be independent from development and use, with scope and rigor aligned to model importance and risk.

3. Third-party and fourth-party oversight

   AI vendors, hosted model providers, external APIs, plugins, and data processors should be managed through planning, due diligence, contract negotiation, ongoing monitoring, and termination. Banks should also consider subcontractors and other fourth-party dependencies when arrangements create material risk or support critical activities.

4. Cybersecurity and access control

   AI systems should inherit bank-grade controls for identity, authorization, configuration, logging, monitoring, communications protection, and supply chain risk. Least privilege should distinguish the human user, AI application, model, agent identity, data source, and downstream tool.

5. Operations and resilience

   Production AI services should be governed like other critical technology services, with change management, monitoring, logging, resilience planning, service-level review, and escalation paths. Runtime failures, anomalous behavior, and unsafe tool use should be visible to operational-risk and security teams.

6. Incident response and notification

   AI-related events should be triaged under established incident criteria. OCC-regulated banking organizations must notify the OCC as soon as possible and no later than 36 hours after determining that a qualifying computer-security notification incident has occurred.

How to operationalize AI governance without blocking approved use cases

For AI systems and AI agents, governance should be tied to the way the system actually behaves in production. That includes access to data, connected tools, workflow triggers, monitoring, exceptions, and the evidence retained for review.

Controls should make it possible to enforce approved use, distinguish human and agent permissions, review changes before production deployment, and escalate events through established bank processes.

AI agent governance for banks

• Use scoped agent identities: Avoid shared credentials. Assign agent or service identities with permissions limited to the approved use case, user context, data domain, and tool set.
• Separate inference from execution: Where possible, separate model output generation from action execution. Apply policy checks before sensitive retrieval, external transactions, privileged operations, or workflow changes.
• Require tool approval workflows: Define which tools an agent may call automatically, which require human approval, and which are prohibited. Approval evidence should include the request, policy decision, approver, and final action.
• Log prompts, retrieval, and tool calls: Capture tamper-evident or immutable logs for prompts, responses, retrieved content, authorization decisions, tool calls, exceptions, overrides, and reviewer actions.
• Test failure and abuse paths: Before production, test authorization failures, prompt-injection attempts, excessive tool calls, sensitive-data access attempts, logging completeness, and escalation procedures.

Evaluation criteria for AI compliance controls

When assessing control coverage, risk, compliance, security, and technology teams should be able to answer practical questions about enforcement, monitoring, change control, and evidence.

• Can policies be enforced across prompts, retrieval, data access, tool calls, agent actions, and workflow triggers?
• Can least privilege be applied by user, agent, application, model, data source, tool, and risk tier?
• Can the bank produce audit-ready records showing approvals, policy decisions, access, actions, blocks, escalations, and reviewer activity?
• Can monitoring support security, operational-risk, and incident-response triage for anomalous AI behavior?
• Can third-party and fourth-party AI dependencies be identified, monitored, and tied to approved use cases?
• Can changes to models, prompts, tools, permissions, vendors, and policies be reviewed before production deployment?

Evidence risk and compliance teams should maintain

Evidence should connect governance decisions to production behavior. Useful records include approvals, policy decisions, access, actions, blocks, escalations, reviewer activity, prompts, responses, retrieved content, authorization decisions, tool calls, exceptions, overrides, and final actions.

For production AI services, evidence should also support monitoring, logging, resilience planning, service-level review, incident-response triage, and change review for models, prompts, tools, permissions, vendors, and policies.

Where Trussed AI fits

If your national bank is moving AI systems or agents into production, evaluate whether governance decisions are enforceable at runtime and whether the resulting evidence is examination-ready.

Runtime governance is most useful when it supports policy enforcement for prompts, retrieval, data access, tool calls, agent actions, workflow triggers, exceptions, and audit evidence without blocking approved use cases.