Looking for a way to connect the company data in your internal system, your AIS, to AI? Short answer: the system stays where it is, and next to it we build a small bridge through which Claude asks only for what the person asking is allowed to see. The rest of this article explains what that means in practice and why it isn't a year-long project.
A system three people understand
Nearly every company has one. An in-house register of jobs, contracts, service cases or complaints. A supplier wrote it years ago, or a handy colleague did. It runs on its own database, and every screen has twenty fields. The data is accurate and complete. Most people just can't get to it.
So it goes through people. A salesperson types into chat, “when did we last service the machine for Novák s.r.o.?”, and someone in the back office opens the system, clicks through three tabs, copies the date and sends it back. Ten minutes of work, once a day or twenty times. When she is on holiday, the answer waits.
“Ask Jana, she knows where it is in the system.”
— The most common sentence in a small company, paraphrased
What connecting your AIS to Claude actually means
AIS (agendový informační systém, an agenda information system) is a term from Czech public administration, where the act on public administration information systems defines it. In companies, people use it loosely for any internal register that runs one area of work. The way you connect it is the same either way.
Between Claude and the database we build a small MCP server. MCP (Model Context Protocol) is an open standard from Anthropic for connecting AI to tools and data. Think of a service counter at an office: Claude doesn't walk into the archive. It hands its request over the counter, and the clerk behind it checks who is asking and hands out only what that person is entitled to.
The server does a few clearly named things: find a job, show a client's history, list open cases. Every request carries the identity of a specific person, and the server lets it reach only the records that person can already see in the system itself. Nothing is copied anywhere, and no new copies appear outside your infrastructure.
Concretely: a service-job register
Take a small service company of twenty people (illustrative). Its system was built to order years ago on Microsoft SQL Server and tracks jobs, machines, technicians and billing status. Accounting then flows into Pohoda. None of that changes. The only addition is the bridge.
- Finds a job by customer, machine serial number or date and returns it in one sentence.
- Sums up a client's history: last service, open complaints, what has been invoiced and what hasn't.
- Lists what a technician has left this week, but only that technician's own jobs.
- Names the record behind every answer, so anyone can check it in one click.
The salesperson now asks Claude directly, “What do we know about machine serial 4471?”, and gets an answer with a link to the record. Jana in the back office gets on with her own work instead of copying dates. This is an illustrative scenario, not a specific customer's story, but questions exactly like these come up in small companies every day.
What AI over your AIS won't do, and why that's good
In its first version the bridge only reads. It doesn't change job statuses, doesn't delete, doesn't issue documents. Writing can be added later, and always with a person confirming. Claude doesn't learn from your data for later use either. It answers from what the server hands it at that moment.
And it won't make decisions. Whether to accept a complaint, what discount to give, which customer gets a technician first: that stays with people. The bridge shortens the path to information; it doesn't replace judgement. That is exactly why it can be trusted: it does one narrow thing, and every step it takes can be traced.
What it would take
Not a year-long project. We start by sitting down with the person who knows the AIS best and picking the three to five questions that come up most often. Those become an MCP server with read-only access, tied to your existing sign-in and running on your own infrastructure. Once it proves itself, more questions and more teams follow. Repeated routines, such as a briefing before a client visit, go into a skills library so the whole team can use them.
What's left
Claude can answer almost anything. It can't answer questions about your company until it reaches the data locked inside your internal register. So the model isn't the bottleneck. The gap between it and your AIS is, and that's the gap we close.
If you have a system three people understand and a queue of questions waiting for them, write to us. On a short call we'll go through which questions keep coming up at your company and what a first bridge would look like.