A board does not need to understand how an AI employee works. It needs to know what the thing is allowed to do, who answers for it, and how management would find out if it went wrong. Briefings fail when they open with technology and leave those three answers until question time.
This guide is for a COO, CIO, CRO or general counsel preparing a board or risk-committee briefing at a US enterprise, including banks. It lists the questions directors tend to ask, what a strong answer sounds like, and the evidence worth putting in the pre-read. For the framework behind the answers, see our practical guide to AI governance for enterprise teams.
What questions will the board ask about AI governance?
What anchors a board's oversight role?
A board's role is oversight, not operation. Three public sources give you language for the pre-read.
- The NIST AI Risk Management Framework 1.0 has a GOVERN function that covers policies, accountability structures and leadership responsibility. Subcategory GOVERN 2.3 says executive leadership takes responsibility for decisions about AI risk, and GOVERN 1.6 calls for a mechanism to inventory AI systems (NIST AI RMF 1.0). Our glossary entry on the NIST AI RMF gives the short version.
- For public companies, the SEC's 2023 cybersecurity rule added Item 106(c) of Regulation S-K, which requires registrants to describe the board's oversight of cybersecurity risk and the processes by which the board or its committee is informed (SEC final rule 33-11216). It covers cybersecurity, not AI in general, but AI employees with system access fall inside that risk.
- For banks, the June 2023 interagency guidance on third-party relationships states that the board has ultimate responsibility for oversight of third-party risk management and for holding management accountable (Interagency Guidance on Third-Party Relationships).
Which jobs does the AI employee do, and which stay with people?
Directors want a scoped answer, not a vision. A good answer names each job, the system it runs in, the volume, and the steps a person still performs. "Reconciling vendor statements against the ledger and routing exceptions to the controller" is a job. "Improving finance" is not.
Bring a one-page job register: job name, business owner, systems touched, human steps, and go-live date. Our guide on how to manage AI employees covers how those job definitions stay current.
Who is accountable when an AI employee gets it wrong?
The answer is a named executive, not a committee and not the vendor. Each AI employee should have a business owner who answers for outcomes and a risk owner who challenges them. The board should be able to find those two names for any deployment.
Evidence: a RACI chart, the charter of the committee that reviews AI deployments, and the escalation path to the CRO or GC.
What can it do without human approval?
This is the question that decides how comfortable a board feels. A good answer defines action tiers: what the AI employee does alone, what it drafts for a person to approve, and what it never does. Payment release, customer communications with legal effect and changes to master data are common approval gates.
Evidence: the permission matrix for each job, plus the approval log showing how often people overrode or corrected the AI employee last quarter.
How do we know the work is accurate?
Accuracy needs a measurement, a sample and a threshold. Management should state the error rate it accepts for each job, how it samples completed work, and what happens when the rate drifts. Directors will be wary of a single headline accuracy number with no sampling method behind it.
Evidence: a quality report with the sampling approach, the last four periods of results, and the thresholds that trigger a pause. The first 30 days of onboarding an AI employee is where these baselines get set.
What data does it touch, and where does it go?
Answer by data class: customer personal data, financial records, credentials, and regulated records such as suspicious activity report material. State what the AI employee can read, what it can write, what leaves your environment, and whether any customer data is used to train a model.
Evidence: a data-flow diagram, the access list by role, retention settings, and the vendor's written position on training use.
What happens when it fails?
Directors do not expect zero failures. They expect a tested plan. A good answer describes a kill switch, a manual fallback so the business keeps running, and a way to find and correct every output the AI employee produced during the failure window.
Evidence: the last test of the fallback, the owner of the stop decision, and how many transactions a rollback would need to review.
Which vendors and models does it depend on?
An AI employee usually rests on a platform vendor, one or more model providers and the systems it logs into. The board should hear about concentration: what happens if a model provider changes terms or has an outage.
For banks, this is third-party risk management under the interagency guidance cited above, and it covers due diligence, contract terms, ongoing monitoring and exit planning. Evidence: the vendor risk assessment, the contract terms on data use and audit rights, and the exit plan.
Which regulations and examiners apply?
Name the regimes that touch each job. A bank should say how the AI employee fits within model risk management. In April 2026 the agencies issued revised model risk guidance that supersedes SR 11-7 (SR 26-2; OCC Bulletin 2026-13). Whether a given AI employee is a model under that guidance is a judgment your model risk team should document, not assume.
Compliance work draws the most examiner attention. Our post on what examiners ask about AI in BSA/AML programs lists the questions to rehearse. Evidence: a regulatory mapping by job and the most recent legal review.
What does it cost, and what is the evidence it pays back?
Ask for actuals. A strong answer compares cost per transaction or hours per cycle before and after, measured on live volume, with the baseline method stated. It also states what was not measured. Projections belong in a separate, labeled section.
Evidence: the baseline, the current figures, and the review cadence. Our own published example is in the Zamp section below.
How will the board learn about incidents?
Set the rule before an incident. Define what counts as a reportable AI incident, the time within which the executive owner must notify the CRO or GC, and the threshold at which the chair is told. Public companies should align that path with the processes they already use to inform the board about cybersecurity events.
Evidence: the incident definition, the notification clock, and a record of the last drill.
How are all AI employees inventoried and reviewed?
The board cannot oversee what management cannot list. A good answer is a single register of every AI employee and agent, including those teams started on their own, with owner, purpose, permissions and last review date. NIST GOVERN 1.6 expects exactly this kind of inventory.
Evidence: the register, the date of the last reconciliation against actual system access, and how new deployments get approved. For tooling that supports this, see our roundup of AI agent governance and identity tools.
What should the board pre-read table contain?
Use one table per briefing so directors can scan it in the meeting.
Director question | What a good answer includes | Evidence to bring |
|---|---|---|
Which jobs does it do? | Named jobs, systems, volumes, human steps | Job register |
Who is accountable? | Named business owner and risk owner | RACI chart, committee charter |
What needs approval? | Action tiers and approval gates | Permission matrix, override log |
Is it accurate? | Error threshold, sampling method, pause trigger | Four periods of quality results |
What data does it touch? | Data classes, access, retention, training use | Data-flow diagram, access list |
What if it fails? | Kill switch, manual fallback, rollback scope | Last fallback test |
Which vendors? | Concentration risk, data terms, exit plan | Vendor risk assessment |
Which regulations? | Mapping by job, model risk position | Regulatory map, legal review |
What is the return? | Measured before and after, method stated | Baseline and current actuals |
How are incidents reported? | Definition, notification clock | Incident policy, drill record |
Is everything inventoried? | One register, reconciled to access | AI register, reconciliation date |
What goes on a one-page board briefing?
Keep the briefing to a single page and put detail in an appendix. A workable layout:
- Decision requested.
Noting, approving a pilot, or approving an expansion, stated in one sentence. - Scope.
The jobs live today and the jobs proposed, from the job register. - Control summary.
Approval gates, accuracy thresholds and the fallback, in four lines. - Accountability.
The business owner and risk owner for each deployment. - Results to date.
Actual measurements only, with the period they cover. - Open risks.
The two or three items management is least comfortable with, and the owner and date for each. - Reporting cadence.
How often the committee sees metrics, and what triggers an out-of-cycle report.
Naming open risks yourself builds more trust with directors than a page with none.
How Zamp Supports a Board-Ready AI Employee Program
Zamp builds AI employees that run back-office jobs end to end, with human approval gates, scoped permissions and a full audit trail of every action. Those controls map to the director questions above: the approval log answers what needs sign-off, the permission scope answers what it can touch, and the audit trail supports incident review. Our trust and security overview describes how governance, audit and security work in practice.
Two published case studies show the kind of evidence a board can ask for. In the biopharma procurement case study, cost per purchase-request review fell from $11.57 to $1.21 over seven weeks while weekly volume grew from 205 to 2,712 requests. In the pharmaceutical rollout case study, one process grew into hundreds of digital workers across five functions, which is the scale at which an inventory and a review cadence become necessary. Neither is a bank deployment, so a bank's board should test the same questions against its own controls.
