Running AI on the site's own machine.

Your audio goes to their servers, your files are indexed on the other side of the world. AI can run on the machine at the site. Here is why, and how to start.

French construction has built up a dependency debt. Otter for the meeting minutes. Notion for the documentation. Salesforce for the pipeline. And now AI copilots, billed per seat, per model, per token.

Each tool on its own solves a real problem. Taken together, they move your data, your governance and your margin to the other side of the world.

Three observations that ought to bother you

One. The minutes of a coordination meeting where a claim is discussed end up in a foreign cloud. The data protection clause is satisfied in the letter, not in the spirit.

Two. The general-purpose AI models (GPT, Claude) have seen our drawings, our site instructions, our joint inspection records. We know that. What we do not know is how long they keep them, what they serve, and to whom they can be shown again.

Three. The SaaS vendors that host your data can change their prices, their terms, their exit policy. You discover the dependency the day the bill doubles, or the day your competitor buys your supplier.

On site there is no second chance. The tool has to hold, and when it holds badly you need to be able to repair it yourself.

The alternative exists, and it holds

In 2023, running a large language model on a desktop computer belonged to science fiction. By 2025 it had become a Sunday afternoon of configuration. llama.cpp, Ollama and vLLM now run the open-weights models (Llama, Mistral, Qwen, Gemma) locally, at a quality close to what the cloud APIs offer.

On the RAG side (augmented search: giving the AI access to your files), projects such as Verba and Quivr can be deployed on a server of your own. Your documents are indexed on your premises. The searches do not leave.

For meetings, Meetily transcribes and summarises locally, without a single audio file leaving the machine. The exact opposite of Otter.

Why construction in particular

Construction brings together three characteristics that make local AI almost self-evident:

  • High contractual confidentiality. Contracts, overruns, claims, technical submissions: sensitive material that has no business passing through a third-party cloud.
  • Patchy connectivity. The machine on a site with no network still has to work. An AI that depends on a cloud API does not keep that promise.
  • Long cycles. A construction project runs 18, 36, 60 months. Over that span, the risk that a SaaS vendor changes course is enormous.

How to start (without redoing everything)

Three reasonable ways in, in increasing order of impact:

  1. Local transcription. Replace Otter or Fireflies with Meetily, or with a local Whisper. Immediate benefit, little friction.
  2. Local augmented search. Index your files and your correspondence in a search engine hosted on your own infrastructure.
  3. A dedicated working agent. Build an agent that watches the project flows continuously (emails, schedules, site instructions) and raises the alert. That is what we deploy with Cabestian OS.

The Cabestian bet

Our conviction is simple: AI in construction will be local, or it will not be credible. US vendors may have the best models today, but they will not keep the sovereignty promise that sensitive projects need. The open source tools have closed most of the gap, and it narrows with every release.

Cabestian helps put that transition together. Not with a single product imposed on you, but with a toolbox chosen for your context. With one non-negotiable principle: you remain the owner of your data, of your code, and of your exit strategy.

If those three words (owned, readable, self-hostable) ring true in your requirements, we can talk.