Connecting AI to company data — how to plug a model into your own information

A language model with no access to your data is a well-read stranger who knows nothing about your company. It can draft an email, but it cannot tell you how many open jobs a given customer has.

All the value of AI in a company begins the moment the model starts seeing company data. And at exactly that moment the questions begin about how much of it, precisely, the model sees.

Three ways to connect — and why the first two fall short#

Pasting into a chat#

You copy data into a chat window and ask. It works immediately, requires nothing, and is the most common way companies start.

The limits show up within a week: the data is always a snapshot from the moment you pasted it, the volume is capped, nobody controls exactly what left the building, and every question means repeating the whole procedure.

This is a good way to check whether it is worth it at all. It is not a way to work.

A custom API integration#

A developer writes code that pulls data from your systems and feeds it to the model. Full control and full flexibility. For the narrower job of wiring two systems together, a ready-made connector in an automation platform gets there without one.

The cost: someone has to write it and then maintain it. Changing model vendor means rewriting part of the code. For a company of 11–200 people with no IT department, that is usually where the conversation ends. And the cost is only half of it: the integration only ever walks the path the developer fixed in advance, so nothing decides mid-question that a different one would fit better.

MCP — the standard that solved it#

Model Context Protocol is an open standard describing how a language model reaches the data and tools of an external system. A system exposes its data once in that standard, and every compatible model can use it — with no integration written separately per vendor.

In 2026, MCP is supported by every major work-platform vendor. The protocol itself has stopped being a differentiator and become a market baseline — which for you means you can simply assume it when choosing a tool.

We explain it in detail in what MCP is.

The question to ask your vendor: whose permissions?#

This is the single most important question in the topic and the one asked least often.

When an employee asks an AI agent about company data, the model can operate in one of two ways:

With the integration's permissions. The integration was configured once, usually by an administrator, and has access to everything. Every person asking gets answers drawn from the full dataset — regardless of what they personally should see.

With the asker's permissions. The model sees exactly what the person asking sees. A salesperson asking about payroll gets exactly what they would get by opening the system by hand: nothing.

The first variant is simpler to implement and therefore more common. It is also a quiet leak waiting for the first innocent question.

Which of the two you end up with is settled earlier than it looks — at the moment you point an AI client at the system's MCP server and pick the account the connection runs on.

Beyond permissions#

Masking sensitive fields. Even within a record someone has access to, some fields can be excluded from what reaches the model. Bank account or national ID numbers do not need to leave the system for an agent to answer a question about case status — and for the fields that do leave, it is worth knowing who processes them and how long they are kept.

A query log. A record of what was asked and which data was used. Without it you cannot reconstruct what happened when a question arises.

Revocable access. An external application connected via MCP should be disconnectable in one click, and the user should see a list of what they have connected. Same logic as signing in with a Google account — except the stakes are higher.

Separating read from write. A model reading data and a model changing data are two different risk levels. How control over writes works is covered in the guide on AI agents for business.

Why not to marry one model#

The language model market moves faster than anything else in business software. Within a year the quality leader, the pricing structure and the limits can all change.

An architecture hard-wired to one vendor transfers that risk entirely to you. A price rise or a quality regression becomes your problem with no exit — because the integration was written for that specific model.

A practical criterion when choosing a tool: can you change model vendor without rebuilding what you have built? If the answer is "yes, it's a setting", the risk is addressed. If it is "we'd have to rewrite the integrations", it is not.

Where to start in practice#

Step 1: one data source. Pick one area — jobs, customers, documents — and make sure it lives in one place with sensible permissions. AI connected to a mess returns a mess, which is why sorting the data out comes before connecting the model.

Step 2: read-only. Week one: the model answers questions and changes nothing. This exposes data quality faster than any audit — bad answers almost always mean bad data.

Step 3: test permissions from the user's side. Log in as an employee with restricted access and ask the agent about something they should not see. It is a five-minute test that tells you more than the documentation.

Step 4: only now, writes. And immediately with human approval of actions.

Then the next source, one at a time — every system you connect lengthens the list of tools the model reads before every single question.

Where to next#

• What MCP is — the protocol explained without jargon
• AI agents for business — control over what the model does with data
• AI adoption for companies with no IT department — the wider context