The policy framework built for any organization using AI
Every company using AI needs a policy. Not a suggestion doc buried in your SharePoint or Google Workspace, but a real, enforceable framework.
What's included
Governance & AI ownership structure
Data sovereignty & vendor trust principles
Procurement pathway for AI tools
AI best practices & critical thinking guidelines
Acceptable & prohibited use cases
Incident response procedures for AI
Output ownership & IP guidelines
What belongs in an AI policy
Most AI policies fail in one of two ways. They are written around whichever product was in the news that quarter, so they stop governing anything the moment a vendor ships something new. Or they are so restrictive that staff route around them, which leaves the institution with the same exposure and no visibility into it. The framework below is what survives both.
Protect member data first
The first question a policy has to answer is what may be typed into a tool that sends data somewhere else. Approve tool classes rather than individual products, define what counts as public or anonymized data, and be explicit that member information does not leave the approved set. A policy that only lists blessed products is out of date the week a vendor ships something new.
Stay vendor neutral
Name capabilities and controls, not brands. The moment a policy is written around one product it stops governing the next one, and the next one usually arrives inside a system you already own. A control row per deployed tool is the practical form: what the tool is, what data class it may touch, who owns it, and what state it is in.
Keep humans accountable
AI drafts, a person signs. In a regulated institution the accountable party has to remain a named human for every output that reaches a member, a regulator, or the board. The policy should say who that is by role, not leave it implied.
Common Questions
Should this be a standalone policy or an amendment to our IT policy?
Standalone, in most cases. A standalone policy gets its own owner, its own review cycle, and its own line in the board minutes, which is what makes it enforceable a year later. An amendment appended to the end-user IT policy tends to become invisible. Leave a pointer in the IT policy so the two stay connected, and revisit at the next annual review whether it can be folded back in.
Does it need to cover AI our vendors add to products we already use?
Yes, and this is the clause most policies are missing. Core banking providers and other vendors ship AI features into existing products without the institution procuring anything new. A policy that only governs tools staff go out and adopt does not govern most of the AI already in the building. Give vendor-embedded AI its own position and a control row.
Who has to approve it?
At a credit union this normally means the board, often after an audit or risk committee sees it first. The binding constraint is the board calendar rather than the drafting: packages are typically due to the executive assistant weeks ahead of the meeting. Work backward from the meeting date.
Is this template specific to credit unions?
The template is written for any organization and covers 14 sections including governance, data handling, and procurement. The framework above is what we apply when adapting it for a Canadian credit union, where the board approval path and vendor-embedded AI matter more than they do elsewhere.
A longer treatment of the three tenets is in the write-up on the blog. If you would rather have the policy drafted and taken through your board, that is the first stage of the engagement.