Board expectations should be aligned with artificial intelligence capabilities by translating strategic ambitions into measurable use cases, validating performance with representative tests, defining human accountability, and linking investment to business outcomes. AI systems can automate pattern recognition, classification, summarization, prediction, and content generation, but they do not guarantee factual accuracy, independent judgment, stable performance, or business value.
What does aligning board expectations with AI capabilities mean?
Alignment means creating a shared understanding between directors, executives, technical teams, risk leaders, and operational users about what an AI system can and cannot do.
A board should be able to answer five questions before approving significant AI investment:
What business problem is the system solving?
Which tasks will AI perform, and which tasks remain human responsibilities?
How will accuracy, reliability, security, and financial return be measured?
What risks could arise from incorrect, biased, leaked, or noncompliant outputs?
What evidence supports the proposed timeline, budget, and expected results?
This process prevents two common governance failures:
AI overstatement: treating a language model, predictive model, or AI agent as an autonomous expert.
AI underinvestment: rejecting useful systems because early experiments did not meet unrealistic expectations.
The objective is not to reduce ambition. It is to establish conditions under which ambition can be tested, governed, and funded responsibly.
Why do boards often misunderstand artificial intelligence?
Boards usually encounter AI through vendor demonstrations, media coverage, investor presentations, and isolated success stories. These sources often show ideal inputs, carefully selected examples, and human correction that is not visible during the demonstration.
AI performance also varies according to:
Data quality and completeness
Prompt or input structure
Domain specialization
Model version
Retrieval system quality
Integration with business software
Human review procedures
Security and access controls
Changes in the operating environment
A model that performs well in a demonstration may perform poorly when exposed to incomplete records, unusual cases, ambiguous language, regulatory restrictions, or conflicting internal data.
Generative AI creates an additional communication problem. A system can produce fluent, well-structured text without possessing a reliable understanding of whether the content is true. This is why fluency must not be treated as evidence of accuracy.
The NIST AI Risk Management Framework describes trustworthy AI through characteristics including validity and reliability, safety, security and resilience, accountability and transparency, explainability and interpretability, privacy enhancement, and fairness with harmful bias managed.
What can AI reliably do today?
AI capabilities differ by task. Boards should assess the task rather than asking whether AI is generally "smart."
Where AI is often effective
AI can provide value when the task has clear inputs, a defined output, and a measurable quality standard. Common examples include:
Classifying customer support requests
Extracting fields from invoices and contracts
Detecting unusual transactions for human investigation
Summarizing long documents
Searching internal knowledge bases
Translating routine business content
Drafting marketing variations
Forecasting demand when historical data is relevant and stable
Recommending next actions to trained employees
Identifying duplicate records
Generating software test cases
Supporting code documentation
Prioritizing operational queues
These use cases still require testing. However, their risk can often be bounded through sampling, confidence thresholds, approval workflows, and exception handling.
Where AI remains unreliable
AI should not be treated as independently dependable when the task requires:
Guaranteed factual accuracy
Legal or medical judgment without qualified review
Understanding undocumented organizational context
Accountability for a high-impact decision
Perfect protection against adversarial input
Reasoning from unavailable or restricted data
Stable performance across every demographic or operating condition
Long-term autonomous planning without controls
Interpretation of ambiguous objectives
Compliance decisions without documented evidence
A system can support these activities, but responsibility must remain with appropriately qualified people and accountable business functions.
How should the board distinguish automation from augmentation?
Automation means that a system performs a task with limited human intervention. Augmentation means that AI supports a person who remains responsible for reviewing information and making the decision.
Automation is more appropriate when:
The task is repetitive
Errors have limited consequences
Outputs can be checked automatically
A reversal process exists
The system operates within narrow boundaries
Augmentation is more appropriate when:
The decision affects employment, credit, health, safety, legal rights, or access to services
Inputs are incomplete or ambiguous
The cost of an error is high
Contextual judgment is required
The organization cannot explain the output adequately
A qualified reviewer can detect and correct errors
A board should ask management to document the decision-rights model for each AI system:
What does the system recommend?
What can it execute?
Who approves the result?
Who investigates exceptions?
Who can stop the system?
Who is accountable when the output is wrong?
"Human in the loop" is not sufficient unless the human has the authority, time, training, and information required to challenge the AI output.
What evidence should management present before requesting AI funding?
A funding proposal should include evidence from the organization's own data and operating environment. Vendor benchmarks can be useful, but they should not replace internal validation.
Management should provide:
A defined business problem
A baseline process and current performance
A target metric
A representative test dataset
Error rates by relevant category
Examples of failure cases
Security and privacy assessment
Regulatory classification
Human review requirements
Implementation costs
Ongoing monitoring costs
Estimated financial and operational benefits
A clear exit or rollback plan
The proposal should separate three types of performance:
Technical performance: accuracy, precision, recall, latency, uptime, retrieval quality, or task completion rate.
Operational performance: reduced handling time, fewer escalations, improved service levels, or increased employee capacity.
Business performance: revenue, margin, retention, loss reduction, compliance improvement, or risk reduction.
A high benchmark score does not automatically create financial value. A model can be technically accurate while being too slow, too expensive, difficult to integrate, or poorly adopted by employees.
How can boards test whether an AI business case is realistic?
A practical approach is to require a staged business case.
Stage 1: Define the use case
The use case should identify:
The user
The decision or workflow
The source data
The expected output
The acceptable error rate
The consequences of failure
The human owner
Avoid broad statements such as "use AI to improve productivity." Replace them with specific objectives such as "reduce average claims-document review time by 25% while maintaining a documented human approval process."
Stage 2: Establish the baseline
Measure the existing process before introducing AI. Relevant baseline data may include:
Average completion time
Cost per transaction
Error rate
Rework rate
Employee workload
Customer satisfaction
Revenue conversion
Compliance exceptions
Without a baseline, the organization cannot demonstrate whether AI created improvement.
Stage 3: Run a representative evaluation
The test set should reflect real operating conditions, including:
Common cases
Rare cases
Poor-quality inputs
Missing information
Multiple languages where applicable
Sensitive or regulated content
Adversarial or misleading inputs
Records from different business units
Evaluation should include both successful outputs and failure modes. A small number of impressive examples should not determine deployment approval.
Stage 4: Pilot within controlled boundaries
A pilot should define:
A limited user group
A specific workflow
A fixed evaluation period
Access restrictions
Review requirements
Incident reporting
Rollback procedures
Success and failure thresholds
The pilot should not quietly become production use. Expansion should require a documented review of results.
Stage 5: Scale only after operational validation
Scaling requires more than a successful pilot. Management should confirm:
Data pipelines are reliable
Model monitoring is available
Users understand limitations
Support teams can handle incidents
Costs remain within approved limits
Security controls work under realistic conditions
The governance owner has authority
What are the main limits of generative AI?
Generative AI systems produce outputs based on statistical patterns learned from data and subsequent tuning. Their usefulness depends heavily on context, data access, instructions, evaluation, and workflow design.
Important limitations include:
Hallucination and unsupported claims
A language model may generate a plausible statement that is not supported by evidence. Retrieval-augmented generation can reduce this risk by supplying approved sources, but it does not eliminate incorrect interpretation, incomplete retrieval, or unsupported synthesis.
Inconsistent outputs
The same request may produce different wording or recommendations. This creates challenges for quality assurance, documentation, and repeatability.
Context limitations
Models have finite context windows and may fail to prioritize the most relevant information in long documents. A large context window does not guarantee accurate reasoning over every included item.
Data leakage and confidentiality risks
Prompts, documents, outputs, logs, connectors, and model-training settings can create different privacy risks. Sensitive information must be classified and governed before it is provided to an AI service.
Bias and uneven performance
Performance may vary across languages, demographic groups, writing styles, locations, or types of records. Testing should measure outcomes across relevant populations and use cases.
Weak causal reasoning
AI may identify correlations without establishing causation. This matters in forecasting, risk assessment, policy analysis, and strategic planning.
Agentic execution risk
AI agents can call tools, change records, send messages, or initiate transactions. Adding execution permissions increases the consequences of an incorrect instruction, compromised account, prompt injection, or defective integration.
Which governance frameworks should boards use?
No single framework answers every governance question. Organizations should combine business controls, technical testing, legal review, and sector requirements.
Relevant frameworks and standards include:
NIST AI Risk Management Framework: organizes AI risk activities around Govern, Map, Measure, and Manage.
NIST Generative AI Profile: extends risk considerations to generative AI systems, including large language models and related applications.
ISO/IEC 42001: provides requirements for an AI management system.
ISO/IEC 23894: addresses AI risk management.
ISO/IEC 27001: supports information-security management.
ISO/IEC 27701: supports privacy-information management.
OWASP Top 10 for Large Language Model Applications: identifies application-level risks such as prompt injection, insecure output handling, and sensitive information disclosure.
MITRE ATLAS: provides a knowledge base for adversarial tactics and techniques against machine-learning systems.
EU AI Act: uses a risk-based regulatory structure, with requirements varying according to the AI system and its use.
The EU AI Act includes obligations concerning risk management, data quality, logging, documentation, human oversight, robustness, cybersecurity, and accuracy for relevant high-risk systems. Its general-purpose AI provisions also address technical documentation, downstream information, copyright policies, training-content summaries, model evaluation, incident reporting, and cybersecurity for applicable providers.
Boards should ask legal and compliance leaders to identify which obligations apply to the organization's role: provider, deployer, importer, distributor, or user.
How should board reporting on AI change?
AI reporting should move beyond the number of pilots launched or employees given access to a chatbot.
A board dashboard should include:
Approved AI use cases
Business owner for each use case
Risk classification
Deployment stage
Performance against baseline
Accuracy and error rates
Material incidents
Privacy and security events
Human override rate
User adoption and training completion
Vendor dependencies
Model or prompt changes
Operating cost
Financial benefit
Regulatory status
Management should report negative results directly. A system that fails in testing may prevent a costly production incident. Suppressing failure data creates a governance problem and makes future investment decisions less reliable.
How can boards set realistic AI timelines?
AI timelines should distinguish between experimentation, integration, controlled deployment, and scaled adoption.
A realistic plan usually depends on:
Data availability
Data-cleaning requirements
Legacy-system integration
Identity and access management
Procurement and vendor review
Legal and privacy assessment
User training
Evaluation design
Monitoring capability
Change-management capacity
The model itself may be available quickly, while reliable deployment takes substantially longer. The most difficult work often involves data permissions, workflow redesign, controls, integration, and employee adoption.
Boards should challenge estimates that omit these activities. They should also ask whether the proposed timeline includes time for failed tests, redesign, and independent review.
What should the board ask an AI vendor?
Vendor claims should be tested through specific questions:
What tasks was the model evaluated on?
Which datasets were used?
How representative are those datasets of the organization's users and records?
What are the known failure modes?
How is factual accuracy measured?
Can customer data be used for training?
Where are prompts, documents, and outputs stored?
How are subcontractors governed?
What logging and audit capabilities exist?
How are model updates communicated?
Can the customer delay or reject updates?
What service levels apply?
What happens when the vendor experiences an outage?
Can the organization export its data and prompts?
What security testing has been conducted?
How does the vendor support regulatory obligations?
What controls exist for prompt injection and unauthorized tool use?
Contracts should define data ownership, confidentiality, breach notification, audit rights, service continuity, deletion, model changes, and termination assistance.
How should organizations communicate AI capabilities to employees?
Employees need practical instructions rather than general warnings.
Training should explain:
Which approved AI tools may be used
Which data may not be entered
When human review is mandatory
How to verify factual claims
How to cite or document AI assistance
How to report harmful or incorrect outputs
Which decisions cannot be delegated
How to recognize prompt injection and malicious content
How to use approved retrieval sources
When to escalate to legal, privacy, security, or risk teams
Policies should distinguish between experimentation and production use. An employee may be permitted to test a tool with public information while prohibited from entering customer records or confidential strategy documents.
What is the right executive decision model for AI investment?
A board can use four investment categories:
Proceed: Evidence shows acceptable performance, manageable risk, clear ownership, and a credible business case.
Proceed with controls: The use case is valuable, but deployment requires stronger review, restricted access, additional testing, or limited scope.
Pilot: The concept is promising, but evidence is insufficient for operational use.
Do not proceed: The use case lacks measurable value, presents unacceptable risk, or cannot be governed effectively.
This model prevents binary decisions based on enthusiasm or fear. It also gives management a clear path to improve a proposal that is not yet ready for deployment.
For additional guidance on practical AI governance and implementation, review the relevant resources available from The AI Table.
Frequently asked questions about board AI expectations
What is the biggest mistake boards make about AI?
The largest mistake is confusing a successful demonstration with a reliable business capability. A demonstration shows that a system can produce a result under selected conditions; it does not prove accuracy, security, scalability, adoption, or financial return in production.
Can generative AI replace expert employees?
Generative AI can automate or accelerate selected tasks, but it should not automatically replace expert accountability. Experts remain necessary where decisions require domain judgment, regulatory responsibility, relationship management, or evaluation of uncertain evidence.
How accurate must an AI system be?
The required accuracy depends on the use case and the cost of errors. A drafting assistant may tolerate more errors than a system supporting medical, employment, credit, safety, or legal decisions. Boards should require use-case-specific thresholds rather than one company-wide target.
Should every AI system have a human reviewer?
High-impact systems generally require meaningful human oversight. The reviewer must have sufficient expertise, time, authority, and access to evidence. Human review is ineffective if employees are pressured to accept AI outputs without examination.
How should AI return on investment be measured?
Measure changes against a pre-AI baseline. Include implementation, integration, licensing, monitoring, training, review, and incident-management costs. Evaluate financial impact alongside quality, risk, compliance, employee workload, and customer outcomes.
What should happen when an AI system fails?
The organization should have an incident process covering detection, escalation, containment, correction, documentation, customer or regulator notification where required, and post-incident review. Systems with consequential failure modes should have rollback or shutdown procedures.
Next steps checklist for the board
Identify the organization's five highest-priority AI use cases.
Assign an accountable executive and operational owner to each use case.
Document what the system can do, cannot do, and must not do.
Establish a baseline for time, cost, quality, and risk.
Require representative testing before production deployment.
Define acceptable error rates and escalation thresholds.
Classify use cases by legal, operational, privacy, security, and reputational risk.
Require human oversight for high-impact decisions.
Review vendor data, security, audit, continuity, and model-update terms.
Establish monitoring for accuracy, drift, incidents, access, and cost.
Report failed tests and material incidents to the board.
Approve scaling only when performance and governance evidence support it.
