How a Company Prepares for Increasingly Capable AI: 10 Questions

AI readiness for more capable models means your company can receive them without losing control over data, decisions and accountability. It does not depend on predicting when those models will arrive. It depends on documented processes, limited access, defined approvals and logs detailed enough to reconstruct what the AI did. The ten questions below can be answered by the owner or the operations lead in a short meeting, and the gaps that surface show where to start.

Key takeaways

• Readiness is about control over your operation, not about forecasting how models will evolve.
• Data needs a named owner, a stated purpose and written limits before any new tool can access it.
• Actions with financial, legal or customer impact need a defined and recorded human approval.
• Logs that cannot reconstruct a decision are useless for audits, error correction or learning.
• A more capable model amplifies what already exists, so processes and controls come before any model change.

Why the question is about control, not the model

The debate about superintelligence usually centers on future capabilities, which is a legitimate long-term discussion. For someone running a company today, though, the useful question is more concrete: when a better model is available, can the organization use it without widening risks it already fails to control? That question applies to a model swap, to a new agent on WhatsApp, or to a tool that starts acting inside internal systems.

The answer is rarely in the model itself. It sits in four layers the company manages: the data that goes in, the processes that define the work, the approvals that authorize actions and the records that show what happened. When those layers are fragile, a more capable model tends to produce errors that are more convincing and harder to detect.

For a closer look at what separates current systems from speculation, read Superintelligence vs ChatGPT: The Real Difference for Business, which keeps the discussion at the level of real operational decisions.

Data: who owns it, what goes in and what stays out

The first group of questions covers data, because that is where exposure often happens without anyone noticing. Answer with the actual list of tools in use, including the ones staff test on their own:

• Which customer, employee and supplier data is currently sent to AI tools, and who authorized each of those connections?
• Is there a written list of what must never be entered into a model, including sensitive data, trade secrets and third-party information?
• Do we know in which country each tool processes and stores data, and has that been assessed under Brazil's LGPD?

If any answer is vague, the gap is in the inventory, not in the technology. A company that does not know which data feeds its agents cannot limit them. Cross-border data flows have their own requirements, covered in the article on international data transfer with AI providers under LGPD.

Processes: what is documented before you automate

More capable models are tempting for poorly described processes, because they can fill gaps with plausible-sounding answers. That is exactly the risk. The questions in this section separate rules from judgment:

• Can I describe the current process step by step, including the most frequent exceptions and who decides each one?
• Which parts of the process are fixed rules, such as deadlines, discount limits or mandatory documents, and which depend on interpretation?

The practical rule is to keep deterministic steps in standard flows with explicit conditions and validations, and reserve AI for the steps that genuinely require reading context. A process that is not written down cannot be delegated, whether to a simple model or an advanced one.

Approvals: who is allowed to say yes on the machine's behalf

This is where an operation gains or loses trust. Every action that changes something for the customer, the cash position or the customer record needs a named human owner. The questions to ask are:

• Which agent actions require human approval before they happen, such as granting a discount, cancelling, declining a request, sending a proposal or changing a record?
• When approval is not possible, because the person is unavailable or the system fails, does the agent stop, hand off or continue? Who is accountable for that decision?
• Is there a way for a customer to request a review of an automated decision, and does a person carry out that review?

The last two questions connect to LGPD provisions on automated decisions and the right to review. The article on Article 20 and the right to review explains what to watch for. Operationally, the rule is simple: if no one can explain or reverse a decision, that decision should not be automatic.

Logs and traceability: the evidence of what happened

Logs are not a technical detail. They are the operation's memory. For each relevant interaction, the company should be able to say what came in, which instructions and which model were used, which tools the agent called and what was actually done. Observability practices, such as those described in the OpenTelemetry observability primer, help frame these records as signals that must be collected, correlated and searchable.

The two questions in this group are:

• For each relevant agent decision, can we reconstruct the input, the version of the instructions, the model used and the action executed?
• Are those records kept somewhere the operations team can query without depending on one person or on a vendor that could change access terms?

If the answer is no, the priority is not hiring a better model. It is instrumenting what already exists. For teams starting to organize this, the piece on testing AI agents with mocks and sandboxes shows how to validate behavior before the system is exposed to customers.

Model changes, vendors and exit

The last question covers change. Models shift in behavior, vendors alter pricing and terms, and platform rules evolve. The company needs to know whether it can detect a quality change and roll it back:

• If the current model is replaced or its behavior changes, do we have a set of test cases that shows whether the output is still acceptable before the change reaches customers?

The useful reference here is evaluation practice. Published guidance on evals from OpenAI and Anthropic's writing on evaluating AI agents both treat evaluation as a continuous process, not a one-time test. For a company, this means keeping a list of real situations with expected responses and running it whenever something changes.

Turning the answers into a plan

Suppose a building materials store wants an agent on WhatsApp to handle quote requests. Illustrative scenario: during the meeting, the owner finds that the price list is updated by one person in a spreadsheet, that discounts above a certain level are agreed by phone, and that no one keeps a history of approved conversations. The questions on data, processes, approvals and logs point to three tasks before any pilot: make the price list a single source of truth, write the discount rule and name who approves exceptions, and start recording each quote along with the version of the price list used.

The suggested path follows four steps, which summarize the working method we apply in AI projects:

• Map the current process and a baseline, using measurements taken from the operation itself.
• Limit data and actions, defining what the agent reads, what it writes and what it never does on its own.
• Pilot one real flow, with logs and a success measure agreed before starting.
• Hand over the operation and decide whether to expand, adjust or stop the pilot.

The logic behind this order is that each step depends on what the previous one produced. It makes no sense to pilot without limits, or to expand without logs. At the end of the meeting, the decision question is objective: which gaps must be closed for a pilot to be safe, and who is responsible for closing them.

If the company works in a sector with well-defined flows, such as electronics repair intake and status tracking, the inventory is usually faster to build. In areas that require a lot of judgment, the approval step deserves more care.

Frequently asked questions

Do we need a technical team to answer these questions? Not necessarily. The questions are management questions and ask for facts about the operation: which data circulates, who approves what and where the records are kept. The technical team comes in afterward to implement the controls leadership defined. When nobody can answer a point, that is already the most important finding of the meeting.

Are these questions only for companies that will adopt superintelligence? They apply to any company that uses or plans to use AI with some autonomy, whether the model is simple or advanced. Superintelligence, as a concept, is not a product a company buys today. What exists are AI systems that keep getting more capable, and the need for control applies to all of them. That makes the exercise worthwhile even if the future debate feels distant.

What is the first step if most answers are negative? Start with an inventory, not with automation. List the AI tools in use, the data each one receives and the actions each one can execute. Then choose a single real process, low in risk and with clear rules, to serve as the pilot. This avoids trying to fix everything at once.

Does LGPD require something specific for AI agents? LGPD applies to the processing of personal data regardless of the technology used. That includes purpose, legal basis, transparency and the possibility of reviewing automated decisions, as the law provides. For official and current guidance, the reference is Brazil's National Data Protection Authority (ANPD), and the broader regulatory picture can be followed in the article on Brazil AI regulation and what companies should do now.

Sources

• NIST AI Risk Management Framework
• OWASP Top 10 for LLM Applications
• OpenTelemetry: observability primer
• ANPD: Brazil's National Data Protection Authority

Sources

• NIST AI Risk Management Framework
• OWASP Top 10 for LLM Applications
• OpenTelemetry: observability concepts
• ANPD: Autoridade Nacional de Proteção de Dados