What the Board Should Be Asking About AI Before Approving the Budget

Microsoft is selling Copilot hard. So is Google, Salesforce, and every major software vendor with an AI story. The pitch lands at the C-suite level, gets handed to IT, and eventually reaches the board as a budget line with a productivity multiplier attached.

Most boards approve it. Most boards should be asking more questions first.

This is not an argument against AI investment. Organizations that deploy AI well will have a real advantage over those that don't. The argument here is narrower: approving the budget without understanding what has to be true in your environment first is how well-intentioned AI investments become liability events.

Four questions separate boards that are governing AI well from those that are rubber-stamping it.

"Has our environment been assessed, or are we assuming we're ready?"

This is the question most boards never ask, because the assumption is that IT would have flagged a problem if one existed. That assumption breaks down for a specific reason: the gaps that create AI risk are not the same gaps that cause day-to-day operational problems. IT teams optimize for uptime and user productivity. Data governance gaps that don't trigger helpdesk tickets don't get prioritized.

An organization can run Microsoft 365 smoothly for years while its SharePoint permissions are a mess, its data loss prevention policies are in audit mode rather than enforce mode, and its sensitivity labels are inconsistently applied. None of that causes visible problems until an AI system starts surfacing confidential content to people who technically have access but shouldn't practically have it.

The board should ask for a readiness assessment result, not an IT team's reassurance. Those are different things.

"What data could our AI system reach, and who would know?"

Copilot and similar AI tools operate with the permissions of the user running them. If a senior manager has accumulated access to folders and SharePoint sites from five years of project work, Copilot can reach everything that manager can reach, and will use it when generating responses.

In most organizations, no one has a clean answer to what any given user can actually access. Permissions accumulate over time. People change roles. Projects end but access doesn't get revoked. The result is that AI deployment, in an unassessed environment, effectively gives every user a tool that can surface anything they've ever been granted access to, whether or not that access was intentional.

The question for the board isn't whether IT trusts the AI vendor. It's whether anyone has actually mapped the data exposure before the system goes live.

"What is our liability position if AI surfaces the wrong information?"

This is where legal and finance need to be in the room alongside IT. Three liability vectors apply before deployment is approved.

The first is internal: an employee uses Copilot and receives a response that includes compensation data, personnel information, or business strategy documents they were never meant to see. The exposure is internal, but the consequences (HR, legal, trust) are real.

The second is regulatory: depending on your industry, surfacing certain categories of data through an AI system to someone without authorization may trigger notification obligations under HIPAA, GDPR, CCPA, or sector-specific regulations. Most organizations don't know whether this applies to them until it's relevant.

The third is insurance: cyber insurers are increasingly asking about AI governance controls at renewal. Some policies now include coverage conditions tied to documented data governance practices. A breach in which AI was a contributing factor, in an environment where governance controls weren't in place, creates claim disputes that wouldn't otherwise exist.

A board that approves an AI budget without understanding these three vectors is approving risk it hasn't priced.

"What does remediation look like if something goes wrong post-deployment?"

This question is less about whether to deploy and more about whether the organization has thought past the launch date. AI deployments that surface the wrong data or create a security incident need a response plan that's different from a standard data breach playbook, because the vector is different.

The board should know, before approving deployment, what the rollback or containment procedure looks like. Not because deployment will fail, but because asking the question surfaces whether anyone has thought about it.


None of these questions require technical expertise to ask. They require governance instincts that boards apply to every other major technology investment, applied here as well.

Organizations that deploy AI with proper governance in place will get more value from it, carry less risk, and be in a stronger position at insurance renewal than those that treat the readiness work as an IT detail. The board's job is to make sure the readiness work actually happened before the budget is approved, not after the system is live.

PresideTech's AI Readiness Assessment gives boards the documented evidence they need to answer these questions with confidence. The AI Readiness Self-Assessment takes ten minutes and identifies where the gaps are likely to be.

Written by a former Microsoft Enterprise Strategy Consultant who worked with Fortune 50 organizations on large-scale Microsoft 365 deployments.