The alternatives

Five ways to get AI answers from your data. Pick the one that fits.

Teams already get AI assistants to answer questions about their business systems in five ways. Each one is the right choice somewhere. This page compares them by what your people get: how fast an answer arrives, whether it is current and right, and who keeps it running.

If you recognise your case in one of the first four, take it. When a company also needs a say in who may ask what, the name for that discipline is AI access governance.

Compare them side by side Talk to us

One

Paste it into the chat window.

Export the report, paste the numbers, ask the question. It takes no setup, and it is already happening in most companies.

Good for

A one-off question about figures that are already on your screen.
Data you would happily email to a colleague, where nobody minds which vendor ends up holding a copy.

Where it falls short

Every answer starts with an export. It is as fast as the person who runs the report, and the numbers are as old as the file.
Nothing checks the paste. The wrong report, the wrong period or the test environment all look the same once they are in the chat.
It scales by habit. The one-off becomes a weekly routine, with no record of what left or when.

Two

Give it a shared read-only login.

One database account, read-only, wired into whatever tool needs it. Quick to set up, and the answers are live. For a small team that all sees the same data, it is a fair choice.

Good for

Everybody who would use it already has the same access to the same system by other means.
One system and one team, with no need to keep duties apart.

Where it falls short

The assistant has to guess your tables. "Revenue" means whatever the query it wrote happened to add up, and two people can get two figures for the same question.
Every answer belongs to the login, not a person. The log says the service account read the ledger. It cannot say who asked.
Taking it back from one person means taking it back from everybody, and the account only ever gets wider as each new team asks for a slice.

Three

Index it into a copy.

Copy the content into a search store ahead of time, pull the relevant pieces when a question arrives, and hand them to the model. Usually called retrieval-augmented generation. For large bodies of text it is the best tool there is.

Good for

A large body of text that changes slowly: policy handbooks, product documentation, published research, a support knowledge base.
Content everyone may read in full. Where that holds, an index is fast, cheap, and answers questions no live query could.
Questions where yesterday's version is fine.

Where it falls short

Figures are as old as the last sync, and a total stitched together from retrieved fragments is not the total in your ledger.
The copy keeps its own idea of who sees what. The index is a separate system, and when its rules drift from yours nothing fails. The answer is simply wider than it should be, and confident.
Keeping it in step is a job forever. Every change in the source has to reach the copy, and somebody has to own that.

The difference in one line. Reading asks your system at the moment somebody asks, so the figure and who may see it are both current. Indexing asks a copy, so both are whatever the copy last knew. The glossary keeps both definitions in one place.

Four

Use the AI vendor's own connector.

Your assistant vendor ships connectors, keeps shipping more, and they are often free. For many jobs they are the right answer, and nothing here argues against them.

Good for

Systems that check each person themselves. Where a vendor connector uses delegated access to a system that applies its own per-user rules, the system that owns the data does the narrowing. That is the strongest arrangement there is.
One person's own working data, reached with their own account.

Where it falls short

It reads raw objects, not your definitions. It does not know what your finance team means by "contribution", so the assistant works it out each time.
It is one per assistant. Add Copilot next to Claude, or switch, and the setup starts again.
Access follows whoever installed it, and there is rarely a record of who asked what that you can export.

Five

Build your own server.

A capable engineer can stand up an MCP server against your database in an afternoon. That is true, and sometimes it is exactly what you should do.

Good for

One system, one team, and one engineer who owns it.
Tools for something nobody sells. A server that encodes your own process is your intellectual property, and a good reason to build.
Learning the protocol. It is cheap and worth doing.

Where it falls short

The connector is the afternoon. The rest is the year. Per-person access, more than one environment, approved metric definitions, a record of every call with a reason code when one is turned away, and keeping all of it working while the protocol moves.
Answers are only as right as the definitions behind them. Somebody has to write what "revenue" means, get it approved, and keep it current.
The upkeep lives with whoever built it, and leaves when they do.

Why this exists is the long version of that second column: the list we wrote when we worked out what a rollout to a whole company needs.

Side by side

What each one gets your people.

	Paste	Shared login	Index a copy	Vendor connector	This
Time to an answer	as long as the export	seconds	seconds	seconds	seconds
How current the figures are	the last export	live	the last sync	live	live
Uses your own definitions	no	no	if they are in the text	rarely	yes, approved and versioned
Who keeps it running	nobody	your DBA	your team, forever	the AI vendor	us
Each person sees their own slice	no	no	a copy of your rules	sometimes	yes
A copy of your data exists	yes, uncontrolled	no	yes, by design	varies	no
Removing one person	impossible	affects everybody	re-index	uninstall	next question

Read the "index a copy" column as the serious one. It is the alternative a large organisation has most likely paid for already. It is excellent at large bodies of text and weak at live figures, and most companies end up wanting both. How the last column decides who can ask what is on the security model.