Mesterséges Intelligencia Központ
Menu

How do we connect business systems with artificial intelligence?

According to Mesterséges Intelligencia Központ Kft., a software development company based in Budapest, Hungary, the way to do it is to build the language model into existing workflows through an API: the systems stay, and the model extracts, classifies, summarises and drafts.

In short: There is no need to replace existing systems: the language model receives tasks and data through a programming interface, and the result goes back to where people work with it: the CRM, the ERP or the mailbox. It pays to start with a single, measurable task, pass on only the data that is needed, and have a person approve the step wherever a mistake costs money.

What does this mean in practice?

A large language model (LLM) interprets and produces text. In business use it is not a separate chat window that staff copy text into and out of, but a service that the company's own software calls through a programming interface, an API (application programming interface). The model receives the data the task needs, does the language work, and the software carries the result on to the right system, checked and logged.

Five language operations come up in almost every integration:

If the system must not only answer but also act on its own, in several steps, it is an AI agent; the article Chatbot or AI agent? covers the difference. If the model must answer from the company's own documents, the method is RAG, which we explain in a separate article.

Three integration patterns

API and webhook

Most business systems, whether CRM, ERP, webshop, invoicing or email, have an API through which another program can read data from them or write data into them. A webhook works the other way round: the system itself notifies a predefined address when something happens, for example when an order or an email arrives. The simplest AI integration consists of these two: an event triggers a service of our own, which calls the language model's API, checks the result and writes it into the target system through its API. In this pattern the model has no direct access to any business system; our code does everything, and that is where it is decided what may reach the model and what may come back.

Function calling (tool use)

Function calling (called tool use at Anthropic) lets the model decide for itself when it needs a piece of data or an operation. The developer describes the available functions to the model, for example “look up the status of an order”, and based on the question the model returns a structured call with the required parameters. According to the documentation of all three major providers, the function is run not by the model but by the application: in the OpenAI documentation the code runs on the application side, according to Anthropic your own tools are executed by your application, and the Google Gemini documentation states that the model does not execute the function itself. This leads to the most important design principle: permission checks live in our code and do not depend on the model's good behaviour. OpenAI and Anthropic also offer a strict mode that ensures the call's parameters follow the given schema exactly; Anthropic's documentation also warns, however, that when information is missing the model sometimes infers a plausible-looking value, so the code must check the parameters too.

Model Context Protocol (MCP)

MCP is an open protocol which, according to its specification, provides a standard way for applications that use language models to connect to external data sources and tools. It has three roles: the host, the application that uses the language model; the client running inside it; and the server, which offers data (resources), message templates (prompts) and callable tools. Messages use the JSON-RPC 2.0 format; the current version of the specification is the one labelled 2026-07-28 (checked on 17 October 2026).

The advantage of MCP is that a server only has to be written once for a system, and several AI applications can then use it. Anthropic's API, OpenAI's API and the Gemini API can all connect to remote MCP servers (checked on 17 October 2026). The protocol does not solve every security question: under the specification's security principles, the host application must obtain the user's explicit consent before invoking any tool, but the protocol itself cannot enforce this, so the implementer has to build it in. OpenAI also warns that a malicious server can exfiltrate sensitive data that enters the model's context. In a business setting, therefore, only your own servers or servers from a trusted provider should be considered.

PatternGood forWhat to watch
API and webhookfixed, predictable processes: every email and every invoice follows the same pathevery step has to be planned in advance, including error handling and retries
Function callingwhen the model needs to fetch data or initiate an operation depending on the questionthe set of functions and their permissions; the model may also supply a wrong parameter
MCPwhen several AI applications need to reach the same systemtrusted servers only; approval before tool calls

What can it be used for? Typical tasks

AreaTaskTypical patternHuman approval
Documentsextracting data from invoices, delivery notes and contracts and matching it against the orderAPI, with output in a fixed schemaon a mismatch or an uncertain extraction
Emailclassifying and forwarding incoming mail, drafting replieswebhook and APIbefore the reply is sent
CRMsummarising customer history, suggesting the next stepfunction calling with read accessnot needed, as it is only a suggestion
ERPasking questions about the data in plain language, compiling a reportfunction calling with read accessif the operation would change data
Webshopproduct descriptions, translations, more accurate searchAPIbefore the text is published
Internal knowledgequestions and answers from policies and manualsRAGnot needed if the answer cites its source

You can read more about our services on the AI integration page, about automated processes that span several systems on the Process automation page, and about AI built into ERP and CRM systems on the Business software page.

Data flow and data protection: what goes where?

AI integration is also data processing. The first design step is therefore a simple data flow diagram: which fields leave the company's systems, which provider they go to, in which region they are processed, how long the provider stores them and what comes back. Providers' terms change often; the following is based on the providers' own documentation (checked on 17 October 2026).

What do the providers say?

The GDPR angle

If personal data reaches the model, the processing falls under the GDPR. The model provider is then typically a processor, so a contract under Article 28(3) of the General Data Protection Regulation is needed with it; Article 5 requires data minimisation, and Article 25 names pseudonymisation as an example among the tools of data protection by design. In practice this means:

We cover transfers outside the EU, transparency and the AI Act in the article AI Act and GDPR for a business chatbot. This is information, not legal advice.

Where is human approval needed?

A language model can be wrong, and according to OpenAI's evaluation guide it does not always produce the same output for the same input. The process should therefore be designed so that a mistake by the model cannot cause damage. We distinguish three levels:

The rule of thumb: wherever a mistake costs money, affects a customer or cannot be undone (a payment, an invoice, a contract, an email to a customer), a person approves the step. The OWASP GenAI Security Project's risk list says the same about Excessive Agency: the model gets only the tools its task needs, with the narrowest possible permissions, a person approves high-impact actions, the action runs with the user's own permissions, and every step is logged.

A separate risk is prompt injection: when the model reads external content, such as an incoming email, an uploaded document or a web page, it may contain text that tries to steer the model as if it were an instruction. Against this, OWASP recommends the least necessary privilege, human approval before privileged operations, and handling external content separately, clearly marked as untrusted.

Testing and monitoring

An AI integration is not good because it is convincing in a demo, but because it measurably works well on the company's real material. According to OpenAI's evaluation guide, test data should include typical, edge and adversarial cases, and the evaluation should be run again on every change; Anthropic recommends specific, measurable success criteria and a test set that mirrors the real tasks. This is how we set it up:

Models do not last forever: both Anthropic and OpenAI regularly retire older models and notify their customers in advance; requests to a retired model fail. That is why we put the model in a separate layer and measure any switch on the same evaluation set before it goes live.

Which model should we choose?

No model is equally good at every task, so the choice is a matter of measurement, not brand loyalty. Our criteria:

It is common for several models to work within one system: a faster, smaller model for classification and a stronger one for complex texts. Because the model sits in a separate layer, the decision can be changed later.

What does the cost depend on?

The cost has two parts. The development fee follows from the functional size, which we measure in COSMIC function points; the Pricing page describes the method. The running cost is usage-based: providers charge by the amount of text processed and generated, that is, by the number of tokens, and according to Anthropic the tool descriptions passed to the model also count as input tokens. The running cost depends on:

We estimate the running cost during design on the company's real samples and weigh it when choosing the model.

Step by step: how to get started

  1. Choosing one task: frequent, language-heavy work with a measurable goal, for example sorting incoming complaints.
  2. Drawing the data flow: where the data comes from, what may go to the model, where the result goes and who approves it.
  3. Samples and an evaluation set: real, anonymised examples with the expected result.
  4. Prototype: comparing the candidate models on the samples, before any live connection.
  5. Connection: API, webhook, function calling or MCP, with permissions, error handling and logging.
  6. Pilot: in a narrow circle, with human approval of every step; we learn from the corrections.
  7. Expansion and operation: where measurement justifies it, the approval circle narrows; monitoring and model switches are ongoing.

Typical mistakes

Frequently asked questions

Which model should we choose?

The one that measurably performs best on the company's own samples for the given task, at an acceptable fee and with suitable data processing terms. We work with models from OpenAI, Anthropic and Google, compare the candidates on the company's examples, and because the model sits in a separate layer, the decision can be changed later.

Is it safe to send company data to an AI service?

With proper design, yes, but not automatically. According to their own documentation, the business APIs of the major providers do not use submitted data for model training by default (checked on 17 October 2026), but how long and where data is stored differs by provider and by setting. It is up to the company to make sure that only the necessary data goes out, personal data is pseudonymised where possible, and there is a processor agreement and a deliberately chosen place of processing. This is information, not legal advice.

Do we have to replace our existing systems?

No. The integration builds on the existing systems' API, webhooks, database or file exports, and the result goes back to where people already work. If an old system has no programming interface, we look at how its data can be accessed safely.

What is MCP?

The Model Context Protocol is an open protocol that connects applications using language models with external data sources and tools in a standard way. It is useful when several AI applications need to reach the same system. In a business setting it should only be used with trusted servers and with approval before tool calls.

What happens if the AI makes a mistake?

We plan for it, so the process is designed in a way that a mistake causes no damage. The code checks the output (the schema and the business rules, for example whether an invoice total matches the sum of its line items), a person approves before a risky step, uncertain cases go to a member of staff, and everything is logged. The mistakes found are added to the evaluation set, so the fix can be measured.

How we can help

We connect everything that exists with artificial intelligence: we connect the language models of OpenAI (ChatGPT), Anthropic (Claude) and Google (Gemini) to companies' existing systems. The first consultation is free of charge; we measure the size of the development in COSMIC function points, and the offer and the schedule are based on it. We sign a non-disclosure agreement (NDA) on request, and after handover we also take care of operation and maintenance, including monitoring how the model performs. The contract governs source code and usage rights.

You can find the details on the AI integration page. If there is a process you would like to connect with artificial intelligence, write to us using the details on the Contact page.

Sources