.jpg)
Most banks can now produce an AI policy. Ask for it and someone will have a document ready, reviewed by legal, with a three-page outline on what they believe the AI is allowed to do or not do.
Ask slightly different question instead, like what will happen in the system when the AI tries to do the thing their policy said it can’t. Most will probably find that question a little harder to answer, resulting in the gap where agentic AI compliance is needed the most.
Here's the test to run on any guardrail before you trust it: could you hand an examiner your actual system, not just the documentation about how the system works, and have it hold up. A policy will tell you what should happen in theory. It doesn't always tell you what stops the opposite from happening, and whether the stop will hold up.
Run it against a policy document first. A written rule that an agent shouldn't approve a transaction above a certain threshold isn’t a true guardrail until something in the system can block the transaction or route to a person before it executes.
Run it against "human in the loop" next. A human in the loop after the decision has executed can’t be your primary point of oversight. It acts as a review of something that already happened, which can be useful for learning, but useless for prevention. The test doesn't ask whether a human was involved, but when.
Most guardrail claims fall apart when it comes to enforcement, which is why you must be specific about which claims exist in structure versus are aspirational.
Three mechanics tend to hold up when you run the test against them.
Pre-execution sign-off. Put into place a hard stop that requires your human in the loop to make a decision before the AI action is allowed to proceed.
Audit logging that happens automatically on the system running. If your audit trail depends on a person choosing to record something, it’s already too far behind on keeping the bank compliant.
Scoped permissions. An agent handling account opening can’t have the same ability to go into the core system that a banker would have for the same task. Narrower access by design means there's less that needs to be caught by a guardrail in the first place.
All of this depends on what sits in the layer around the core, how agentic decisions get routed, what triggers a true stop, and what writes to the audit logs.
An examiner won’t grade your bank on intentions alone. They’ll be looking to see what systems your bank built around the execution and how those prevented any mishaps. Run the tests on your own stack before someone else comes and runs it for you.