# 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:

- **Extraction:** an invoice, a delivery note or an incoming email becomes structured data (customer, line items, deadline).
- **Classification:** the system decides whether an email is a complaint, a request for a quote or a billing question, and puts it in the right queue.
- **Summarising:** a long email history with a customer becomes a background note of a few sentences in the CRM.
- **Drafting:** a draft reply, a quote text or a product description that a member of staff reviews.
- **Answering:** staff ask questions of the company's documents or data in plain language.

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?](https://www.mestersegesintelligenciakozpont.hu/en/knowledge-base/chatbot-vs-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](https://www.mestersegesintelligenciakozpont.hu/en/knowledge-base/ai-on-company-documents-rag).

## 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](https://developers.openai.com/api/docs/guides/function-calling) documentation the code runs on the application side, according to [Anthropic](https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview) your own tools are executed by your application, and the [Google Gemini](https://ai.google.dev/gemini-api/docs/function-calling) 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](https://modelcontextprotocol.io/specification/2026-07-28), 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](https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview), [OpenAI's API](https://developers.openai.com/api/docs/guides/tools-connectors-mcp) 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.

| Pattern | Good for | What to watch |
|---|---|---|
| API and webhook | fixed, predictable processes: every email and every invoice follows the same path | every step has to be planned in advance, including error handling and retries |
| Function calling | when the model needs to fetch data or initiate an operation depending on the question | the set of functions and their permissions; the model may also supply a wrong parameter |
| MCP | when several AI applications need to reach the same system | trusted servers only; approval before tool calls |

## What can it be used for? Typical tasks

| Area | Task | Typical pattern | Human approval |
|---|---|---|---|
| Documents | extracting data from invoices, delivery notes and contracts and matching it against the order | API, with output in a fixed schema | on a mismatch or an uncertain extraction |
| Email | classifying and forwarding incoming mail, drafting replies | webhook and API | before the reply is sent |
| CRM | summarising customer history, suggesting the next step | function calling with read access | not needed, as it is only a suggestion |
| ERP | asking questions about the data in plain language, compiling a report | function calling with read access | if the operation would change data |
| Webshop | product descriptions, translations, more accurate search | API | before the text is published |
| Internal knowledge | questions and answers from policies and manuals | RAG | not needed if the answer cites its source |

You can read more about our services on the [AI integration](https://www.mestersegesintelligenciakozpont.hu/en/services/ai-integration) page, about automated processes that span several systems on the [Process automation](https://www.mestersegesintelligenciakozpont.hu/en/services/process-automation) page, and about AI built into ERP and CRM systems on the [Business software](https://www.mestersegesintelligenciakozpont.hu/en/services/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?

- **OpenAI:** according to its [data controls documentation](https://developers.openai.com/api/docs/guides/your-data), data sent to the API is not used to train models unless the customer explicitly opts in. Abuse monitoring logs are retained for up to 30 days by default. Data storage and processing in Europe (the EEA and Switzerland) is available with separate approval and specific retention settings.
- **Anthropic:** according to its privacy centre, inputs and outputs of its commercial products, including the API, are by default [not used for model training](https://privacy.claude.com/en/articles/7996868-is-my-data-used-for-model-training), and for the API they are [as a rule deleted within 30 days](https://privacy.claude.com/en/articles/7996866-how-long-do-you-store-my-organization-s-data), with the listed exceptions. On Anthropic's own API, the place of processing can be “us” or “global” according to the [documentation](https://platform.claude.com/docs/en/manage-claude/data-residency); on Amazon Bedrock and Google Cloud the region is determined by the chosen endpoint.
- **Google:** under the [Gemini API terms](https://ai.google.dev/gemini-api/terms), in the paid services Google does not use prompts and responses to improve its products and logs them only for a limited period to detect abuse; applications offered to users in the EEA, Switzerland and the UK may only be built on the paid services. According to Google Cloud's [Vertex AI data residency page](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/learn/data-residency), processing on the EU multi-region endpoint stays within the EU, while the global endpoint carries no such guarantee; which model is available in which region differs from model to model.

### 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](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679) 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:

- only the fields the task needs reach the model;
- names and identifiers are masked or pseudonymised wherever possible, and the answer is matched back inside our own system;
- the model can only see what the user asking the question is allowed to see;
- we log who called the model, when and with which data.

We cover transfers outside the EU, transparency and the AI Act in the article [AI Act and GDPR for a business chatbot](https://www.mestersegesintelligenciakozpont.hu/en/knowledge-base/ai-act-and-gdpr-for-business-chatbots). This is information, not legal advice.

## Where is human approval needed?

A language model can be wrong, and according to [OpenAI's evaluation guide](https://developers.openai.com/api/docs/guides/evaluation-best-practices) 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:

- **Suggestion:** the model only suggests (it summarises, drafts or proposes a category), and a person makes the decision and carries out the operation. Here the cost of a mistake is low.
- **Prepared operation:** the model prepares the step, such as filling in the complaint or writing the reply, and a member of staff approves or corrects it with one click.
- **Automatic operation:** the step runs without approval, but only with narrow permissions, volume limits, logging and spot checks.

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](https://genai.owasp.org/llmrisk/llm062025-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](https://genai.owasp.org/llmrisk/llm01-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](https://platform.claude.com/docs/en/test-and-evaluate/develop-tests) and a test set that mirrors the real tasks. This is how we set it up:

- **Evaluation set:** real samples, anonymised where needed, with the expected result, for example the fields to extract or the correct category.
- **Measurement before go-live:** we compare the candidate models and prompts on this set.
- **Re-measurement on every change:** for a new prompt, a new model version or a new document type.
- **Logging:** the input, the output, the model and the prompt version, and any human correction. The log is also the source of the next evaluation cases.
- **Monitoring:** error rate, share of human corrections, response time and token usage, with alerts.

Models do not last forever: both [Anthropic](https://platform.claude.com/docs/en/about-claude/model-deprecations) and [OpenAI](https://developers.openai.com/api/docs/deprecations) 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:

- the quality of Hungarian text on the company's own samples;
- the nature of the task: text, scanned documents, images or tables;
- the reliability of function calling and structured output;
- speed and usage fees at the expected volume;
- the data processing terms and the place of processing;
- availability and the model's life cycle.

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](https://www.mestersegesintelligenciakozpont.hu/en/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](https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview) the tool descriptions passed to the model also count as input tokens. The running cost depends on:

- the number and length of the documents and emails processed;
- how many model calls one process needs (an agent working in several steps means several calls);
- the chosen model;
- the size of the context and tool descriptions passed to the model;
- special settings, such as geographically restricted processing, which providers may charge at a higher rate.

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

- **A chat window instead of an integration:** staff copy data by hand into a general AI interface, so the data leaves the company unchecked and nothing can be measured.
- **Too many permissions:** the model can reach everything the integration account can reach.
- **No evaluation set:** quality is judged by impression and model switches by guesswork.
- **A model hard-wired into the code:** when the model is retired, the whole integration has to be rewritten.
- **Data protection at the end:** the data flow diagram and the processor agreement are much harder after the fact.
- **Everything at once:** five processes in one project, without measurement, and none of them is ever really finished.

## 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](https://www.mestersegesintelligenciakozpont.hu/en/services/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](https://www.mestersegesintelligenciakozpont.hu/en/contact) page.

## Sources

- [OpenAI: Function calling](https://developers.openai.com/api/docs/guides/function-calling)
- [OpenAI: Data controls in the OpenAI platform](https://developers.openai.com/api/docs/guides/your-data)
- [OpenAI: MCP servers](https://developers.openai.com/api/docs/guides/tools-connectors-mcp)
- [OpenAI: Evaluation best practices](https://developers.openai.com/api/docs/guides/evaluation-best-practices)
- [OpenAI: Deprecations](https://developers.openai.com/api/docs/deprecations)
- [Anthropic: Tool use with Claude](https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview)
- [Anthropic: Data residency](https://platform.claude.com/docs/en/manage-claude/data-residency)
- [Anthropic: Define success criteria and build evaluations](https://platform.claude.com/docs/en/test-and-evaluate/develop-tests)
- [Anthropic: Model deprecations](https://platform.claude.com/docs/en/about-claude/model-deprecations)
- [Anthropic Privacy Center: Is my data used for model training?](https://privacy.claude.com/en/articles/7996868-is-my-data-used-for-model-training)
- [Anthropic Privacy Center: How long do you store my organization's data?](https://privacy.claude.com/en/articles/7996866-how-long-do-you-store-my-organization-s-data)
- [Google Gemini API: Function calling](https://ai.google.dev/gemini-api/docs/function-calling)
- [Google: Gemini API Additional Terms of Service](https://ai.google.dev/gemini-api/terms)
- [Google Cloud Vertex AI: Data residency](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/learn/data-residency)
- [Model Context Protocol: Specification, 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28)
- [OWASP GenAI Security Project: LLM06:2025 Excessive Agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/)
- [OWASP GenAI Security Project: LLM01:2025 Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/)
- [EUR-Lex: General Data Protection Regulation, Regulation (EU) 2016/679](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679)