Artificial intelligence is moving faster than most corporate policy processes were designed to handle.

That is especially true in financial services. Employees are already using generative AI. Vendors are putting AI into products that banks have relied on
for years. Business units are experimenting with Copilot, automated analysis, document generation and AI agents. Models are being embedded into workflows that may never have been considered “model-driven” before.

The question for management is no longer whether AI will be used. It’s how will the organization use it responsibly, understand where it is being used, and maintain appropriate control as the technology changes. That starts with a good AI policy.

A good policy should give employees clear rules without trying to predict every technology that will appear over the next five years. It should establish who is accountable, what requires approval, what is prohibited, how risk is assessed, and what evidence the organization needs to demonstrate that its controls actually work.

Stage One: Decide What the Policy Covers

One of the first mistakes companies sometimes make is defining AI too narrowly. They write a policy for ChatGPT or generative AI while ignoring machine learning models, AI capabilities embedded in third-party applications, internally developed systems and new tools being piloted by individual departments. A practical policy starts with broad coverage.

CIMCON’s policy template, for example, applies to AI systems regardless of type or whether they are in development, testing or production. It specifically brings business use of tools such as ChatGPT and Copilot within the governance process. The policy also needs to cover AI that has not yet made it into formal production. Banks are already experimenting with AI in pilots, proofs of concept and third-party applications, and those uses can still involve customer data, influence business decisions or introduce new risks. Governance should therefore apply based on how the technology is being used and the risk it creates, not simply whether someone has classified it as a production system.

Stage Two: Find Out What You Actually Have

You cannot govern what you do not know exists. Maybe it was Socrates who first coined that, but we’ll agree, it does sound obvious. The fact is AI inventory is likely to become one of the harder parts of AI governance because AI can appear anywhere from centrally managed departmental tools to desktop applications. Employees may also experiment with publicly available AI tools without realizing that their use has created a governance issue.

An AI policy therefore needs an inventory requirement. At a minimum, organizations should understand:

• what the AI system is
• who owns it
• what business process it supports
• what data it uses
• what it produces
• who uses it
• whether it was developed internally or supplied by a third party
• what happens if it produces an incorrect result

NIST recommends AI systems to be identified and placed into a centralized inventory, with the inventory maintained as an ongoing process rather than a one-time exercise[ https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf].

That last point is important. The AI environment a bank inventories in January may look very different by June.

Stage Three: Assign Somebody Who Is Accountable

Policies fail when responsibility belongs to everybody; if an AI system has no identifiable owner, problems eventually end up bouncing between Technology, Risk, Compliance, Legal and the business. Someone needs to own the system.

That person does not need to personally perform every test or approve every change, but there should be clear accountability for the system’s use, documentation, controls and ongoing condition.

NIST’s AI RMF Playbook states organizations are to “Establish policies that separate management of AI system development functions from AI system testing functions, to enable independent course-correction of AI systems.”[ https://airc.nist.gov/airmf-resources/playbook/govern/] CIMCON’s framework identifies roles including AI System Owner, Developer, Tester, Reviewer or Department Head, User and Risk Team. The owner is accountable for the system, while independent testers and risk personnel provide validation and oversight.

That structure will look familiar to banks because the underlying idea is not particularly exotic. Good AI governance borrows heavily from disciplines financial institutions already understand: model risk management, operational risk, information security, change management and internal control.

Stage Four: Determine How Much Risk It Creates

Not every AI application deserves the same level of oversight. An internal tool summarizing meeting notes does not create the same risk as an AI system influencing a credit decision. Treating them exactly the same would create two problems. Either low-risk systems become buried in bureaucracy, or high-risk systems receive controls that are too weak.

A good policy therefore establishes a risk classification methodology. Factors commonly considered include:

• Technical complexity. How complicated is the system, and how difficult is its behavior to understand?
• Scale. Is it being used by one person, one department or throughout the enterprise?
• Data. What data goes into the system? Is it sensitive, regulated or personally identifiable?
• Financial impact. What happens if the result is wrong?
• Regulatory impact. Could the system affect compliance obligations?
• Customer impact. Could an error affect a customer, applicant or investor?
• Reputational impact. How would the organization explain a failure publicly?

CIMCON’s policy template combines technical considerations such as complexity, scale and data quality with financial, regulatory and customer impact to produce a final criticality assessment. The higher the risk, the stronger the controls should become.

Stage Five: Put Controls Around the Risk

Once a system has been classified, the policy needs to say what happens next. Common controls include documentation, employee training, access restrictions, version control, backup and retention, independent testing, change management, approvals and segregation of duties.

High-risk applications generally need more formal review and stronger evidence that controls have been completed. AI also introduces some testing requirements that traditional software programs may not have addressed adequately.

Organizations may need to evaluate:

• hallucinations and factual accuracy;
• source attribution;
• data quality;
• bias and fairness;
• privacy;
• cybersecurity;
• explainability and interpretability;
• model or data drift;
• reliability;
• prompt manipulation;
• and whether the system continues to behave as expected after changes.

CIMCON’s policy framework specifically identifies testing in areas including fairness, cybersecurity, privacy, interpretability, explainability, data drift, hallucination, source attribution and LLM risk assessment. It also calls for independent validation rather than relying exclusively on the system owner.

The point is to know what could go wrong and have evidence that somebody checked.

Stage Six: Establish Rules for Generative AI

Generative AI deserves particular attention because adoption can spread extraordinarily quickly. Employees need practical answers to real questions around their ability to use a tool that will increase their productivity exponentially.

• Can I put customer information into a public AI service?
• Can I use AI to draft customer communications?
• Can I summarize confidential documents?
• Can AI-generated code be put into production?
• Do I need to verify an AI-generated answer before using it?
• Can AI make a decision, or must a person review the result?
• Can we use an AI agent that takes actions instead of merely producing information?
• Without clear answers, employees will create their own rules.

Most policies therefore need provisions addressing confidential information, privacy, intellectual property, acceptable use, approved systems, human review, record retention, disclosure requirements and prohibited activities. Some uses should simply be off limits.

CIMCON’s template, for example, identifies prohibited categories including manipulative AI, inappropriate surveillance, malicious deepfakes and misinformation, social scoring and discriminatory applications.

Stage Seven: Deal With Third Parties

Much of a financial institution’s AI risk will arrive through vendors. That creates another important governance question: Who is responsible when your vendor’s AI produces the answer, when the answer cannot be “the vendor”?

The organization still needs enough information to assess how the product is being used, what data is involved, what controls the vendor has implemented and whether the system is appropriate for the intended use. It’s no surprise this can be difficult. Some vendors will provide excellent documentation. Others will provide very little. Large technology providers may offer standardized information but resist completing every questionnaire a customer sends them. AI policy therefore needs to connect with third-party risk management.

Organizations should decide what information is required from vendors, which applications require additional due diligence, what testing can be performed independently and what contractual protections may be necessary.

Stage Eight: Control Changes

An AI system approved today may not present the same risk six months from now. Vendors change models, data changes, and business units often find new uses for existing tools. A system that started as a low-risk pilot can become part of a significant business process without anyone formally deciding to make that transition. Change management should catch that before it becomes a control problem. A sound policy should require significant changes to be documented, reviewed and, when necessary, retested and reapproved.

CIMCON’s template calls for an audit trail showing what changed, why it changed, who made the change, what testing was performed and who approved it.

That discipline matters because six months after an incident, management will not want to hear, “We think somebody changed something.”

Stage Nine: Reassess the System

Periodic reassessment should be part of the governance process. An AI system may look very different a year after it was first approved, even if no one has made a formal change to it. Its use may have expanded, the vendor may have updated the underlying model, the data may have changed, or new regulatory expectations may apply. For higher-risk systems in particular, organizations should periodically confirm that the original risk assessment is still valid and that the required controls remain in place.

CIMCON’s policy template addresses this through periodic attestations, with a documented last assessment date, next assessment date and current status for each AI system.

Where AI Policies Commonly Go Wrong

There are several predictable failure modes which are outlined below.

#1. The policy becomes a legal document nobody can understand. Employees need to know what they can and cannot do. If they need a lawyer to interpret every paragraph, the policy will not govern behavior.

#2. The organization bans everything. Excessively restrictive policies often create shadow AI. Employees still use the technology; management simply loses visibility into it.

#3. The organization approves everything. The opposite problem is treating every AI application as harmless experimentation. Some uses can affect customers, financial decisions, confidential information and regulatory obligations.

#4. There is no inventory. A policy without an inventory is largely aspirational.

#5. There is an inventory but no ownership. Someone needs to be accountable for every meaningful AI system.

#6. Every system gets the same controls. Risk-based governance matters. Otherwise the process becomes too expensive for low-risk applications and too weak for high-risk ones.

#7. The policy stops at approval. AI governance requires monitoring, testing, change management and reassessment.

#8. Third-party AI is ignored. Buying the technology instead of building it does not eliminate the risk.

#9. The policy is frozen in time. The technology will change faster than the policy committee. Principles and governance mechanisms should remain durable even as individual technologies evolve.

The Goal Is Controlled Adoption. Financial institutions should not approach AI governance with the assumption that the safest institution is the one using the least AI because that will eventually become its own business risk. Banks need to experiment. They need to improve productivity. They need to understand where AI can improve operations, risk management, customer service and decision-making.

But experimentation needs boundaries. Management should know where AI is being used, who is responsible for it, how significant the risk is and what controls have been put around that risk.

The institutions that get this right will have policies people understand, processes people can actually follow, and enough automation to make the governance sustainable.

A Practical Starting Point for Financial Institutions

Developing an AI policy from a blank sheet of paper can consume months of meetings across Risk, Compliance, Technology, Legal, Information Security and the business. This article talks about the complimentary AI & GenAI Risk Management Policy template CIMCON has developed to give financial institutions a practical starting point. The template draws heavily from the NIST AI Risk Management Framework and covers AI inventory, ownership, risk assessment, controls, testing and validation, approvals, change management and periodic attestation. Financial institutions can adapt the framework to their own organization, risk appetite and existing governance structure rather than starting from scratch. If your institution is developing or revisiting its AI policy, contact CIMCON and we will be happy to provide a free copy of the template.