“I Built My Own”: What a Proprietary LLM Actually Is, and Why Lawyers Should Care About the Answer

This week I watched a vendor announce, on LinkedIn, that their product runs on a proprietary LLM. Not GPT-4. Not Claude. Their own model, fine-tuned on millions of domain documents, trained on infrastructure they control. The pitch was aimed at professionals who carry real fiduciary weight for their clients: your sensitive documents never touch a third-party model, because I built mine from the ground up.

One detail gave the game away. The model was named with an :latest tag.

If you have ever used Ollama, the open-source tool for running downloaded models locally, you will recognise that tag instantly. It is not something you would ever invent for a model you trained. It is the default versioning suffix Ollama appends when you pull someone else’s open-weight model onto your machine. The “proprietary LLM” was, in all likelihood, Llama or Mistral with a fine-tune on top. Possibly just a system prompt.

I asked the obvious question in the comments: fine-tuned using which foundation model?

Then, I realised that this is actually not an obvious question: otherwise, more people would ask it.

And I want to be clear that this is not about one founder or one product. I have now seen the same pattern in marketing content tools, translation engines, contract review platforms, and half the things currently sold as “AI agents”. The vocabulary varies (proprietary model, private LLM, our own AI, purpose-built engine) but the pattern is always this:

An open-weight base model, downloaded for free, dressed up as an in-house artefact and sold as one.

The individual vendors are doing what the market currently rewards, and the market rewards it because almost nobody in the buying audience can read a model tag.

What interests me is the definitional vacuum they all walk through. Because here is the uncomfortable part:

“Proprietary LLM” has no formal definition anywhere. Not in the EU AI Act, not in any standard, not in any licence. It is a marketing term wearing a technical costume, and lawyers are buying confidentiality promises based on it.

So let’s do what lawyers do when a term is doing load-bearing work without a definition. Let’s try to construct one. And along the way, I want to make a broader argument: the reason this matters is not just IP hygiene. It is safety.

Before you buy the house, you establish who owned it, what encumbrances travel with it, and whether the seller actually holds what they claim to sell.

A “proprietary LLM” claim is a chain of title assertion about a model. And right now, vendors are selling houses without deeds. There are three places we could anchor a real definition: the licence, the regulation, and the disclosure norms.

Each gets us part of the way. None of them, alone, closes the gap.

The closest thing we have to settled taxonomy is the three-way split between proprietary, open-weight, and open-source models.

In industry usage, a proprietary model is one whose weights are closed: you access it through an API, under the developer’s terms, and you never hold the artefact itself (the GPTs Opus, Sonet or Gemini models).

An open-weight model is one whose weights you can download and run, but under a licence that restricts what you may do; Meta’s Llama family is the canonical example.

Open source, properly so called, is stricter still: the Open Source Initiative’s Open Source AI Definition (version 1.0, October 2024) requires that a model be usable, studiable, modifiable, and shareable, including sufficient information about the training data. Llama fails that test. So do most models marketed as “open”[^1].

Under this axis, the vendor’s claim inverts. A model whose weights you pulled from a public registry is definitionally someone else’s open-weight model.

What you own, at most, is the delta: your LoRA adapter weights, your deployment stack, your licence to the composite work[^2].

Calling the result “my proprietary LLM” is like buying a flat off-plan, repainting the kitchen, and describing yourself as the property developer.

And the licence axis has teeth the market ignores.

The Llama 3 Community Licence requires derivative works to display “Built with Llama” and to include the licence in redistributions. If your marketing says “I built my own” and your base model says “Built with Llama”, one of those statements is enforceable and the other is… a sales pitch.

But licensing alone cannot carry the definition, because a licence tells you what you may do with weights, not what you did to them.

For that, we need the second axis.

The EU AI Act deliberately avoids the proprietary/open vocabulary. It defines a general-purpose AI model at Article 3(63) and carves out open-source exemptions at Articles 2(12) and 53(2), which turn on licence terms and the public availability of weights, architecture, and usage information. Nowhere does it tell you when a modified model becomes a new one.

The Commission’s Guidelines on the scope of obligations for GPAI models, published on 18 July 2025, finally gesture at an answer.

A downstream actor who modifies a model becomes the provider of a new model, with the provider obligations that follow, only where the modification leads to a significant change in the model’s generality, capabilities, or systemic risk (paragraph 62). The indicative criterion, at paragraph 63: training compute for the modification exceeding one third of the compute used to train the original model.[^3]

Sit with that number. A LoRA fine-tune of (for example…) a 7-billion-parameter model uses a vanishingly small fraction of the base model’s training compute. Orders of magnitude below one third.

Under the closest thing European law has to a state-of-the-art test, such vendor has not created a model at all. They have modified one, and the provider obligations, alongside the meaningful control, stay upstream with (for example…) Meta or Mistral.

The regulatory axis gives us something the licensing axis cannot: a quantitative boundary between derivative and original. It is crude, compute is an imperfect proxy for transformation, but it is a line drawn by a regulator rather than a marketing department. Any serious definition of “proprietary LLM” should borrow it: if you would not qualify as the provider of a new model under the Commission’s own threshold, you do not get to call the model proprietary.

The third axis is softer but arguably the most developed: the provenance norms embedded in model documentation.

Model cards, proposed by Mitchell et al. in 2019, established the expectation that a model ships with structured documentation of what it is and how it was made.

Hugging Face then built lineage directly into the infrastructure: the Hub’s model card spec includes a base_model metadata field for fine-tunes, adapters, quantisations and merges, which powers the model tree display and lets anyone filter for every derivative of a given foundation model.

The Llama licence’s attribution requirement pushes in the same direction from the licensing side, and the AI Act’s Annex XII documentation requirements for GPAI providers cover design specifications and training process.

But here’s the massive catch: the base_model field is optional.

The entire disclosure infrastructure exists, the lineage graph, the relationship inference, the filtering… and none of it is enforced.

Hugging Face has literally run bots submitting pull requests to add the field where model authors left it out.

The documentation ecosystem already treats “which foundation model” as a question every model should answer. It just does not force anyone to answer it.

So, the marketing term “proprietary LLM” survives in precisely that enforcement gap.

A workable definition might sit at the intersection of the three axes: a proprietary LLM is one you trained from scratch, or one you modified past the regulatory threshold of new-provider status, and whose provenance you disclose in full either way.

Everything else is a fine-tune of someone else’s model, and should be sold as one.

Here is where I want to push past the IP framing, because the IP framing undersells the problem.

A lawyer who is AI literate knows what an LLM is and roughly what fine-tuning means. A lawyer who is AI safety literate knows something more specific: safety properties are trained into the foundation model, and everything downstream inherits them. Or degrades them.

To put that in terms anyone can understand: the base model’s alignment training, the RLHF or Constitutional AI or DPO process that taught it to refuse harmful requests and behave within bounds, is not a wrapper you keep when you modify the model[^4].

It is a set of learned behaviours encoded in the weights, and fine-tuning updates the weights.

Qi et al. showed in 2023 that fine-tuning an aligned model on as few as ten adversarial examples can strip its safety behaviour, and, more alarmingly, that fine-tuning on entirely benign data degrades safety guardrails as a side effect[^5].

Now apply that to our dear “I built my own” vendors.

Their model’s safety behaviour, whatever remains of it, was built by [Meta’s / Mistral’s / Open-weights model provider’s] alignment teams.

Their fine-tune on millions of domain documents either preserved that work, degraded it, or altered it in ways that are difficult to pinpoint.

And without knowing the base model, the fine-tuning method, and the evaluation they ran afterwards, neither they nor their clients can say which.

When a vendor declines to name the foundation model, they are not protecting a trade secret. They are concealing the identity of the party whose safety training their product depends on, and obscuring whether that training survived their modifications.

This is why alignment being hard and unsolved matters to a procurement decision.

If alignment were solved, provenance would be an IP question: attribution, licence compliance, dependency risk. Because it is not solved, provenance is a safety question.

The safety commitments that matter, the frontier labs’ evaluation regimes, the red-teaming, the alignment research itself, all attach to foundation models.

The fine-tune-as-propietary economy launders those commitments: it takes a model whose safety properties were someone else’s work, modifies it in ways that unpredictably erode them, and sells the result under a name that makes the upstream dependency invisible.

And this cuts both ways across the closed/open divide.

Closed-weight providers owe us transparency about their safety training and evaluation. But open-weight providers now power an entire market of “proprietary” fine-tunes, and their responsibility does not end at the point of upload.

The false dichotomy, either a big lab’s API or my own sovereign model, obscures the actual structure: almost everything in the middle of the market is somebody’s fine-tune of somebody else’s foundation model, inheriting safety properties nobody downstream is measuring.

If you are an AIGP/ Compliance Officer, GC or in-house counsel, evaluating a tool that claims a proprietary model, four questions do most of the work:

1. Which foundation model, exactly? Name and version. If the answer is evasive, you have your answer. There is no such thing as a proprietary LLM built by a small vendor from scratch; frontier-scale pretraining costs are measured in the tens of millions of dollars and above.

2. What did you do to it? Full fine-tune, LoRA adapter, or prompt engineering. These are different chains of title. Ask what data, and whether the base model’s licence permits the use and the marketing.

3. What safety evaluation did you run after modification? Fine-tuning degrades alignment; Qi et al. is a short read, send it to them. A vendor who has never heard of this problem has not tested for it.

4. Where does inference actually run? “Infrastructure I own and control” and “dedicated cloud instances under a hyperscaler’s shared responsibility model” are, and I say this with love, not the same claim. Get the region, the sub-processors, and the responsibility split in writing.

None of this requires a lawyer to become an ML engineer. It requires the same instinct we already apply to every other asset:

Do not accept the seller’s description of what they own, establish the chain of title.

The vendor in my anchor story did nothing the market does not currently invite. But the market invites it because the buyers, lawyers, of all people, have not yet insisted that “proprietary” is a provenance claim, and provenance claims get verified.

Disclosure: I am Head of Legal at EquiStamp, an AI safety & evaluations company. This post reflects my personal opinion only.

[^1]: The OSI definition’s data requirement is the sticking point: it demands sufficiently detailed information about the training data for a skilled person to recreate a substantially equivalent system. No frontier open-weight release currently meets it.

[^2]: LoRA (Low-Rank Adaptation, Hu et al., 2021) freezes the base model’s weights and trains small adapter matrices alongside them. It is a parameter-efficient fine-tuning method: a technique for how you update a model cheaply. It is not an alignment method. RLHF and DPO are training objectives aimed at instilling preferences and safety behaviour; LoRA is plumbing that can carry any objective, including ones that undo the alignment work. A lawyer who knows this distinction can ask a vendor “did your fine-tune touch the model’s alignment, and how do you know?” and understand the answer.

[^3]: European Commission, Guidelines on the scope of the obligations for general-purpose AI models under Regulation (EU) 2024/1689, 18 July 2025, paragraphs 62-63. Where the original model’s training compute is unknown, the fallback threshold is one third of 10^23 FLOP (the presumption threshold for GPAI status), or one third of 10^25 FLOP for systemic-risk models. The criterion is expressly indicative rather than a bright line, and the Commission acknowledges compute is a proxy. It remains the only number on the table.

[^4]: RLHF: reinforcement learning from human feedback, the post-training process by which a raw pretrained model is shaped toward helpful, harmless behaviour (Ouyang et al., 2022, the InstructGPT paper, is the canonical reference). DPO: direct preference optimisation, a simpler method achieving similar ends without a separate reward model (Rafailov et al., 2023). If those two sentences were new to you, that is the AI literacy gap. Knowing that this training is fragile under subsequent fine-tuning is the AI safety literacy gap, and it is the one that matters for procurement.

[^5]: Qi et al., “Fine-tuning aligned language models compromises safety, even when users do not intend to!” (2023). The headline finding: safety alignment of GPT-3.5 Turbo materially degraded by fine-tuning on ten adversarially designed examples at a cost of a few dollars, and measurably degraded by fine-tuning on benign, commonly used datasets. The benign case is the one that should worry buyers of domain fine-tunes.