The important question isn't what AI can do. It's what you should let it do.

AI is moving from answering questions to taking actions. That makes capability only half the conversation. Businesses also need to decide where the AI's authority starts and stops.

For most of the time businesses have been using generative AI, the risk has been reasonably contained. Ask AI to draft an email. It drafts an email.

If it's terrible, don't send it. Ask it to analyse a document. Read the analysis.

Ask it to write some code. Test the code. There is normally a person sitting between what the AI produces and what happens next.

That distinction is starting to disappear. AI can increasingly use tools, work with files, access business systems, browse websites and carry out actions. Which means we're moving from:

AI that tells you what it would do to: AI that can actually do it.

That's much more useful. It also requires a different conversation.

Capability and authority are not the same thing

Imagine an AI that is capable of replying to customer emails. There are several ways you could use it. It could:

Read the incoming email. Recommend what the response should say. Prepare the response.

Send the response. Those sound like small differences. Operationally, they're enormous.

The AI's underlying ability may be exactly the same. What changes is its authority. That's the distinction I think businesses need to start thinking about.

Not simply: Can the AI do this? But:

Should it be allowed to do this without somebody checking?

I think about AI permissions as a ladder

There isn't one switch marked: AI ACCESS: ON There are levels.

1. Read The AI can see information. A customer email.

A document. A CRM record. A spreadsheet.

A report. It can analyse that information but can't alter anything. This is usually the lowest level of operational authority.

2. Recommend The AI can look at the information and suggest what should happen. This customer appears to qualify for a refund.

These five leads should probably be followed up. This invoice appears to be overdue. Nothing has happened yet.

A human still decides. 3. Prepare Now the AI can create the next action.

Draft the email. Prepare the proposal. Complete the form.

Create the document. Populate the CRM fields. But it stops before committing the action.

A human can review it. 4. Change Now the AI can alter internal systems.

Update the CRM. Move a file. Change a status.

Edit a document. Create a task. This is where mistakes begin to have operational consequences.

5. Send Now the AI can communicate outside the business. Send the customer email.

Submit the form. Contact the supplier. Message the prospect.

The action is no longer entirely internal. Someone outside your organisation can see it. 6. Spend

Now we're getting into much more significant authority. Purchase something. Issue a refund.

Approve an expense. Place an order. Commit company money.

The potential cost of a mistake rises quickly. 7. Publish Put something somewhere the public can see it.

Change the website. Publish a social post. Send a newsletter.

Update public information. Again, the consequences have moved beyond the system itself. 8. Delete

Remove a record. Delete a file. Cancel something.

Revoke access. Destroy information. Some actions are easily reversible.

Others aren't. That should affect how much freedom the AI receives.

The ladder doesn't mean every business stops at the same rung

There is no universal rule saying AI should never send an email or spend money. The point is to make the decision deliberately. Consider two actions.

AI automatically reschedules a £15 internal software booking. AI automatically approves a £15,000 supplier payment. Both involve money.

The appropriate controls are obviously different. So rather than creating one company-wide rule about "AI autonomy", I'd look at individual processes. What could go wrong?

How likely are we to notice? Can it be reversed? Who is affected?

How much money is involved? Does the action leave the organisation? Is sensitive information involved?

That gives you a much more sensible basis for deciding what the AI should be allowed to do.

Human approval should sit where the consequence changes

This is the part I'd pay particular attention to when designing an AI workflow. You don't necessarily need a person checking every single step. That would defeat much of the point.

Instead, look for the point where the consequence changes. Let the AI: find the information,

analyse it, prepare the document, fill in the fields,

calculate the amount. Then perhaps stop before: SEND

PAY PUBLISH DELETE

APPROVE A human checks the work at that boundary. Once approved, the automation continues.

That can remove most of the work without removing the human from the decision that matters.

Approval doesn't have to mean checking everything

There is another version of this. Suppose AI handles customer refunds. You might decide:

Under £20, the AI can issue the refund automatically if certain conditions are met. £20 to £200 requires a customer-service manager. Above £200 requires another level of approval.

Now authority depends on risk. Businesses already operate like this. Expense limits.

Banking permissions. Purchase approvals. Access levels.

Management sign-off. AI doesn't require us to invent the concept. We need to apply existing operational thinking to a new kind of system.

Give AI the least authority it needs

This is a principle from security that translates extremely well to AI. If something only needs to read customer records, don't give it permission to delete them. If it only needs to prepare emails, don't give it permission to send them.

If it only needs one folder, don't give it the entire company drive. If it only needs to check invoices, don't give it unrestricted access to the bank account. The useful question is:

What is the minimum access and authority this AI needs to perform this job properly? Start there. Increase it when there is a reason.

More capable AI can actually make this more important

It might seem as though better AI reduces the need for controls. If the system becomes more accurate, perhaps we can just trust it. But greater capability can increase the number of things the system is capable of doing.

An AI that can only write text has limited operational reach. An AI that can: browse,

use software, write code, access files,

send messages, update systems, and trigger other tools

has much greater reach. Even if its error rate falls, the possible consequence of an error can rise. A very capable system with excessive permissions can create a bigger problem than a less capable system that can't do very much.

Mistakes can travel through workflows

This is something I think becomes particularly important with agents. Imagine AI incorrectly concludes that a customer cancelled an order. If all it does is tell an employee:

I think this order has been cancelled. someone may notice the mistake. Now imagine the AI:

changes the order status, updates the CRM, emails the warehouse,

issues the refund, sends the customer a cancellation email, and updates the sales report.

One wrong conclusion has now become six actions. Each later system may treat the earlier action as fact. This is why AI workflow design isn't simply about whether the model is accurate.

You need to think about how far an error can travel before somebody notices it.

Reversibility matters

Some AI actions are cheap to undo. Create the wrong internal task? Delete it.

Put a document in the wrong folder? Move it. Draft a bad email?

Don't send it. Other actions are harder. Send confidential information to the wrong person.

Publish incorrect information. Delete something permanently. Make a payment.

Accept contractual terms. Cancel a customer's service. Those deserve a higher threshold.

A useful question for every automated action is: If the AI gets this wrong, how easily can we put it back? The harder the answer, the more control I'd put around the action.

The AI should know when it isn't allowed to decide

A well-designed AI workflow shouldn't only know what it can do. It should know when to stop. The customer is asking something outside the normal process.

Stop. The information in two systems conflicts. Stop.

The amount exceeds the approval threshold. Stop. The AI isn't sufficiently confident which record is correct.

Stop. The action involves something explicitly excluded from automation. Stop.

Then escalate to a person. That isn't the AI failing. Escalating correctly is part of the job.

We need logs

Once AI starts taking actions, businesses also need to know what happened. What did the AI access? What information did it use?

What did it change? What did it send? Which tool did it call?

Did a human approve the action? When? What happened afterwards?

You don't necessarily need an enormous enterprise monitoring system for every small AI workflow. But if an AI can make meaningful changes to your business systems, there should be some record of what it did. Otherwise, when something goes wrong, you're left reconstructing the process afterwards.

"The AI did it" isn't accountability

This becomes especially important when customers or money are involved. An organisation can't really say: The AI decided to do that.

The AI is part of the organisation's system. Somebody chose to deploy it. Somebody determined what it could access.

Somebody decided which actions it could perform without approval. That means businesses need clear ownership. Who owns this workflow?

Who checks it? Who receives an alert when it fails? Who can switch it off?

Who is responsible for changing the rules? The more autonomous the process becomes, the more important those answers are.

Don't forget the accounts the AI is using

This sounds like a small technical detail. It isn't. Suppose an AI agent needs access to your CRM.

Whose account does it use? An employee's account? An administrator account?

A dedicated service account? Does that account have access to everything? What happens when somebody leaves?

Can you revoke the agent's access without disrupting somebody else's? The same questions apply to: email,

cloud storage, accounting software, social platforms,

websites, supplier systems, and internal tools.

If AI is becoming part of the workforce, its access needs to be managed like access. Not like a clever browser extension everybody installed one afternoon.

Then there is the outside world

An AI agent isn't necessarily operating only inside your trusted systems. It may browse websites. Read emails.

Open documents. Process information sent by customers. That creates another issue.

Some of the information it encounters may contain instructions. And those instructions may conflict with what you told the agent to do. This is one reason prompt injection matters much more when AI can take actions.

A malicious instruction inside a webpage or document is relatively harmless if the AI can only summarise it. It's more concerning if the AI can also: send files,

change records, use credentials, or trigger other systems.

Again, capability and permission interact. The AI doesn't only need to resist a bad instruction. Good system design should also limit what a successful bad instruction could achieve.

Don't build security entirely around the AI behaving perfectly

This is probably the broader principle. We don't secure ordinary software by saying: It's very reliable, so it won't do anything bad.

We limit permissions. Separate systems. Require authentication.

Set spending limits. Keep backups. Record activity.

Use approvals. Restrict access. AI shouldn't be different.

Better models will make fewer mistakes. Safety systems will improve. Agents will become better at recognising suspicious instructions.

But businesses should still design around the possibility that something goes wrong.

A simple way to think about any AI workflow

Before allowing an AI to act, I'd ask five questions. 1. What can it see? Which information and systems can the AI access?

2. What can it change? Can it alter records, files or settings? 3. What can leave the business?

Can it send messages, upload files or publish information? 4. What can it commit us to? Can it spend money, approve something, make a booking or accept terms?

5. Where does a human need to step in? Which actions have enough consequence that someone should check first? You don't need a 70-page AI governance policy to start answering those questions.

You need to understand the process you're automating.

The safest AI isn't necessarily the least useful one

There's a temptation to respond to all this by giving AI no authority whatsoever. That misses the point too. If every AI action requires a person to manually perform the same action afterwards, you haven't automated very much.

The objective is appropriate authority. Give the system enough freedom to remove meaningful work. Keep controls around the actions where mistakes matter.

And adjust those boundaries as the technology and your confidence in the process improve.

We already know how to do much of this

This is one of the reasons I don't see AI implementation as something completely detached from everything businesses did before it. We've spent decades thinking about: permissions,

access control, approval processes, audit trails,

risk, business rules, system ownership,

and exception handling. AI changes what the software can do. It doesn't make those disciplines obsolete.

It makes them more important.

So don't start with maximum autonomy

When someone demonstrates an AI agent completing an entire process on its own, it's impressive. But that's not necessarily how I'd introduce it into a real business. I'd start by giving it enough access to be useful.

Let it read. Let it recommend. Let it prepare.

See how reliably it performs. Then decide where it makes sense to let it change things. Send things.

Publish things. Spend things. And decide where you still want somebody to press the button.

Because the important question isn't whether AI is capable of doing something. Increasingly, it probably will be. The question for the business is:

How much authority are you prepared to give it? And that decision belongs to you, not the AI.

Where to go next

• AI is getting smarter. Your business data might be what holds it back. Before deciding what AI can do, work out what information it should actually be able to access.
• AI agents aren't digital employees. Here's what they actually are. What an AI agent actually does and why thinking in processes is more useful than creating imaginary AI employees.
• AI can now use the computer. That changes what businesses can automate. When AI can operate the same software your people use, permissions become much more important.
• The next shift in AI isn't better prompting. It's handing over the workflow. What happens when AI starts carrying work across multiple steps and systems.

Related: AI is getting smarter. Your business data might be what holds it back..