Most AI governance frameworks focus on pre-deployment approvals. Few address what to do when an autonomous workflow fails at 2 a.m., routing a customer escalation through systems you didn't know it could access.
This checklist fills that gap. It's for model risk and assurance teams moving from static model oversight to real-time execution control. Use it to assess whether your institution can monitor, govern, and defend AI behavior once agents are embedded in operating processes.
What This Checklist Covers
You're not just validating a model's accuracy on a test set. You're ensuring that when an AI agent calls a tool, retrieves data, or routes an exception, your institution knows what happened, who authorized it, and what to do if it breaks.
This is important because the focus is shifting from evidence of controls to evidence of decision quality. SR 11-7, DORA, and the EU AI Act all require you to reconstruct how an automated decision was made and whether it can be defended after the fact.
Prerequisites
Before using this checklist, confirm:
- You've identified at least one workflow where AI executes actions (not just provides recommendations).
- You have access to the system logs, application IDs, or telemetry layer for that workflow.
- You can name the business owner, not just the technology owner.
- You understand what data sources the workflow accesses.
If you can't meet these prerequisites, start there. You can't govern execution you can't observe.
Execution Control Checklist
Inventory and Visibility
1. Can you list every AI workflow with execution rights in your institution?
Not just approved use cases. Every workflow where AI can call tools, route work, escalate exceptions, or trigger actions with reduced human intervention. Include co-pilots, local agents, and user-configured workflows that have moved from research to recurring operational use.
Good looks like: A tiered, risk-based inventory distinguishing between research prompts and workflows affecting customer interaction, regulated reporting, trading support, or financial crime disposition. Each high-risk workflow has an application ID, owner, and change control record.
2. Does your inventory update faster than your approval cycle?
If your AI inventory is a quarterly spreadsheet, it's a register, not a control. You need live visibility into what's running, where it's running, and when usage patterns change.
Good looks like: Telemetry that flags when a workflow's token usage spikes, when a new data source is accessed, or when an agent begins calling tools it wasn't provisioned for. Your second and third lines can see this without waiting for the next governance committee meeting.
Authority and Accountability
3. For each high-risk workflow, can you name the individual who owns the process outcome?
Not the developer. Not the AI program lead. The person accountable if the workflow produces a wrong decision, accesses unauthorized data, or fails mid-execution.
Good looks like: A documented chain of responsibility mapping process builders, coders, process owners, risk functions, and technology teams to specific workflows. When a workflow crosses business, risk, compliance, and technology silos, escalation paths are defined in advance.
4. Does the agent have defined entitlements, or does it inherit the user's permissions?
If an agent can access everything the user can, you've created a privilege escalation risk. Treat agents like digital employees: onboard them, permission them, monitor them, and map them to an owner.
Good looks like: Each agent has its own identity, a documented set of tool permissions, and access restrictions tied to the workflow's risk tier. You can revoke an agent's access without revoking the user's access.
Run-Time Controls
5. Can you test prompts and outputs before they reach production?
Generative systems introduce unpredictable behavior into everyday work. You can't assume a prompt that worked yesterday will work safely tomorrow.
Good looks like: Prompt-injection testing, output review, and deterministic verification layers embedded in the workflow. High-risk outputs trigger a human review or a secondary validation step before execution.
6. Do you log enough data to reconstruct the basis for a decision?
Policy manuals don't control an agent at the point it retrieves data or routes an exception. Logs do. You need machine data: prompts, outputs, connector activity, entitlement changes, data sources accessed, and tool calls made.
Good looks like: Audit records that show not just that a control existed, but how the decision was formed. If a regulator asks why a workflow flagged a transaction, you can show the data inputs, the reasoning chain, and the human review (if any) that followed.
7. What happens when the workflow fails mid-execution?
Does the system stop? Roll back? Escalate to a human? Allow another workflow to intervene? The answer must be tested, not assumed.
Good looks like: Documented failure modes, tested recovery procedures, and evidence that the escalation path works. If an agent can't complete a customer request, it doesn't leave the customer in limbo or route the request to a system that wasn't designed to handle it.
Data and Telemetry
8. Can you identify drift in agent behavior over time?
Token usage, model selection, data source access, and tool-calling patterns are not purely technology metrics. They're indicators of scale, cost dynamics, adoption, and emerging concentration risk.
Good looks like: Dashboards that flag when a workflow's behavior changes: accessing new data sources, calling tools more frequently, or consuming tokens at a rate inconsistent with its documented use case. Your risk function sees these signals before they become incidents.
9. Do you apply data access restrictions at the workflow level?
An agent approved for fraud monitoring shouldn't have access to all customer records. Scope data access to the workflow's documented purpose.
Good looks like: Data minimization controls that restrict each workflow to the datasets it needs. If an agent attempts to access data outside its scope, the request is logged and blocked.
Common Mistakes
Treating AI governance as model governance. Model validation remains necessary, but it doesn't tell you whether an agent has the right entitlements or what happens when it fails mid-execution.
Forcing accountability onto a single owner. Cross-functional workflows require cross-functional accountability. Placing it on the person least able to control the outcome doesn't make the institution safer.
Waiting for the next committee meeting. If your governance cycle is slower than your adoption cycle, you're governing last quarter's AI landscape, not this quarter's.
Assuming the control works. Test your recovery procedures. Simulate a failure. Confirm that the escalation path routes to a human who knows what to do.
Next Steps
Pick one high-risk workflow. Walk through this checklist. If you can't answer a question with specifics, that's your control gap.
Then ask: If this workflow failed tomorrow, could you reconstruct what happened, who authorized it, and what data it used? If the answer is no, you're not ready to scale.
The firms that will scale AI safely aren't the ones with the most approvals. They're the ones that can make AI execution observable, defensible, and recoverable before scale turns a local weakness into an enterprise control failure.
