Security, Compliance and Governance for Open-Source and Closed-Source LLM Deployments

Deploying a large language model is not simply a question of choosing between an open-source model and a commercial API. It is an enterprise risk decision involving:

• What information the system will process.
• Where that information will travel.
• Who can access the model, prompts, outputs and logs.
• What actions the model can perform.
• How the organisation will detect failures or attacks.
• Which party is accountable when something goes wrong.
• What evidence can be presented to auditors, regulators, customers and executives.

A common mistake is to assume that:

• On-premises automatically means secure.
• Cloud automatically means less private.
• Open-source automatically means transparent.
• Closed-source automatically means supported and compliant.
• Private networking means no third party processes the data.
• A model that cannot directly access a database cannot leak information.
• Prompt guardrails alone can prevent prompt injection.

None of these assumptions is consistently true.

Security depends on the complete system: the model, data pipelines, retrieval layer, APIs, tools, identities, infrastructure, monitoring, people and operating processes.

The right way to think about LLM deployment is therefore:

Do not ask only, “Where is the model hosted?” Ask, “Who controls every layer, what can cross each trust boundary, and what evidence proves the controls are working?”

---

1. Start by Clarifying the Terminology​

1.1 Open-source, open-weight and closed-source models​

The terms open-source model and open-weight model are frequently used interchangeably, but they are not identical.

An open-weight model normally makes its trained parameters available for download. However, the organisation may not receive:

• The complete training dataset.
• The full training pipeline.
• Data-filtering methodology.
• Intermediate checkpoints.
• Optimiser state.
• Reproducible training instructions.
• Permission to use the model for every purpose.
• Permission to modify or redistribute it without restrictions.

The Open Source Initiative’s Open Source AI Definition requires freedoms to use, study, modify and share the system, together with access to the preferred form for making modifications. Under this definition, publishing weights alone does not necessarily make an AI system fully open source.

Throughout this article:

• Open-source LLM means a model meeting meaningful open-source criteria.
• Open-weight LLM means downloadable weights whose licence or development artefacts may still be restricted.
• Closed-source or proprietary LLM means a model whose weights, source code or training process are controlled by a commercial provider.

This distinction matters for compliance. A model may be downloadable but still carry commercial-use limitations, redistribution restrictions, acceptable-use conditions or attribution requirements.

---

1.2 The main deployment patterns​

Enterprise LLM deployments usually fall into five patterns.

Pattern A: Open-weight model on-premises​

The organisation downloads the model and operates it on its own:

• Servers.
• GPUs.
• Storage.
• Network.
• Kubernetes or virtual machines.
• Inference runtime.
• Monitoring platform.

The organisation has the greatest infrastructure control, but also inherits almost all operational responsibility.

Pattern B: Open-weight model self-hosted in the cloud​

The organisation deploys the model in its own AWS, Azure, Google Cloud or other cloud account.

The organisation controls the workload configuration, but the cloud provider controls the underlying physical infrastructure.

Pattern C: Proprietary model through the provider’s API​

The application sends prompts to a vendor-hosted endpoint.

The provider manages:

• Model weights.
• Model serving.
• Infrastructure.
• Model updates.
• Capacity.
• Some security and safety controls.

The customer remains responsible for application design, access control, data governance, output handling and appropriate use.

Pattern D: Proprietary model through a hyperscaler​

A commercial model is consumed through a managed platform such as:

• Azure AI services.
• Amazon Bedrock.
• Google Vertex AI.

This may create a different contractual, networking and data-processing relationship from using the model provider’s direct API.

For example, Microsoft states that prompts, completions, embeddings and training data for Azure Direct Models are not made available to other customers or model providers and are not used to train foundation models without customer permission. AWS states that third-party model providers do not have access to Amazon Bedrock customer prompts, completions or service logs in its model deployment accounts.

Pattern E: Proprietary model privately deployed on-premises or in a customer VPC​

A limited number of providers offer proprietary models as containers, appliances or private deployments.

The customer may operate the infrastructure while the provider protects the intellectual property of the model through:

• Encrypted weights.
• Contractual controls.
• Signed containers.
• Licence servers.
• Remote attestation.
• Confidential computing.

Cohere, for example, documents private deployment options for on-premises and customer-controlled VPC environments. NVIDIA also documents an architecture in which encrypted proprietary model artefacts are released only after confidential-computing attestation succeeds.

Closed-source on-premises deployment is therefore possible only when the provider commercially and technically supports it. Possessing an API licence does not provide a right to download or self-host a proprietary model.

---

2. Separate Security, Compliance and Governance​

These concepts overlap but solve different problems.

2.1 Security​

Security asks:

• Can an attacker gain access?
• Can the system disclose confidential information?
• Can the model be manipulated?
• Can data or model artefacts be poisoned?
• Can the application perform unauthorised actions?
• Can the service be made unavailable?
• Can an insider misuse it?
• Can the model, prompts or intellectual property be stolen?

Security controls primarily protect:

• Confidentiality.
• Integrity.
• Availability.
• Authenticity.
• Accountability.

2.2 Compliance​

Compliance asks:

• Which laws, regulations, contracts and standards apply?
• Are personal data being processed lawfully?
• Is a Data Protection Impact Assessment required?
• Is the system classified as high risk?
• Are retention and residency requirements met?
• Can users exercise applicable rights?
• Are the model licence and training-data conditions acceptable?
• Can the organisation demonstrate conformity?

A technically secure system can still be non-compliant. For example, encrypted personal data may still be collected without an appropriate purpose or retained for too long.

2.3 Governance​

Governance asks:

• Who is accountable for the AI system?
• Who approved the use case?
• Who accepts residual risk?
• How are models and datasets selected?
• What changes require reapproval?
• Who monitors performance and harm?
• When must humans intervene?
• How are incidents escalated?
• How is the system retired?

Governance converts security and compliance from one-time exercises into repeatable management processes.

ISO/IEC 42001 establishes an AI management-system approach, while the NIST AI Risk Management Framework organises AI risk activities around Govern, Map, Measure and Manage. NIST Cybersecurity Framework 2.0 adds the broader cybersecurity functions Govern, Identify, Protect, Detect, Respond and Recover.

---

3. Use a Six-Plane Security Model​

A useful way to structure LLM risk is to divide the system into six interconnected planes.

3.1 Business and governance plane​

This includes:

• Approved use case.
• Risk classification.
• Business owner.
• Model owner.
• Data owner.
• Security owner.
• Human-oversight model.
• Acceptable-use policy.
• Regulatory classification.
• Risk acceptance.
• Incident accountability.

3.2 Data plane​

This covers:

• User prompts.
• Uploaded documents.
• Training data.
• Fine-tuning data.
• Retrieval corpora.
• Embeddings.
• Conversation history.
• Outputs.
• Feedback data.
• Evaluation datasets.
• Logs and traces.
• Agent memory.
• Tool responses.

3.3 Model plane​

This covers:

• Foundation model.
• Tokeniser.
• Model weights.
• Quantised versions.
• Fine-tuned checkpoints.
• LoRA adapters.
• Embedding models.
• Rerankers.
• Safety classifiers.
• Model configuration.
• System prompts.
• Decoding settings.

3.4 Application and action plane​

This includes:

• Prompt templates.
• Orchestration frameworks.
• RAG pipelines.
• Agents.
• Tool calls.
• Plugins.
• MCP servers.
• APIs.
• Approval workflows.
• Business rules.
• Output parsers.

3.5 Infrastructure plane​

This includes:

• Cloud accounts.
• Networks.
• GPU nodes.
• Containers.
• Kubernetes.
• Secrets.
• Identity systems.
• Databases.
• Object storage.
• Vector stores.
• Logging platforms.
• Backup and recovery.

3.6 Assurance and evidence plane​

This contains the evidence demonstrating that controls work:

• Evaluation results.
• Red-team findings.
• Audit logs.
• Model cards.
• Data lineage.
• Risk assessments.
• DPIAs.
• Penetration-test reports.
• Approvals.
• Change records.
• Incident records.
• Access reviews.
• Supplier attestations.

Weakness in any one plane can compromise the entire system.

---

4. Build the Threat Model Around Assets and Trust Boundaries​

Before selecting controls, identify what must be protected.

4.1 Important assets​

Typical LLM assets include:

• Personal data.
• Customer records.
• Health or financial information.
• Trade secrets.
• Source code.
• Internal policies.
• Authentication credentials.
• Model weights.
• Fine-tuning datasets.
• System prompts.
• Proprietary embeddings.
• Agent tools.
• Business decisions.
• Audit evidence.
• GPU capacity.

4.2 Potential adversaries​

Consider:

• External attackers.
• Malicious users.
• Fraudsters.
• Competitors.
• Disgruntled employees.
• Overprivileged administrators.
• Compromised suppliers.
• Malicious model publishers.
• Attackers controlling retrieved web pages or documents.
• Compromised tools or agents.
• Accidental insiders.
• Users attempting to bypass policy restrictions.

4.3 Trust boundaries​

Map every place where information crosses from one control domain to another:

• Browser to application.
• Application to AI gateway.
• Gateway to model endpoint.
• Model to vector database.
• Retriever to document store.
• Agent to business tool.
• Cloud to on-premises network.
• Customer tenant to shared infrastructure.
• Development to production.
• Vendor environment to customer environment.
• Logging pipeline to observability platform.

For each boundary ask:

1. What data crosses it?
2. Is the data necessary?
3. Is the caller authenticated?
4. Is the request authorised?
5. Is the communication encrypted?
6. Can the receiving system retain the data?
7. Can it send data elsewhere?
8. Is the activity logged?
9. Can the action be reversed?
10. Who is responsible if the boundary fails?

Zero-trust architecture is useful here because it treats access to resources—not network location—as the primary security decision. Being inside a corporate network should not automatically make an LLM workload trusted.

---

5. Understand the Major LLM Threat Categories​

The OWASP Top 10 for LLM Applications highlights risks including:

• Prompt injection.
• Sensitive-information disclosure.
• Supply-chain vulnerabilities.
• Data and model poisoning.
• Improper output handling.
• Excessive agency.
• System-prompt leakage.
• Vector and embedding weaknesses.
• Misinformation.
• Unbounded consumption.

MITRE ATLAS complements this with adversarial tactics and techniques covering model access, poisoning, model extraction, data collection, exfiltration, impact and attacks against RAG or agentic systems.

These frameworks should be used as threat-modelling inputs rather than as simple compliance checklists.

---

5.1 Prompt injection​

Prompt injection occurs when malicious or untrusted content changes the model’s behaviour.

It may be:

• Direct: A user enters instructions designed to override the application’s rules.
• Indirect: Malicious instructions are hidden inside documents, websites, emails, images or retrieved content.
• Stored: Harmful instructions are saved in memory or a knowledge base and activated later.
• Cross-agent: One compromised agent sends malicious instructions to another.
• Multimodal: Instructions are hidden in images or other media.

Prompt injection is especially dangerous because models do not reliably distinguish between instructions and untrusted data. OWASP therefore treats prompt injection as a fundamental application-level risk.

Controls​

Use layered controls:

• Treat retrieved content as untrusted.
• Clearly separate system instructions, user input and external context.
• Do not allow the model to directly determine authorisation.
• Allowlist tools and actions.
• Use deterministic policy checks outside the model.
• Require approvals for high-impact actions.
• Restrict data available to each request.
• Detect suspicious input patterns.
• Scan external documents.
• Sanitize rendered output.
• Use short-lived credentials.
• Test direct, indirect and multimodal injections.
• Record the origin of retrieved context.

A prompt such as “ignore malicious instructions” is not a sufficient control.

---

5.2 Sensitive-information disclosure​

Information can leak through:

• The model response.
• Conversation history.
• Logs.
• Distributed traces.
• Vector search.
• Cached responses.
• Error messages.
• Tool responses.
• Debug interfaces.
• Fine-tuning data.
• Model memorisation.
• Cross-tenant retrieval.
• Support access.
• Vendor abuse-monitoring systems.

Controls​

• Classify data before it reaches the model.
• Block prohibited data categories.
• Redact or tokenise identifiers.
• Use tenant-aware retrieval filters.
• Apply row-level and document-level permissions.
• Minimise prompt content.
• Disable unnecessary prompt logging.
• Redact telemetry.
• Encrypt sensitive stores.
• Separate production and evaluation datasets.
• Test for memorisation and extraction.
• Apply output DLP.
• Prevent sensitive data from entering cache keys.
• Establish explicit retention and deletion rules.

Embeddings must also be treated as sensitive data where they encode or permit inference about protected source information.

---

5.3 Data and model poisoning​

Attackers may manipulate:

• Training data.
• Fine-tuning data.
• Human feedback.
• Retrieved documents.
• Embedding indexes.
• Evaluation datasets.
• Model weights.
• LoRA adapters.
• Safety classifiers.
• Agent memory.
• Tool descriptions.

Poisoning may create:

• Hidden backdoors.
• Biased outputs.
• Incorrect recommendations.
• Trigger-based behaviour.
• Retrieval manipulation.
• Safety-control bypass.
• Persistent misinformation.

Controls​

• Approve data sources.
• Track provenance.
• Hash and sign datasets.
• Separate data submission from data approval.
• Scan for duplicates, anomalies and unusual triggers.
• Use trusted evaluation sets.
• Maintain immutable dataset versions.
• Review changes to knowledge bases.
• Rebuild indexes from approved source documents.
• Test models for backdoor behaviour.
• Monitor sudden shifts in outputs.
• Require code review for adapters and prompt changes.

---

5.4 Excessive agency​

An LLM becomes materially more dangerous when it can:

• Send emails.
• Execute code.
• Modify records.
• Approve payments.
• Delete documents.
• Create accounts.
• Change infrastructure.
• Access customer systems.
• Submit regulatory reports.
• Make employment or credit decisions.

OWASP describes excessive agency as arising from excessive functionality, permissions or autonomy.

Controls​

Separate reasoning from execution.

The model may propose an action, but a deterministic control layer should decide whether the action is:

• Allowed.
• Within the user’s authority.
• Within a transaction limit.
• Appropriate for the current workflow.
• Subject to human approval.
• Reversible.
• Properly logged.

Use:

• Least-privilege tool scopes.
• Per-tool identities.
• Just-in-time credentials.
• Transaction limits.
• Read-only defaults.
• Human approval for high-risk operations.
• Idempotency controls.
• Dual authorisation.
• Dry-run modes.
• Sandboxed execution.
• Kill switches.
• Tool-call audit logs.

Never give an agent the full permissions of its developer or infrastructure administrator.

---

5.5 Improper output handling​

LLM output must be treated as untrusted input.

A generated response can contain:

• Malicious HTML.
• JavaScript.
• SQL.
• Shell commands.
• Incorrect URLs.
• Unsafe code.
• Fabricated citations.
• Manipulated tool parameters.
• Path traversal instructions.
• Data-exfiltration payloads.

Controls​

• Validate structured output against schemas.
• Escape HTML.
• Parameterise SQL.
• Apply command allowlists.
• Never send raw LLM output directly to a shell.
• Validate file paths.
• Check URLs and domains.
• Scan generated code.
• Run code in disposable sandboxes.
• Require approval before deployment.
• Reject unexpected fields.
• Constrain output lengths and types.

---

5.6 Unbounded consumption and denial of service​

LLMs create distinctive availability and financial risks:

• Extremely long prompts.
• Repeated requests.
• Recursive agent loops.
• High-cost model routing.
• Large context windows.
• Tool-call explosions.
• Large document ingestion.
• GPU memory exhaustion.
• KV-cache exhaustion.
• Deliberately expensive decoding.
• Cache-bypass attacks.

Controls​

• User and tenant quotas.
• Token limits.
• Request size limits.
• Tool-call limits.
• Agent step limits.
• Timeouts.
• Concurrency controls.
• Cost budgets.
• Circuit breakers.
• Request prioritisation.
• GPU admission control.
• Model fallback.
• Semantic caching with access-aware keys.
• Alerts for abnormal token consumption.
• Rate limits at both gateway and model layers.

---

6. Secure the Data Lifecycle​

6.1 Data discovery and classification​

Before deployment, determine whether the system will process:

• Public information.
• Internal information.
• Confidential business data.
• Personal data.
• Special-category or highly sensitive data.
• Payment information.
• Health information.
• Authentication secrets.
• Legal privilege.
• Export-controlled information.
• Customer-regulated data.

Do not classify the application only by its intended input. Consider accidental input as well. Employees frequently paste information into general-purpose assistants that the original design did not anticipate.

6.2 Data minimisation​

Send only the minimum information necessary.

Instead of sending an entire customer record, send:

• The relevant product.
• A pseudonymous customer identifier.
• The specific transaction.
• Only the fields needed to answer the question.

Data minimisation improves:

• Privacy.
• Security.
• Model relevance.
• Cost.
• Explainability.
• Incident containment.

6.3 Pseudonymisation and tokenisation​

Replace direct identifiers with tokens before model processing.

For example:

• Customer name → CUSTOMER_1042
• Account number → ACCOUNT_TOKEN_17
• Email → EMAIL_TOKEN_4

Maintain the reidentification mapping in a separate, tightly controlled service.

Pseudonymisation is not anonymisation. If the organisation can reconnect the token to an individual, the information remains personal data.

6.4 Encryption​

Use encryption across three states.

Data in transit​

Require:

• TLS for external and internal traffic.
• Certificate validation.
• Private connectivity where appropriate.
• Mutual TLS for sensitive service-to-service communication.
• Certificate rotation.

Data at rest​

Encrypt:

• Prompt stores.
• Conversation history.
• Vector databases.
• Document stores.
• Model artefacts.
• Checkpoints.
• Evaluation data.
• Logs.
• Backups.

Use customer-managed keys when the risk model requires separation from provider-managed keys.

Data in use​

For highly sensitive workloads, assess confidential computing or trusted execution environments. NIST defines confidential computing as the use of hardware-enabled features to isolate and process encrypted data in memory so that the data is at less risk of exposure and compromise from concurrent workloads or the underlying system and platform (NISTIR 8320).

This can be valuable when:

• The infrastructure operator should not see model weights.
• The model provider should not see customer prompts.
• Sensitive data must remain protected from the host.
• Cryptographic attestation is required before key release.

Confidential computing does not eliminate application vulnerabilities, malicious outputs or poor access control.

6.5 Retention and deletion​

Define separate retention periods for:

• User prompts.
• Model outputs.
• Conversation state.
• Safety-monitoring logs.
• Security logs.
• Agent memory.
• Fine-tuning files.
• Evaluation datasets.
• Vector embeddings.
• Backups.
• Failed requests.
• Support records.

A provider may claim zero retention for one API mode while another feature—such as file storage, grounding, search or persistent assistants—retains data.

For example, Google documents specific conditions under which Vertex AI can support zero-data-retention configurations, while certain features such as grounding can change retention behaviour (Google Cloud Vertex AI data governance).

Therefore validate retention at the feature level, not merely at the vendor level.

---

7. Secure Open-Source and Open-Weight Models​

Open models provide greater control, but they create a significant supply-chain responsibility.

7.1 Verify the model source​

Do not download a model based only on:

• Popularity.
• Community comments.
• A familiar name.
• Benchmark performance.
• A link posted in a tutorial.

Record:

• Publisher.
• Repository.
• Commit or release.
• Model identifier.
• File hashes.
• Licence.
• Model-card version.
• Download date.
• Security scan result.
• Approval owner.

Mirror approved artefacts into an internal registry rather than allowing production servers to download models directly from the internet.

7.2 Avoid unsafe serialisation​

Some machine-learning formats can execute code during deserialisation.

PyTorch explicitly warns against loading data from untrusted sources. Hugging Face provides pickle scanning and recommends safer serialisation approaches. Safetensors is designed to store numerical tensor data without executable content and is intended as a safer alternative to pickle-based formats (Hugging Face Safetensors).

Controls should include:

• Prefer Safetensors or similarly non-executable formats.
• Disable unnecessary remote code.
• Avoid unrestricted trust_remote_code.
• Load untrusted artefacts only in isolated analysis environments.
• Block network egress during inspection.
• Scan model packages and containers.
• Review custom modelling code.
• Compare file hashes with approved values.
• Convert models in a sandbox.
• Sign the approved internal artefact.

7.3 Create a model bill of materials​

A model bill of materials should record:

• Base model.
• Model version.
• Licence.
• Model weights.
• Tokeniser.
• Inference runtime.
• Quantisation method.
• Quantisation tool.
• Fine-tuning datasets.
• Adapters.
• Safety model.
• Embedding model.
• Reranker.
• Python packages.
• CUDA version.
• GPU driver.
• Container image.
• Operating system.
• Prompt template.
• Evaluation suite.
• Known limitations.

This is the AI equivalent of knowing every component in a production software stack.

7.4 Secure the model supply chain​

Apply software-supply-chain practices to:

• Model weights.
• Containers.
• Adapters.
• Datasets.
• Prompt packages.
• Evaluation artefacts.

SLSA provides an incremental framework for improving artefact provenance and build integrity. Its principles can be adapted to AI artefacts, even when AI-specific provenance standards are still maturing (SLSA).

Recommended controls include:

• Reproducible packaging.
• Signed artefacts.
• Provenance attestations.
• Isolated builds.
• Protected build identities.
• Immutable registries.
• Approval before promotion.
• Separation of build and release roles.
• Verification at deployment time.

7.5 Evaluate the licence​

Review:

• Commercial-use rights.
• Redistribution rights.
• Modification rights.
• Attribution requirements.
• Copyleft conditions.
• Use restrictions.
• Output restrictions.
• Patent terms.
• Termination clauses.
• Geographic restrictions.
• Obligations for derivative models.
• Restrictions affecting regulated use cases.

The legal review must cover the entire stack, including:

• Base model.
• Fine-tuned model.
• Embedding model.
• Reranker.
• Datasets.
• Inference software.
• Guardrail models.

7.6 Protect the weights​

Open weights may still be commercially valuable after fine-tuning.

Protect:

• Fine-tuned checkpoints.
• Proprietary adapters.
• Quantised variants.
• Customer-specific configurations.
• Evaluation datasets.
• Distillation datasets.

Use:

• Restricted registries.
• Encryption.
• Separate production identities.
• No direct developer access to production weights.
• Export controls.
• Download monitoring.
• DLP.
• Secure deletion.
• Watermarking or fingerprinting where appropriate.

7.7 Plan patching and ownership​

With self-hosted models, no managed provider automatically solves:

• Runtime vulnerabilities.
• CUDA vulnerabilities.
• Container vulnerabilities.
• Kubernetes vulnerabilities.
• Driver updates.
• Model-serving defects.
• Tokeniser defects.
• Prompt-template vulnerabilities.
• Model safety improvements.

Assign owners for:

• Model updates.
• Runtime patching.
• Infrastructure patching.
• Security advisories.
• Regression testing.
• Emergency rollback.
• Model retirement.

---

8. Secure Closed-Source Models​

Closed-source models reduce infrastructure responsibility but increase vendor dependency and opacity.

8.1 Understand the provider’s data practices​

Establish:

• Whether prompts are used for training.
• Whether outputs are used for training.
• Whether training use is opt-in or opt-out.
• Default retention.
• Configurable retention.
• Abuse-monitoring retention.
• Human access conditions.
• Support access.
• Subprocessors.
• Processing locations.
• Backup retention.
• Deletion timelines.
• Data residency options.
• Legal-request handling.

OpenAI states that business and API data are not used to train its models by default and documents enterprise access, encryption, retention and DPA options. These commitments must still be checked against the specific service, account type and configuration (OpenAI Enterprise privacy).

8.2 Assess model opacity​

The provider may not disclose:

• Complete training data.
• Detailed model architecture.
• Full safety-training methods.
• All known limitations.
• Exact benchmark datasets.
• Internal red-team findings.
• Weight changes between releases.

Compensate through:

• Independent evaluation.
• Contractual assurance.
• System cards.
• Provider documentation.
• Third-party certifications.
• Regulatory disclosures.
• Your own red teaming.
• Behavioural monitoring.
• Output controls.

Do not treat a provider certification as proof that your application is compliant. A provider can secure its platform while the customer builds an unsafe workflow on top of it.

8.3 Control model changes​

Managed models can change through:

• New model versions.
• Safety updates.
• Routing changes.
• Deprecations.
• Context-window changes.
• Tool-use changes.
• Pricing changes.
• Regional availability changes.

Require:

• Version pinning where available.
• Advance change notification.
• Regression testing.
• Shadow evaluation.
• Approval before migration.
• Rollback plans.
• Model-substitution controls.
• Monitoring for behavioural drift.

8.4 Review the contract​

Important contractual areas include:

• Data ownership.
• Input and output rights.
• Training-data use.
• Confidentiality.
• Security obligations.
• Audit reports.
• Breach notification.
• Data deletion.
• Data residency.
• Subprocessor notification.
• Service availability.
• Support response.
• Model deprecation.
• Intellectual-property claims.
• Indemnification.
• Liability limitations.
• Regulatory cooperation.
• Exit assistance.
• Export of customer data.

8.5 Build an exit plan​

Vendor lock-in is a governance and resilience risk.

Maintain:

• Provider-neutral prompt interfaces.
• An AI gateway.
• Model abstraction.
• Portable evaluation suites.
• Exportable conversation data.
• Independent vector stores.
• Provider-neutral tool schemas.
• A fallback model.
• Tested migration procedures.

---

9. Secure On-Premises LLM Deployments​

On-premises deployment gives control but transfers responsibility to the organisation.

9.1 Physical security​

Protect:

• Data-centre access.
• GPU servers.
• Storage devices.
• Management ports.
• Backup media.
• Network equipment.
• Console access.

Use:

• Restricted access.
• Visitor logging.
• CCTV where appropriate.
• Asset inventory.
• Tamper controls.
• Secure media disposal.
• Separation of administrative zones.

9.2 Management-plane security​

GPU and AI clusters may include powerful out-of-band management interfaces.

Secure:

• Baseboard management controllers.
• IPMI or equivalent interfaces.
• Hypervisors.
• Cluster controllers.
• Kubernetes control plane.
• Image registries.
• Storage controllers.
• Firmware update services.

Management interfaces should be:

• On isolated networks.
• Accessible only through privileged access systems.
• Protected with MFA.
• Logged.
• Regularly patched.
• Denied direct internet access.

9.3 Workload isolation​

Separate:

• Development.
• Testing.
• Evaluation.
• Production.
• High-sensitivity workloads.
• Different business units.
• Different customers.

Use:

• Namespaces.
• Dedicated node pools.
• Network policies.
• Pod-security controls.
• Runtime sandboxes.
• Read-only filesystems.
• Non-root containers.
• Resource quotas.
• Seccomp or equivalent restrictions.
• Admission policies.
• Signed-image enforcement.

9.4 Network architecture​

A strong on-premises architecture typically includes:

• No direct internet access from inference nodes.
• Deny-by-default egress.
• An internal API gateway.
• Segmented storage networks.
• Separate management networks.
• Private model registries.
• Controlled update channels.
• Internal DNS controls.
• East-west traffic monitoring.
• Firewall rules based on application identity.

An air gap can reduce some external threats but may create new risks:

• Delayed patches.
• Manual transfer errors.
• Weak artefact provenance.
• Reduced telemetry.
• Difficult vulnerability management.
• Uncontrolled removable media.

An air-gapped system still needs a secure update and evidence-transfer process.

9.5 Availability engineering​

On-premises capacity is finite.

Plan for:

• GPU failure.
• Storage failure.
• Model-loading failure.
• Driver incompatibility.
• Power interruption.
• Cooling failure.
• Network partition.
• Capacity exhaustion.
• Disaster recovery.
• Replacement lead times.

Use:

• Capacity reservations.
• Health checks.
• Model replicas.
• Queues.
• Back-pressure.
• Priority classes.
• Load shedding.
• Tested backups.
• Alternative inference capacity.
• Smaller fallback models.

---

10. Secure Cloud LLM Deployments​

Cloud services operate under a shared-responsibility model.

The provider may secure the underlying physical infrastructure, but the customer remains responsible for matters such as:

• Identity configuration.
• Network configuration.
• Data classification.
• Application vulnerabilities.
• Prompt handling.
• Tool permissions.
• Logging.
• Retention.
• Tenant separation.
• Appropriate model use.

AWS explicitly applies its shared-responsibility model to Amazon Bedrock (AWS Shared Responsibility Model).

10.1 Private connectivity​

Where supported, use:

• Private endpoints.
• Private Link.
• Private Service Connect.
• VPC endpoints.
• VPN.
• Dedicated interconnect.
• Private DNS.
• Public-access disablement.

Microsoft documents private endpoints and disabling public network access for Azure OpenAI resources. Google documents Private Service Connect for Vertex AI (Azure OpenAI networking, Vertex AI networking).

However:

Private connectivity means traffic avoids the public internet. It does not necessarily mean the model is running inside your own tenant, that the provider cannot process the data, or that no third party is involved.

The service architecture and contract must still be reviewed.

10.2 Identity and access​

Prefer:

• Workload identities.
• Managed identities.
• Short-lived tokens.
• Role-based access.
• Attribute-based policies.
• Separate identities per application.
• MFA for human administration.
• Privileged access management.
• Regular access reviews.

Avoid:

• Shared API keys.
• Keys embedded in source code.
• Long-lived credentials.
• Production credentials in notebooks.
• One identity across multiple business units.
• Administrator credentials for inference.

10.3 Cloud account separation​

Separate:

• Development.
• Testing.
• Production.
• Regulated workloads.
• Security tooling.
• Shared services.
• Logging accounts.
• Backup accounts.

Use organisation-level controls such as:

• Service control policies.
• Resource policies.
• Region restrictions.
• Tagging requirements.
• Encryption requirements.
• Public-access prohibitions.
• Approved-model lists.

10.4 Cloud logging​

Capture:

• Authentication events.
• Administrative changes.
• Model invocation metadata.
• Policy decisions.
• Tool calls.
• Retrieval sources.
• Safety-filter results.
• Rate-limit events.
• Errors.
• Model-version changes.

Do not automatically log:

• Full prompts.
• Complete retrieved documents.
• Raw credentials.
• Personal information.
• Confidential model outputs.

Security logs should be useful without becoming a second ungoverned copy of sensitive data.

10.5 Region and data residency​

Confirm where each component processes and stores data:

• Model inference.
• Prompt storage.
• File upload.
• Vector storage.
• Fine-tuning.
• Logging.
• Content safety.
• Search grounding.
• Backup.
• Support.

A model endpoint being created in one region does not necessarily prove that every associated feature processes data only in that region.

---

11. Secure RAG Architectures​

Retrieval-augmented generation introduces a separate data-access system.

OWASP identifies vector and embedding weaknesses as a distinct risk because poor access controls or manipulated indexes can lead to unauthorised data access or retrieval manipulation (OWASP Top 10 for LLM Applications).

11.1 Preserve source permissions​

The retrieval layer must enforce the permissions of the source system.

If a user cannot access a document in SharePoint, a document-management system or a customer repository, the user should not gain access through the chatbot.

Use:

• Identity-aware retrieval.
• Tenant filters.
• Document ACLs.
• Metadata filters.
• Row-level security.
• Security trimming.
• Permission-aware caching.

11.2 Secure ingestion​

During ingestion:

• Authenticate the source.
• Scan documents.
• Validate file types.
• Reject encrypted or malformed files where appropriate.
• Extract metadata.
• Record provenance.
• Apply classification.
• Detect secrets.
• Detect personal data.
• Quarantine suspicious content.
• Require approval for sensitive sources.

11.3 Defend against retrieval poisoning​

Attackers may place documents containing:

• False information.
• Hidden prompt injections.
• Manipulated keywords.
• Instructions to reveal secrets.
• Links to malicious tools.
• Content designed to dominate retrieval.

Controls include:

• Trusted-source allowlists.
• Document signing.
• Ingestion approval.
• Source-reputation scoring.
• Recency controls.
• Duplicate detection.
• Anomaly detection.
• Instruction-content detection.
• Retrieval diversity.
• Source citation.
• Human review for high-impact answers.

11.4 Protect embeddings and indexes​

Protect vector databases with:

• Authentication.
• Tenant isolation.
• Encryption.
• Backups.
• Access logging.
• Index versioning.
• Deletion propagation.
• Rebuild procedures.
• Integrity checks.

Deleting a source document should trigger deletion from:

• Object storage.
• Chunk stores.
• Vector indexes.
• Search indexes.
• Caches.
• Evaluation corpora where applicable.

---

12. Secure Agentic Systems​

Agentic systems increase risk because the model can make repeated decisions, invoke tools and maintain state.

OWASP’s agentic security work emphasises threats involving compromised tools, excessive permissions, poisoned shared memory, insecure inter-agent communication and related risks (OWASP GenAI Security Project).

12.1 Introduce a tool broker​

Do not connect the model directly to critical systems.

Place a tool broker between the model and business applications.

The broker should:

• Authenticate the user.
• Authenticate the agent.
• Check the requested action.
• Verify the user’s authority.
• Validate parameters.
• Enforce transaction limits.
• Redact sensitive results.
• Require approval where necessary.
• Log the action.
• Return only minimum necessary data.

12.2 Use scoped tools​

Instead of providing a general database tool, provide narrow tools such as:

• get_order_status(order_id)
• create_refund_request(order_id, reason)
• draft_customer_email(case_id)
• schedule_appointment(customer_id, slot)

Avoid tools such as:

• execute_sql(query)
• run_shell(command)
• call_any_api(url, payload)
• manage_cloud_resource(action)

Narrow tools improve authorisation, validation, auditability and testing.

12.3 Separate read and write actions​

Use different credentials and workflows for:

• Reading information.
• Drafting an action.
• Approving an action.
• Executing an action.

For high-risk operations, use:

Model proposes → policy engine checks → human approves → deterministic service executes.

12.4 Control memory​

Agent memory should have:

• Explicit purpose.
• Defined schema.
• User and tenant ownership.
• Retention limit.
• Write validation.
• Source attribution.
• Integrity controls.
• Deletion support.

Do not allow arbitrary tool output or retrieved text to become trusted long-term memory.

---

13. Build Compliance into the Architecture​

13.1 Identify your regulatory role​

Depending on the jurisdiction and use case, the organisation may be:

• Model provider.
• AI-system provider.
• Deployer.
• Distributor.
• Importer.
• Data controller.
• Joint controller.
• Data processor.
• Subprocessor.

The role can differ across different parts of the same solution.

For example, an organisation may be:

• A customer of a foundation-model provider.
• A controller for employee data.
• A processor for a client’s customer data.
• A provider of a downstream AI application.

Document these roles rather than assuming “we are only using an API.”

13.2 Apply a risk-based regulatory classification​

Under the EU AI Act, obligations vary according to the system’s role and risk level. High-risk systems can require risk management, data governance, documentation, logging, human oversight, robustness, cybersecurity and accuracy. The European Commission states that the Act entered into force on 1 August 2024 and applies in phases, with broad applicability beginning on 2 August 2026 and specific exceptions or earlier obligations for prohibited practices and general-purpose AI (European Commission — AI Act).

Do not classify the foundation model alone. Classify the complete use case.

The same LLM could support:

• A low-risk internal writing assistant.
• A regulated employment-screening workflow.
• A high-impact credit-decision system.
• A customer-service chatbot.
• A clinical-support application.

The regulatory risk depends heavily on the intended purpose and downstream workflow.

13.3 Conduct a privacy impact assessment​

A privacy assessment should cover:

• Purpose.
• Lawful basis.
• Categories of data.
• Data subjects.
• Data sources.
• Necessity.
• Proportionality.
• Accuracy.
• Bias.
• Automated decisions.
• Human oversight.
• International transfers.
• Retention.
• Security controls.
• Individual rights.
• Vendor processing.
• Residual risk.

The UK ICO provides an AI and data-protection risk toolkit intended to help organisations reduce risks to individuals’ rights and freedoms (UK ICO — AI and data protection).

13.4 Address individual rights​

Design processes to support, where applicable:

• Access.
• Correction.
• Deletion.
• Objection.
• Restriction.
• Portability.
• Review of automated decisions.
• Explanation or meaningful information.
• Complaint and appeal.

This requires data lineage. The organisation must know where a person’s data exists across:

• Source systems.
• Prompts.
• Conversation stores.
• Vector indexes.
• Fine-tuning files.
• Logs.
• Backups.
• Evaluation datasets.

13.5 Manage copyright and intellectual property​

Review:

• Model licence.
• Dataset rights.
• Fine-tuning rights.
• Input ownership.
• Output ownership.
• Code-generation risks.
• Trademark risks.
• Confidential information.
• Provider indemnities.
• Redistribution rights.
• Attribution requirements.

Do not assume that because a model is publicly downloadable, every commercial use is permitted.

13.6 Apply sector-specific requirements​

Additional controls may apply in:

• Financial services.
• Healthcare.
• Insurance.
• Employment.
• Education.
• Telecommunications.
• Government.
• Critical infrastructure.
• Legal services.
• Children’s services.

Sector rules may affect:

• Recordkeeping.
• Model validation.
• Explainability.
• Outsourcing.
• Resilience.
• Human review.
• Data localisation.
• Supplier audits.
• Incident reporting.

---

14. Establish an AI Governance Operating Model​

14.1 Maintain an AI inventory​

Record every AI system, including unofficial or experimental systems.

The inventory should include:

• System name.
• Business owner.
• Technical owner.
• Intended purpose.
• Users.
• Affected individuals.
• Deployment pattern.
• Models used.
• Model versions.
• Data categories.
• Vendors.
• Integrations.
• Risk level.
• Regulatory classification.
• Approval status.
• Last review.
• Retirement date.

14.2 Introduce risk tiers​

A practical model could include:

Tier 1: Low risk​

Examples:

• Public-content summarisation.
• Internal brainstorming with no confidential data.
• Grammar assistance.

Controls may be lightweight.

Tier 2: Moderate risk​

Examples:

• Internal knowledge assistant.
• Customer-service drafting.
• Software-development assistance.

Requires formal data controls, evaluation and monitoring.

Tier 3: High risk​

Examples:

• Financial recommendations.
• Employee-related decisions.
• Customer eligibility.
• Regulated advice.
• Sensitive personal data.

Requires independent review, stronger human oversight, formal validation and executive risk acceptance.

Tier 4: Prohibited or exceptional​

Examples:

• Uses prohibited by law.
• Uncontrolled autonomous financial execution.
• Unsupported safety-critical decision-making.
• Covert manipulation.
• Unapproved biometric or surveillance uses.

14.3 Define accountability​

A useful RACI includes:

Business owner​

Accountable for:

• Business outcome.
• Appropriate use.
• Human process.
• Benefits realisation.
• Residual business risk.

Model or AI product owner​

Accountable for:

• Model selection.
• Evaluation.
• Versioning.
• Limitations.
• Monitoring.
• Model retirement.

Data owner​

Accountable for:

• Data quality.
• Access.
• Classification.
• Retention.
• Permitted use.

Security team​

Responsible for:

• Threat modelling.
• Architecture review.
• Security testing.
• Incident response.
• Vulnerability management.

Privacy and legal teams​

Responsible for:

• Regulatory roles.
• DPIA.
• Contracts.
• Data processing.
• Rights.
• Licence review.

Independent risk or assurance team​

Responsible for:

• Challenge.
• Validation.
• Audit.
• Control testing.
• Risk reporting.

14.4 Use stage gates​

Recommended gates include:

1. Use-case approval
2. Data approval
3. Vendor and licence approval
4. Architecture security review
5. Evaluation approval
6. Privacy and compliance approval
7. Production readiness
8. Change approval
9. Periodic recertification
10. Retirement approval

14.5 Maintain required documentation​

The minimum evidence pack should contain:

• System description.
• Intended use.
• Prohibited uses.
• Architecture.
• Data-flow diagram.
• Threat model.
• Model card.
• System card.
• Model bill of materials.
• Data-source register.
• Risk assessment.
• DPIA where applicable.
• Vendor assessment.
• Licence review.
• Evaluation report.
• Red-team report.
• Human-oversight design.
• Incident-response plan.
• Monitoring plan.
• Rollback plan.
• Approval records.
• Change history.

---

15. Apply Controls Across the AI Lifecycle​

NIST’s Generative AI Profile recommends managing generative-AI risks through the AI RMF functions Govern, Map, Measure and Manage. NIST’s Secure Software Development Framework can be used alongside this to integrate secure development practices into the AI lifecycle (NIST AI RMF Generative AI Profile, NIST SSDF).

Phase 1: Strategy and discovery​

Determine:

• Business problem.
• Intended users.
• Potential harm.
• Data sensitivity.
• Regulatory classification.
• Required level of autonomy.
• Need for on-premises or cloud deployment.
• Acceptable residual risk.

Do not start model procurement before understanding the use case.

Phase 2: Model and vendor selection​

Assess:

• Model capability.
• Security.
• Licence.
• Data handling.
• Region.
• Retention.
• Support.
• Explainability.
• Versioning.
• Cost.
• Portability.
• Vendor viability.

Phase 3: Architecture and design​

Produce:

• Data-flow diagram.
• Trust-boundary map.
• Threat model.
• Access model.
• Network design.
• Logging strategy.
• Human-oversight design.
• Failure-mode analysis.

Phase 4: Build​

Apply:

• Secure coding.
• Dependency scanning.
• Secret scanning.
• Artefact signing.
• Model verification.
• Dataset versioning.
• Infrastructure as code.
• Policy as code.
• Unit and integration tests.

Phase 5: Evaluation​

Evaluate:

• Task quality.
• Hallucination.
• Groundedness.
• Bias.
• Harmful content.
• Prompt injection.
• Data leakage.
• Tool misuse.
• Access-control bypass.
• Denial of service.
• Cost.
• Latency.
• Failover.

Use representative and adversarial datasets.

Phase 6: Production release​

Require:

• Approved model version.
• Signed artefacts.
• Production configuration.
• Monitoring.
• Rate limits.
• Incident procedures.
• Rollback.
• Support ownership.
• User communication.
• Final risk acceptance.

Phase 7: Operations​

Continuously monitor:

• Security incidents.
• Model quality.
• Data leakage.
• Policy violations.
• Cost.
• Model drift.
• Retrieval quality.
• Tool failures.
• User complaints.
• Provider changes.
• New vulnerabilities.

Phase 8: Retirement​

Retirement should include:

• Disabling endpoints.
• Revoking credentials.
• Deleting data.
• Removing embeddings.
• Archiving evidence.
• Destroying obsolete weights.
• Ending vendor access.
• Updating the AI inventory.
• Migrating dependent workflows.

---

16. Reference Architecture for a Secure Enterprise LLM Platform​

A secure architecture can be visualised as follows:

Important architectural principles​

1. The application never trusts the model as an authorisation engine.
2. The model does not receive unrestricted database credentials.
3. Retrieval preserves source-system permissions.
4. Tool execution is separated from model reasoning.
5. Sensitive data is minimised before model invocation.
6. Logging is useful but redacted.
7. Model versions are controlled.
8. Every high-impact action is attributable.
9. Every critical component has a fallback or fail-safe state.
10. Security policies are enforced outside the prompt.

---

17. Comparison of Deployment Patterns​

Area	Open-weight on-premises	Open-weight in customer cloud	Proprietary managed API	Proprietary private deployment
Infrastructure control	Very high	High	Low	High
Operational responsibility	Very high	High	Lower	Medium to high
Model transparency	Potentially high	Potentially high	Limited	Limited to medium
Data-path control	Very high	High	Contract and service dependent	High
Scalability	Hardware constrained	Cloud scalable	Provider managed	Contract and capacity dependent
Patching responsibility	Customer	Customer and cloud provider	Provider plus customer application	Shared
Supply-chain risk	High customer responsibility	High customer responsibility	Provider dependency	Shared
Vendor lock-in	Lower at model layer	Lower at model layer	Often high	High
Customisation	High	High	Feature dependent	Usually high
Upfront cost	High	Medium	Low	High
Audit evidence	Customer must generate	Shared	Provider assurance plus customer evidence	Shared
Primary concern	Operational maturity	Cloud configuration and model supply chain	Data handling and provider dependency	Complex shared responsibility

---

18. How to Choose the Right Deployment Model​

Use a risk-based decision rather than an ideological preference.

Choose open-weight on-premises when:​

• Data must remain within a controlled physical environment.
• External model calls are prohibited.
• Offline operation is necessary.
• Model customisation is strategically important.
• The organisation has mature platform, security and ML operations.
• Hardware capacity can be sustained.
• The model licence is acceptable.
• The organisation can patch and monitor the full stack.

Choose open-weight in the cloud when:​

• You need control over the model and data path.
• Elastic infrastructure is valuable.
• Cloud governance is mature.
• Private networking is available.
• You can secure containers, Kubernetes and model artefacts.
• Data residency can be satisfied.

Choose a proprietary managed API when:​

• Rapid access to high-performing models matters.
• The data is appropriate for third-party processing.
• Contractual and technical safeguards are acceptable.
• The provider offers suitable retention, residency and security controls.
• Infrastructure management is not a strategic capability.
• Vendor dependency is acceptable or mitigated.

Choose proprietary private deployment when:​

• A proprietary model is required.
• Data sovereignty is critical.
• The provider offers supported private deployment.
• The organisation can operate the required infrastructure.
• Contractual responsibility is clearly divided.
• Model updates and licence enforcement can be securely managed.

Use a hybrid model when:​

Different data classes and use cases have different requirements.

For example:

• Highly sensitive requests → private open-weight model.
• General drafting → managed proprietary model.
• Regulated customer decisions → specialised, validated model and deterministic rules.
• Public summarisation → lower-cost cloud model.

An AI gateway can route each request according to:

• Data sensitivity.
• User role.
• Jurisdiction.
• Use case.
• Cost.
• Model capability.
• Availability.
• Regulatory requirements.

---

19. Example: Regulated Customer-Service Assistant​

Consider a bank deploying a customer-service assistant.

Risks​

The assistant may process:

• Customer names.
• Account details.
• Transactions.
• Complaints.
• Vulnerability information.
• Authentication status.
• Financial circumstances.

It may also access:

• Product policies.
• Customer records.
• Complaint systems.
• Appointment booking.
• Fraud-reporting workflows.

Recommended design​

Data handling​

• Authenticate the customer before account-specific retrieval.
• Replace direct identifiers with temporary tokens.
• Send only necessary account fields to the model.
• Keep authentication credentials outside the model context.
• Apply short conversation-retention periods.
• Prevent sensitive prompts from entering general caches.

RAG​

• Separate public product information from customer-specific information.
• Enforce customer and employee permissions.
• Index only approved policies.
• Record policy version and effective date.
• Provide citations in responses.
• Rebuild indexes when policies change.

Tool use​

The model can:

• Retrieve an account balance.
• Draft a complaint summary.
• Propose an appointment.
• Create a fraud-report draft.

The model cannot independently:

• Transfer money.
• Change customer identity details.
• Approve credit.
• Close an account.
• Reject a complaint.
• Remove a fraud marker.

High-impact actions require deterministic checks and human approval.

Model routing​

• Public product questions may use a managed cloud model.
• Customer-specific questions may use a private endpoint.
• Highly sensitive investigations may use an on-premises model.
• Every route is controlled by data classification and policy.

Governance​

• The customer-service director owns the business outcome.
• The data owner approves source systems.
• Compliance approves customer communications.
• Model risk validates quality and bias.
• Security performs prompt-injection and tool-abuse testing.
• Operations monitors incidents and performance.

This hybrid architecture provides stronger protection than selecting one model and sending every request through it.

---

20. Minimum Enterprise Control Baseline​

Every production LLM deployment should have at least the following controls.

Governance​

• Named business owner.
• Named technical owner.
• AI inventory entry.
• Approved use case.
• Risk classification.
• Prohibited-use definition.
• Documented human oversight.
• Periodic review.

Data​

• Data-flow diagram.
• Data classification.
• Data minimisation.
• Retention schedule.
• Encryption.
• Access control.
• Deletion procedure.
• Prompt and log policy.

Model​

• Approved model and version.
• Model card.
• Licence review.
• Evaluation report.
• Known-limitations register.
• Change and rollback process.
• Model provenance.

Application​

• Input validation.
• Output validation.
• Prompt-injection testing.
• Rate limits.
• Tenant isolation.
• Secure retrieval.
• Tool allowlisting.
• Human approval for high-impact actions.

Infrastructure​

• Private connectivity where required.
• Least-privilege identity.
• Secret management.
• Vulnerability scanning.
• Signed artefacts.
• Monitoring.
• Backup.
• Disaster recovery.
• Network segmentation.

Supplier​

• DPA where applicable.
• Security assessment.
• Retention confirmation.
• Data-use confirmation.
• Subprocessor review.
• Incident-notification terms.
• Exit plan.
• Model-change process.

Assurance​

• Security testing.
• Red teaming.
• Privacy review.
• Compliance review.
• Audit logs.
• Incident-response exercises.
• Access reviews.
• Control evidence.

---

21. Common Mistakes to Avoid​

“The model is on-premises, so it is secure.”​

On-premises systems can still have:

• Weak administrator access.
• Unpatched GPU drivers.
• Unsafe model artefacts.
• Exposed management interfaces.
• Poor network segmentation.
• Inadequate monitoring.
• Insider risk.
• Insecure RAG indexes.

“The vendor does not train on our data, so privacy is solved.”​

Privacy also depends on:

• Retention.
• Human access.
• Subprocessors.
• Processing location.
• Legal basis.
• Data minimisation.
• User rights.
• Logging.
• Support access.
• Feature-specific storage.

“The system prompt contains our security rules.”​

System prompts are behavioural instructions, not reliable security boundaries.

Authorisation, transaction limits and access control must be enforced outside the model.

“RAG means the model only uses approved information.”​

RAG can retrieve:

• Incorrect documents.
• Outdated documents.
• Unauthorised documents.
• Poisoned documents.
• Prompt-injection content.

“Human in the loop makes the system safe.”​

Human review fails when:

• Reviewers are overloaded.
• Explanations are unclear.
• The interface encourages automatic approval.
• The human lacks authority or expertise.
• The model’s recommendation anchors the decision.
• Too many alerts create fatigue.

Human oversight must be designed as a control, not added as a label.

“Open weights mean there is no vendor risk.”​

Open-weight systems remain dependent on:

• Model publishers.
• Community packages.
• GPU vendors.
• Runtime projects.
• Container sources.
• Dataset suppliers.
• Cloud or hardware providers.

“A compliance certificate makes our application compliant.”​

A provider’s ISO or SOC report covers a defined provider control environment. It does not certify:

• Your prompts.
• Your business process.
• Your tool permissions.
• Your RAG data.
• Your human oversight.
• Your regulatory classification.
• Your application code.

---

Conclusion​

The security of an LLM deployment is not determined by whether the model is open or closed, or whether it runs on-premises or in the cloud.

Each approach changes who owns which risks.

Open-source and open-weight deployment provide control, customisation and portability, but require strong model-supply-chain security, infrastructure operations, patching and licence governance.

Closed-source managed models reduce infrastructure burden and may provide mature enterprise controls, but require careful assessment of data processing, retention, model opacity, contractual commitments, provider changes and vendor dependency.

On-premises deployment provides physical and network control, but makes the organisation responsible for the full operational stack.

Cloud deployment offers scalability and managed security capabilities, but requires disciplined identity, networking, data governance, configuration and shared-responsibility management.

The most effective enterprise approach is to:

1. Classify the use case and data.
2. Map the complete data flow.
3. Identify trust boundaries.
4. Separate model reasoning from authorisation and execution.
5. Apply controls to data, models, applications, infrastructure and suppliers.
6. Evaluate both normal performance and adversarial behaviour.
7. Maintain continuous governance, monitoring and evidence.
8. Select the deployment model based on risk rather than assumptions.
9. Preserve the ability to change models or providers.
10. Treat every LLM as one component within a governed business system.

The objective is not to eliminate all AI risk. The objective is to make risk visible, assign ownership, apply proportionate controls, maintain evidence and ensure the organisation can safely detect, respond to and recover from failures.