A business AI assistant connected to your data can answer questions about bookings, case files, invoices and documents by reading the real information, show where that information came from and, if you allow it, prepare actions such as a change or a quote for someone to confirm. It is not a chatbot replying with canned text or with whatever it knows from the internet. Nor is it a colleague who decides on its own: it only sees the data you grant it, with the permissions of the person using it, and important actions go through a confirmation step. This article looks at how it works in detail and where the limits are.
What changes with a business integration?
The language model can be the same one: I work with Anthropic (Claude) and OpenAI models via API. The difference is not the model but what gets built around it. General chat tools can connect to external services these days too; a business assistant, however, is configured around your systems, with clear rules on:
- which sources it can consult (documents, management software, booking engine, CRM);
- who can use it and with which permissions;
- which actions it can propose and which need confirmation;
- what is logged for later review.
That layer of rules is software, written and tested like any other part of a management system. That is where reliability is decided, not in the prompt.
FAQ chatbots and AI assistants
A FAQ chatbot has a list of preset questions and answers. If a customer’s question does not match any of them, it replies generically or points to a form. It is simple and predictable, and for some cases that is perfectly fine.
An AI assistant connected to data understands freely worded questions and answers by reading current information. Asked “is my booking for Saturday confirmed?”, a FAQ chatbot can only explain how to check; a connected assistant can look up the status of that booking, once it has identified the customer.
Which information can an assistant access?
Two kinds of source, which often coexist:
| Source | Examples | How it reaches them |
|---|---|---|
| Unstructured documents | Manuals, procedures, contracts, terms of sale, emails | Document search (RAG) |
| Structured data | Bookings, availability, case files, invoices, customer records | Calls to the management software or booking engine APIs |
Access is decided source by source. A customer-facing assistant has no need for supplier records; one for the accounts team has no need for support conversations.
Example: querying a management system
Imagine a tour operator who wants to ask “how many bookings do we have for tomorrow?” without opening the admin panel and setting filters. The assistant turns the question into a precise request to the management software (date, booking status), receives the result and replies with the number and a note of which data it used. If the question is ambiguous (tomorrow for which tour? confirmed only?), it should ask rather than guess.
Example: customer support
A customer writes on WhatsApp: “is my booking confirmed?”. The assistant might, for example, ask for the booking reference and the email address used, verify them and only then read the status. If the request turns into a refund or a complaint, it hands the conversation to a person along with a summary of what has been said so far.
Example: documents and invoices
In accounts, the question might be “which invoices for this customer are still open?”. The answer comes from the management software’s structured data, not from searching PDFs. For incoming documents, on the other hand, the assistant can read a supplier invoice, extract the details and propose the entry: confirmation stays with whoever handles the books, with the original document alongside.
Tool calling and APIs explained
“Tool calling” is how a model asks to use a tool. It works like this:
- The backend describes the available tools to the model, such as “search bookings by date” or “read a customer’s open invoices”.
- Faced with a question, the model proposes calling a tool with certain parameters.
- The backend checks the user’s identity, the parameters and the permissions, and only calls the API if everything is in order.
- The result goes back to the model, which uses it to write the answer.
The key point: the model never touches the database directly. It proposes; the software decides. If the management software does not yet have suitable APIs, building them is often the first job; I cover that in the article on APIs and business software integration.
Reading data and taking actions
Reading and changing data are separate permissions, granted separately. Many assistants start read-only, and that is fine. When it makes sense for them to act, for example updating a booking or creating a draft quote, each action is its own tool with its own rules and value checks: a date in the past or a group larger than capacity is rejected by the software, whatever the model proposed.
RAG and structured data access
RAG (retrieval-augmented generation) means that before answering, the system searches the documents for relevant passages and passes them to the model along with the question. It suits procedures, terms and manuals. It does not suit figures that change by the minute, such as availability or balances: those need a direct API call that returns the exact value at that moment. A good assistant uses both routes and always cites its source: the document and section, or the record in the management software.
Security and permissions
The rules I work with:
- The assistant inherits the user’s permissions. If a member of staff cannot see another branch’s data in the management software, they cannot see it by asking the assistant either.
- Access only to the data needed for the use case, nothing more.
- Providers whose contracts exclude training on submitted data. That is how I choose AI services; it does not replace the privacy assessment that remains the company’s responsibility.
- A log of every question, call and action, so what happened can be reconstructed.
- Spending limits on AI service usage.
When human approval is needed
A practical rule: approval is needed whenever an action changes data, involves money or reaches a customer. That covers changing or cancelling bookings, quotes, accounting entries and outgoing emails on sensitive matters. The confirmation must spell out what is about to happen and what changes compared with before, not just a generic “proceed?”.
Limits and errors
An AI assistant makes mistakes. It can misread a question, pick the wrong document or summarise badly. The safeguards are part of the design: cited sources so answers can be checked, an “I don’t know” when the data is not there, confirmation on actions, and a log to analyse errors. Before going live it is worth preparing a set of real questions with expected answers and checking how the assistant behaves, repeating the test after every change.
How much does development cost?
There is no standard price, because it depends on what needs connecting. The factors that weigh most:
- Sources: how many, and whether they already have usable APIs.
- Channels: website, WhatsApp, internal panel.
- Users and permissions: a single role or many.
- Actions: read-only, or changes with confirmation too.
- Evaluation: how many test questions and difficult cases.
- Maintenance: keeping documents, tools and rules up to date over time.
- Usage: on top of development there is a running cost for AI services, which depends on request volume.
Development and the monthly running cost should be estimated separately, based on your own numbers.
How to start with one use case
The safest route is to pick one question or task that wastes time every day, connect the assistant only to the data that task needs, read-only if possible, and try it with a few people. If you need ideas on which processes lend themselves to it, I have put together ten practical examples of AI in business processes.
Let’s start with one repetitive task and check whether an AI assistant is a suitable solution. The page on AI assistants connected to your data explains how I work; to talk it through, get in touch.
Frequently asked questions
Can an AI assistant read data from my management software?
Yes, as long as the software exposes data in a controlled way, through APIs or dedicated queries. If it does not, those can be built; the assistant should never access the database directly.
Can it update a booking or create a quote?
It can prepare them. The action is carried out by the software after value checks and, for important operations, after a person confirms.
Does the AI use my data for training?
I use AI services whose contracts exclude training on submitted data, and the assistant only accesses the data you decide.