Build vs Buy vs Fine-Tune AI Models: Security, Supply Chain and Accountability Trade-offs

Choosing whether to train your own model, buy access to someone else's or fine-tune an existing one is usually made on cost and capability, yet it decides most of the security and accountability burden the organisation will carry for years. Each route moves risk to a different place: training data and weights you must protect, a supplier whose updates and data handling you cannot see, or an adapted model whose safety behaviour you have quietly changed. This guide compares the three routes on six properties: data exposure and training-data leakage, weights provenance, update and patching control, key and API credential management, evaluation and red-team burden, and regulatory accountability. For each route it gives a threat model, architecture in words, failure modes, controls, decision criteria and a worked scenario. It is for security architects, AI platform owners and risk leads approving a model sourcing decision. For the narrower question of retrieval versus adaptation see RAG vs Fine-Tuning.

Key takeaways

• Buying moves risk to the contract. A hosted model API means the supplier holds the weights and runs the updates, so your controls become data handling terms, credential hygiene, version pinning and continuous evaluation of a model you cannot inspect.
• Fine-tuning is where most organisations underestimate the burden. Research by Qi and colleagues jailbroke GPT-3.5 Turbo through a fine-tuning API with 10 adversarial examples for under $0.20, and found that benign fine-tuning also weakened safety alignment, so every fine-tuned model needs its own safety evaluation.
• Building from scratch buys control at the price of owning everything. You own data provenance, poisoning defences, weight security, documentation and every evaluation, and models can memorise and regurgitate training data, including personal data.
• Weights are both an asset and a supply chain. Downloaded base models and adapters can be poisoned or carry unsafe serialisation, and your own weights become a high-value target once trained.
• Accountability follows modification. Under the EU AI Act, substantially modifying a high-risk system or changing its intended purpose can make you a provider, and the Commission's GPAI guidelines say only significant modifications of a general-purpose model bring provider obligations.

The three routes defined

• Build: pretrain a model on data you assemble, on infrastructure you control, producing weights you own. In practice this includes training a smaller domain model from scratch, not only frontier-scale efforts.
• Buy: consume a model you do not train or hold: a hosted API, a model embedded in a SaaS product, or a licensed model served by a cloud provider. You configure prompts, retrieval and guardrails, but not the weights.
• Fine-tune: adapt an existing base model with your data, either through a provider's managed fine-tuning service (the provider keeps the weights) or by downloading open weights and training full parameters or adapters such as LoRA yourself. Mechanics are covered in the Fine-Tuning and LoRA Security Guide.

Many real systems combine routes, for example a bought model with retrieval plus a small fine-tuned classifier. Assess each model component separately: the controls follow the route, not the product.

Side-by-side comparison

Build: threat model, failure modes and controls

Threat model. The attacker's targets are the training data and the weights. Poisoning can enter at pre-training, fine-tuning or embedding (OWASP LLM04:2025 Data and Model Poisoning; ATLAS AML.T0020 Poison Training Data), and trained weights are an exfiltration target. Carlini and colleagues extracted hundreds of verbatim sequences from GPT-2, including personal contact details, from records that appeared in a single training document, and reported that larger models are more vulnerable. Web-scale corpora also carry secrets: the 12,000 live secrets found in a public LLM training dataset shows what a crawl collects if nobody filters it.

Architecture in words. Data is collected from internal systems and external sources into a curated store; a pipeline filters, deduplicates and labels it; training jobs on a GPU cluster read the store under a job identity and write checkpoints to object storage; a registry promotes a signed final model to serving.

Failure modes. Unfiltered PII and secrets in the corpus; training jobs running as broad cloud roles that can read far more data than the run needs; checkpoints left in buckets with wide read access; no record of which data version produced which weights, so a poisoning report cannot be traced.

Controls. Data provenance records per source and version (NIST SP 800-53 SR-4 Provenance); PII and secret scanning before data enters the corpus; deduplication to reduce memorisation of repeated records; per-job identities scoped to one dataset version; weights treated as crown-jewel assets (see the Securing AI Model Weights); signed artefacts and build provenance (see the SLSA and Build Provenance Guide); and red-teaming for training data exposure and membership inference, which NIST AI 600-1 lists as action MS-2.10-001.

Buy: threat model, failure modes and controls

Threat model. The supplier relationship is the attack surface. Your prompts, retrieved documents and outputs cross into the supplier's environment; your API keys can be stolen and resold or used to run up cost (see the LLMjacking Guide); and the model can change underneath you. OWASP LLM03:2025 Supply Chain lists outdated or deprecated models as a risk and recommends that the application relies on a maintained version of APIs and the underlying model. NIST AI 600-1 names Value Chain and Component Integration as one of its twelve generative AI risks.

Architecture in words. An application or gateway holds a credential for the provider, sends prompts with retrieved context, receives completions and logs them; the provider runs the model, may retain inputs for abuse monitoring under its terms, and publishes version and retirement schedules.

Failure modes. Static API keys in code and CI, shared across teams; calling a floating model alias so behaviour changes without a change ticket; no contractual clarity on retention, training use or incident notification; no fallback when a model version is retired; and over-trust in published benchmark results, which OWASP notes models can be fine-tuned to bypass.

Controls. Contract terms that cover content ownership, usage rights, security and provenance (NIST AI 600-1 GV-6.1-004) and limits on unauthorised secondary data use and incident notification (GV-6.2-007); supplier due diligence covering IP, privacy and security (GV-6.1-009), for example with the AI Vendor Security Questionnaire Template; credentials in a vault or, where the provider supports it, workload identity federation instead of static keys; per-application keys with spend limits; pinning a dated model version and re-running your evaluation suite before moving; continuous monitoring of the third-party system in production (GV-6.2-004); and a documented fallback model.

Fine-tune: threat model, failure modes and controls

Threat model. Fine-tuning inherits every base model risk and adds three of its own. First, safety drift: as Qi and colleagues showed, a handful of examples can remove refusal behaviour, and even benign data can weaken it. Second, concentrated data: the fine-tuning set is usually your most sensitive, task-specific data and can be extracted through the model's outputs (ATLAS AML.T0057 LLM Data Leakage, AML.T0024 Exfiltration via AI Inference API). Third, supply chain: OWASP LLM03:2025 calls out vulnerable LoRA adapters and collaborative model merging as ways to compromise a base model, and ATLAS lists AML.T0058 Publish Poisoned Models. The Hugging Face API tokens exposure found 655 valid tokens with write permission, which researchers said could have let an attacker replace popular models with poisoned ones.

Architecture in words. A base model is pulled from a hub or selected from a provider catalogue; a training set is exported from business systems; a job (managed by the provider, or on your own GPUs) produces new weights or an adapter; the result is evaluated and deployed, either on the provider's endpoint or on your own serving stack.

Failure modes. Fine-tuning on raw support tickets or chat logs containing personal data; pulling base models or adapters by name without pinning a revision or verifying the file format; skipping safety re-evaluation because "the base model was already tested"; fine-tuning credentials with write access to the production model registry; and losing track of which base version an adapter depends on when the provider retires it.

Controls. Minimise and de-identify training data before export; pin base model revisions and load only safe formats (see the Model Supply Chain Guide); sign and inventory adapters in an AI bill of materials (see the AI Supply Chain and AI-BOM Guide); separate identities for data export, training and registry promotion; and make safety and security re-evaluation a release gate. NIST AI 600-1 calls for re-evaluating models fine-tuned on top of third-party models (MP-4.1-007) and verifying that fine-tuning does not compromise safety and security controls (MS-2.7-008).

Regulatory accountability by route

As checked on the European Commission's pages in November 2026, obligations for general-purpose AI model providers have applied since 2 August 2025, the Commission's enforcement powers apply from 2 August 2026, and providers of models placed on the market before 2 August 2025 must comply by 2 August 2027. Confirm current status before relying on dates, because implementation of the Act continues to change.

Outside the EU the same question appears in contracts rather than statute: who answers for outputs, incidents and data subject requests. See the EU AI Act Provider vs Deployer Obligations Guide and the EU AI Act GPAI Obligations Guide.

Choosing: decision criteria

Decision checklist. Before approving a route, answer: which data classes will reach the model in training and in use; who holds the weights and how their provenance is evidenced; who decides when the model changes and how you will be told; which credentials and identities the route creates and who owns them; what evaluation and red-team effort is budgeted for every release; and which legal role the organisation takes, recorded by legal and compliance.

Worked scenario: a claims triage assistant

An insurer wants a model that reads claim notes and suggests a triage category. The data includes health information and personal data.

1. Buy first: the team tests a hosted model with prompting and retrieval of policy wording. Accuracy is acceptable for drafting but inconsistent for categories. Contract review confirms the retention and training-use terms of the chosen API tier; keys move to a vault with per-environment spend limits; the model version is pinned.
2. Fine-tune a small classifier: rather than fine-tuning the large model on claim notes, the team fine-tunes a small open-weight classifier in-house on de-identified notes, pinned to a base revision loaded from a safe format, with its adapter signed and recorded in the AI-BOM.
3. Evaluate: a release gate tests category accuracy, membership inference and extraction attempts on the classifier, and prompt injection against the hosted model with retrieved notes.
4. Accountability: legal records the organisation as deployer of the hosted model and owner of the classifier, and checks whether the use case falls within a high-risk category.
5. Operate: a version change from the provider triggers the evaluation suite; the classifier is retrained only through the same pipeline.

The split keeps the most sensitive data out of the supplier's training path and keeps the in-house model small enough to evaluate thoroughly.

Implementing the decision

1. Classify the use case and data: record data classes, intended purpose and the legal role per route.
2. Threat model the chosen route using the sections above and NIST AI 600-1's risk list.
3. Set up identities and credentials: vaulted provider keys or federation for buy; scoped job identities for training; separate promotion rights for the registry. See the Self-Hosted LLM Security Guide where you serve weights yourself.
4. Pin and record: model versions, base revisions, adapter hashes and dataset versions in an inventory.
5. Pilot with evaluation gates: run in a limited user group with logging; block promotion on failed safety or leakage tests.
6. Plan rollback: keep the previous model version or a fallback provider ready, and document how to switch.
7. Review on change: any new version, new data source or new purpose re-enters step 1.

Detection and measurement

• Log: provider API usage per key, model version in every request, training job identities and data reads, registry promotions, and downloads of base models and adapters.
• Alert on: unpinned model aliases in production, spikes in API spend, use of a provider key from an unexpected network, and unsigned or unregistered adapters in serving.
• Metric 1: percentage of production model calls pinned to a dated version.
• Metric 2: percentage of fine-tuned releases that passed safety and leakage evaluation before deployment (target 100%).
• Metric 3: days from a supplier model retirement notice to a tested migration.
• Metric 4: share of model artefacts (base, adapter, weights) with recorded provenance and signature.
• Metric 5: number of static provider API keys older than the rotation policy.

Common failure patterns

• "We fine-tuned, so it is ours to judge": teams skip safety re-testing after tuning, even though benign data can weaken alignment.
• Fine-tuning on the knowledge base: frequently changing or permissioned content is baked into weights instead of retrieved, so it cannot be revoked per user.
• Floating model versions: production behaviour changes overnight because the application called an alias.
• Write tokens on model hubs: broad tokens in code allow model replacement, as the Hugging Face API tokens exposure showed.
• Licence blind spots: OWASP LLM03:2025 notes that dataset licences may restrict usage, distribution or commercialisation, and building or tuning on them can create legal exposure.
• Single-supplier dependence with no fallback: NIST AI 600-1 action GV-6.2-005 recommends redundancy policies covering model weights and other system artefacts.

Framework mapping

Practitioner checklist

• Record the route, data classes and legal role for every model component before build starts.
• Pin dated model versions and base model revisions; ban floating aliases in production.
• Put provider keys in a vault or replace them with federation; one key per application with spend limits.
• Minimise and de-identify fine-tuning data; scan training corpora for PII and secrets.
• Load base models and adapters only from pinned revisions in safe formats, and sign them.
• Make safety, leakage and prompt injection evaluation a release gate after every tuning run and every supplier version change.
• Negotiate retention, training use, incident notification and retirement notice terms with model suppliers.
• Keep a tested fallback model and a documented rollback path.

Standards and references

• NIST: AI 600-1 Generative Artificial Intelligence Profile
• OWASP: Top 10 for LLM Applications 2025
• MITRE: ATLAS
• European Commission AI Act Service Desk: Article 25, Responsibilities along the AI value chain
• European Commission AI Act Service Desk: Article 53, Obligations for providers of general-purpose AI models
• European Commission: Guidelines for providers of general-purpose AI models
• NCSC: Guidelines for secure AI system development
• arXiv: Fine-tuning Aligned Language Models Compromises Safety, Even When Users Do Not Intend To

Related NHI Mgmt Group resources: RAG vs Fine-Tuning · Fine-Tuning and LoRA Security Guide · Model Supply Chain Guide · Securing AI Model Weights · DeepSeek and High-Risk AI Vendor Assessment Guide