The useful AI is the one that knows your business. That's also the risky bit.

Generic AI can help you write an email. AI that knows the customer, their previous conversations, the order, your policies and what happened last time can help you deal with the enquiry. That's a much bigger opportunity. It also requires a much bigger conversation about access.

There's a fairly obvious limitation when you first start using AI in a business. It doesn't know your business. You know the customer.

The AI doesn't. You know which products you sell. It doesn't.

You know how your company handles refunds. It doesn't. You know where the latest price list lives.

It doesn't. You know that the document called FINAL-prices-v7-USE-THIS-ONE.xlsx is, despite appearances, not the final version. The AI definitely doesn't.

So we compensate. We paste things in. Upload documents.

Explain the context. Copy emails. Describe the customer.

Tell it the rules. And suddenly the answer gets much better. That's the beginning of a much bigger shift.

Because the really useful business AI isn't necessarily the AI with the highest score on some abstract intelligence test. It's the AI that has the right context for the work it's doing.

Intelligence without context only gets you so far

Imagine I give an extraordinarily capable person a job in your company on Monday morning. They're intelligent. Experienced.

Fast. But they don't know: your customers,

your products, your terminology, your systems,

your pricing, your history, your processes,

your exceptions, or how you actually do things. They can still be useful.

But they're limited. Now imagine they've worked there for five years. They know where everything is.

They understand which information matters. They know what happened with this customer last time. They understand the exceptions.

Same person. Very different capability inside the business. AI has a similar context problem.

This is why connecting AI to business information matters

The first phase of AI at work has involved a lot of humans manually supplying context. Here's the email. Here's our website.

Here's the document. Here's what the customer said last time. Here's the spreadsheet.

Here's our tone of voice. Here's the policy. That's useful.

But it's also cumbersome. The obvious next step is: Why can't the AI get the relevant information itself?

Increasingly, it can. AI can be connected to: documents,

email, CRM systems, calendars,

databases, project-management systems, customer-service platforms,

internal knowledge, and other business software. Now things become much more interesting.

And much more sensitive.

Context changes the usefulness of the answer

Ask generic AI: Write a follow-up email to this customer. It can produce something plausible.

Now give it: the original enquiry, previous correspondence,

the proposal, notes from the last call, the customer's account history,

the company's current service information, and the agreed next step. That's no longer simply generic writing assistance.

It can prepare something grounded in the actual relationship. That's much more valuable.

The same applies across the business

An AI answering: What is our refund policy? is only useful if it has the correct policy.

An AI answering: What's happening with this customer? needs access to the places where customer information actually lives.

An AI preparing a sales proposal needs: the enquiry, product information,

pricing, previous conversations, and potentially previous proposals.

An AI helping with operations needs: orders, status information,

supplier communications, process rules, and exceptions.

An AI helping developers may need: the codebase, documentation,

issues, technical architecture, and deployment information.

The model's general intelligence matters. But the context surrounding it increasingly determines what it can actually do for the business.

And this is where the risk changes

There's an enormous difference between: Help me rewrite this paragraph. and:

You can access our email, CRM, documents and customer records. The AI hasn't simply become more useful. Its position inside the business has changed.

It can potentially see much more. And if it can take actions as well as read information, the difference becomes larger again.

There are really two questions

When connecting AI to a business system, I'd separate: WHAT CAN IT SEE? from:

WHAT CAN IT DO? Those are not the same permission. An AI might be allowed to read customer records without changing them.

It might prepare a CRM update without applying it. It might draft an email without sending it. It might identify an overdue invoice without initiating any financial action.

It might suggest a calendar change without making one. This distinction is enormously useful. Access to information does not automatically need to mean authority to act.

Read access can still be significant

That doesn't mean read-only access is harmless. If an AI can read: every customer record,

all employee documents, financial information, commercially sensitive files,

contracts, emails, and internal conversations,

that's substantial access even if it can't change a single thing. So "it only has read access" isn't the end of the risk assessment. Ask whether it actually needs to read all of that.

Give AI the information required for the job

This sounds obvious, but it's a very good design principle. Suppose AI is categorising sales enquiries. Does it need access to every HR document?

No. Suppose it's preparing an order update. Does it need the entire company inbox?

Probably not. Suppose it's answering questions from a particular policy library. Does it need every document in the company drive?

Again, probably not. The goal isn't: Give the AI all our data so it becomes really clever.

It's: Give this AI process the information it needs to perform this job well. That's a very different architecture.

More context isn't automatically better context

This is worth emphasising. If you connect AI to everything, you haven't necessarily made it smarter. You may have made it more confused.

Imagine asking somebody a question and giving them 20,000 documents "just in case". Some are old. Some contradict each other.

Some are duplicates. Some shouldn't be there. Some are irrelevant.

Some contain information they shouldn't have access to. That's not good context. That's a cupboard.

Useful AI needs relevant, trustworthy and appropriately accessible information.

Your AI inherits your information problems

This connects to something I've written about before. If your business has: three different price lists,

two versions of the process, outdated CRM records, unnamed documents,

contradictory policies, and important knowledge living in people's heads, connecting AI doesn't fix the underlying problem.

It exposes it. AI can retrieve information very quickly. That isn't particularly helpful if the information is wrong.

Source matters

If AI tells an employee: The customer is entitled to a refund. I'd want to know why.

Did it use: the current refund policy? an old policy?

a previous email? something on the website? a note written by another employee?

its general knowledge? Where practical, business AI should make important sources visible. That gives the person using it a much better basis for deciding whether to trust the answer.

Freshness matters too

Business information changes. Prices change. Products change.

Policies change. People leave. Customers update details.

Processes evolve. So giving AI access to information isn't enough. You also need to think about:

Which information is authoritative? How current is it? What happens when it changes?

A beautifully implemented AI system connected to stale information can be worse than a mediocre system connected to the right information.

Access should follow the process

This is why I keep coming back to process mapping. Start with the work. What is the AI trying to do?

Then ask: What information is required? Where does that information live?

Which parts should it be able to retrieve? Which actions follow? Which actions require approval?

Now permissions emerge from the workflow. That's much better than connecting an AI to everything first and deciding what to do with it afterwards.

Think in layers of context

Not every AI task needs the same depth of business knowledge. I find it useful to think about several levels. LEVEL 1: PUBLIC CONTEXT

Information anybody could access. Your website. Published product information.

Public documentation. LEVEL 2: BUSINESS KNOWLEDGE Internal processes.

Policies. Templates. Product documentation.

Approved internal information. LEVEL 3: CUSTOMER OR CASE CONTEXT Specific customer records.

Previous conversations. Orders. Support history.

Account information. LEVEL 4: SENSITIVE BUSINESS CONTEXT Financial information.

Confidential commercial documents. Employee information. Sensitive customer information.

LEVEL 5: ACTION ACCESS The ability to change systems, send communications, create transactions, publish information or otherwise act. As you move down those levels, the potential usefulness can increase.

So should the care.

Don't confuse access with intelligence

There's another reason this distinction matters. Sometimes an AI system looks dramatically "smarter" simply because it has better information. A generic assistant might give a vague answer.

A connected system gives a precise one. The underlying model may be identical. The difference is context.

For businesses, that's actually encouraging. You don't always need to wait for the next frontier model to get more value from AI. Sometimes the improvement comes from designing the information around the model better.

But context creates dependency

Once employees become accustomed to AI knowing: where documents are, what happened with customers,

how processes work, and what information matters, that AI system becomes operationally important.

Now ask: What happens if it becomes unavailable? What happens if an integration breaks?

What happens if access permissions change? What happens if the AI retrieves the wrong source? What happens if the provider changes?

Again, we're moving from AI as a handy tool towards AI as infrastructure. The operational standard needs to rise with it.

Connected AI also changes the security conversation

The question is no longer only: Are employees pasting confidential information into ChatGPT? That's still worth thinking about.

But connected AI creates a broader set of questions. Which systems can it reach? Which accounts does it use?

Which permissions does it inherit? Can it retrieve information across departments? Can it take actions?

What gets logged? Can access be revoked quickly? What happens when an employee changes role?

What happens when someone leaves? These are ordinary systems questions. AI doesn't make them disappear.

It makes them more important.

Prompt injection becomes more relevant too

There's another complication when AI can read information from outside the business. An AI system may encounter text in: an email,

a webpage, a document, a support request,

or another external source. That content isn't automatically trustworthy simply because the AI can read it. A malicious or misleading instruction inside external content could attempt to influence what the AI does.

This becomes much more serious when the AI also has access to tools or sensitive information. The principle is straightforward: Content the AI reads should not automatically gain authority over what the AI is allowed to do.

Permissions still need to come from the system.

Imagine the inbox problem

Suppose an AI assistant can: read your email, access customer records,

and send messages. An email arrives containing instructions that attempt to manipulate the AI into retrieving unrelated information or taking an inappropriate action. A person would hopefully recognise that an email doesn't get to rewrite company security policy.

The AI system needs the same separation. External content is information. It isn't authority.

That's a very important distinction as AI becomes more connected.

Actions change the risk again

Reading an email is one thing. Sending one is another. Looking at an invoice is one thing.

Paying it is another. Reading a customer record is one thing. Changing it is another.

Preparing a website update is one thing. Publishing it is another. This is why I like separating AI capability from AI authority.

A system may be perfectly capable of doing something that you still don't want it doing autonomously.

Start read-only where possible

For a new connected AI workflow, one sensible progression is often: READ Let it access the information.

Then: RECOMMEND Let it suggest what should happen.

Then: PREPARE Let it create the proposed action.

Then perhaps: ACT WITH APPROVAL A person confirms.

Only after you've built evidence about reliability should you consider whether appropriate routine actions can happen automatically. You don't have to hand over everything on day one.

The safest AI isn't necessarily the least useful AI

There's an easy response to all of this: Don't connect AI to anything. Don't give it access.

Don't let it act. That certainly reduces some risks. It also removes much of the opportunity.

At the other extreme: Connect it to everything. Give it broad permissions.

Let it work autonomously. That maximises capability and potentially creates unnecessary exposure. The useful design space is in the middle.

Enough context to do the job well. Enough authority to make the workflow useful. Enough restriction that one mistake can't become a much bigger problem.

This is an architecture problem, not a trust exercise

I don't particularly like the question: Do we trust AI? It's too broad.

Trust it to do what? Under what conditions? With what information?

With what consequence if it's wrong? Instead of deciding whether AI is trustworthy in the abstract, design the system so it doesn't need unlimited trust. Limit access.

Limit authority. Make sources visible. Log actions.

Require approval where appropriate. Create escalation paths. Make important actions reversible where possible.

That's much more practical.

People need different AI access too

We already accept that employees shouldn't all have identical access to every business system. AI should be treated similarly. An AI workflow supporting marketing may need different information from one supporting finance.

A customer-service assistant needs different permissions from a coding agent. An internal knowledge assistant may need broad read access but no action access at all. Don't create one enormous AI identity with the keys to the company.

Design around roles and tasks.

And personal AI creates another question

As AI assistants become more capable, employees may want them to understand more about their work. Their email. Calendar.

Files. Contacts. Projects.

Messages. The more context an assistant has, the more useful it can become. But businesses need clarity around the boundary between:

personal productivity and company information and systems.

That's another reason a coherent AI approach matters. Otherwise every employee may independently create their own version of a connected business assistant.

The goal is useful context, not maximum context

I think this is the principle I'd keep. When designing AI for a business, don't ask: How much data can we connect?

Ask: What does this process need to know? Then provide that information as reliably and narrowly as practical.

If it needs more later, expand deliberately. This has another advantage. Less irrelevant context can often make the system easier to understand, test and maintain.

The better AI gets, the more this matters

As AI becomes more capable, businesses will naturally want to give it more meaningful work. More meaningful work usually requires more meaningful context. And increasingly it may require the ability to act.

So the conversation moves from: Can AI write this? to:

Can AI understand this customer? then: Can AI manage this part of the process?

and eventually: What should AI be allowed to do inside the business? That's a very different stage of adoption.

The useful AI is the connected AI

Not always. There will remain plenty of valuable standalone uses. But for many operational tasks, the big improvement comes when AI stops needing a person to manually explain the business every time.

It can find the relevant context. Understand what's happening. Prepare the next step.

Potentially take an appropriate action. That's when AI starts moving from assistant to infrastructure.

And that's exactly why we need to design it properly

The more AI knows about your business, the more useful it can become. The more systems it can reach, the more work it can potentially handle. The more actions it can take, the more human effort it can remove.

Those are enormous opportunities. They're also reasons to stop treating AI access casually. Don't give AI everything.

Don't give it nothing. Give it what the job requires. Know where that information comes from.

Know what it can do with it. Know what happens when it's wrong. And increase access and authority because the workflow justifies them, not simply because the technology allows them.

The goal isn't an AI that knows everything about your business. It's an AI that knows what it needs to know to do its job well.

Where to go next

• AI is getting smarter. Your business data might be what holds it back. Before connecting AI to more information, make sure the information itself can be trusted.
• The important question isn't what AI can do. It's what you should let it do. Use the Creative Sauce AI Authority Ladder to decide where AI should read, recommend, prepare and act.
• The most important AI may be the AI you stop noticing What happens when connected AI becomes part of the infrastructure underneath ordinary work.
• Do you really need 14 different AI tools? More connected AI also means more accounts, permissions and data relationships to manage.

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