Open and closed AI models: what the difference means for a hotel

An open-weight AI model publishes its trained parameters, so anyone can download and run it. A closed model is reached only through its owner's service. For a hotel, the closed vs open source AI models question changes where the model runs, who decides when it changes and how you pay, not whether its answers are right for your own questions.

Two vendors pitch an AI assistant for your front desk. One says it runs on open models, the other on a proprietary model. Both sentences sound reassuring, and neither tells you whether the assistant will answer your team's questions correctly. After reading this you will know what the labels actually mean, what changes for your hotel in practice, and which questions to put to every candidate vendor.

What is an AI model, in plain words?#

A model is a very large set of numbers that turns an input, such as a question, into a likely output, such as an answer. Those numbers are produced by training on text, and they are the part that is either published or kept private.

Training is the expensive step: text is passed through the model many times and the numbers are adjusted until the outputs look useful. The result is called the weights, or parameters. Using a trained model is called inference, and inference is cheap compared with training. That is why a model can be copied and run by someone who did not build it.

The model is only one part of a hotel product. The rest is retrieval of the hotel's own data, business rules, permissions, logging and the screens staff use. A model that writes fluent sentences is not automatically right; fluency and correctness are separate properties, and the difference matters most in numbers, dates and names. This is why a product description that stops at the model tells you very little about what the assistant will do at 23:00 on a sold-out night. If you want the background, read why fluent is not the same as right.

What does open-weight mean, and what is actually shared?#

Open-weight means the trained parameters are published for others to download and run. It does not mean the training data, the training code or the recipe behind them is published, which is why open-weight is the more accurate word than open source.

In the strict sense, open source would include the data and the code needed to rebuild the model. Most published models share only the finished parameters. Licences differ: some carry conditions on commercial use, attribution or naming, and a hotel buying a product rarely sees which licence applies. Ask.

A closed model is reached through its owner's service. You send text, you get an answer, and the parameters stay on the owner's side. Open weights make a model portable: the same parameters can run on a cloud service, on a software vendor's servers or on hardware you control. Closed does not mean secretive about quality, and open does not mean audited. Neither label says anything about how the model was tested.

Where can the model run, and what changes for the hotel?#

There are three placements: the model owner's service, the software vendor's servers, or hardware you control. The placement decides which company processes the text you send, and that is the part a hotel should care about.

Through the model owner's service, you start fast with no hardware, but the text you send leaves your building and reaches a third party. On the vendor's servers, the vendor holds both the model and the data flow, so the vendor's contract and security practice carry the weight. On your own hardware, the text stays on machines you control, but you need a suitable machine, someone to keep it running and a plan for updates.

Running a model locally is a technical arrangement, not a legal status. It changes who holds the data; it does not by itself settle your obligations as a data controller. Phrases such as "the data never leaves" are marketing sentences. Ask instead for the specific flow: what text is sent, to whom, for how long it is kept and how it is deleted.

Latency and connectivity also differ. A local model keeps working when the internet link drops; a hosted model does not.

Who decides when the model changes?#

With a closed model, the owner decides, and your product can behave differently next month without anyone at the hotel touching a setting. With an open-weight model you host, you decide, and you also carry the work.

Closed services update models, retire old versions and change defaults. A vendor can usually pin a version for a while, but not forever. Ask how much notice you get before a change, whether old versions stay available, and whether the vendor re-runs its own tests after every model change.

An open-weight model you host is frozen until you update it. That stability is real, and so is the risk of running a version nobody patches. Either way, an answer that was correct last quarter can become wrong after an update. A fixed set of test questions, re-run after each change, is a reliable check, and it works best alongside monitoring and a person reading the answers.

Write the answer into the contract: who may change the model, how you are told, and what happens if the new version fails your test set.

How is the cost structured, in plain words?#

Closed models are usually billed by use, so the bill grows with every question asked. Open-weight models shift cost to hardware and people, so the bill is flatter but has a floor.

Usage is counted in tokens, roughly pieces of words. A long guest message, a long document or a long conversation all cost more than a short question. A closed model has almost no fixed cost and a bill that follows adoption: if staff start using the assistant heavily, the bill moves.

An open-weight model you host needs a machine, electricity, someone to install and update it, and someone to notice when it stops answering. Both paths carry the same hidden cost: building a test set, running it, and monitoring answers after go-live. That work does not disappear because a model is free to download.

Compare total cost at your expected volume, not price per unit. A cheap unit price at high volume can cost more than a fixed machine and a part-time engineer. For the wider picture of AI pricing, see how AI tools are priced: seats, usage and what drives the bill.

Does the label tell you whether the answers are right?#

No. Open or closed says nothing about accuracy on a hotel's own questions, because accuracy depends on the task, the data the assistant is given and the limits placed on it.

A small model restricted to a narrow job, such as answering questions about tonight's housekeeping list, can beat a large general model that was never given that list. Quality is measured, not declared. Build a set of real questions from your own operation, including the awkward ones, and record what a correct answer looks like.

Include traps: a question about a rate that does not exist, a request to change a booking without authorization, a guest name that appears twice. Test what the assistant may do, not only what it says: which actions run directly, which wait for a person, and which need two confirmations. Re-run the same set after every model change, and keep the results so a later comparison means something. The method is described in how to test a hotel AI assistant before staff or guests use it.

What should you ask a vendor about open and closed models?#

Ask for the placement, the change policy and the evidence, in that order. A vendor who can answer all three has thought about the problem; one who answers only with the word open has not.

The answers should be specific enough to write into a contract or an annex, not reassuring adjectives. If a vendor cannot show measured results on cases like yours, treat the model label as decoration. Ask the same questions of every candidate, so the answers can be compared side by side.

What to do next#

The label is the start of the conversation, not the end of it: placement, change policy and evidence are what a hotel can actually hold a vendor to. Write five questions from your own operation, ask every candidate vendor to answer them with the same assistant, and compare the answers side by side.

This is how we approach the question ourselves. Our architecture is model-agnostic and built: we choose models per deployment by measured evaluation, and the benchmark that decides it, 30 cases with 5 traps, is built and not yet run. We have no trained model yet. If you want to see how that works in practice, talk to OtelCiro or request a briefing.