Superintelligence Board Oversight: Questions to Ask Management

Superintelligence board oversight comes down to four questions put to management: where the company is exposed to more capable AI, who owns the outcomes by name, which controls limit what AI systems can do, and how ready the company is when models improve or change. The board does not need to predict when or whether superintelligence arrives. It needs evidence that today's AI work is bounded, owned and reversible, so the company can absorb greater capability without surprise.

Key takeaways

• Oversight does not require a forecast. It requires evidence that current AI work is bounded, owned and reversible.
• Ask for an inventory of where AI already touches customers, money, data and decisions, including tools staff adopted on their own.
• Every AI system needs a named accountable executive, and the board must know which committee receives the reports.
• Controls matter more than intentions: narrow permissions, written approval boundaries, a tested way to stop an agent, and logs that someone reads.
• Readiness means a model change, vendor change or jump in capability triggers a defined review rather than a surprise.

What does superintelligence board oversight actually cover?

Directors usually meet this topic in one of two poor framings. In the first, it is distant speculation: interesting, but nothing to act on. In the second, it is a technical matter delegated entirely to IT. Neither helps a board that is accountable for risk, capital allocation and the reliability of what the company tells customers and regulators.

A more useful framing treats superintelligence as a direction of travel: models becoming more capable at reasoning, planning and acting through tools. Nobody on your board can say when particular thresholds will be crossed, and management cannot either. What the board can examine is how the company behaves as capability rises: what it allows AI to do, who is answerable, and how quickly it notices that something changed. Those questions are worth asking whether progress is gradual or abrupt.

Useful vocabulary already exists. The NIST AI Risk Management Framework organizes the work into governing, mapping, measuring and managing risk, and the OECD AI Principles emphasize accountability, robustness and transparency. Neither tells you what to buy, but both help a board say what it expects to see. Management can also start from the superintelligence readiness checklist and adapt it to the company.

The sections below use four headings, exposure, ownership, controls and readiness, because they give a board a compact structure that does not depend on technical depth.

Exposure: where could more capable AI reach the business?

Start with what already exists. Exposure is not only the agent the company deliberately built. It includes every place where an AI model can read company information, produce something a customer sees, or influence a decision. Ask management to account for each of these channels:

• Customer-facing output, such as replies, quotes or recommendations drafted or sent by AI.
• Internal agents with access to company systems like email, calendars, documents, the CRM or finance tools.
• Staff using personal or free AI accounts with company data.
• Suppliers that added AI features to software the company already uses.
• Decisions informed by AI output, such as forecasts, screening or prioritization, where nobody checks the reasoning.

The most useful single request is a one-page inventory with an owner beside every line. It will be incomplete the first time, and that incompleteness is itself information. A board that sees a short, confident list should ask how management knows nothing is missing.

The second exposure question is dependency. If the primary model provider changed its terms, retired a version or suffered a long outage, which processes would stop and which would merely slow down? Management should be able to answer in business terms, not technical ones. If the honest answer is that nobody has checked, that is a finding worth recording. The article on keeping the gains in-house as models change explains how companies reduce this dependency in practice.

Ownership: who is accountable, by name?

An AI system with a shared owner has no owner. The board should ask for one named executive per system, someone with authority over the process the system serves, not only someone who understands the technology. When an agent sends a wrong message to a customer, the person answering for it should be the person who owns the customer relationship.

Ownership has a few practical tests. A named owner should be able to answer these without preparation:

• What the system is allowed to do and what it is forbidden to do.
• What evidence shows it still works.
• What the last incident or near miss was, and what changed afterward.
• What it costs to run and which budget carries that cost.
• How to pause it, and who else is able to.

The executive sponsor role deserves attention because it is where accountability often thins out. The piece on what an executive sponsor for an AI project requires describes the time and authority the role needs. Boards should also ask what happens when that person leaves, because continuity of ownership is a control in its own right.

Finally, decide where reporting lands. Many companies place AI risk with the audit or risk committee, others with the full board for a period. Either can work. What does not work is leaving it unassigned. For companies without a formal structure, a lightweight governance start for mid-sized firms offers a workable minimum.

Controls: what can the agents do, and who can stop them?

Intentions do not limit an AI agent. Permissions do. The board's question is not whether management trusts the system, but what the system is technically able to do if it behaves badly, is manipulated, or simply makes a mistake. The OWASP guidance on authorization is a good reference for the principle of least privilege, and the OWASP Top 10 for LLM Applications catalogs the specific ways language model systems get misused, including prompt injection through emails, web pages and documents the agent reads.

Ask management to demonstrate, not describe, the following controls:

• Least privilege: each agent has only the access its role needs, granted system by system and reviewed on a schedule.
• Approval boundaries: a written list of actions the agent may take alone, actions that need human approval, and actions that are forbidden.
• A stop mechanism: a named person, a tested way to pause the agent, and the ability to revoke its credentials quickly.
• Logging: a record of what the agent read, decided and did, kept long enough to investigate an incident.
• Untrusted input handling: defenses against instructions hidden in content the agent processes.
• Backup and recovery: the agent's memory and configuration can be restored to a known good state.

The word tested matters. A stop switch nobody has used in practice is a hope. Ask when the last drill happened and what it revealed. A recurring review closes the loop: the guide to a quarterly AI agent permission review shows what evidence management can bring to the board each cycle.

Readiness: what happens when the model changes?

More capable AI usually arrives as an update, not an announcement. A provider releases a better version, a default changes, a tool gains new abilities. The question for the board is whether the company has a defined response, or whether the first sign of change will be a customer complaint.

Illustrative scenario: a distribution company runs an agent that drafts supplier replies and updates order notes. Its model provider releases a stronger version, and the new one is more persuasive and more willing to propose delivery terms on its own. A company with no baseline would not notice until a supplier cited a commitment nobody approved. A company with a fixed set of test cases, a recorded production version and a written approval boundary would see the difference before switching, and would keep the agent inside its authority.

That difference comes from a plan management can show the board. A sound change procedure looks like this:

• Record which model version is in production and pin it where the provider allows.
• Keep a fixed set of representative cases from real work, with outcomes agreed by the process owner.
• Run the new model against the same cases alongside the old one before changing anything live.
• Compare behavior as well as accuracy: tone, willingness to act, refusals and handling of ambiguous requests.
• Re-read permissions and approval boundaries, since a more capable model may attempt more than before.
• Release to a small group first, with a written rollback path.
• Record the decision and the evidence, and report it to the owner.

The board does not need to approve every model update. It should confirm that this procedure exists, that someone owns it, and that it has been used at least once.

Which questions should the board put to management?

The list below is short on purpose. It can be raised at a regular meeting and answered in writing, one page per question, with an owner's name attached.

• Exposure: Which processes, customers and data sets does AI touch today, including tools nobody formally approved?
• Dependency: Which providers would be hard to replace, and what would we lose within a week if one withdrew service?
• Ownership: Who is accountable for each system, and which board committee receives the report?
• Authority: What can each agent do without a human, and who approved those limits?
• Stopping: Who can pause an agent, how fast, and when was that last tested?
• Evidence: What recurring evaluation shows the system still does its job, and what does it show now?
• Change: What happens when a model is updated or replaced, and who signs off?
• Incidents: What went wrong since the last report, what changed as a result, and how would the board hear about the next one?

Treat the quality of the answers as the signal. Specific, short, owned answers suggest a company that is prepared. Long answers about vision, or answers that defer to a vendor, suggest the work has not started. Neither is a failure on its own, but the board should know which one it is looking at.

How does a managed approach support board reporting?

Be Human designs, implements and operates personalized AI infrastructure for companies. A first engagement defines one useful role for an agent, the memory and tools it needs, its approval boundaries and an observable success criterion. Managed operations can then include monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements. In board terms, that produces material for the questions above: an inventory of what the agent can reach, a record of its permissions and approvals, evaluation results over time, and a log of incidents and changes. The company keeps control of identity, memory, channels, tools and permissions, and management decides what the board sees.

Frequently asked questions

Does a mid-sized company board really need to discuss superintelligence? It does not need to debate timelines or philosophy. It does need to know how much of the business already depends on AI and whether that dependence is controlled. Those questions matter now and become more important as models improve.

Should the board create a separate AI committee? Usually not at first. Assigning AI reporting to an existing audit or risk committee, with a named management owner, is enough for most mid-sized companies. A dedicated committee becomes reasonable when AI affects core products or regulated decisions.

How often should management report on AI to the board? A short written update at regular meetings is usually sufficient, with an immediate report for any incident that affects customers, data or money. The update should cover inventory changes, permission changes, evaluation results and model changes. Consistency of format matters more than length.

What if management says the vendor handles all of this? Vendors can supply tools and evidence, but accountability stays with the company. Ask management to show which controls the vendor provides, which the company runs itself, and how the company would verify either. A good partner will welcome that question and answer it in writing.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.