Planning for Superintelligence Without Guessing a Date

To plan for superintelligence without guessing a date, leaders should base decisions on steps that stay sound whether capable AI arrives early, late, or in a form nobody has predicted. Those steps are reversible, measured against evidence from your own operations, and bounded by explicit permissions. The goal is not to forecast the future but to keep your company able to adopt better systems as they appear, without rebuilding its data, memory and controls each time.

Key takeaways

• Plan around decisions that remain correct under many arrival scenarios, not around one predicted date.
• Separate reversible choices, such as vendor interfaces and tool scopes, from choices that are hard to undo, such as exposing proprietary know-how.
• Keep memory, tools and permissions under company control, with least-privilege access and a named owner for each.
• Measure every capability you depend on with repeatable checks, so you can see whether a newer system performs better on your work.
• Review the plan on a fixed rhythm and change it on evidence, not on headlines.

Why a forecast is the wrong foundation for the plan

Expert opinion about when systems more capable than people might appear varies widely, and it shifts as the field moves. A budget, hiring plan or vendor contract built around one date will be wrong at least once, and the cost of that error lands on the people who carried out the plan. Not having a date is not a reason to wait, though. The useful question is which decisions would still be sound if capability rose quickly, slowly, or in ways that look nothing like today's systems.

The NIST AI Risk Management Framework treats AI risk management as an ongoing practice across the system lifecycle, not a single approval at the point of purchase. The OECD AI Principles point in the same direction by asking organizations to be accountable for how their systems behave. You do not need to know when a more capable system will arrive to know that you need an inventory of where AI touches your work, a way to test it, and a way to change it.

Separate reversible decisions from irreversible ones

Most planning mistakes come from treating every decision with the same urgency. Some choices are cheap to change. Others shape the company for years and are expensive to unwind. Start by sorting your open decisions into two groups.

Reversible choices include:

• The model provider behind a given task, as long as the calling code talks to an interface you control.
• Prompts, instructions and workflow steps, which can be versioned and rolled back.
• The scope of a tool an agent can use, which can be narrowed or widened through a review.
• The size of a pilot and the set of users, which can be expanded or stopped.

Choices that are hard to reverse include:

• Giving a third party your proprietary process documentation, customer records or unreleased product details without clear terms on use and deletion.
• Letting an agent hold standing credentials to systems that move money or change customer data.
• Retiring the people who understand how a process really works before that knowledge is written down and tested.
• Signing multi-year commitments that tie your data formats to one vendor.

Move quickly on the first group and slow down on the second. For each irreversible choice, write down the reason, name who approved it, and set a date for the next review. For a wider view of how these layers fit together, see a one-page architecture map for leaders.

A step-by-step plan that holds under any arrival date

Run this sequence in each planning cycle. It is deliberately short so that it can be repeated without ceremony.

• Inventory: list every place AI already touches your work, including tools staff use without central approval. Note which data each one reads and writes.
• Name owners: assign one accountable person to each process and one to each agent. Ownership is what makes change possible.
• Write the boundaries: for each agent, state what it may do alone, what needs human approval, and what it must never do.
• Define success: set one measurable outcome per use, tied to the business process, such as the error rate on a defined sample or the time to a decision.
• Keep memory portable: store instructions, reference material and decision logs in formats you can export and read without the vendor.
• Build the check before the upgrade: define the test cases and the metrics that would show whether a newer model is better for your work.
• Release in small, reversible steps: every change has a rollback path and a named person who can stop the work.
• Review on a fixed rhythm: permissions, costs, evidence and dependencies, then decide what to change.

Hold this sequence fixed and let the content change. When a new capability appears, the question becomes whether it passes your checks inside your process, not whether it matches someone's prediction.

How do you measure capability with checks you can repeat?

Vendor announcements and benchmark results describe tests that may not resemble your work, so your own evidence is what matters. Observability concepts help here. The OpenTelemetry observability primer describes telemetry as the signals, such as traces, metrics and logs, that let you understand what a system did and why. Apply the same idea to agent work: record which inputs an agent received, which tools it called, what it produced, and where a person corrected it.

Build a small, fixed set of representative cases from real work. Include the awkward ones and the cases where earlier attempts failed. Run that set whenever the model, prompt or tool changes, and keep the results so that you can compare them over time. A repeatable check lets you say that a change improved a process, and it tells you clearly when it did not. Pair it with a precise definition of success, as described in how to define success criteria for an AI agent pilot.

Keep permissions, memory and tools under company control

As systems become more capable, the main risk shifts from what they can say to what they can do. The OWASP authorization guidance offers a useful baseline: deny by default, grant the minimum access needed, and check permissions on every action instead of trusting an earlier step. An agent that drafts replies does not need write access to the product catalogue. An agent that reads customer history does not need the ability to export it.

Review these grants on a schedule and whenever an agent's role changes. Keep memory, meaning the stored context an agent relies on, in storage your company controls, with a record of what was added and by whom. This is what allows you to move an agent to a different model later without losing what it learned from your operation. For the review itself, follow how to run a permission review for your AI agents, step by step.

Illustrative scenario: a regional distributor reviewing its plan

Illustrative scenario, not a client account: a regional distributor of building materials wants a plan for more capable AI, but its leaders disagree about timing. The operations director proposes a large tooling purchase for the following year, while the finance lead wants to wait. They reframe the discussion around three questions: which steps are reversible, which checks would show that a new system is better, and which permissions they could revoke quickly if something went wrong.

They approve a small set of moves. Order-status drafting goes ahead with read-only access to the order system and human sign-off before any message leaves the company. Standard procedures are moved into a knowledge base the company owns and can export. The large purchase is deferred, and the team agrees on a test set of real customer questions drawn from recent work. The purchase will be reconsidered only when a candidate system passes that test in their own process. Nothing in the plan depends on when a more capable model arrives.

How does a managed approach keep the plan current?

Be Human designs, implements and operates AI agents that keep their identity, memory, channels, tools, permissions and operating context under human control. 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, integration maintenance, permission review, incident response and controlled improvements, so the checks described above run on a schedule rather than when someone remembers. Changes move through a defined request and approval path, which keeps each upgrade reversible and documented. For a 90-day view of the preparation work, see a 90-day plan to prepare your company for far more capable AI.

If you are unsure which of your processes is the right first place to apply this plan, the free Be Human AI diagnostic can help you find the first task worth handing to an agent.

Frequently asked questions

Can a company plan for superintelligence if nobody knows when it will arrive? Yes. Plan around decisions that stay sound across a range of outcomes, such as keeping data portable, limiting agent permissions and measuring performance on your own work. These steps help whether capability grows quickly or slowly, and they remain worthwhile if the timeline turns out different from what anyone expected.

What is the first concrete step for a business owner? Make an inventory of where AI already touches your work, including tools staff use without central approval, and name an accountable owner for each process. Then pick one process where a mistake would be visible and reversible. This gives you a base for every later decision.

How often should the plan be reviewed? Review it on a fixed rhythm, such as every quarter, and also whenever a model, tool or permission changes. Use the same checks each time so the results can be compared. Change the plan when the evidence changes, not when a new announcement appears.

Do we need a large budget or a dedicated team to start? No. A small pilot with one owner, a written set of boundaries and a repeatable test set is enough to begin. Larger investments should wait until a candidate system has passed those checks in your own processes.

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