AI Governance Policy Template: What to Include Before Employees Start Using ChatGPT and Other AI Tools

TL;DR

• Between 40–65% of enterprise employees use AI tools not approved by their organization — in financial services, that’s a data protection, UDAAP, and model risk exposure that compounds every quarter without a documented policy
• An AI governance policy must go beyond naming prohibited tools — it needs to specify what data is off-limits, what uses require human review, what records to retain, how exceptions get approved, and what enforcement looks like
• Vendor-embedded AI (Copilot, Salesforce AI, Workday AI) often operates without policy coverage — include it explicitly
• The policy is a control only when employees have attested to it, managers know how to enforce it, and exceptions are tracked

The Gap Is Already There

By the time an organization publishes an AI governance policy, employees have been using AI tools for months. The compliance team has been using ChatGPT to summarize regulatory updates. The credit analyst uses Copilot to draft committee memos. The BSA analyst uses an AI tool to organize SAR narratives.

Some of those tools run on enterprise accounts with contractual data protections. Some run on personal accounts where the data handling terms haven’t been reviewed. Most of the usage hasn’t been inventoried.

Enterprise AI governance research published in May 2026 documented that 47% of generative AI users in enterprise environments access those tools through personal, unmanaged accounts — bypassing enterprise data controls entirely. IBM’s 2025 Cost of a Data Breach Report found 40–65% of employees self-report using AI tools not approved by IT.

In financial services, that’s not an IT hygiene problem. It’s a GLBA data protection exposure, a potential UDAAP violation if AI outputs influence customer-facing decisions, and a model risk gap — all of which compound every quarter without a documented, enforced policy.

Major institutions recognized this early. JPMorgan Chase, Deutsche Bank, Wells Fargo, Goldman Sachs, Citigroup, and Bank of America have all restricted or banned personal ChatGPT access — most while developing enterprise alternatives with contractual data protections. But restriction without a policy specifying what’s allowed, what’s prohibited, and how exceptions get approved isn’t governance. It’s a ban that gets worked around.

This article covers the ten sections an AI governance policy for financial services needs to actually function as a control.

Section 1: Purpose, Scope, and Effective Date

What to include: A one-paragraph statement of why the policy exists (data protection, risk management, regulatory compliance, customer protection), who it covers (all employees, contractors, and third parties accessing company systems), which AI tools and features it applies to, and the effective date.

Why it matters: Scope determines whether the policy applies to vendor-embedded AI (it should) and whether contractors are covered (they should be). Undefined scope creates a gap regulators interpret as a program weakness, not an oversight. If the policy doesn’t say it covers Microsoft Copilot, employees will reasonably assume it doesn’t.

Sample language: This Policy governs the use of generative AI tools, AI-assisted features within third-party software platforms, and AI models used to generate, summarize, classify, or analyze information by all [Company] employees, contractors, and service providers with access to Company systems or data, effective [date].

Section 2: Tool Classification — Approved, Restricted, and Prohibited

What to include: A three-tier classification for AI tools, updated on a documented review cycle:

Why it matters: Most employees don’t know whether a tool is approved — they know it’s available in their browser. The policy needs to tell them explicitly, with a process for requesting additions to the approved list. The approved list must be maintained and communicated when it changes; a list that’s 18 months out of date is not a control. The broader AI governance framework should specify who approves new tools and at what threshold.

Section 3: Prohibited Data Inputs

What to include: An explicit, categorical list of data types that cannot be entered into any AI tool — approved, restricted, or otherwise — without a specific approved exception:

Why it matters: The most common AI-related data breach in financial services isn’t a technical exploit — it’s an employee pasting a customer record, a SAR narrative, or MNPI into a personal ChatGPT session. The prohibited data list is the policy element that directly prevents that failure mode. It needs to be categorical and specific, not aspirational.

The standard to apply: if the data requires special handling under GLBA, HIPAA, or securities law, it’s off-limits for any AI tool without reviewed data protection controls.

Section 4: Approved and Prohibited Use Cases

What to include: Function-specific examples of what AI tools may and may not be used for:

Approved uses (examples):

• Summarizing published regulatory guidance, enforcement actions, or case law for internal briefings
• Drafting internal policy documents or procedures, subject to compliance review
• Generating first drafts of board or management reports, subject to human review and source verification
• Organizing and structuring information from non-prohibited data sources

Prohibited uses (examples):

• Automated customer-facing credit, fraud, or eligibility decisions without documented human review
• Generating SAR narratives using case-specific customer transaction data
• Producing regulatory submissions or examination responses without verification of every cited fact and source
• Creating adverse action notices without legal review
• Using AI to prepare competitive intelligence from confidential client data

Why it matters: The distinction between approved and prohibited isn’t always intuitive — a BSA analyst and a product marketing manager face completely different risk profiles. Use case examples calibrated to actual job functions are more useful than abstract policy language. The AI compliance checklist is a good companion document for employee-level guidance on day-to-day decisions.

Section 5: Human Review Requirements

What to include: A defined requirement that AI-generated outputs used for customer-facing decisions, regulatory filings, board materials, or any external communication must be reviewed, verified, and documented by a qualified human before use. Specify what “review” means: not reading the output and clicking send, but verifying the underlying facts, citations, and conclusions against original sources.

Why it matters: In compliance work, an unverified AI output that contains an error isn’t a minor quality issue — it’s a potential compliance failure with someone’s name on it. NIST AI RMF MANAGE function guidance and the U.S. Treasury’s Financial Services AI Risk Management Framework (February 2026) both require documented human oversight for high-risk AI applications in regulated contexts.

The AI output review checklist provides the specific review steps — source verification, scope confirmation, accuracy check, escalation criteria — that make “human review” a real control rather than a rubber stamp.

Section 6: Customer-Facing AI Disclosures

What to include: Where AI tools are used in customer interactions — automated communications, chatbots, credit decisioning, fraud flagging — the policy must specify:

• Whether customers must be informed they’re interacting with AI
• What disclosures are required for adverse actions driven or influenced by AI (ECOA, FCRA, CFPB guidance)
• Who reviews AI-generated customer communications before transmission, and how that review is documented

Why it matters: EU AI Act high-risk AI provisions effective August 2, 2026 require transparency for automated decision systems affecting individuals. The CFPB’s position under Reg B and ECOA — clarified in 2024 and 2025 guidance — is that AI-driven adverse actions require specific reason disclosure, not generic “AI system” explanations. The policy needs to operationalize these requirements at the use-case level before an examiner asks whether the institution has them.

Section 7: Vendor-Embedded AI

What to include: An explicit statement that AI features embedded in approved SaaS platforms — Microsoft Copilot in Outlook, Salesforce Einstein, Workday’s AI features, ServiceNow’s AI, DocuSign’s AI tools — are subject to the same prohibited data, use case, and human review requirements as standalone AI tools. Require a documented data handling and security review before enabling any AI feature in an existing platform.

Why it matters: Vendor-embedded AI is the most common governance gap in financial services AI policies. Most institutions reviewed standalone generative AI tools — they didn’t revisit whether enabling Copilot in M365 or Salesforce AI carried similar data handling implications. An employee who doesn’t think “Copilot is a ChatGPT equivalent” may use it in ways the organization would classify as prohibited if they recognized the tool for what it is. The AIHR’s AI policy guidance explicitly identifies vendor-embedded AI as a category that requires the same governance treatment as standalone generative AI.

Section 8: Recordkeeping and Output Documentation

What to include: For AI outputs used in regulatory submissions, board materials, customer-facing decisions, or compliance documentation, specify what records must be retained:

• The AI tool used (and model version where available)
• The input or prompt, where it doesn’t contain prohibited data
• The AI output before and after human review and editing
• The name of the human reviewer and the date of sign-off

Why it matters: When a regulator asks how a compliance document was produced, “we used AI and reviewed it” is not a complete answer. The documentation trail must show who reviewed what, what they changed, and what source material they verified. NIST AI RMF GOVERN function guidance requires organizations to document AI use in consequential decisions — not just have a policy that says they do.

Section 9: Exception Approval Process

What to include: A defined pathway for employees who believe a use case not covered under approved uses should be permitted:

• Who reviews exceptions (typically Risk, Legal, and Compliance in a documented consultation)
• What documentation the requester must provide: the specific tool, the use case, what data would be used, proposed guardrails
• Review turnaround time
• How approved exceptions are tracked and periodically rereviewed as part of AI governance reporting

Why it matters: A policy with no exception pathway gets worked around. Employees with legitimate use cases that aren’t covered will find their own solution — often using a restricted tool with prohibited data, outside any oversight structure. The exception process keeps the AI inventory current and the risk team informed. Exceptions that keep coming in for the same use case are a signal that the approved use case list needs to be updated.

Section 10: Training, Attestation, and Enforcement

What to include:

Attestation: Mandatory annual attestation that employees have read, understood, and agree to comply with the policy. Required on hire for new employees.

Training: Role-specific training modules for employees in BSA/AML, credit, compliance, customer-facing functions, and any role that uses AI tools regularly. Training should cover prohibited data examples specific to the employee’s job function — not just abstract categories.

Enforcement: Consequences proportionate to violation severity and intent. A baseline structure:

• First-time inadvertent violation: documented warning, re-training
• Intentional or repeat violation: escalation to management and HR
• Violation involving prohibited data (customer NPI, MNPI, exam materials): immediate escalation, potential separation
• Self-disclosure: treated as mitigating factor, with a clear and accessible reporting path

Incident reporting: Employees should know where to report potential violations — including their own — without fear of disproportionate consequences for good-faith disclosure. An environment where employees hide AI-related incidents compounds the risk.

Why it matters: A policy that hasn’t been attested to is difficult to enforce. Regulators treat employee attestation programs as evidence of governance seriousness. If an employee shares customer NPI with a personal ChatGPT session and claims they didn’t know the policy prohibited it, the absence of a signed attestation is an argument they can make. The Corporate Governance Institute notes that AI policies without enforcement mechanisms and attestation programs are treated as advisory documents — not controls.

So What?

The AI governance policy is the compliance team’s answer to a problem that already exists: employees are using AI tools today, and the question isn’t whether to permit it — it’s whether the use is documented, governed, and connected to a risk program.

A policy that lists prohibited tools but doesn’t specify prohibited data, human review requirements, an exception process, and enforcement is a disclaimer document, not a control. The ten sections above are the difference.

The AI Risk Assessment Template & Guide includes a pre-built Shadow AI Register for inventorying undisclosed employee AI tool use, an AI Use Case Inventory with auto-tiering across 11 risk domains, and 8 pre-written responses to the most common bank partner AI governance questions — so the program behind the policy is as complete as the policy itself. Get it here for $59.