# Your Board Needs a Quarterly AI Risk Report. Here Is the Template.
If a board member or investor asked you today to describe your AI risk exposure, you probably have a real answer. You know which vendors you use. You track incidents. You've thought about your regulatory posture. The problem is almost never that the AI program doesn't exist. It's that the program is invisible to the people who need to see it.
That gap has real consequences. NIST AI RMF 1.0, published January 26, 2023, places governance at the foundation of AI risk management through its Govern function: roles, accountability, oversight, and periodic review. And where AI is mission-critical, the Delaware oversight cases offer a useful analogy: board oversight runs on specific reporting systems, not informal management assurance. (In re Caremark International Inc. Derivative Litigation, 698 A.2d 959 (Del. Ch. 1996); Marchand v. Barnhill, 212 A.3d 805 (Del. 2019); In re Boeing Co. Derivative Litigation, 2021 WL 4059934 (Del. Ch. Sept. 7, 2021).) And for companies deploying AI systems that reach EU users, Article 50 of the EU AI Act (which requires transparency disclosures for AI-generated content reaching consumers) comes into application on August 2, 2026. GPAI model provider obligations (the documentation and Code of Practice requirements under EU AI Act Article 53 for providers of general-purpose AI models) began applying in 2025, which already puts vendor documentation and provider status in your diligence file.
AI governance does not become credible the day you write a policy. It becomes credible when the board can see the risk categories, who owns each one, the evidence behind them, the open gaps, and the incident history, on a schedule that repeats.
The clock to August 2, 2026 is already running.
A founder who can't hand a board member or investor a quarterly AI risk report is carrying governance debt that surfaces at the worst possible time. This article gives you the template: five risk categories, six fields each, deployable in a single working session and updatable every quarter.
Who this is for. You're between Series A and Series B, and you already run AI somewhere that matters: in the product, the customer workflow, underwriting, hiring, analytics, or back-office operations. What you probably haven't done is turn that activity into something a board member can read. If you're heading into a Series B raise, selling to enterprise buyers, or about to pick up EU users, this report should exist before someone asks for it.
What Changed
NIST AI RMF Govern Function (January 2023). The NIST Artificial Intelligence Risk Management Framework (AI RMF 1.0) is voluntary guidance, and it puts the Govern function at the foundation of AI risk management: the roles, accountability, oversight, and periodic review that let a board actually see AI risk and act on it.
Delaware oversight duty by analogy. The Delaware oversight cases are not AI cases. But they establish a pattern that matters when AI becomes mission-critical: boards need specific reporting systems for mission-critical risk, not informal assurances that management has it handled. The Caremark standard (698 A.2d 959) requires reporting protocols and active monitoring. Marchand (212 A.3d 805) applied that logic to mission-critical operations. Boeing (2021 WL 4059934) reinforced that generic risk-committee language is not enough when the risk requires a specific escalation path.
EU AI Act Article 113 (August 2, 2026). For companies deploying AI systems that reach EU users, Article 50 transparency obligations come into application on August 2, 2026, under EU AI Act Article 113. That date is final law. Separately, GPAI model provider obligations have been applying since August 2, 2025, so provider Code of Practice status belongs in your diligence file today.
Why It Matters for Business Decisions
Diligence. Investors expect a documented AI governance program, and evidence the board has eyes on it. A Project Liberty survey found 73% of respondents believe companies with stronger responsible AI practices are more likely to succeed financially. The founder with a quarterly report reads as credible. The founder without one has a gap diligence will find.
Enterprise sales. The report that satisfies your board is the same one that answers an enterprise buyer's security, privacy, and responsible-AI questionnaire. And for a growth-stage company, the buyer usually asks before the investor does. If your sales team is improvising answers to those questions, you're already paying for the report you didn't build.
FTC exposure. FTC Section 5(a) (15 U.S.C. § 45) enforcement goes after companies making AI claims they can't back up. Publish an AI responsibility statement without the controls and incident log to support it, and you're in deceptive-practice territory. The FTC's 2024 Operation AI Comply enforcement actions put it plainly: enforcement lives in the gap between the public promise and the internal proof.
Transaction risk. An undocumented AI governance program is a reps-and-warranties problem. "We have strong AI governance" is a representation. If the documentation doesn't exist, that comes out in diligence, at the point where walking away gets expensive.
One honest counterpoint. A very early-stage company may not need all five categories at once. The format scales: start with Model Risk and Vendor Dependency, add the rest as you grow.
Decision Framework
Answer these before you build the report. They'll tell you how much of the template to turn on right now.
- Is AI mission-critical to your product? If an AI failure would seriously disrupt your core product, the Delaware oversight cases are a useful analogy. Management-level oversight isn't enough. The report has to reach the board.
- Does your AI output reach EU users? EU AI Act Article 50 transparency obligations apply August 2, 2026. Your Regulatory Exposure section is where that evidence lives.
- Have you made public AI claims you can't document? Responsibility statements, accuracy claims, uptime numbers: each one is a potential FTC Section 5 exposure point. The report is what the proof looks like.
- Who owns each AI risk category, by name and role? NIST AI RMF Govern asks for specific accountability. "The engineering team" is not an owner.
- What would you hand a Series B investor tomorrow? If the answer is "I'd assemble it from scratch," the quarterly report is the thing you're missing.
Audience-Specific Implications
For Founders
The quarterly AI risk report makes your AI program legible to the people whose judgment you need: your board, your investors, an acquirer. It forces the ownership and gap questions that stay invisible inside a fast-moving engineering org. If a board member can read it and size up your AI risk posture without a 30-minute briefing from you, it's doing its job.
For Investors and Boards
The right question isn't "do you have an AI governance policy?" It's "can you show me last quarter's AI risk report?" A policy states an intention. A quarterly report shows a review process that actually runs. The Delaware oversight cases, by analogy, point in the same direction: active monitoring depends on a reliable reporting system, not occasional management assurances. Ask for the report.
Quarterly AI Risk Report Template
Lift this into a board deck, a data room, or a quarterly governance review. Each category reads on board software, on a phone, and on paper. Fill in the fields that apply and leave the gaps visible with a planned fill date.
Every category uses the same six fields: risk name, risk level, owner, evidence artifacts, gaps, and next review date.
At a glance, the five categories:
- Model Risk: wrong, biased, or hallucinated outputs that move decisions, customer outcomes, or compliance
- Vendor Dependency Risk: third-party AI provider risks you can't control directly, from model changes to outages to a provider going dark
- Data Quality and Privacy Risk: poor, unrepresentative, or improperly used data that opens up privacy-law exposure
- Regulatory Exposure: AI obligations under the EU AI Act, state AI laws, or sector rules you haven't documented yet
- Incident History: the AI failures, surprise outputs, and customer complaints from the quarter
I'll build out Vendor Dependency Risk as the worked example, because it's the most tangible category for most teams. The other four follow the same six-field structure.
Risk Category 1: Model Risk
Current Risk Level: [ ] High [ ] Medium [ ] Low
High: known failure modes, no mitigation, active incidents. Medium: some testing, known gaps, monitoring underway. Low: documented testing, bias checks done, nothing unresolved.
Owner: \_\_\_\_\_\_ (VP Engineering / ML Team Lead / CTO)
Evidence Artifacts: - [ ] Accuracy metrics (test-set and production) - [ ] Bias testing record (last test date: \_\_\_\_\_\_) - [ ] Production failure/hallucination log (period: \_\_\_\_\_\_) - [ ] Model change log with pre-deployment testing - [ ] Customer escalations tied to model behavior
Gaps: [Example: "Hallucination test: in progress, Q3 2026. Fairness audit: not started, Q4 2026."]
Next Review Date: \_\_\_\_\_\_\_\_\_\_
Regulatory Anchors: NIST AI RMF Measure function; EU AI Act Article 15 (accuracy and robustness requirements for high-risk AI systems); FTC Section 5(a) (15 U.S.C. § 45) substantiation requirements.
Risk Category 2: Vendor Dependency Risk
The worked example, built out in full.
What it covers: Third-party AI provider risks you can't directly control: model changes, pricing shifts, service discontinuation, or outages.
Current Risk Level: [ ] High [ ] Medium [ ] Low
High: single vendor, no SLA, no continuity plan, provider not signed on Code of Practice. Medium: SLA in place, continuity plan in draft. Low: SLA, alternative vendor documented, provider signed.
Owner: \_\_\_\_\_\_ (Head of Product / VP Engineering)
Evidence Artifacts: - [ ] GPAI vendor inventory (all providers and model versions in use) - [ ] Provider Code of Practice status: Signed / Unsigned / Unknown (verify at EU AI Act GPAI Code of Practice signatories) - [ ] Contract terms reviewed: pricing-change notice, SLA uptime, support response time - [ ] Alternative vendor evaluated and documented (yes / no / in progress) - [ ] Provider incident history this quarter (outages, model changes, disruptions)
Gaps: [Example: "Continuity plan: in progress, Q3 2026. Cost modeling for alternative provider: not started."]
Next Review Date: \_\_\_\_\_\_\_\_\_\_
Regulatory Anchors: NIST AI RMF Govern function; EU AI Act Article 53 (provider documentation obligations for GPAI models); EU AI Act Article 113 (Article 50 transparency obligations, August 2, 2026).
Risk Category 3: Data Quality and Privacy Risk
Current Risk Level: [ ] High [ ] Medium [ ] Low
High: no provenance docs, known privacy gaps, no retention procedures. Medium: partial docs, assessment pending. Low: documented provenance, assessment done, retention and deletion in place.
Owner: \_\_\_\_\_\_ (Head of Data / Data Privacy Officer / GC)
Evidence Artifacts: - [ ] Training data provenance (source, collection method, licensing) - [ ] Data curation record (filtering, labeling, validation) - [ ] Retention and deletion policy with AI-specific procedures - [ ] Privacy impact assessment (GDPR / CCPA: complete / in progress / not started) - [ ] Third-party data contracts and subprocessor agreements reviewed - [ ] Data quality or bias audit results (last audit date: \_\_\_\_\_\_)
Gaps: [Example: "CCPA screen: complete. GDPR basis for EU training data: in progress. Subprocessor agreements: two of five outstanding."]
Next Review Date: \_\_\_\_\_\_\_\_\_\_
Regulatory Anchors: NIST AI RMF Map function; EU AI Act Article 10 (data and data governance requirements, including quality and relevance of training data); GDPR Article 5 (principles of lawfulness, fairness, and transparency in personal data processing); California Consumer Privacy Act (CCPA).
Risk Category 4: Regulatory Exposure
Current Risk Level: [ ] High [ ] Medium [ ] Low
High: EU reach confirmed, no Article 50 procedures, no state inventory. Medium: screen done, state inventory started, gaps open. Low: Article 50 disclosures in place, state inventory complete, change log maintained.
Owner: \_\_\_\_\_\_ (General Counsel / Compliance Officer / Founder)
Evidence Artifacts: - [ ] EU AI Act applicability screen: does AI output reach EU users? (Yes / No / Unknown) - [ ] Article 50 transparency disclosures for EU-facing AI content (yes / no / not applicable) - [ ] GPAI provider/vendor diligence where applicable (Code of Practice status; Annex XII access requests if applicable) - [ ] State AI law inventory: Illinois, NYC, Colorado, Connecticut, California, Texas - [ ] Sector rules reviewed: healthcare, financial, employment, education AI (mark applicable) - [ ] Regulatory change log: laws, enforcement, or guidance this quarter
Gaps: [Example: "Article 50 disclosures: live for chatbot; not yet for email feature (target: August 1, 2026). Colorado SB 26-189: under review."]
Next Review Date: \_\_\_\_\_\_\_\_\_\_
Regulatory Anchors: EU AI Act Articles 2, 50, 113 (Article 50 transparency obligations come into application August 2, 2026; GPAI provider obligations applied from August 2, 2025); FTC.gov guidance on AI claims (FTC Section 5); state laws (Illinois HB 3773, NYC Local Law 144, Colorado SB 26-189, Connecticut SB 5, Texas TRAIGA).
Risk Category 5: Incident History
This is the most direct evidence that the oversight system actually works.
Current Risk Level: [ ] High [ ] Medium [ ] Low
High: incidents undocumented or unresolved, no root-cause process. Medium: incidents logged, some resolved, analysis underway. Low: every incident logged with root cause and fix, nothing high-severity open, monitoring catches problems first.
Owner: \_\_\_\_\_\_ (Head of Engineering / Head of Operations / Incident Commander)
Evidence Artifacts: - [ ] Incident log this period (date, description, root cause, remediation, resolution) - [ ] Root-cause analysis done for each incident (yes / no / in progress) - [ ] Customer impact documented (customers affected, service impact, communication sent) - [ ] Remediation timeline with an owner for each open item - [ ] Follow-up testing to prevent recurrence - [ ] Zero incidents this quarter: confirmed / pending confirmation
Gaps: [Example: "Q2 2026: two incidents. Incident 1 (April 12): resolved, data input error, monitoring added. Incident 2 (June 3): under investigation, no customer impact. Follow-up: June 30, 2026."]
Next Review Date: \_\_\_\_\_\_\_\_\_\_
Regulatory Anchors: NIST AI RMF Manage function; EU AI Act Article 73 (serious incident reporting, by analogy); In re Caremark, 698 A.2d 959 (Del. Ch. 1996) (board oversight requires documented monitoring and response systems).
How Does the Template Fit a Real Board Cadence?
Fill it out once to set a baseline. Update it quarterly and add it as a standing board agenda item or appendix. A board member should be able to read it in five minutes and ask you specific questions off the page.
On the "Gaps" field, leave the gaps visible. A documented gap with a completion date is evidence of a governance system that's running. A category marked "complete" with nothing under it is a problem waiting for diligence to find.
Practical Takeaways
- Complete Vendor Dependency and Model Risk first. If your product reaches EU users and runs on a GPAI model, these two categories are the foundation for your Article 50 readiness file and your FTC substantiation record. They show what systems you use, what claims you make, what provider documentation you rely on, and where the unresolved gaps sit.
- Assign an owner by name and role, not by team. "Engineering team" is not an owner. "VP Engineering" is. An unnamed owner at the point the report reaches the board is itself a gap.
- Build the Incident History section even at zero incidents. Zero incidents plus confirmed monitoring reads better in a data room than a blank section. An undocumented incident becomes reps-and-warranties exposure in any transaction.
- Track Article 50 compliance by feature, not by company. A regulator asking about EU AI Act obligations will ask about a specific AI system or output, not the company's overall posture. Your record has to match that specificity before anyone asks.
- Add the report as a standing board agenda item. The Delaware Caremark standard, applied by analogy, turns on ongoing monitoring. One review doesn't clear it. Quarterly is the right cadence for most growth-stage companies.
Frequently Asked Questions
What goes in a board AI risk report?
A quarterly AI risk report typically covers five categories: Model Risk (accuracy, bias, hallucination), Vendor Dependency Risk (third-party AI providers and their contract terms), Data Quality and Privacy Risk (training data provenance, GDPR/CCPA compliance), Regulatory Exposure (EU AI Act Article 50 obligations, state AI laws, sector rules), and Incident History (AI failures, surprise outputs, customer complaints from the quarter). Each category uses six fields: risk level, owner by name and role, evidence artifacts, gaps with planned close dates, and next review date. The NIST AI RMF 1.0 Govern function, published January 26, 2023, provides the accountability and periodic-review scaffolding most boards expect to see behind the report.
When do EU AI Act transparency rules apply to my startup?
EU AI Act Article 50 transparency obligations come into application on August 2, 2026, under Article 113 of the final law. Article 50 applies to certain AI systems and to AI-generated or manipulated content that reaches EU users, so those disclosure requirements attach to specific features or systems, not to every AI output your product produces. GPAI model provider obligations (Article 53 and related provisions) have been applying since August 2, 2025, which means your vendor documentation and provider status should already be in your governance file. Scope depends on the nature of your AI output and your EU user footprint; the question to work through with qualified counsel is which specific systems trigger each obligation.
Does the Delaware Caremark duty apply to AI governance?
The Delaware cases (Caremark in 1996, Marchand in 2019, and Boeing in 2021) are not AI cases, but they establish a board oversight pattern that applies when any risk becomes mission-critical to the business. The Caremark standard requires specific reporting systems and active monitoring, not just management assurances that things are fine. Marchand applied that logic to mission-critical operational risk, and Boeing reinforced that generic risk-committee language is insufficient when a specific escalation path is needed. For a company where AI failure would seriously disrupt the core product or create material liability, the analogy to a documented board-level AI risk report is worth working through with counsel.
What goes in the board AI risk report for a Series B diligence process?
Series B investors are increasingly asking to see documented AI governance as part of diligence. A Project Liberty survey found 73% of respondents believe companies with stronger responsible AI practices are more likely to succeed financially. The report elements that matter most in diligence are: the five risk categories with current risk levels and named owners, the Incident History section (even showing zero incidents with confirmed monitoring), Vendor Dependency evidence including GPAI provider Code of Practice status, and Regulatory Exposure documentation showing whether Article 50 obligations have been addressed feature by feature. A policy document alone typically does not satisfy diligence; reviewers want evidence that a review process actually runs.
How often should a growth-stage company update its AI risk report?
Quarterly is the right cadence for most growth-stage companies deploying AI in the product or core operations. The NIST AI RMF Govern function calls for periodic review and accountability structures on a defined schedule. By analogy, the Delaware oversight cases point toward ongoing monitoring rather than one-time reviews. Practically, the cadence also aligns with board meeting schedules: an AI risk report added as a standing board agenda item or appendix gives the board a recurring signal that the oversight system is actually running, not just documented.
Closing Perspective
Here's what I keep coming back to when a founder tells me they're not ready. The quarterly AI risk report isn't about writing new governance. It's about writing down the governance you already have. If you're testing models, you have Model Risk documentation to capture. If you have vendor contracts, you have Vendor Dependency evidence to log. The report just makes that work visible to the people who need to see it.
The real cost of waiting isn't regulatory. It's that a board member or investor who finds the governance gap in a meeting has to decide whether the founder knew about it or didn't. Neither answer builds confidence. The founder who hands over the report before anyone asks has already made a different argument about how the company is run.
August 2, 2026 is the external deadline. Your next board meeting is the one that's closer. The template is above.
This article is for informational purposes only and does not constitute legal advice. Every company's situation is different, and you should consult with qualified legal counsel before making compliance decisions based on the developments discussed here.