A company can run a large language model on servers it controls and connect it to its support tickets, documents and internal tools, without that data leaving. This article explains, in plain words, which tasks fit, where the model can run, what to decide before hiring anyone, what kinds of cost to expect, why pilots stall before production, and how to check a company that offers to build it.
Yes, a company can use AI on its support tickets, documents and internal tools without that data leaving its own servers. A large language model, or LLM, is the kind of AI behind chat assistants. Some of these models can be downloaded and run on servers the company controls, in its own building or in its own cloud account, and connected to the systems staff already use.
The model is the smaller part of the work. What decides whether the system reaches daily use is the choice of task, a written description of a correct answer, and a named person who checks the answers and runs the system after launch. The last part of this article shows how to check a company that offers to build it.
The short answer: run an open-weight model on servers you control and connect it to one task in one system first, such as sorting support tickets or reading incoming documents. Before hiring anyone, write down which data the model may see, what a correct answer looks like, who checks the answers at first and who runs the system after launch. Then hire a builder who asks about those answers before recommending a model.
Read next
“AI on our own servers” means the model runs on hardware your company controls, and no text is sent to an outside AI company. Your ticket, document or question goes from your system to the model and back, and it never leaves your network or your cloud account.
This is possible because of open-weight models. An open-weight model is one whose developer publishes the model files, so anyone can download them and run the model under its licence. The AI services you use in a browser work differently: your text travels to the provider's servers and is processed there.
Keeping data inside covers more than the model. The system also keeps logs, a search index of your documents, the examples it is tested on and the screens where people check its answers. Each of these holds copies of your data, and each has to stay on your servers too.
An LLM is useful where people today read text and then fill in, sort or write something. Typical tasks inside a company:
Some work is a poor fit for an LLM, and it is better to know this before the project starts:
A simple test for any task: it fits an LLM when a person does it today by reading text, the correct result can be written down, and a wrong result can be caught before it causes harm.
Yes. The choice is where the model runs, and only two of the three common arrangements keep the data on servers you control:
A company can use more than one arrangement. Public documents can go to a provider's service while customer records stay on a model you run. The rule that sends each kind of data to its place then has to be written down and enforced. An earlier article on this blog, on running an LLM in a closed perimeter, compares these options in more detail.
Whether a model you can run yourself is good enough is measured on your own documents and tickets, not taken from a public ranking. Many internal tasks are narrow, such as reading one kind of form or sorting tickets into a known list of teams, and a test on real examples from your work answers the question.
Open-weight models come with different licences, so someone should read the licence of the model you pick. The Qwen3 models Alibaba released in 2025 and OpenAI's gpt-oss models are published under the Apache 2.0 licence, while the largest open model of the later Qwen3.8 release comes with its own Qwen3.8-Max licence. Meta's Llama 3.3 comes with Meta's own community licence, which adds conditions, including following Meta's acceptable use policy.
An LLM does not replace your systems. It sits between them: it reads text from one place and puts a result in another. Adding it to an internal system means answering four plain questions:
Start with one task in one system. At first the model suggests and a person decides. The model is allowed to act on its own only on the parts where it keeps being right on real work, and the manual way stays as the fallback.
The people who do the work today should shape the system. They know which documents are hard, which answers are wrong and where a mistake costs money. They are also the people who will check the answers in the first months, so their time belongs in the plan.
Before anyone builds an AI system for you, answer seven questions in writing. None of them needs an engineering background, and each answer changes what has to be built:
Written answers to these seven questions are your brief. Given to three builders, they produce three proposals you can compare. Without them, you receive three demonstrations of a chat window.
A demo answers one question: can the model do the task on good examples? Daily use adds four more, and a pilot that stalls has usually skipped them:
Finishing a stalled pilot usually means building these four things around the model, not buying a better model. An earlier article on this blog, on the AI pilot that never reached production, explains each of them in more depth.
Any builder who takes over a stalled pilot needs three things from you: the pilot's examples, the documents it failed on, and the name of the person who will own the system. A builder who asks for none of them is planning a new demo.
This article gives no prices. “An AI system on our own servers” covers projects that differ many times over in size, and a number quoted before anyone has heard your answers to the seven questions above is a sales number, not an estimate.
What is useful is knowing the kinds of cost, because most of them depend on decisions you control:
The cost follows a different pattern from a provider's service. A provider charges for the amount of text the model reads and writes. Servers you own, or rent by the month, cost about the same whether they are busy or idle, so the volume of work decides which arrangement costs less for you.
Scope is the part of the cost you control most directly. One task, in one system, for one team is the smallest first version that still shows whether the system is worth extending.
Four kinds of supplier answer when a company says “we want AI on our own servers”:
Before anything else, ask any supplier for these proofs:
Then listen to what the supplier asks you. A company that has built this asks before it quotes:
A quick test for any AI supplier: ask what happens to a document or ticket the model gets wrong. A supplier who has built this answers with where the wrong answer goes and who fixes it. A supplier who has not answers with the name of a model.
Of the kinds of supplier described above, amBrain is an engineering company.
What amBrain can say publicly about its own work with language models, in full: We have taken an LLM integration to production inside a client's FinTech perimeter: extracting and normalising unstructured broker and venue notices — corporate actions, instrument and margin changes — into structured records the trading system consumes.
The client is not named, where the model ran in that project is not disclosed, and no numbers about that project are given. This article is not a case study of it. It explains how to plan and choose, and it does not claim that amBrain has built a support-ticket system, a staff assistant or any internal AI system other than the notice extraction named above.
Beyond that integration: amBrain has been building software since 2019. We work in three formats: full delivery, a dedicated team, or engineers embedded in your team. The client keeps full ownership of the product and the code, except our reusable components.
If you are at the beginning, the useful next step is not a vendor search. It is one page with written answers to the seven questions in this article. Give the same page to every builder you talk to, us or anyone else, and their proposals can be compared line by line.
Bring your current architecture and the failure mode that worries you, and we will go through it together in half an hour.