Checklist for discussing AI governance at the board level

Hello, this is Legal Agent.

AI governance is no longer just a front-line tool-usage rule; it belongs at board level. AI use involving customer information or trade secrets, or AI touching individual rights directly, as in hiring or healthcare, tends to come back as company-wide risk if left to a single department. This is not about stopping AI use but deciding what work it is used for, what risk is managed, and what value is created, so the discussion should put business, legal and reputational considerations on the same table.

Spell out the purpose of use

Start with what the company uses AI for: efficiency, a core feature of a new service, customer support, internal knowledge search, or development support. The risk differs by use case. The board should avoid stopping at an abstract word like "DX": only tying AI use to a specific function, such as contract review or a product feature, lets it identify what risk to manage and what controls to fund. Whether AI is positioned as an internal efficiency tool or as central to product value should be decided here too, since that weight drives how much to invest in controls.

Input data and information management

Input data is one of the most important points, since entering personal information, trade secrets, or M&A and fundraising information into AI creates information-management risk. The board should confirm what data categories may be entered, which AI services may be used, whether personal accounts are permitted or an enterprise contract required, and how logs are managed. Leaving personal-account use unchecked means the company cannot know who entered what, making a suspected leak impossible to investigate. Where data goes to an external AI service, contract terms, training use and incident response should be checked too, in coordination with IT and security.

How output is used, and human review

How AI output is used is another line to draw: internal reference, shown to customers, contract or policy drafting language, or input to hiring decisions. The further downstream the use, the larger an error's impact. The board should separate work where output can be used as-is from work requiring human review, building in confirmation especially for legal judgment, healthcare or important customer interactions. AI output reads naturally, which makes an embedded error easy to miss, so deciding function by function how much to rely on it is worthwhile.

Contracts and training that make the policy work

Making governance effective needs three layers: reviewing AI service contracts, building internal rules and guidelines, and explaining them to employees. The rules are where things stall. A policy alone does not tell staff whether a customer contract may be summarised by AI or a personal-data inquiry may be entered, so translating these into concrete guidelines and FAQs is what lets staff decide. The board should look past whether a policy exists to whether training has happened and how violations are handled.

Ten items for the board to check

• the purpose of AI use and the business functions involved
• which AI services are used and under what contract terms
• what data may and may not be entered
• handling of personal information, trade secrets and customer information
• the scope of permitted output use and human review
• the state of internal rules, guidelines and training
• log management, audit and incident response
• terms of use and privacy policy where the company provides an AI service
• reputational risk and customer explanation
• a mechanism for periodic review

Not every item needs a complete answer; identifying which ones cannot yet be answered is itself the first useful outcome of a board discussion on AI governance.

Set a trigger for review in advance

AI governance is not a one-time decision, since technology, services, law and public expectations keep changing. Deciding only to "review periodically" rarely leads to action; it works better to define concrete triggers in advance: a change to an AI service's specifications or contract terms, a change in law or guidance, an internal incident or near-miss, or a new AI use case or product. The policy is then revisited whenever one of these occurs, rather than drifting out of step with actual practice.