The Czech word is napojeni. The English word is integration. The verb is to integrate, or in plain speech to connect. When a vendor offers to connect your accounting system to AI, the proposal will say integration or connector. The rest of that meeting rests on another six words, so here they are.
Integration, not connection
A connection is a cable or a login. An integration is the thing you actually care about: a standing arrangement where two systems hand data to each other and nobody has to sit between them exporting spreadsheets. Connecting a system to AI is to integrate a system with AI, or less formally to connect X to Y. Hooking into an interface usually appears on the quote as API integration.
The difference is not a language lesson. When a proposal says connector, you are buying a piece of software. When it says integration, you are buying a state of affairs that somebody has to keep alive. The two words sit in different lines of the budget.
We have it connected. To what exactly, and who can see it in there, nobody asked.
— A digitisation meeting, abridged
Seven words that will come up
You do not need to write code. You need to know what each thing does, so you can tell when somebody is selling you a door and when they are selling you a lock.
- Integration. A standing link between two systems so they pass data without a person in the middle.
- API. The door a piece of software leaves open for other software: ask here, this is how I answer.
- Endpoint. One specific address on that door, for example the one where invoices live.
- Connector. The software that joins two interfaces and translates one into the other.
- Authentication and token. Proof that a real person or service is behind the request.
- Scope. What exactly that token is allowed to open. Read invoices yes, delete them no. It is a formal term, defined by the OAuth 2.0 standard.
- Webhook. The reverse direction: the system calls you when something happens, instead of you polling it forever.
With those seven you can survive the meeting. What is left is the names of specific systems and version numbers.
And then there is MCP
MCP stands for Model Context Protocol. Anthropic published it as an open standard in November 2024, and it solves one dull but expensive problem: every integration used to be invented from scratch. Each system had its own interface, each link to AI was one-off work, and nobody could repeat it a month later.
An analogy. APIs are doors into one particular building, each a different height with a different handle. MCP is the agreement on how those handles get described, so the model can read for itself what is behind the door and what it is allowed to do there. The piece of software that publishes the description is called an MCP server. It is small, one per system, and you can read it in an afternoon.
What travels through it is the point. The identity of the person asking rides along with the request, instead of one shared company key. A salesperson asks about their own deals, finance asks about invoices, and neither of them gets further than they would get in their own browser.
Concretely: accounting, CRM and one bridge
A twenty-person company keeps its books in an accounting system such as Pohoda, its deals in some CRM, and its contracts on a shared Drive. A question like how much do March customers still owe us today, and which are already on a second reminder, currently means an export, a spreadsheet, and half an hour from somebody who was meant to be doing something else. With a bridge in place it is one question in plain language.
- It turns the question into a specific request against the accounting interface.
- It sends the identity of the person asking, not a universal key that opens everything.
- It returns the answer with links to the records it came from, so it can be checked.
- It writes to the audit trail: who asked, about what, and when.
Illustratively: a freelance bookkeeper running the books for five small firms could walk through receivables for every client in the morning, and spend the afternoon only on the ones that genuinely need a phone call. The checking stays with her. The hunting goes away.
What integration will not do, and why that is good
It will not give you rights you do not have. If payroll is closed to you, it is closed to the answer as well. It will not decide to write off a receivable, will not send a reminder without approval, and will not sign anything. And it will not create a copy of your database in somebody else's service, because it asks through the interface you already run and the data stays where it was.
That reads like a list of limitations. It is a list of reasons the pattern is usable in accounting and payroll, where mistakes hurt. A bridge that can do everything never gets let into a company. A bridge that does exactly one thing and leaves a trace does.
What it would take
You start with one system and one question that repeats every week. The bridge runs on your infrastructure, under your identity, with your audit trail. It is not a year-long programme. It is a first connection that either saves time or does not, and that shows up quickly.
What is left
The model is not the bottleneck today. Claude can read an invoice and a contract. The bottleneck is the distance between it and the data your company already has: in accounting, in the CRM, on the Drive, in the mailbox. The glossary above is really a map of that distance, written in English.
If you already know which weekly task annoys you most, write to us. A short call is enough for us to say whether a bridge fits it, what it would take, and where it would not be worth starting.