How to integrate ChatGPT into your software or website
"We want to bring ChatGPT into the business" is one of the requests we hear most this year, and it almost never means the same thing. For some it's a chat on the website that answers customers; for others, it's the management system drafting replies or reading invoices. This article explains, without jargon, what it takes to integrate ChatGPT into your software or your website, what it can really do, how to do it safely and where to start without wasting money.
First things first: ChatGPT knows nothing about your company
This is the idea that clears up most misunderstandings. The model behind ChatGPT can write, summarize and reason about text, but it doesn't know your products, your customers or your procedures. Ask it about the status of an order and it will make something up, with great confidence.
What makes an integration useful is that, on every question, your own system looks up the information it needs (the customer record, the relevant section of the manual, the order) and hands it to the model along with the question. The model doesn't learn or keep anything about your business: it reads what you give it at that moment and answers from there. That's why the quality of the answer depends far more on how well organized your data is than on which model you pick.
Three levels of AI in your software
A chat on your website. It's the most visible option and the quickest to set up: a window that answers frequent questions. It works well when the answers come from public, stable information (hours, terms, services). It falls short as soon as a customer asks something that depends on their own data.
An assistant that knows your documentation or your data. This is where the value goes up: an assistant that answers your team about your procedures, your contracts or your own system, citing where each answer comes from. It's what we deliver with every project, so that knowledge of the product doesn't depend on us.
Automating one specific task. This is usually where the real savings are: sorting incoming emails and leaving a draft reply ready, pulling the data from an invoice or a delivery note into your system, or summarizing a call and logging it on the customer record. One example is the assistant that answers and screens calls, which we describe in custom software development. In every one of these cases, a person reviews before anything goes out the door.
How to integrate ChatGPT safely
The most dangerous mistake is giving the model direct access to the database "so it can find everything". The right approach is the opposite: the model only talks to your system through a controlled door, with narrow permissions, and never sees more than it needs for each task.
In practice that means four things. Each use gets its own permissions: the customer service assistant doesn't see the accounting. Reading and acting are kept apart: looking up an order is one thing and changing it is another, which is best left to a person. There are usage limits, so a mistake or an abuse doesn't blow up the bill. And every call is logged: who asked what, which data was used and what was answered. If something goes wrong, that log is how you find out why.
What about my data?
It's the question that holds most people back, and it has a good answer. When the integration is built on the OpenAI API or on Azure OpenAI, rather than the consumer version of ChatGPT, the data you send isn't used to train the models by default. Azure OpenAI also lets the service run inside your own subscription and in the region you choose, with the same guarantees as the rest of your infrastructure.
If you handle personal data about customers or employees, privacy law still applies: you need to know which data goes to the model, for what purpose and under which contract. The sensible approach is to send only what's essential and to keep everything, the code and the services, in your name. We explain why in who owns the code of your software, and it applies just as much to an AI integration.
What it costs to run
The running cost isn't a flat fee: you pay for what gets processed, so it grows with volume. A task used ten times a day costs little; the same task run on every email the company receives costs a lot more. That's why it pays to estimate the volume before you start, set limits from day one and choose the model according to the task: not everything needs the most powerful one.
On top of that comes building the integration itself, which is what really makes the difference: preparing the data, building the controlled door and designing what happens when the model gets it wrong.
The risks, stated plainly
It gets things wrong. Confidently, too. The answer is to design for the error: the assistant cites the source of each answer, says "I don't know" when it can't find one, and a person reviews anything with consequences. It's the same as with the rest of your software: what sets a good system apart is how it handles failures, as we explain in how you handle failures is the difference.
Depending on a single provider. Models change every few months, and today's best one won't necessarily be the best a year from now. The integration should let you switch models without rebuilding the system. It's the same logic we apply in custom vs off-the-shelf software: what's yours should keep working even if whoever serves you changes.
Where to start
Not with a big AI project, but with one repetitive, specific task: the one someone does by hand twenty times a day and everyone can describe. Measure how long it takes today, build the integration for that task and measure again. If it works, you have the proof for the next one; if it doesn't, you've learned cheaply.
That's how we work, with deliveries every two weeks: in the first one you already see something working with your real data, not a demo with made-up examples. How we approach AI for your business is on its page, and if you have a task in mind that you'd like to automate, tell us about it and we'll tell you honestly whether AI is the right tool or whether something simpler will do.