01 AI Consulting 02 Software Development 03 About 04 Blog
DE EN
Arrange a call
All posts

AI & Law

LLM Wrappers: Expensive Liability or Legitimate Product? When a “GPT Wrapper” Has Substance — and When It Doesn't

A GPT wrapper — often called an AI wrapper — is a software layer built around a third-party AI model such as GPT, Claude, or Gemini. “Wrapper” is frequently used as a slur. Unjustly so: what matters is not whether you use someone else’s model (nearly everyone does), but what you build around it — data, workflow, integration, and a legally sound foundation. That is precisely how you tell substance from expensive packaging.

This article answers the central question that German-language search has so far only half answered: the tech camp debates defensibility and moats but ignores the law. The legal camp touches on the term but never assesses the economic substance. Here both axes come together — written by someone who is legally responsible for the solution and builds it.

What Exactly Is a GPT/LLM Wrapper?

An LLM wrapper is software that drives a pre-trained language model through its API and embeds it in a concrete, specialized use case. The term, in itself, says only one thing: the most expensive and most difficult piece — the model itself — comes from a third party. That is not a defect. It is an architectural decision that, for more than 95 % of all use cases, is the economically correct one.

The Layered Architecture: Model, System Prompt, Context/RAG, Data, UI

Picture a wrapper as an onion. At the core sits the third-party model. Around it are layered:

  • System prompt & logic — the instructions that tune the model to your use case.
  • Context / RAG — feeding in relevant, proprietary content at runtime (retrieval-augmented generation for enterprises).
  • Proprietary data — data assets no competitor possesses.
  • Workflow & integration — embedding into existing tools, processes, and interfaces.
  • UI & experience — the surface that makes the whole thing usable in the first place.

LTO puts it succinctly: an AI wrapper creates genuine value through fine-tuning, domain-specific system prompts, context injection, and a usable interface — without these components, you really are buying nothing but expensive “packaging” (source: LTO).

Wrapper ≠ Your Own Model — and Why That Is Almost Always the Right Choice

Training your own foundation model costs tens to hundreds of millions and becomes outdated within months. Even tech heavyweights are backing away from it: the coding startup Codeium, looking back, described its own model-training efforts as “a mistake” and now bets on the application layer (source: Latent.Space). The lesson: competition does not happen in the model, but in the layer around it.

”Cheap Trick” or Real Product? The Substance Test

The more interesting question is not “wrapper, yes or no,” but where on the spectrum — between an interchangeable shell and a deeply rooted product — a given tool sits.

The Weak End: Interchangeable “Prompt-Only” Tools

At the bottom end are tools whose entire value creation is a clever system prompt. They can be rebuilt over a weekend, switching to a competitor costs the user nothing, and the moment the base model gains a feature natively, the business is finished. High churn here is not bad luck — it is structural.

The Strong End: Vertical Wrappers with Data and Workflow Depth

At the top end are products like the AI code editor Cursor, the legal AI Harvey, or Beck Noxtua in the German legal market. They, too, use third-party models — but they are deeply embedded in a professional workflow, process domain-specific context, and are anchored in their users’ daily work. It is precisely these wrappers that reach double-digit billion-dollar valuations, while the generic “custom GPTs” have largely missed product-market fit (source: Latent.Space). The scale is real: Harvey was valued at USD 11 billion on 25 March 2026, and Cursor’s parent Anysphere at USD 29.3 billion in November 2025 — both run third-party models at their core (sources: CNBC – Harvey, CNBC – Cursor).

Key takeaway: “Wrapper” is not a verdict on quality. It describes the architecture. The substance lies in what you build around the model.

When Does an AI Wrapper Have a Moat? — The Six Sources of Defensibility

A moat is what stops a competitor from simply copying you. For an AI product there are six realistic sources — and several that only look like a moat.

Moat sourceA real moat?Why
Proprietary data & data layerYes (the strongest)Proprietary, hard-to-obtain data cannot be reproduced by any competitor through a prompt.
Deep workflow / tool integrationYesWhoever sits inside the daily workflow is hard to displace.
Switching costsYes, conditionallyConfigured settings, history, and integrations raise the barrier to switching.
Distribution / salesYes, conditionallyExisting market access and a customer base are real, but erodible.
Data flywheelYes, if realUsage generates data that improves the product, which generates more usage. A moat only if the data is exclusive and product-relevant.
Brand / trustConditionallyHighly valuable in regulated/sensitive contexts (law, healthcare), otherwise slow to build.
A better prompt / nicer UI aloneNoCopyable within days; overtaken by the base model or a competitor.

Proprietary Data & the Data Layer (the Real Moat)

The model is equally available to everyone. Your data is not. By far the strongest, most durable competitive advantage of an AI wrapper is a data layer that no one else has: curated domain data, your own case data, exclusive integrations. A data flywheel emerges when using your product generates new, exclusive data that makes it better — which in turn attracts more usage.

LLM wrapper data flywheel: interchangeable third-party model at the center, proprietary data layer as the real competitive advantage around it

The model is a commodity, the data layer is not: a wrapper’s competitive edge lies not in the third-party core but in the exclusive data and the flywheel that surround it.

Deep Integration & Switching Costs

A tool deeply embedded in a customer’s CRM, ERP, or professional tools cannot be swapped out overnight. Cursor’s strength lies not in the model, but in the fact that it lives inside the developer’s editor (source: Latent.Space).

What Is NOT a Moat

A better system prompt, a nicer interface, a clever trick: all copyable, all fleeting. Anyone who bases their entire defensibility on this has no moat — they have a head start of a few weeks.

The Underestimated Risk: Dependence on the Model Provider

Every wrapper inherits its supplier’s risk. That is the uncomfortable flip side of the “don’t build, use” logic.

Vendor Lock-In, Pricing and Shutdown Risk (Read the Model ToS)

The model provider can raise prices, deprecate models, change terms of service, or discontinue a service. Read the model ToS like a supply contract: What happens to your data? May it be used for training? What termination and shutdown clauses exist? These clauses are a genuine contractual risk, not fine print.

Multi-Provider Strategy & Open Weights as Resilience Levers

The answer is architecture: an abstraction layer that makes the specific model interchangeable, a multi-provider strategy, and — where data sovereignty matters — the use of open-weights models. Anyone who needs maximum control over data flows and availability should seriously consider data-sovereign AI via on-premise or EU cloud. This reduces the concentration risk tied to a single U.S. provider.

This is the gap no purely technical article fills. A wrapper is never just technology — it is a product that someone is liable for, that processes data, and that falls within a legal framework.

RiskApplicable provision (as of April 2026)Practical consequence
Liability for faulty outputWerkvertrag/warranty (German contract for work and services, secs. 631 et seq., 633 et seq. BGB), possibly product liabilityYou owe a working deliverable; “the AI did it” does not automatically excuse you.
Data protection in the API chainArt. 28 GDPR (processing on behalf), Chapter V (third-country transfer)A data processing agreement (DPA) with the model provider is required once personal data flows; secure the U.S. transfer.
AI Act roleArts. 16/26, Art. 25 (downstream provider)Depending on the depth of intervention, deployer or provider obligations apply — the role is not freely chosen.
Third country / CLOUD ActChapter V GDPR, U.S. CLOUD ActU.S. providers may be subject to government access — relevant for sensitive data.
IP in prompt/output/fine-tune dataUrhG (German Copyright Act, threshold of originality), model ToSWho “owns” output and training data is nuanced and depends on the ToS.

Who Is Liable for Incorrect AI Output?

If your wrapper owes a deliverable — for instance a draft contract, an analysis, a calculation — then you are liable to your customer, not OpenAI or Anthropic. From this perspective, hallucinations are a defect in the deliverable you supplied. How far you can limit this through your terms and conditions depends on the individual case and on content review (secs. 305 et seq. BGB, the German rules on standard-business-terms control).

GDPR in the API Chain: DPA, Third-Country Transfer, CLOUD Act

As soon as personal data flows to the model provider, that provider is, as a rule, your processor — a data processing agreement under Art. 28 GDPR is then mandatory. If the provider is located in a third country (typically the U.S.), Chapter V GDPR and the assessment of the transfer come into play. More on this in the guide to GDPR-compliant AI and data processing.

EU AI Act: Does the Wrapper Make Me a “Provider” or a “Deployer”?

This is the most underestimated question. Whoever merely uses an AI system is regularly a deployer with reduced obligations (Art. 26). But whoever intervenes substantially — for instance modifying a GPAI model, or modifying a high-risk system so that its purpose or capabilities change materially — may become a (downstream) provider under Art. 25 of the AI Act, subject to the considerably stricter set of obligations (source: Freshfields). A mere system prompt or a light stylistic fine-tune does not normally trigger this; a substantial change to the range of tasks can.

As of April 2026 — important: Full application of the AI Act takes effect on 2 August 2026; the GPAI obligations already apply. In parallel, the EU is negotiating the Digital Omnibus, a simplification package that could push back the high-risk deadlines (Annex III). This package has not yet been adopted or published in the Official Journal — as long as that has not happened, the original timeline applies unchanged (sources: Gibson Dunn, White & Case). Please check the then-current status before making decisions.

IP & Contract: Who Owns the Prompt, the Output, and the Fine-Tune Data?

Under German copyright law, purely machine-generated output generally enjoys no copyright protection of its own, for lack of human creative originality. Usage rights in the output are mostly governed by the model ToS; you should clearly assign your own fine-tune and training data to yourself by contract. Here it pays to fix things cleanly by contract early on rather than litigate later.

Build a Wrapper or Build It Yourself? — The Build-vs-Buy Decision Tree

  • A lean wrapper is enough when no personal/sensitive data flows, the use case is non-critical, and you want to deliver value quickly.
  • A data/compliance layer becomes mandatory as soon as personal or business-critical data is processed, you owe liability-relevant deliverables, or regulatory obligations apply.
  • Open weights / self-hosting (data-sovereign AI) is the answer when data sovereignty, avoiding third countries, or availability guarantees take priority.

The underlying logic — buy the ordinary, build the exceptional — applies here too; explored in depth in the article Build vs. Buy: Off-the-Shelf vs. Custom Software. When the data layer is the actual value, the path usually leads to legally sound, custom software development rather than to an off-the-shelf tool.

The 7-Question Substance Check

Answer these questions honestly and in writing. The more you can answer with “Yes, demonstrably,” the more substance your wrapper has:

  1. Data: Do I have proprietary data that a competitor cannot easily obtain?
  2. Workflow: Does my product sit deep within the user’s workflow?
  3. Flywheel: Does usage generate exclusive data that measurably improves the product?
  4. Resilience: Can I survive a price hike, a ToS change, or the shutdown of my model provider?
  5. Liability: Do I know who is liable for faulty output, and is that addressed by contract?
  6. Data protection: Do I have the DPA, third-country assessment, and training opt-out under control?
  7. AI Act role: Do I know whether I am a deployer or a (downstream) provider?

Conclusion: Substance Beats Layer Thickness

Being a “wrapper” is no flaw — it is the economically sensible architecture for almost any AI product. The right question is never “wrapper or not?” but “where is my substance?” It lies in the data layer, in the workflow, in resilience against the model provider — and in a legally robust foundation of liability, data protection, and a clean AI Act classification. Whoever masters both axes builds a product. Whoever just writes a prompt buys expensive packaging.

Are you planning an AI feature or product and want to know up front whether it has substance and a clean legal foundation? Let’s go through exactly these seven questions for your specific case in an initial consultation.

Written by Leon Lotz, business lawyer & developer. As of 24 April 2026. This is general information, not legal advice, and does not replace individual legal counsel.

FAQ

Is a GPT wrapper a legitimate business model? Yes — if it creates genuine value through data, workflow, or integration. No, if it is just a thin prompt layer that the base model or a competitor can overtake at any time.

What distinguishes a wrapper from a “real” AI app? The substance layers (data, workflow, integration, law), not the question of whether a third-party model is used — nearly all applications do that.

How big is the risk of depending on OpenAI or Anthropic? Real: price changes, availability, ToS adjustments, model shutdowns. Mitigable through an abstraction layer, a multi-provider strategy, and open-weights models for data-sovereign scenarios.

Do I need a data processing agreement (Art. 28 GDPR) for an AI wrapper? As a rule, yes, once personal data flows to the model provider — plus an assessment of the third-country transfer under Chapter V GDPR if the provider is located outside the EU.

Does using a third-party model make me a “provider” within the meaning of the AI Act? It depends on the depth of intervention. Mere use makes you a deployer (Art. 26). A substantial change can make you a downstream provider under Art. 25, with stricter obligations. As of April 2026, subject to the ongoing Digital Omnibus process.

Build a wrapper or train your own model? For more than 95 % of SME cases: a wrapper plus your own data layer. Your own model only pays off for very specific needs — and even tech corporations often rate their own training attempts as a mistake.

Sources — as of 24.04.2026
Leon Lotz

Leon Lotz

Leon Lotz is a business lawyer and founder of MusketierSoftware. He combines legal depth with real software craft.