What Not to Delegate to AI in Business: 3 Tests to Apply

What Not to Delegate to AI in Business: 3 Tests to Apply

Impact, reversibility and accountability: three tests for what not to delegate to AI in business, and what to keep with named people who own the outcome.

••

Want to apply this in your company?

Book a call with Juan →

What Not to Delegate to AI in Business: 3 Tests to Apply

Do not delegate to AI any decision that combines high impact on people or cash, difficulty reversing it, and the need for someone to answer for it. AI can prepare, summarize and propose, but in those cases the final decision belongs to an identified person with the authority and context to own the result.

Key takeaways

  • Three tests decide what stays with people: impact, reversibility and accountability.
  • The greater the possible harm and the harder it is to undo, the less autonomy the AI should have.
  • Delegating the preparation (drafting, summarizing, triage) is different from delegating the final decision.
  • Every decision needs an owner with a name, and an AI system cannot fill that role.
  • The boundary is not fixed. It moves as logs, evaluations and a well-measured pilot show what is safe.

Why ask what not to delegate before asking what to automate

Most conversations about AI in business start with opportunity: what can we automate? It is a fair question, but it favors enthusiasm and leaves the limits to be set after the first incident. When a limit appears only after a mistake, it tends to be drawn in a hurry and out of fear.

Reversing the order helps. If you define first what stays with people, everything else can be automated with more confidence, because the risk area is already fenced off. It also makes the conversation with your team easier. Many employees worry about being replaced, and they relax once they see where human judgment remains part of the design.

To choose what to automate first, use the decision matrix for picking processes. This article covers the other side: what should stay out, or stay under approval.

The three tests: impact, reversibility and accountability

There is no universal list of forbidden tasks. There is a set of questions that, applied to each decision, show how much autonomy the AI can have.

  • Impact: if the decision is wrong, who is hurt and how badly? A poorly worded reply to a sales lead is a different matter from denying a customer a benefit or issuing a warning to an employee.
  • Reversibility: can it be undone? Fixing an internal text is cheap. Sending a payment, deleting a record, cancelling a contract or publishing a statement on behalf of the company may not be reversible, and even when it is, the lost trust does not come back with it.
  • Accountability: who answers to the customer, the regulator, the court or the board? If the answer is a person or a team, that person must have seen and understood the decision. A language model does not account for its actions, holds no authority and cannot take responsibility for an error.

The key point is that the three tests add up. A low-impact task that is easy to undo can be automated with light supervision. A high-impact task that cannot be undone and carries personal accountability stays with people, even if the model seems right most of the time. Being right most of the time does not help when the exception is the case that lands on your legal team's desk.

What usually stays with people

Based on the three tests, some categories almost always call for a human decision. This is not a fixed rule, it is a starting point for an internal conversation.

  • Decisions about people: hiring, firing, promoting, disciplining, evaluating performance. These directly affect someone's life and carry risk of bias and employment-law duties. AI can organize information, but it should not be the criterion. For resume screening, see AI resume screening, bias and compliance.
  • Financial decisions outside policy: granting credit, making a discount exception, approving a refund above the approval limit, authorizing a new payment or changing a supplier's bank details. The article on AI in finance operations covers what to delegate and what to lock.
  • Legal commitments: accepting a contract, signing an amendment, answering a formal notice, promising a deadline or a warranty on the company's behalf.
  • Crisis communication and serious complaints: an accident, a data leak, a defective product, a customer in distress. In these moments tone matters as much as content.
  • Sensitive and vulnerable data: health, children, delicate financial situations. Brazil's data protection law (LGPD) requires extra care with sensitive data, and the national authority (ANPD) is the official reference for guidance. See also LGPD and artificial intelligence for organizing legal basis and record-keeping.
  • Strategic and ethical decisions: entering or leaving a market, changing pricing policy, defining what the company will and will not do. AI can build scenarios, but values and bets belong to whoever answers for the business.
  • Irreversible actions in systems: deleting data, changing production, granting access, moving money. Even when the agent has the tool, the action should go through approval.

Delegate the preparation, not the decision

Most of the value of AI in risky areas is in preparation. The common mistake is treating the task as all or nothing: either the AI decides, or it stays out. There is a useful and safe middle ground.

In practice, the AI can read the case history, summarize it, gather the applicable rules, flag inconsistencies, draft a reply and suggest a recommendation with its reasoning. The responsible person reviews, adjusts and decides. The time savings come from the reading and assembly work, which is what consumes the most hours, while the judgment stays human.

For this middle ground to work, the approval has to be real. If people click approve without reading because the volume is high, the design has become an automatic decision with a human facade. That is why it is worth measuring how long reviews take, how many suggestions are edited and how many are rejected. If nobody ever rejects anything, either the model is excellent or the review is not happening, and only the records can tell you which.

A decision guide: how to classify each task

A simple routine that fits in a one-hour meeting with the teams involved helps classify tasks without abstract debate.

  • Step one: write the task in one sentence, with the result it produces (a reply, a payment, a record change).
  • Step two: describe the worst plausible error, not the rare and absurd one. Who would be affected, and how?
  • Step three: ask whether the error can be detected and undone in time, and at what cost.
  • Step four: identify who answers for this decision today, by role and by name.
  • Step five: choose the autonomy level: the AI only suggests, the AI acts with approval, the AI acts within limits with sampled review, or the task stays fully human.
  • Step six: record the decision and a review date. Limits change, and a written record keeps the rule from turning into folklore.

If the answer to step three is that it cannot be undone, and the answer to step four is that someone answers for it personally, the autonomy level rarely goes beyond suggesting or acting with explicit approval.

Illustrative scenario: a cancellation with a refund on WhatsApp

Imagine, as an illustrative scenario, an installation services company that handles customers on WhatsApp. An unhappy customer asks to cancel and get their money back, and mentions they might go to Procon (Brazil's consumer protection agency).

A sensible design splits the case into parts. The AI agent can confirm the customer's identity, pull the contract and the support history, summarize the complaint and check whether the request fits the cancellation policy. It can also reply carefully, saying the case is under review and what the next step is, without promising an outcome.

What the agent does not do: approve a refund outside policy, admit fault on the company's behalf, deny the customer's right or respond to the Procon mention. It hands the case to a person in the responsible team, with the summary ready and a reasoned recommendation. The person decides, and the decision is recorded with the reason.

In this design, the customer is answered quickly, the team gets the preparation work done in advance, and whoever answers for the decision is still someone with a name and authority. For customer support in general, the article on AI customer support: what to automate and what to keep human applies the same logic to more situations.

How to turn the limit into a technical control

A rule written in a document prevents nothing if the agent has access to the tool. The limit has to exist in the system too.

  • Minimum permissions: the agent sees only the data and triggers only the actions the task needs. Read access before write access, write access before financial actions.
  • Built-in human approval: high-impact actions generate an approval request instead of running directly.
  • Approval limits in code: amounts, customer types and case categories that require a person should be checked outside the model by a deterministic rule, not only requested in the prompt.
  • Input and output validation: what goes into and comes out of the agent passes through checks. The article on guardrails for AI agents explains how to organize this.
  • Decision logging: every action, approval and rejection is logged, with the context used.

These practices line up with public references. OWASP lists excessive agency given to an agent among the risks of applications built on language models, and the NIST AI Risk Management Framework proposes organizing governance, mapping, measurement and management of risk. The OECD AI Principles also address accountability and human oversight. These sources help you justify internally why the limit exists.

How this thinking shows up in our working method

In implementation work, the method follows four moves: map, limit, pilot and hand over. When mapping, we describe the current process and its starting point, including who decides what. When limiting, we define the data the agent can access, the actions it may take and what requires human approval. When piloting, we choose one real workflow, with logs and a success metric agreed in advance. When handing over, we transfer the operation and the company decides whether to expand, adjust or stop.

The boundary of what stays with people is set mainly in the limiting step, but it is revisited in the pilot. If the records show that one type of case is handled consistently and at low risk, the company can extend autonomy for that type. If they show failures at a sensitive point, the limit tightens. To measure this methodically, see the guide to pilot metrics and decision gates.

Frequently asked questions

Can AI make decisions in a company? It can make low-impact, easily reversible decisions, within clear rules and with a record. Decisions that affect people, significant money or legal obligations should have a responsible person, with the AI in a support role.

Does LGPD ban automated decisions? Not in general, but the law gives people the right to request review of decisions made solely through automated processing that affect their interests. In practice, this reinforces keeping a person who can review and explain the result. For specific cases, get legal advice and check ANPD publications.

If the AI is right almost every time, why keep a person in the decision? Because the cost of an error matters more than how often it happens. In high-impact decisions that cannot be undone, the rare case is exactly the one that causes harm, a formal complaint or lost trust, and someone has to answer for it.

Do the limits change over time? Yes, and they should change based on evidence. With logs, evaluations and a measured pilot, a company can extend autonomy for case types shown to be safe, or reduce it where there are failures. What matters is that the change is a recorded decision, not a habit that settles in on its own.

Sources

AI governanceAI delegationhuman in the loopbusiness automationAI risk management