90 Day Plan to Prepare Your Company for Advanced AI: Map, Limit, Pilot

To prepare your company for more capable AI, you do not need to guess when it arrives or what it will do. You need mapped processes, clear limits on data and actions, and at least one real workflow running with logs and a named owner. A 90 day plan in three blocks, map, limit and pilot, builds that foundation with evidence you can verify, without promising any result.

Key takeaways

• Preparing the company does not depend on predicting future technology. It depends on knowing which processes exist, which data moves through them and who decides what.
• The first block produces a map and a baseline. Without them, no change can be evaluated honestly.
• The second block defines what the AI can see and do. The more capable the system, the more important it is that the limit sits outside it, in permissions and rules.
• The third block runs a single real workflow with logs, an agreed metric and human review, and ends in a decision: expand, adjust or stop.
• Every block ends with deliverables that someone else can check. If it cannot be checked, it does not count as delivered.

What does it mean to prepare when nobody knows what comes next?

The term superintelligence usually appears in debates about systems that would outperform people on almost every intellectual task. Today that is a hypothesis, not a product your company can buy. If you want to understand where each concept ends, read the difference between AGI, ASI and AI agents and separate what is debate from what is a tool you can actually run.

What a company really operates are increasingly capable models and agents that read documents, use tools and carry out steps in sequence. Preparing for that is a management problem, not a forecasting exercise. The useful questions are practical:

• Which processes would I hand to a more capable system, and which never?
• What data could it see, and what must stay out of reach?
• What actions could it take on its own, and which require a person's approval?
• How would I notice that something went wrong, and who responds?

These questions apply to today's model and even more to tomorrow's. A company that answers them in writing is better prepared than one that follows every news item but has no documented permissions.

Three references help give the reasoning some structure: the NIST AI Risk Management Framework, which organizes AI risk management; the OWASP Top 10 for LLM applications, which describes typical failures of systems built on language models; and Anthropic's article on building effective agents, which argues for starting simple and adding complexity only when needed. None of them promises a business result. They serve as a technical foundation.

Block 1, first 30 days: how do you map without stalling operations?

The goal of the first block is to know where the company stands today. Mapping is not redesigning processes. It is describing what actually happens, with whom, in which tools and with which data.

Suggested steps:

• List the processes that consume the most time from skilled people: customer service, quoting, checking, collections, triage, reporting.
• For each one, describe the input, output, owner, tool used (spreadsheet, CRM, WhatsApp, ERP) and the point where a human decision happens.
• Mark where personal data, financial data or sensitive customer information is involved.
• Choose two or three candidate processes and record a baseline: how long they take, how many rounds of back and forth they need, what kinds of errors appear. Record it the way the operation already measures it, even if it is a team estimate, and say that it is an estimate.
• Survey the informal AI use that already exists. People often use assistants on their own, and that is part of the map.

Verifiable deliverables for this block:

• A process inventory, one page per process, reviewed by the owner of each area.
• A list of data by sensitivity, showing where each type is stored.
• A written baseline for the candidate processes.
• A report of current AI tool use, without punishment, only to learn the reality.

A simple completion test: someone who did not take part in the survey can read the documents and explain the process to another person. If they cannot, the map is still vague.

If informal use turned up, this is the moment to start a clear rule. The article on a company policy for ChatGPT use details what is usually allowed, restricted and banned.

Block 2, days 31 to 60: how do you limit data, actions and responsibilities?

In the second block, the company decides what the AI can touch. The logic is that the limit should not depend on the model behaving well. It should live in permissions, credentials and workflow rules. This matters more as models become more capable and more persuasive, because a system that can act needs a ceiling on action defined by the people who operate it.

Suggested steps:

• Sort actions into three groups: the agent can do alone (check status, draft a reply), the agent proposes and a person approves (send a proposal, change a record, grant a discount), and the agent never does (delete data, touch payments, decide about people).
• Apply the principle of least privilege. Each integration gets only the permissions the pilot workflow needs, with its own credentials that can be revoked. The OWASP authorization cheat sheet is a good checklist reference.
• Define what the agent reads and what it does not. Sensitive data stays out of the context, or goes in minimized.
• Check the legal basis and the LGPD duties for the chosen workflow, including notice to the data subject and any transfer of data outside Brazil. The ANPD website is the official starting point, and the article on Brazil AI regulation and what companies should watch helps you know what to follow.
• Write the intervention plan: who can pause the agent, how, and how long it takes to resume operating after a problem.
• Name one owner per workflow. Without a name, responsibility dissolves.

Verifiable deliverables for this block:

• An action matrix with the three groups above, signed by the area owner.
• A list of integrations and permissions granted, with a review date.
• A record of decisions on data and legal basis, reviewed by whoever handles privacy or legal.
• A pause procedure tested at least once, with the result written down.

An honest test for this block: if the agent were tricked by a malicious message hidden in a document or email, what is the worst it could do with its current permissions? If the answer is uncomfortable, reduce permissions before moving on. OWASP material on prompt injection prevention describes this kind of risk.

Block 3, days 61 to 90: how do you pilot a real workflow safely?

The third block puts a single workflow into real operation, with a small scope. The important word is single. Several simultaneous pilots produce noise and no conclusion.

Suggested steps:

• Choose the workflow with the best mix of real pain, controllable data and low risk. Answers to frequent questions, request triage or document drafts are usually better candidates than financial decisions.
• Define the success metric before starting, together with the team, and write down what would be a signal to stop. An example formulation: time to first correct answer, or amount of rework per request, compared with the baseline from the first block.
• Prepare test cases with anonymized real situations and hard situations. Test first in an isolated environment with simulated data. The article on testing AI agents with mock tools and a sandbox shows how to do this without risk.
• Turn on records of every decision: what came in, what the agent answered or proposed, which tool it used, who approved. The observability concepts from OpenTelemetry help you think about logs, metrics and traces.
• Keep a person reviewing outputs at the start. Reduce review only when the records show stability.
• Schedule short weekly reviews to look at errors, cases escalated to a human and complaints.

Verifiable deliverables for this block:

• A documented pilot, with scope, metrics and stop criteria.
• A set of test cases and the results of each round.
• A record of the agent's decisions, accessible to whoever audits.
• A final report comparing the baseline with what was observed, including what did not work.

The end of the third block is a decision: expand, adjust or stop. Stopping is a legitimate outcome. A pilot that shows the process is not a good candidate has saved an investment.

Illustrative scenario: a triage pilot at a services company

Illustrative scenario, not related to any real company. A services company receives quote requests by WhatsApp and email. In the first block, the team finds that each request passes through three people and that many messages arrive without enough information. They record this as the baseline.

In the second block, they define that the agent can ask qualification questions and assemble a summary of the request, but cannot state prices or promise deadlines. It gets read-only access to the customer records and no access to payment data. Any mention of a complaint or a legal matter goes straight to a person.

In the third block, the pilot runs for only one type of service. Each conversation generates a record with the summary and the routing decision. The agreed metric is the share of requests that reach the estimator complete. At the end, the team compares it with the baseline, lists the misunderstanding errors and decides to adjust the questions before expanding. Nothing in this scenario depends on the model being more or less powerful: if a better model appears, the limit stays the same and the test can be repeated.

How do map, limit, pilot and transfer fit together?

The three blocks follow the method we use in AI projects: map the current process and baseline, limit data and actions, pilot a real workflow with logs and an agreed metric, and transfer the operation with documentation, training and decision criteria. The fourth step happens after day ninety: whoever operates the system must be able to adjust, pause and audit it without depending on the people who built it. For a view of how these blocks are organized technically, see the company superintelligence layer architecture.

How do you know the plan worked, and when should you not expand?

The plan worked if the company can answer in writing what the AI can see, what it can do, who answers for it and how it is switched off. That is verifiable. Financial results are not part of the criteria, because nobody can guarantee them in 90 days and promising that would be dishonest.

Signs that you should not expand yet:

• The baseline was never measured, so there is nothing to compare against.
• The records do not let you reconstruct a specific decision.
• The team works around the agent because it gets in the way instead of helping.
• Sensitive data showed up in the workflow that was not on the map.
• Nobody takes responsibility for the workflow.

Signs that you can expand with care: the errors are known and handled, human review has decreased because the records show stability, and the next candidate workflow has already gone through the mapping block. Repeat the cycle for it instead of copying the previous pilot.

Finally, set aside a periodic review of the plan. When a new model appears, run the same test cases before changing anything in production. The prepared company is not the one that reacts fastest to every release, it is the one that can test and decide calmly.

Frequently asked questions

Do I need to wait for superintelligence to exist before starting this plan? No. The plan deals with processes, data and permissions, which matter with today's models. If more capable systems appear, the company will already have limits and tests ready to reassess them.

Who should take part in the 90 days? Ideally a sponsor with decision power, the owner of each mapped process, someone from technology and someone who handles privacy or legal. In small companies, one person can hold several roles, as long as it is written down.

Does the plan work for customer service on WhatsApp? Yes, and it is a good pilot candidate when the scope is narrow and there is handoff to a human. You need to handle opt-in, conversation windows and personal data, and the limit on what the agent can promise should be in the action matrix. The article on the WhatsApp 24 hour customer service window covers how an agent should act inside it.

What do I do if the pilot shows the process is not a good candidate? Document the reason and close it. That is a valid result of the plan, because it avoids expanding something that does not hold up. Go back to the inventory from the first block and choose the next process based on the baseline and the risk.

Sources

• NIST: AI Risk Management Framework
• OWASP: Top 10 para aplicações com LLM
• Anthropic: Building effective agents
• ANPD: Autoridade Nacional de Proteção de Dados