How do you give AI access to business data?

You give AI safe access to business data by not giving the access to the model, but to software with its own account, read-only permissions wherever possible, only the systems and fields the task needs, and a log of everything that is read and done. Personal data is removed wherever possible before a model sees it. The question is not whether the model can be trusted, but how much damage it can do if it makes a mistake or is misled.

Why should AI not simply get access to your CRM?

It is tempting. You connect an AI assistant to Salesforce or HubSpot, click Allow, and can ask questions about your pipeline. It works within five minutes. What happens at that moment:

• The AI application receives a key with your account's permissions. If you are an administrator, it can do everything an administrator can.
• Everything it reads goes to a language model: contacts, email addresses, phone numbers, notes about customers.
• What happens to that data depends on the provider's terms, which hardly anyone has read.
• There is often no record of what has been read or changed.

The CRM is also not a neutral source. It contains personal data, commercial arrangements and free text that anyone may have entered, including someone outside the company via a web form. A CRM connection without restrictions combines confidential data, text from outside and often a route to the outside as well. That combination is exactly where things go wrong.

What are the layers of safe AI access?

Safe access consists of five layers. Each layer limits what can happen in the next.

1. Which systems

Start by asking which systems the task really needs. To check invoices against contracts, that is the accounting system and the contract repository. Not the mailbox, not the HR system, not the shared drive. Every extra system is extra risk with no return.

2. Which permissions

Reading is different from writing, and writing is different from sending or deleting. For analysis and checks, read access is almost always enough. Grant write permissions only for a specific task, and then as narrowly as possible: adding notes, not changing records.

3. Which key, under which account

The software logs in with a key. Two rules of thumb:

• Its own account. Give the AI application its own user in every system, not an employee's account. That way the permissions can be defined precisely, and you can see in every system what the AI did and what a person did.
• Revocable. A connection via OAuth, the familiar Allow screen, can be revoked per app. A standalone API key sitting in a configuration file is often valid indefinitely and hard to trace.

4. Which data goes to the model

Even with the right permissions, not everything needs to go to the language model. Names, email addresses, phone numbers and bank account numbers are not needed for most analyses. An intermediate step that replaces them with tokens before the model sees them reduces the risk considerably. How that works is covered in how does tokenisation of business data work.

5. What is recorded

Every call: which system, which data, which action, when. Stored where the AI itself cannot reach it, and kept long enough to reconstruct a problem from weeks ago. See AI monitoring explained.

What are the ways to connect AI to data?

For serious applications on revenue data, the second or third approach is the right one. A direct connection is fine for experimenting with dummy data, not for production. How tools work is explained in what is tool calling.

Where does it go wrong?

The director clicks Allow. From then on the connection runs with the director's permissions: every customer, every deal, all the email. Three months later nobody remembers.

An API key in a shared document. Keys leak in mundane places: in a spreadsheet of settings, in a chat message to a colleague, in code that becomes public. A key works for anyone who has it.

Too many fields. An analysis of invoice amounts receives the entire customer record, including contacts and free-text notes. Those notes sometimes contain data that should never have been there.

No separation between testing and production. An experiment with real customer data in a free AI tool whose terms allow input to be used to improve models.

Permissions that do not carry over. An employee may only see their own customers in the CRM. The AI application with an administrator key shows them every customer. Access rules have to live in the data itself, not only in the interface. That principle is called row-level security: the database decides, per user, which rows are visible.

Worked example: what an overly broad key can cost

Worked example: suppose an AI assistant has read and write access to the entire CRM through an account manager's account. Because of an error in an instruction, it updates the "expected close date" field on 300 deals to the same date.

• Restoring from a backup or by hand: say two days of an employee's work.
• The forecast for that quarter is wrong for a week, and a management meeting takes decisions on the wrong figures.
• Because the changes are recorded under the account manager's account, it is not immediately clear what the AI did and what the account manager changed.

With its own account and read-only access, this would not have happened. With its own account and write access, it would at least have been immediately visible and reversible. The cost of proper scoping is an hour of configuration. The cost of not having it is unpredictable.

How do you connect AI safely, step by step?

1. Describe the task in one sentence. For example: check every month whether invoiced amounts match contract prices.
2. List the data needed for it. Not systems, but fields: contract number, price, start date, invoice lines. Contacts are usually not on the list.
3. Create a separate account in each system for the AI application, with read-only access to that data.
4. Decide what goes to the model. Can names and contact details be left out? If so, have an intermediate step replace them.
5. Record what the provider does with the data. Where is it processed, is it stored, is it used for training, is there a data processing agreement?
6. Switch on logging and decide who reviews it.
7. Schedule a review every six months of all connections and keys. In Google Workspace and Microsoft 365 you can see, per account, which apps have been granted access.

What does data protection law require?

As soon as personal data is involved, data protection law applies, in the EU the GDPR. That means, among other things: a purpose for which you process the data, no more data than necessary, and agreements with every party that processes it on your behalf. An AI provider that receives customer data is usually a processor, and that calls for a data processing agreement. Check the rules in your jurisdiction. The practical side is covered in how do you protect personal data in AI systems.

How does RiOS handle this?

RiOS, currently in beta, is being built on the same principles: read-only access wherever possible, writing back only after approval, only the systems you choose to connect, row-level security in the database and a tokenisation layer that removes personal data before anything reaches an AI model. A data processing agreement is part of onboarding, before anything is connected. The full model is on the security page. The wider role of AI in revenue control is covered in how does AI work within Revenue Intelligence.

Frequently asked questions

Is read-only access really safe?

Safer, not risk-free. With read-only access AI cannot break anything in your systems, but the data it reads can still end up in the wrong place. That is why limiting fields, tokenisation and agreements with the provider belong alongside it.

Can I connect my CRM to a free AI tool?

First check in the terms whether your input is used for training and where the data is processed. For customer data, a business edition with a data processing agreement is the minimum.

Who in my company should decide on this?

The owner of the data, usually the finance director or the board, together with whoever manages the system. Not the employee who finds the tool handy and clicks Allow.

How can I see which AI connections already exist?

The admin console of your CRM, email platform and accounting system shows, per account, which apps and keys have access. Go through that list for the accounts with the most permissions.