Skip to content

Guides · AI

How do you integrate artificial intelligence into business software?

by Salvo De Luca, founder and CEO of Dialogicom · published 5 November 2026 · updated 6 November 2026

You start from a specific task, not from the model. The software calls a model through an API, sends it only the data it needs, checks the answer and writes it where it belongs. The rest of the work is measuring cost and quality, and deciding where a person has to step in.

Abstract representation of artificial intelligence: a network of connected glowing nodes on a dark background

Where to start

The task first, then the model.

The most common mistake is to start with the question "which AI should we use?". The useful question is a different one: which repetitive work do we want to remove, or which decision do we want to make faster?

A good first task has three traits. It happens often. Its result is something a person can judge. And a mistake is not serious, or can be fixed before it reaches a customer. Some examples:

  • Answering customers' frequent questions from your own documents.
  • Reading emails and forms and filling in the fields of your management software.
  • Drafting a quote or a report that a person then reviews.
  • Routing incoming requests to the right team.

A task chosen this way can be measured: how many cases, how many errors, how much time, before and after. Without a measure you cannot tell whether AI is helping or just adding a step.

The connection

How a model connects to your software.

The most capable language models, such as those from Anthropic, OpenAI and Google, are used through APIs: your software sends a request with instructions and data, and gets an answer back. You do not need to replace your management software. You need a piece of software in the middle that prepares the request, sends it, checks the answer and writes it in the right place. There are four parts to design.

The instructions

A text that explains the task to the model, the tone, and what it must not do. It is written, tested and corrected like the rest of the code, and kept with its versions.

The data

Only what the task needs: the text of the request, the customer record, the paragraph of the manual. The less you send, the less you spend and the less you expose.

The answer format

When the answer has to go into a management system, you ask the model for a precise format, for example named fields with values. The software checks it before using it.

The fallback plan

A provider can be slow or not answer. The software has to know what to do: retry, switch to another model, or hand the work to a person.

If the answers must come from company documents, you add a search step that finds the relevant passages and gives them to the model together with the question. It is called RAG, and it has a guide of its own.

Costs

What it costs, and how to avoid surprises.

Cloud models are paid per use, based on how much text goes in and comes out. Text is measured in tokens, which are pieces of words. A single request usually costs little, but the cost multiplies with the number of requests and varies a lot from one model to another. Four habits keep it under control:

  • Use the most capable model only where it is needed, and a cheaper one for simple tasks.
  • Send only the text that is needed, not the whole archive with every question.
  • Set a usage cap, per user or per feature, so that a bug or an abuse does not turn into a surprise invoice.
  • Record the usage of every request, so you know what each feature costs.

With a model installed on your own servers you do not pay per use, but you pay for hardware, power and maintenance. How to choose between the two is explained in the guide on local and cloud models.

Quality

How results are checked.

A language model can be confidently wrong: it writes a convincing answer even when it is false. This is called a hallucination, and it cannot be removed entirely. It is managed by design, with checks in the right places.

The source, cited

When the model answers from your documents, the answer says where it comes from, so the reader can check.

Ordinary rules

A tax code, an amount, a date are checked with simple rules before they are saved. The AI proposes, the software verifies.

A person where mistakes are costly

Answers about prices or contracts, or decisions on important cases, go through a person before they leave.

A second check

For some tasks a second model rereads the first model's answer and fixes obvious errors. It reduces errors; it does not eliminate them.

You also need a test you can repeat: a list of real cases with the right answer, run again whenever the instructions or the model change. It is the simplest way to notice when quality gets worse.

Data

Privacy: the technical side.

When software sends text to a cloud model, that text reaches the provider. The technical side decides what gets there and what does not.

  • Send the minimum: no personal data if the task does not need it.
  • Filter: in some features the software can reject a text containing emails, phone numbers, tax codes or IBANs before it leaves.
  • Log with restraint: to track cost and timing, numbers and codes are enough, not the text of the messages.
  • Choose the place: for the most confidential data, a model on your own servers.

These are technical choices. Whether a given use of data is lawful, and on what terms, is set by the law and by your contracts: check it with your adviser. We give them the technical information they need.

Our experience

What we already do.

What we write here comes from software we use every day. Minerva, our study tutor, uses language models for explanations, maps and tests, and searches the materials the student uploads. The AI assistants on our website answer on different topics, each with its own instructions.

For Pavé, a real estate agency, we connected an agent to email, WhatsApp, the property archive and the viewing calendar.

Limits

What to know before you start.

  • A model can be wrong: you need checks and, for some decisions, a person.
  • Providers change models and prices: the software should be designed to switch models without a rewrite.
  • First tests on a few examples always look great: real quality shows on real cases and over time.
  • Not every process needs it: if a simple rule is enough, a rule costs less and is more predictable.

Frequently asked questions

The questions we get on this topic.

Almost never, at the start. Good instructions are usually enough and, if your documents are needed, a search that passes them to the model with each question. Custom training costs more and is only useful in particular cases.

It depends on the task and on the systems to connect. We suggest starting from a single task, measuring it on real cases and then extending: the first result comes early and you can see whether it is worth going on.

Yes, if the software is designed for it. Calls to the model go through one place, and changing model becomes a matter of configuration and new quality tests.

It usually removes the repetitive part. People stay where judgement is needed and check the cases where a mistake is costly.

Do you have a task to start from?

Tell us about the process: we will tell you whether AI can help, where to start and how to measure it. We reply within 24 working hours.