Governance teams can use AI to flag potential problems in board packs: inconsistent dates, missing sections, unexplained changes, mismatched totals, and claims that need a source. The useful output is a review queue linked to the original material. The governance team remains responsible for checking the flags and approving the final pack.
Begin with a bounded task such as checking version consistency across papers. A tool that produces confident summaries without reliable source references creates more work for reviewers and can obscure important uncertainty.
Define the review before selecting a tool
Record which papers the system can inspect, which checks it should perform, and what it must leave to a human reviewer. Financial statements, commercially sensitive forecasts, personal information, and privileged material can need different handling arrangements. Choose an approved environment and agree access, retention, and provider terms before introducing documents.
The NIST Generative AI Profile discusses risks that inform this kind of controlled use. The checklist below is Artebello’s practical review design; it is not a certification or a replacement for your organization’s governance requirements.
Board-pack checks that produce useful evidence
| Check | What AI can flag | What the reviewer must verify |
|---|---|---|
| Completeness | Missing required headings, attachments, or decision sections | Whether the omission is real and what the board needs |
| Period and version | Different reporting dates or document versions | Which date and version are authoritative |
| Numbers | Different values for the same metric across papers | Source records, definitions, arithmetic, and approved figures |
| Narrative consistency | A summary that appears to contradict a risk or finance paper | Context, materiality, and any legitimate explanation |
| Decision clarity | A paper that describes activity without stating the decision requested | The accountable executive’s proposed decision and options |
| Evidence | Statements without a traceable supporting source | Whether the source supports the exact claim |
| Action tracking | Actions without an owner, date, or closure evidence | The agreed action and actual status |
| Sensitive information | Material that may require restricted circulation | Classification, necessary access, and approved redaction |
Ask for a source location with every finding: document name, section, page, and relevant excerpt. An unsupported flag should be classified separately from a verified defect. Do not allow the system to silently rewrite figures or replace the approved pack.
A review workflow with clear ownership
- Freeze the input set. Assign a pack identifier, record versions, and identify the document owners.
- Run deterministic checks first. Check required fields, attachments, dates, and arithmetic with ordinary rules where possible.
- Run bounded AI checks. Ask for suspected contradictions and unsupported narrative claims with source references.
- Triage the findings. Separate confirmed defects, false positives, and issues requiring an owner’s explanation.
- Resolve with the paper owner. Record the decision and corrected source, rather than treating the AI suggestion as approval.
- Approve the final version. Recheck changed sections and retain the review record according to the organization’s process.
The final sign-off should identify who reviewed the pack and which unresolved issues were escalated. AI-generated text should never imply that a review took place when it did not.
Worked example: a conflicting revenue figure
In a fictional pack, the executive summary says quarterly revenue is 12.4 million, while the finance paper says 12.1 million. The tool returns both source locations and labels the discrepancy “requires verification.”
The finance owner checks the ledger and confirms that 12.1 million is the approved figure. The summary owner corrects the narrative, and the governance reviewer records the change. If both figures were valid under different definitions, the correct action would be to explain those definitions, not automatically choose one number.
The example illustrates a controllable quality check. It does not demonstrate that an AI tool can independently validate financial reporting.
How to evaluate a pilot
Use historical or synthetic packs containing known defects, with sensitive information removed or processed under approved controls. Include clean papers as well as defective ones; otherwise you cannot measure false alarms.
Measure:
- Detection: how many known defects the tool finds, broken down by check type.
- Review effort: how long people spend validating findings and resolving false positives.
- Traceability: whether each finding points to an accurate source location.
- Permission behavior: whether unauthorized users can access restricted material.
- Missed critical issues: which material defects remain undetected.
Set the pilot’s acceptance criteria before running it. A demonstration that catches one conspicuous typo is not enough to justify broader use. A good pilot can conclude that a specific check should remain rule-based or entirely manual.
Go-live gate
Confirm the input boundary, approved environment, access controls, retention rules, reviewer responsibilities, escalation process, and incident contact. Document what happens when the system cannot produce reliable references or the service is unavailable. Review the executive AI governance checklist and launch checklist before expanding.
Frequently asked questions
Can AI approve a board pack?
It can assist quality checks. Approval remains with the designated people and governance process. Separate flag generation from sign-off in both the tool and the audit record.
How should we start?
Choose one document class and a few explicit checks. Use an approved test collection, establish a manual baseline, and compare reviewer effort and defect detection before expanding.
How do we avoid confidential information appearing in outputs?
Control the approved inputs, provider arrangements, user access, retrieval permissions, and output distribution. Test those boundaries using realistic user roles. A prompt instruction alone is not a reliable access control.
For broader readiness, take the assessment. For help designing the pilot and its evidence requirements, discuss an opportunity-mapping engagement.