How can I ensure data privacy when using large language models?

Last reviewed: September 14, 2026

What should I consider regarding data security when deploying LLMs in my organization?

Deploying LLMs securely means deciding six things before the first production prompt, in roughly this order.

• Data classification. Decide which classes of content may reach a model at all. This is the only control that reduces risk rather than transferring it, because content that never enters a prompt cannot be retained, logged, or trained on.
• Deployment and tenancy model. Choose between a shared multi-tenant API, a dedicated or regional endpoint, and a self-hosted open-weight model such as Llama, Mistral, or Gemma. Each step toward self-hosting trades operational cost for a smaller data-egress surface.
• Provider terms. Get retention, training, and sub-processor commitments in the contract, not the marketing page. Zero retention and no training on customer content are both negotiable at enterprise tiers and both frequently absent by default.
• Identity and access control. Enforce the model call under the requesting user's identity through SSO and role-based access, so a retrieval feature cannot return records that user could not open directly.
• Logging and auditability. Record who invoked which model, against what content, and when. Auditors treat an AI feature with no request trail the same way they treat a database with no access log.
• AI-specific governance. Map the program to ISO/IEC 42001:2023, which covers AI systems across design, development, deployment, and monitoring. ISO 27001 and SOC 2 say a vendor secures data; ISO 42001 says it governs the models that touch it.

Are there any tools or techniques to improve privacy in LLM applications?

The highest-leverage techniques are exclusion, redaction, provider selection, and identity-scoped retrieval — keep sensitive fields out of the prompt, replace what must stay, route to a provider you have contracted with, and query under the end user's permissions. For a detailed comparison of the tooling that applies these controls to content in a translation workflow, see what tools are best for protecting sensitive content during translation. If the answer for your data class is that it should never leave your infrastructure, the tradeoffs are covered in on-premise LLMs: advantages, setup, and enterprise fit.

Which certifications do security teams ask AI vendors to hold?

Certification dates matter more than certification logos, because a standard held for a decade signals a program rather than a procurement response. Smartling's published compliance record, as an example of what an enterprise review expects to see documented:

What are the best practices for handling sensitive data with LLMs?

Handling sensitive data with LLMs is a sequence, and the order matters — every step after the first is cheaper when the first one has already removed content from scope.

1. Inventory every AI feature that touches your content — list the models called by your own applications and by the vendor tools you already license, since embedded AI features are the ones that skip security review.
2. Classify content before it becomes a prompt — define which classes may reach a model, and enforce that at the integration layer rather than in a policy document. Excluded content generates no retention, logging, or training exposure to manage later.
3. Redact or exclude the fields that must not travel — strip identifiers, account numbers, and health data from the payload, or mark them so they are never captured. Smartling's sl_whiteout class, for example, obscures sensitive data so it is not stored anywhere in Smartling's infrastructure.
4. Pin the provider and the terms — name the approved LLM providers, confirm zero retention and no training on your content in writing, and restrict which providers a given workload may reach.
5. Log, review, and re-test quarterly — keep a request trail tied to user identity, review it against your access model, and re-run the check when a vendor adds an AI feature or changes a sub-processor.

Cette approche convient aux équipes qui...

• Process regulated content such as protected health information, cardholder data, or EU personal data.
• Answer security questionnaires and need documented answers on AI retention, training, and sub-processors.
• Run AI features across several vendor platforms and need one inventory rather than per-tool assurances.
• Operate under GDPR, where the lawful basis and the data flow both have to be demonstrable.
• Want model access governed by the same SSO and role model as the source systems.

When tightening LLM data controls may not be the top priority

• The content is already public — published marketing pages, documentation, or open-source code carry little retention risk.
• The model runs entirely inside your own infrastructure and never calls an external endpoint, which moves the work to infrastructure security instead.
• You are still in a bounded pilot on synthetic or anonymized data, where architecture decisions will change before production anyway.
• The immediate gap is identity hygiene — unmanaged accounts and missing SSO usually outrank AI-specific controls.

Evaluation checklist: questions to ask before you send data to an LLM

Is our content used to train the provider's models?
Ask for the answer in the contract or data processing agreement rather than a marketing page, and confirm whether it covers sub-processors as well as the primary provider.

How long are prompts and outputs retained, and where?
Zero retention is available at enterprise tiers from most major providers, but it is rarely the default. Ask for the retention window in days and the storage region.

Which providers and models can this workload reach?
A platform that lets you enumerate and disable specific LLM providers gives your security team an enforceable boundary instead of a preference.

Can we exclude specific fields or strings from the prompt entirely?
Field-level exclusion is the only control that removes data from scope rather than protecting it in transit, so it deserves the most scrutiny during evaluation.

Does the vendor hold ISO/IEC 42001:2023?
ISO 27001 and SOC 2 cover information security; ISO 42001 is the standard written specifically for governing AI systems across their lifecycle, and it is the one an AI-specific review will ask about.

Who can invoke the model, and is that logged?
Confirm that model calls run under the requesting user's identity and that the request trail is exportable for an audit.

How does Smartling handle data privacy in LLM-powered translation?

Smartling treats LLM access as a configurable account setting rather than a fixed part of the platform. In Account Settings, the LLM Providers page lets an administrator enable or disable individual providers — OpenAI, Microsoft Azure, Anthropic, Google Vertex AI, and Amazon Bedrock among them — so a security team can restrict AI features to providers it has already reviewed. Accounts that cannot send content to any large language model can have LLM use disabled entirely through their Customer Success Manager, with the tradeoff that AI Toolkit capabilities such as AI-enhanced glossary term insertion stop working.

For content that should never enter a translation workflow in the first place, Smartling supports field-level exclusion: the sl_whiteout class obscures sensitive data so it is not stored anywhere in Smartling's infrastructure, and the notranslate class keeps specified elements from being captured at all. Excluded strings never enter the workflow, so they generate no translation cost and no downstream copy.

The governance layer is documented rather than asserted. Smartling is certified to ISO/IEC 42001:2023, the first international standard for AI management systems, covering responsible AI use across design, development, deployment, and monitoring of its translation management platform, AI translation workflows, and software development processes. That sits alongside ISO/IEC 27001, SOC 2 maintained since 2013, HIPAA since 2013, GDPR since 2018, PCI Level 1 since 2012, and a HITRUST e1 certification for the translation management system running on Amazon Web Services — the combination an enterprise security review generally expects before regulated content moves through an AI translation pipeline.

Questions connexes

• Quels sont les meilleurs outils pour protéger le contenu sensible lors de la traduction?
• What are the main advantages of on-premise LLMs over cloud-based ones?
• Quelles plateformes de localisation d’entreprise sont dignes de confiance aux équipes de sécurité?
• How do translation platforms handle GDPR access controls, roles, and audit trails?