The EU AI Act is Coming: Is Your Translation Vendor Ready or Faking It?

The EU AI Act entered into force in August 2024 and its obligations are phasing in through 2026. Most coverage focuses on foundation models, biometric surveillance, and social scoring. Almost none of it mentions machine translation. That is a problem, because translation tools sit directly in the path of regulated AI use for any organization that operates across languages in the European Union.

If your company translates contracts, HR documents, medical records, or customer communications with an AI-powered tool, the AI Act applies to you. Not theoretically. Operationally. The question is whether your current vendor can help you meet those obligations or whether they are hoping you will not ask.

What the EU AI Act actually requires and why translation tools are in scope

The AI Act is a horizontal regulation. It does not list specific products. It classifies AI systems by risk level and assigns obligations based on that classification. Machine translation systems are AI systems under the Act's definition in Article 3(1): software that generates outputs such as text for a given set of objectives, using techniques including machine learning and statistical approaches.

Most translation tools will fall into the limited-risk or general-purpose AI categories rather than the high-risk annex. But that does not mean they escape regulation. Articles 50 and 52 impose transparency obligations on all AI systems that interact with natural persons or generate content. And the moment a translation tool processes personal data, employment records, legal documents, or health information, the deployer's obligations under the AI Act compound with existing GDPR requirements.

The practical consequence is this: organizations deploying AI translation are "deployers" under the Act. Deployers must understand what the system does, how it processes data, what risks it introduces, and whether they can explain all of that to regulators and data subjects. Your translation vendor is the "provider." The burden of enabling your compliance falls on them. If they cannot answer basic questions about their system's architecture, data handling, and training practices, they are transferring regulatory risk to you.

For a structured breakdown of how these requirements map to translation workflows, see our EU AI Act compliance documentation.

The "no training on your data" requirement as a risk reducer

One of the most consequential questions under the AI Act is whether an AI system learns from the data it processes. Article 53 requires providers of general-purpose AI models to document training data, including summaries of the content used. Article 10 imposes data governance requirements on training datasets for high-risk systems. Both provisions create a direct exposure for any translation vendor that feeds customer content back into model training.

This is not a hypothetical concern. Several major translation platforms have historically reserved the right to use customer translations to improve their models. Some still do, buried in terms of service that few procurement teams read carefully. The risk is compounding:

1. GDPR exposure. If customer content contains personal data and enters a training pipeline, the vendor may be processing that data beyond its original purpose, triggering Article 6 and Article 9 issues under GDPR.
2. AI Act transparency failure. If the vendor cannot clearly document whether your data influenced model training, you cannot meet your deployer obligations under Article 26.
3. Loss of confidentiality. Training data can surface in model outputs. A vendor that trains on your legal contracts creates a channel for information leakage to other customers.

The cleanest architectural answer is a strict no-training guarantee: the vendor processes your content for translation and discards it. No fine-tuning, no feedback loops, no corpus retention. This is not a nice-to-have. Under the AI Act's transparency and documentation requirements, it is the simplest way to limit your regulatory surface area.

At noll, we made this decision at the architecture level. Customer content is never used for training. It is processed, delivered, and deleted. There is no ambiguity to explain to a regulator because there is no ambiguity in the system.

Transparency: what you must be able to explain

Article 13 of the AI Act requires that high-risk AI systems are designed to be sufficiently transparent for deployers to interpret outputs and use the system appropriately. Article 50 extends transparency obligations more broadly, requiring that persons are informed when they interact with AI-generated content.

For translation, this means your organization should be able to answer several concrete questions:

1. Processing architecture. Does the vendor use a single model or route content to multiple providers? If content is sent to third-party APIs like Google, DeepL, or OpenAI, each subprocessor adds a link to the compliance chain.
2. Data retention. How long does the vendor retain source text and translations? Is retention configurable? Can you verify deletion?
3. Subprocessor disclosure. Under GDPR Article 28, processors must disclose subprocessors. Under the AI Act, the chain extends further. If your vendor routes content to a foundation model provider, that provider's training practices, data handling, and geographic processing all become relevant to your risk assessment.
4. Output provenance. Can you determine whether a given translation was machine-generated, human-reviewed, or a hybrid? Article 50(2) requires marking AI-generated content in certain contexts.
5. Data minimization. Is the vendor collecting metadata, usage patterns, or content beyond what is necessary for the translation service?

These are not aspirational questions. They are the minimum baseline for a deployer conducting due diligence under the AI Act. If your vendor cannot answer them clearly, with documentation, that is itself a finding.

We publish our full data handling practices, including exactly what we collect, what we do not, and why, in our transparency and data minimization documentation. We believe every translation vendor should do the same.

Vendor checklist for AI translation under the EU AI Act

When evaluating a translation vendor for AI Act readiness, these are the questions that matter. Not marketing claims. Documented, verifiable answers.

Data handling

1. Does the vendor train on customer content? Is there a contractual guarantee, not just a policy page?
2. What is the data retention period for source text and translations? Is it configurable per customer?
3. Where is content processed geographically? Are there EU-only processing options?
4. Does the vendor use subprocessors for translation? If so, which ones, and what are their data handling practices?

Transparency and documentation

5. Can the vendor provide a system description compliant with AI Act documentation requirements?
6. Does the vendor disclose the AI models used, including version and provider?
7. Is there a mechanism to mark outputs as AI-generated for downstream compliance?
8. Does the vendor publish a subprocessor list and notify customers of changes?

Risk management

9. Has the vendor conducted a conformity assessment or risk assessment relevant to AI Act obligations?
10. Does the vendor maintain logging sufficient for your internal audit requirements?
11. What incident response process exists if a data handling or model behavior issue is identified?
12. Does the vendor carry cyber liability insurance that covers AI-related regulatory actions?

Contractual protections

13. Does the data processing agreement explicitly address AI Act obligations, or only GDPR?
14. Is there an indemnification clause for regulatory penalties arising from the vendor's non-compliance?
15. Can the contract be terminated without penalty if the vendor changes its data handling practices materially?

No vendor will score perfectly on every point today. The AI Act's obligations are still phasing in. But the difference between a vendor that can answer these questions substantively and one that deflects or refers you to a generic privacy page is the difference between a partner and a liability.

How to operationalize compliance: policy and procurement

Awareness is not compliance. Compliance is operational. Here is how to move from understanding the AI Act's requirements to embedding them in your translation workflows.

Step 1: Classify your translation use cases

Not all translation carries the same risk. A marketing blog post and an employment contract have fundamentally different regulatory profiles. Map your translation workflows by content type, data sensitivity, and regulatory context. This classification determines which AI Act obligations apply and at what intensity.

Step 2: Update your procurement criteria

Add AI Act readiness to your vendor evaluation framework. The checklist above is a starting point. Weight the criteria by your organization's risk profile. For regulated industries like finance, healthcare, and legal, data handling and subprocessor transparency should be non-negotiable.

Step 3: Amend your data processing agreements

Most existing DPAs were written for GDPR. They do not address AI-specific obligations like training data governance, output marking, or system documentation. Work with legal to add AI Act-specific clauses. If your vendor resists, that tells you something.

Step 4: Establish internal governance

Designate responsibility for AI translation compliance. This might sit with legal, IT security, or a dedicated AI governance function. The point is that someone owns it, monitors vendor compliance, and escalates issues.

Step 5: Document and audit

The AI Act emphasizes documentation throughout. Maintain records of your vendor assessments, risk classifications, and compliance decisions. Conduct periodic audits, at least annually, to verify that vendor practices have not changed and that your internal controls remain effective.

The organizations that treat the AI Act as a procurement and governance exercise rather than a legal emergency will be the ones best positioned when enforcement begins in earnest. The regulation rewards preparation. It penalizes improvisation.

We built noll to make this straightforward. No training on your data, full subprocessor transparency, EU processing, configurable retention, and documentation you can hand to a regulator without rewriting it first. That is not a feature list. It is what compliance-ready translation infrastructure looks like.