Customers now ask for AI on their own data: an MCP server in front of the API is the safe answer
The request is "ChatGPT on our data". The safe way to say yes is an MCP server with named read-only tools in front of your API, never a model on the database. What it looks like, and where to start.
More and more customers ask me the same thing: can we have an AI assistant on our own data. Behind it is a reasonable wish. Someone wants to ask a question in plain language and get an answer from the real system, orders, stock, customers, tickets, instead of clicking through five screens.
The quick way to say yes is to give a model a database connection and a prompt. I do not do that. A model with a connection string can read every table, including the ones nobody meant it to see, and nothing in a prompt reliably stops it. A prompt is a request, not a rule.
Named tools, read-only
MCP, the Model Context Protocol, is the open standard assistants use to call tools. An MCP server in front of your existing API exposes a short list of named tools, for example orders.search, customer.get and stock.low. Each tool does one thing, validates its input and calls the API the way your app already does. The model never sees a table. It sees a menu of questions it is allowed to ask.
The first version has read tools only. Anything that changes data comes later, and only where a person approves the action. That approval is built into the tool, not promised in a prompt.
The user's own rights
The server runs every call with the token of the person asking. If someone cannot see another customer's orders in the app, they cannot see them through the assistant either. There is no second permission model to keep in sync, and no way for a clever question to reach further than the person asking could reach.
A log of every call
Each call is logged: who asked, which tool ran, what came back. That makes the setup auditable. After a month it also shows which questions people actually ask, which is the best guide to what to build next.
What stays the same
Your API does not change. A new assistant, or a new model next year, is a configuration change in front of it, not a rebuild. I use this pattern in my own inventory product, and the case study on this site shows it running.
Where to start
Start with one workflow, not with "AI for the whole company". Pick a question that people ask every week and that costs real hours, write down what a good answer looks like, and build the two or three tools that answer it. That is the scope of AI Integration: quoted per use case at EUR 90 per hour excl. VAT, model costs capped and visible, and an evaluation set that decides whether it goes live. Details are at /services/ai-integration.
If the real question is bigger, such as which assistant, which hosting, whether to build or buy, that is a decision before it is a project. The Architecture Review is made for it: two days, 16 hours, EUR 1,440 excl. VAT, with a written recommendation and the conditions under which it would change. Details are at /services/architecture-review.
Tell me which question your team asks most often. I reply within one working day with the workflow I would start with.
This article is about: AI Integration
More news: PHP security release of 21 October fixes two critical remote code execution bugs · PHP 8.2 reaches end of life on 31 December: a two-day Health Check shows where your system stands · all news