// Pillar · 9 min read
WHAT "OWNING THE MODEL" ACTUALLY MEANS.
Every AI vendor's marketing page now says some version of "you own your AI." It usually doesn't survive five minutes of scrutiny. Here's the unsentimental version: what actually transfers in a real handover, what stays with the vendor, and what to ask before signing anything.
By the Marapone team · Updated 2026
The five layers of "the model"
"The model" is shorthand for at least five distinct artifacts. Ownership claims have to be precise about which layer they cover.
- Base model weights — the open-weight Llama or Qwen file.
- Fine-tune deltas — the LoRA or full fine-tune trained on your data.
- Vector store — the embedded representation of your documents.
- Application code — the API services, ingest pipelines, UI.
- Runbooks — the operational documentation.
"You own your AI" usually means item 3 or 4 only. A real handover covers all five.
Layer 1: Base model weights
If the system uses an open-weight model (Llama 3.1, Qwen 2.5, Mistral), the weights are already free under their respective licences. "Owning" them means they're on disk in your environment, not pulled from someone else's API at inference time. That's a meaningful distinction — air-gap support depends on it.
If the system uses a closed-weight API (GPT-4, Claude, Gemini), no vendor can transfer the weights to you. They're not theirs to transfer. Any claim of "you own the model" in that context is shorthand for "you own your account."
Layer 2: Fine-tune deltas
If the system was customized by training a LoRA adapter or doing a full fine-tune on your data, that artifact is the most operationally valuable thing in the build. It encodes everything specific to your business.
Ownership of the fine-tune means three things, all of which should be in writing:
- The weights themselves are on your disk in a portable format (not stuck in a vendor tenant).
- The training script and dataset are yours, so you can retrain when needed.
- The vendor cannot deploy your fine-tune for any other client.
A surprising omission:
Some vendors hand over the fine-tuned weights but not the training script. Without the script, you can't retrain when carrier formats or shipper contracts change. Ask for both.
Layer 3: Vector store
The vector store contains numerical representations of your documents — invoices, contracts, BOLs, customs declarations. From an ownership perspective, the question is whether you can export the embeddings and the index in a portable format.
If the vector store is ChromaDB, Qdrant, Weaviate, or any standard open-source option, the answer is yes — the data files on disk are portable. If it's a vendor-proprietary store, the answer is "we'll see."
Layer 4: Application code
This is the API layer, the ingest pipelines, the UI. Ownership means you have the source code in a Git repository in your account, under a licence that lets you modify and redistribute.
Three honest tiers:
A: Full source under a permissive licence (MIT, Apache 2.0). You can fork, modify, host elsewhere. This is what we ship.
B: Source available, internal use only. You can read it, modify it for your own use, but not redistribute. Common in enterprise contracts.
C: No source, hosted only. You have an account on a vendor platform. "Ownership" is a marketing word.
Ask which tier you're getting before believing the ownership claim.
Layer 5: Runbooks
If the application code arrives but no one knows how to install, back up, or extend it, it's a brick. Real handovers include operational documentation:
- Install runbook (fresh-system to running).
- Ingest runbook (add a new shipper or carrier).
- Retraining runbook (improve the model on new examples).
- Backup & restore runbook.
- Incident playbook.
Without runbooks, the source code is theoretical ownership. With them, it's practical.
What stays with the vendor (honestly)
Even in a real handover, two things stay with the vendor:
Trade-craft. The vendor's experience of how to ingest from MercuryGate vs SAP TM, how to tune embeddings for invoice OCR, the dozen heuristics they apply by default. You get the resulting system but not the training that produced the choices.
Future model upgrades. If a better open-weight model ships next year, you can swap it yourself with the runbooks, but if you'd rather have help, the vendor is still the natural party to call. That's why a retainer exists — it's not lock-in, it's optional access.
The seven questions to ask before signing
- Are you using open-weight or closed-weight models for inference?
- Do I receive the fine-tune weights and the training script?
- Is the vector store portable (ChromaDB, Qdrant, etc.) or proprietary?
- Do I get full source code in my Git account under a permissive licence?
- Do I get install, ingest, retraining, backup, and incident runbooks?
- If I cancel any retainer, does the system continue to run?
- Can I redeploy the system to a different cloud or on-prem location without your involvement?
If any answer is no or "let me check with our legal team," the ownership claim is partial.
WANT TO SEE A REAL HANDOVER?
WE'LL SCREEN-SHARE THE REPO.
Anonymized walkthrough of an actual client codebase, runbooks, and configs. No NDA needed for the walkthrough.
Request the Walkthrough →