AI governance policy template, including who may approve licensing company data

When a company needs this policy

A mid-market company needs a written AI policy as soon as employees use generative AI tools on company information, which in most offices is already happening. The policy usually gets drafted when something lands on the CFO's desk: a sponsor asking for an AI governance update, a customer security questionnaire about AI use, a software renewal that adds AI features to the vendor's terms, exit preparation, or an inquiry about licensing company data.

Most templates stop at inbound use, meaning what staff may put into AI tools. That leaves a gap. Nobody is named as the person who can approve sending company records out to train someone else's models, and that decision deserves the same discipline as any other use of a company asset.

The regulatory backdrop keeps moving. California's privacy agency lists regulations on risk assessments, cybersecurity audits and automated decisionmaking technology that took effect on January 1, 2026, with some compliance deadlines phased in from 2027 to 2028. Companies with EU customers or operations should also track the EU AI Act, whose application dates have been amended since adoption, so check the consolidated text. And FTC staff have stated that companies' promises not to use customer data for undisclosed purposes, such as training models, are enforceable wherever those promises are made (January 2024 staff post, not a rule).

This is general information, not legal, tax or financial advice. Confirm with your own counsel before adopting any policy.

Part A: the inbound policy

Replace each {placeholder} with your own details. Part A is a conventional acceptable use and governance section.

Part B: the outbound data clause

Part B governs the opposite direction: company records leaving the company for someone else's AI work. It does not decide whether to license; it decides who may say yes and on what evidence.

B9 matters more than it looks. Advisers, board members and sponsor representatives can be referral partners, and a written disclosure keeps the approval clean.

How to tailor the template

Three company types need extra lines:

• PE-backed portfolio companies. Name the sponsor's representative as a consulted party and align {board_trigger} with the reserved matters in the shareholder agreement.
• Buy-and-build platforms. Apply Part B to every subsidiary and record which entity owns each dataset; integration archives such as M&A integration records often span several entities.
• Agencies, outsourcers and BPOs. State that client-owned records are outside Part B unless the client consents in writing.

Rollout timeline

What never to include in the policy

• Named data buyers or prices; those belong in individual agreements.
• A standing pre-approval for licensing records. Each license needs its own review under B2 and B3.
• Customer-facing promises the company cannot keep, such as never sharing any data in any form, if it may later license de-identified records.
• Examples copied from real customer records or tickets.
• Referral reward amounts or the commercial terms of any partner arrangement.

How Part B connects to a licensing decision

When a company does explore a license, the data rights documentation guide lists the paperwork B3 depends on, and board approval for a data license covers the step B2 triggers. The page on exclusive licenses and a future sale explains why exclusivity is a sensible board trigger. Project-heavy firms should read customer implementation project records before scoping, and what an AI data buyer is describes who sits on the other side of the agreement.

Next step

Adopt the policy, then use it. If a company you advise has years of its own records and a sponsor ready to run Part B, check who qualifies and register as a partner to introduce it, or have the company apply at sourcex.si/apply.