Governing the invisible: a practical framework for AI oversight
November 2026 | SPOTLIGHT | BOARDROOM INTELLIGENCE
Financier Worldwide Magazine
As artificial intelligence (AI) becomes more autonomous, adaptive and interconnected, corporate boards face a governance problem that traditional reporting does not readily address: how to oversee systems whose behaviour directors cannot realistically understand in technical detail.
The answer is not to turn directors into AI engineers. It is to give them sufficient evidence to determine whether AI is being used within controlled and accountable boundaries.
The challenge is not simply complexity. Boards have always overseen technically esoteric activities, from derivatives and cyber security to pharmaceutical development and complex supply chains. What is distinctive about modern AI is the combination of probabilistic behaviour, incessant change, ever-expanding capabilities, burgeoning scale, agentic autonomy and interconnection with other systems.
Increasingly, AI systems can retrieve information, make recommendations, interact with software and take actions with limited human intervention. An AI agent with access to email, a payment platform, a code repository or a customer database presents different governance challenges from a model that merely produces a report.
The board does not need to comprehend every model. It needs to understand what authority has been delegated to AI, the boundaries around that authority, the assumptions on which the system’s use depends, the means to detect deviations and the responses to failed controls.
The objective is not to make AI completely transparent. It is to make the organisation’s reliance on AI governable.
System governance instead of model design
Much responsible-AI discussion has focused on model architecture: its accuracy, testing, biases and training. Despite those issues’ importance, they can lead boards toward governance myopia.
An AI model rarely makes a consequential business decision in isolation. It functions within a wider system comprising data, prompts, retrieval mechanisms, business rules, application programming interfaces, human approvals, downstream software and permissions.
Examples abound. AI-enabled credit processes, procurement systems, customer-service platforms, even software-development tools. The important governance question is not simply what the model produces but what the system can cause to happen.
For material AI systems, boards should therefore ask about: (i) the information the system can access; (ii) the decisions it can influence; (iii) the actions it can take; (iv) the systems it can invoke; (v) the actions requiring human approval; (vi) the evidence retained; (vii) controls that are technological versus merely procedural; and (viii) the personnel authorised to restrain it.
These are governance, rather than engineering, questions focusing on delegated authority: what the system can read, decide, execute and cause other systems or people to do. The inquiry, however, must overcome technological complexity and information deficiencies.
Boards traditionally rely on management to turn operational complexity into information they can use to exercise oversight. AI makes that task harder because AI systems can change faster than the board’s reporting cycle and sometimes faster than management can fully understand or describe. Relatedly, PwC Governance Insights Center’s ‘Board Oversight of AI Transformation’ August 2026 study noted that “71% of directors say that AI is the board capability most in need of strengthening”.
This creates an observability gap: a space between what an AI-enabled system can do and what those responsible for overseeing it can see and understand. Management therefore must be able to describe to the board the capabilities and safeguards of the company’s material AI systems.
For material systems, reporting should therefore cover their purpose and functions, the models and data they rely on, connected systems, permissions, decisions or actions they can influence, responsible personnel, approval thresholds, testing, material changes, incidents, and circumstances requiring suspension or reassessment.
The board does not require every technical detail. It needs enough reliable evidence to know that management understands the systems and can control them when circumstances change. The board also must be satisfied that the company has sufficient evidence to demonstrate to outsiders that it exercised appropriate control. That evidence might include AI inventories, access logs, testing records, change histories, approval records, incident reports, validation results, vendor assessments and records of human intervention.
The direction of AI regulation increasingly reinforces this approach. The EU Artificial Intelligence Act, for example, imposes requirements concerning risk management, documentation, logging, human oversight, robustness and cyber security for relevant high-risk systems, alongside transparency obligations for specified uses (see Regulation (EU) 1689 of the European Parliament and Council of 13 June 2024).
A framework for board oversight
A practical model can be built around the six questions outlined below.
First, where is AI being used? Management should maintain an enterprise-wide inventory of material AI use, including internally developed systems, vendor products and AI functionality embedded within existing software. Materiality should consider factors such as impact, autonomy, access, scale and reversibility.
The inventory should focus on capability and consequence rather than on whether something has formally been labelled an ‘AI system’ (a meeting summarisation tool and an AI system influencing recruitment, credit, pricing, safety or financial reporting should not necessarily receive the same level of oversight.)
AI governance is not limited to systems the company develops itself. AI can enter an organisation through other means, including cloud services, enterprise software, cyber security tools, customer relationship management platforms, human resources systems, coding assistants and vendor application programme interfaces. An organisation may therefore have delegated significant AI capability without deliberately deciding to ‘deploy AI’.
Vendor assurances are useful, but they do not necessarily establish what the company’s particular configuration can do, what data it exposes, what permissions have been granted or whether controls work effectively in the company’s environment. Rather, the board should inquire into the existence and efficacy of controls over AI risks delegated to third parties.
Second, what authority does AI have? For every material AI application, management should define its action boundaries, focusing on what it can read, write, recommend, approve, execute or trigger. This is particularly important for agentic AI. Expanding an AI system’s permissions can materially change the risk profile even when the underlying model remains unchanged.
The boundaries should be integrated into the system, not merely mandated by policy. For example, a policy requiring employees to review AI-generated payments is weaker than an architecture that prevents an AI agent from initiating a payment without appropriate authorisation.
Third, what assumptions does AI’s use depend upon? Every deployment rests on assumptions about data quality, users, operating conditions, permissions, business processes and output reliability. Those assumptions can become invalid even when the underlying model has not changed. Management should therefore identify the conditions under which approvals remain valid and the circumstances that require reassessment.
Fourth, what has changed? AI governance cannot rely solely on pre-deployment validation. A model can remain technically unchanged while becoming unsuitable because the business environment around it has changed. Boards should mandate reassessment following material model or system changes, new data sources, expanded permissions, new use cases, significant performance deterioration, unexplained output patterns, changes in operating context or serious incidents.
Fifth, what has gone wrong or nearly gone wrong? The most consequential AI event may be an exception that was not anticipated when the system was approved. Boards should therefore understand the organisation’s exception architecture. What causes escalation to a human? What constitutes an unusual event requiring automated processing to stop? Who can suspend the system? How quickly can that happen? Has the intervention mechanism been properly tested?
The objective is not to eliminate mishap. It is to ensure that breaches are bounded, visible and actionable.
Sixth, what independent evidence shows that controls work? This is where observability becomes assurance. Management reporting should distinguish between controls that exist and controls that have been tested. Internal audit, an independent AI assurance function, external testing or periodic specialist reviews can provide assurance separate from the executives responsible for deploying the technology. As in other aspects of business oversight, those responsible for achieving an outcome should not be the sole source of assurance that the controls surrounding it work.
To implement this framework, directors could receive reporting structured around six issues: (i) AI usage; (ii) scope of AI authority; (iii) assumptions underlying AI systems; (iv) changed circumstances; (v) incidents and near misses; and (vi) independent confirmation of control efficacy.
The sixth issue is crucial. Boards should focus on assessments, not absences. Reports of no incidents are not necessarily reassuring. They might mean the system is operating safely, but possibly that nobody is looking effectively. More robust indicators might include tests performed, exceptions identified, controls challenged, near misses, intervention events and corrective actions completed.
Controls, not code
AI does not change the nature of director duties, but it does alter the context in which existing responsibilities must be exercised. The focus on AI governance should not be whether directors understand the technology, but on whether they have sufficient evidence to validate management confidence in system use and safety. The framework proposed above is designed to facilitate that inquiry and support board oversight that is both realistic and effective.
Theodore Edelman is a founding partner at Gold Collins Edelman Advisors. He can be contacted on +1 (646) 270 0811 or by email: ted@gceadvisors.com.
© Financier Worldwide
BY
Theodore Edelman
Gold Collins Edelman Advisors