Superintelligence Questions Every Board Should Ask in Writing

The most useful superintelligence board questions are practical ones. A board that wants its company to hold up as AI systems grow more capable should ask management for written answers about who owns company data and know-how, which actions an AI system may take alone, how the company can leave a provider, and how it will see what those systems actually do. Written answers can be checked against contracts, permission records and logs later, which is what makes them worth asking for.

Key takeaways

• Ask for every answer in writing, and tie each one to a contract clause, a permission record or a log.
• Settle data and know-how ownership before any agent receives access to company systems.
• State approval limits as specific actions with named approvers, not as general intentions.
• Make exit rights cover memory, instructions, permissions and evidence, not only the model or the code.
• Give monitoring a named owner, agreed thresholds and a fixed review rhythm.

Why the answers must be written

Boards often receive reassurance in a meeting and find that it has faded by the next quarter. A written answer does three things a verbal one does not. It forces management to name an owner. It creates a document that can be compared with what actually happens months later. And it exposes gaps, because a question that cannot be answered in writing usually means nobody has made the decision yet.

The NIST AI Risk Management Framework organizes AI risk work around governance, mapping, measurement and management. The questions below follow the same logic in board language. They are not a technical audit. They ask whether the company has made the decisions that technical teams will later have to implement. The eight questions are:

• Who owns the company data, memory, prompts and workflows the agent creates, and can the company export all of them?
• Which systems may the agent read, which may it write to, and what does it never touch?
• Which actions require a named human approval before they happen, and who holds that approval?
• Who can stop or roll back the agent without asking the vendor, and how quickly can they do it?
• If the provider fails, changes its terms or is replaced, what can the company take with it, and how fast?
• How do the agent's permissions change when a model is upgraded or a new tool is connected, and who signs that change off?
• How are the agent's actions recorded, and who reviews those records on what schedule?
• What evidence would show the board that the agent is still doing the job it was approved to do?

A board that cannot yet judge the technical answers can still judge whether each answer has an owner, a document and a date. Companies that are still building their governance basics may find the lightweight structure in AI governance for mid-sized companies a useful place to start.

Questions one and two: data and know-how

Ownership comes first because it is the question most often answered by default. Standard vendor terms may grant broad rights to usage data, and the most valuable material may sit in places nobody budgeted to keep. The way the company's staff handle exceptions, the wording that wins renewals and the decision rules behind refunds often live in conversation histories and configuration files. The board should ask management to list each category of material the agent creates or holds, name the person responsible for it, and show that the company can export it in a usable form.

The second question concerns boundaries. An agent that can read the whole shared drive carries a different risk from one that reads a single folder of approved procedures. The OWASP Top 10 for LLM Applications lists excessive agency and sensitive information disclosure among the main risks for this reason. Ask for a short list of systems the agent reads, a shorter list of systems it writes to, and an explicit statement of what it never accesses, such as personnel files or unreleased financial results.

Questions three and four: approval limits

An approval limit is useful only when it names an action, a threshold and a person. The sentence "the agent should ask before doing anything important" is an intention, not a control. A usable limit reads differently: refund drafts above an agreed amount are prepared by the agent and released by the finance lead, messages to new external contacts go out only after the account owner reviews them, and changes to customer records are logged and reversible for a stated period.

The fourth question is about stopping. Ask who can pause the agent on a Friday evening, whether that person needs the provider's help to do it, and how the work already in progress would be handled. The answer should be a named role, a single step and a procedure that has been tested at least once. Pausing without losing finished work is a discipline of its own, and how to stop an AI pilot without wasting the work already done walks through it.

Questions five and six: exit rights and change control

Exit rights are the questions boards most often skip, because they feel like planning for failure. In practice the cost of leaving a provider is decided at the start. Ask whether the company can receive its memory stores, instruction files, tool definitions, permission matrix, evaluation sets and logs in a readable format, and how long a transfer would take. A company that holds only a vendor-specific export of conversation history has less control than it assumes. The longer analysis of this risk is in how to avoid AI vendor lock-in with business agents.

The sixth question concerns change. Capability tends to widen through model upgrades, new tools and new channels, and each of these can expand what an agent is able to do without anyone deciding that it should. Ask for the rule that sends every such change through a review before it reaches production, and ask who signs off. If the answer is that the vendor updates things automatically, the board has found a gap that needs an owner.

Questions seven and eight: monitoring

Records are useful only if someone reads them. Ask who reviews the agent's logs, how often, and what they look for: failed actions, escalations, unusual volume, requests outside the approved scope and corrections made by staff. Observability guidance such as the OpenTelemetry primer describes traces, metrics and logs as the basic signals of a running system. For a business agent, the practical equivalent is a record of what it was asked, what it read, what it did and which human approved each sensitive step.

The eighth question asks for evidence rather than confidence. Agree on two or three measures that match the job, such as how often a person had to correct the output, how often the agent escalated a case it should have escalated, and whether any action fell outside its approved list. Then set a recurring permission review so that access is checked against the current role, not the role from the first month. The steps for that review are described in how to run a permission review for your AI agents, step by step.

Turning the questions into a first-quarter plan

Answers that cannot be found in a contract, a permission record or a log are not yet answers.

Illustrative scenario: a mid-sized distributor gives its operations leader a first agent that drafts replies to supplier questions. The board asks the eight questions. Management discovers that supplier correspondence sits in a vendor workspace with no tested export path, that the agent can send messages without anyone reviewing them, and that nobody reads its logs. The fix is not a new strategy. It is a short set of written changes:

• Write the eight answers on one page, with a named owner for each.
• Attach the contract clause, permission record or log that supports each answer.
• Test one full export of memory, instructions and logs before the agent handles live correspondence.
• Change the agent so it drafts replies and a buyer sends them, and record that rule in the permission matrix.
• Put a monthly log review and a quarterly permission review on the calendar, with a named reviewer for each.
• Ask management to list any unanswered question with a deadline, and report it at the next meeting.

Be Human designs and operates personalized AI infrastructure for companies, so these questions are answered during design rather than discovered after launch. A first engagement defines one useful role, the memory and tools it needs, its approval boundaries and an observable success criterion. Managed operations then cover monitoring, recurring evaluations, permission review and controlled changes, with the records kept in a form the company can show its board.

If your company is not yet sure which task would be the right first one to hand to an agent, the free Be Human AI diagnostic can help you find it.

Frequently asked questions

Does a board need technical knowledge to ask these questions? No. Each question asks who owns a decision, where a record lives or what evidence exists, and those are governance questions a board can judge. Technical teams answer the implementation details, but the board can and should insist that every answer carries a name, a document and a review date.

Are these questions only relevant to companies that build their own AI models? No. Most companies that use AI will rely on a provider's model, and the risks of data ownership, approval limits, exit rights and monitoring apply to them as much as to model builders. Dependence on a provider is often the larger exposure for a company that does not build models.

Should the board wait until advanced AI is closer before acting? No. The controls that matter for a superintelligence future are the same controls that matter for capable systems today, such as clear ownership, limited access, tested exits and reviewed logs. Building them now means the company does not have to redesign its arrangements when systems become more capable.

Who in management should answer the questions in writing? The answers should come from the executive sponsor for the AI work, with each section completed by the person who operates that area, such as finance for approvals or operations for logs. The board should expect one document, signed off by the sponsor, that lists the owner and the evidence for each answer.

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