Boards do not approve AI governance investment because the regulator might fine you. They approve it because the inventory work is already happening, in spreadsheets, in part-time effort, badly, and consolidating it is cheaper than continuing the way you are. The fine is the third reason, not the first.
This piece is the structure of a board paper that gets approved. The five sections, the three numbers, the 90-day delivery plan, the three objections to anticipate. It assumes you have read the EU AI Act's basic structure; it does not re-explain the four risk tiers.
The Five-Section Paper
Boards approve operational decisions in a recognisable structure. AI governance fits the same structure. The five sections, in the order that works:
Problem. Specific to your firm. "We do not have a complete inventory of the AI systems in use across the organisation." Not abstract. Not aspirational. The problem statement is the hook because every subsequent section is grounded in it, and it is the foundation on which the entire enterprise AI governance case rests.
Regulatory exposure. The cost of the problem under enforcement. The four EU regimes; EU AI Act, GDPR, DORA where applicable, NIS2, each create exposure attached to the inventory you do not have. The exposure framing is real, but it is one section of five, not the whole paper.
Operational cost. The cost of the problem in current state. FTE hours on register maintenance, on vendor questionnaires, on RoPA updates, on the audit preparation that runs from a base of incomplete data. The board is interested in this section because it is recoverable spend, not just risk avoidance.
Proposed approach. What you are going to do. The 90-day delivery plan, with named outputs at each stage, mapped to who owns what.
Investment ask. The number, the duration, and what the board is approving. Specific. With a request for sign-off framed as a question, not an open invitation.
Notice what is not in the structure: a section on AI ethics. A section on the strategic importance of AI. A section on regulatory uncertainty. These are the sections that make AI compliance pitches lose credibility. Boards have seen too many of them.
Numbers That Work
Three quantified figures, sourced specifically to your firm's situation, do most of the work. Generic numbers from industry reports do not, boards discount them automatically.
Regulatory exposure. Take your largest current AI use case, typically the HR recruiting tool, the customer-support AI, or the credit-decisioning system, and map it to the relevant fine band. Under the EU AI Act, Article 99 sets penalties up to €15 million or 3% of global annual turnover for non-compliance with most provider and deployer obligations, including the obligations attaching to high-risk systems. The €35 million / 7% upper band is reserved for prohibited-practice violations under Article 5; for most mid-market firms, the relevant fine band is the lower one. State the figure honestly. Boards remember when they are quoted the wrong band. Article 50's transparency and AI-content-labelling duties are already in force and already enforceable, which gives this section a live deadline to point to rather than a future one.
Operational cost. Audit your current state. How many FTE-hours per quarter does the DPO and their team spend maintaining the Article 30 RoPA? How many hours does the security team spend on vendor questionnaires for SaaS not on the central inventory? How much time did the last regulatory inspection consume across functions? The answer is usually five to twelve weeks of distributed FTE per year at most mid-market firms, and that figure is the most compelling AI risk management cost argument the paper can make, because it is recoverable spend, not just risk avoidance.
Opportunity cost. The harder figure to quantify but the most consequential. Without an inventory, every regulatory enquiry consumes executive time disproportionately. Every commercial conversation that reaches "can you tell us what AI you use", increasingly common in enterprise sales, runs into the same gap. The figure to put in the paper is conservative: the number of inquiries (regulator, customer, audit) per year that would close in days rather than weeks if the inventory existed.
How To Frame The Deadline
The EU AI Act enforcement architecture now has four dates that matter. 2 February 2025, already binding for prohibited practices and Article 4 AI literacy. 2 August 2026, when the Article 50 transparency and AI-content-labelling duties took effect - that date has already passed, and those obligations are now live and subject to enforcement. 2 December 2027, the deadline for standalone high-risk systems under Annex III, following the Digital Omnibus on AI's 16-month deferral from the original August 2026 date. 2 August 2028, for high-risk AI embedded in products already covered by EU product-safety law under Annex I, deferred from the original August 2027 date.
The framing that works: the December 2027 date is fixed, the discovery and classification work to identify which systems are high-risk takes thirty to sixty days, and the documentation work for high-risk systems takes another sixty to ninety days. The deferral bought firms more runway, but a firm that waits until the back half of 2027 to start is still not on schedule against a hundred-fifty-day build. The extra time changes the pace of the conversation, not the need for it, and the Article 50 transparency duties are enforceable now, which is its own separate, immediate reason to have the inventory in place.
The framing that does not work: implying the regulator is poised to fine your firm specifically. Boards discount panic. The realistic statement, most firms will not be fined in the first year of enforcement, the firms that are will be selected to set examples, and the cost of being one of the examples is high, carries more weight than a generic threat. That framing positions AI compliance as an operational priority rather than a regulatory anxiety.
The 90-Day Delivery Plan
Boards approve plans, not principles. The structured 90-day programme that has worked in the audits we have run:
Weeks 1–2: discovery. Connect data sources - SSO, email metadata, finance and procurement, where consented browser and endpoint telemetry. Produce the first complete AI inventory across the four discovery layers.
Weeks 3–6: classification and register population. Each tool through the EU AI Act decision tree. The deployer-versus-provider determination per system. The Annex III category assignment for high-risk systems. The GDPR processor mapping. Where applicable, the DORA register entry. The Article 30 RoPA refresh from the new inventory.
Weeks 7–10: controls and reporting setup. Per-tier control assignments, ownership per tool, exception register for tools that cannot yet be brought into governance. The reporting cadence to the executive committee.
Weeks 11–13: first audit-ready cycle. The documentation pipeline tested against a regulatory-style request. The internal audit findings on the new state. The handover to steady-state operation.
Output at day ninety: an audit-ready inventory and classification register, the Article 30 RoPA reflective of the inventory, the DORA register entry where applicable, and the AI governance framework operating. Not a finished programme, governance is continuous, but one that can survive an external inspection.
Three Objections To Anticipate
Every board has these three. Pre-empting them in the paper saves the discussion.
"We already have OneTrust." The answer is that OneTrust is a documentation platform built for the controller-side compliance work - RoPA, DPIAs, vendor risk questionnaires. It does not solve the inventory problem because it relies on the firm telling it what to document. The inventory the firm cannot produce is the input OneTrust needs and does not have. The two are complementary, not substitutes.
The OneTrust objection is the one that comes up most often, and it is the one that requires the most care in the room. The CFO who raises it is not being obstructive. They approved a real investment, and the platform is already running. The DPO uses it daily. The question, 'Why do we need another platform when we already have OneTrust?' is a reasonable one coming from someone who believed the problem was already solved. The answer to this question is not the technical explanation of documentation platforms versus inventory layers. It is a single question back: what does OneTrust currently show as your AI inventory? In almost every conversation where this has come up, there is no answer; they just stare at each other. The inventory OneTrust has is the one the firm gave it, which is the same incomplete list the firm had before the OneTrust purchase was made.
The OneTrust objection is the one that comes up most often, and it is the one that requires the most care in the room. The CFO who raises it is not being obstructive. They approved a real investment, and the platform is already running. The DPO uses it daily. The question, 'Why do we need another platform when we already have OneTrust? " is a reasonable one coming from someone who believed the problem was already solved. The answer to this question is not the technical explanation of documentation platforms versus inventory layers. It is a single question back: what does OneTrust currently show as your AI inventory? In almost every conversation where this has come up, there is no answer; they just stare at each other. The inventory OneTrust has is the one the firm gave it, which is the same incomplete list the firm had before the OneTrust purchase was made. The platform did not create any new inventory; it documented what was already known. The gap it was supposed to close is still open. That single question will get you further than any slide in the paper. - Ankur Arora, Co-Founder, Montro |
"The regulator hasn't enforced yet." The answer is that the regulator's enforcement timeline is fixed, and the work to be ready takes longer than the time between now and the deadline. The firms that wait to start until enforcement actions appear are typically not ready when the inquiry arrives. The asymmetry of being among the first cases the supervisor selects is large.
"This is IT's job." The answer is to walk through who actually signs the register at the regulator's request. The DPO signs the Article 30 RoPA. The CISO signs the security risk-management framework. The management body signs off on the cyber risk position under NIS2. IT runs the inventory layer, but IT does not sign. The cross-functional ownership is what the regulator expects, and the board paper is the mechanism that establishes the enterprise AI governance accountability structure the regulation requires.
The Ask
The board paper closes with a specific question, not an open invitation. Two examples that have worked:
"The board is asked to approve €X for the 90-day programme described, with quarterly reporting against the milestones, and to confirm that the DPO and CISO are jointly accountable for the programme outputs."
"The board is asked to approve a six-month engagement covering discovery, classification, controls implementation, and the first operational quarter, with a board-level review at month four to assess the steady-state cost."
Specific. Time-bound. With a named accountability. The question the board needs to answer is yes or no, not what to do.
Frequently Asked Questions
Who should own the AI governance board paper - the DPO, CISO, or CFO?
In practice, the most effective board papers are co-owned, the DPO or Head of Compliance owns the regulatory framing, the CISO owns the security and operational risk framing, and the CFO owns the investment case. A paper presented by one function alone is more easily deflected as a departmental ask. A paper presented jointly, with the CFO's fingerprints on the cost argument, is harder to defer without a documented rationale.
How long does it typically take a board to approve a governance investment of this type?
At most mid-market firms, a well-structured compliance investment paper moves through one board cycle, typically four to six weeks from submission to decision, when it contains specific deliverables, a named accountability structure, and a displacement argument. Papers that arrive without those elements tend to be deferred for further information, which adds another full cycle. The single most common reason for deferral is an investment ask that is not specific enough to approve or decline.
What should go in the board paper if the firm has no existing AI inventory at all?
That is the problem statement. "We do not have a complete inventory of the AI systems in use across the organisation" is the opening line of the paper, not a reason to delay writing it. The absence of an inventory is not a prerequisite gap, it is the central evidence that the investment is needed. The paper proposes to close the gap; it does not need to have closed it first.
How does a board paper for AI governance differ from a standard IT investment proposal?
Three differences matter. The regulatory exposure section names specific fine bands under specific articles, not generic risk language. The operational cost section quantifies existing FTE waste, not projected future savings. And the ask is framed as a compliance obligation with a fixed enforcement date, not a capability improvement with a flexible timeline. Boards that have approved IT investment proposals before will notice the difference in specificity, and that specificity is what makes the AI governance framework paper credible rather than deferrable.
