A client sends an agency a contract for urgent translation, with names, signatures, pricing and a draft acquisition plan still inside. An employee pastes the whole file into an AI translation website to get a first draft. The translation may be useful, but the agency has already made a separate decision: it has sent client material to a third-party service.
That decision needs a confidentiality check before the upload, not an explanation after a client asks who could see the document. An AI translation tool can process, retain or use submitted content under terms that differ from the agency’s own expectations. A familiar brand name or a privacy-friendly setting doesn’t answer whether the client authorised that particular use.
For an agency, the practical question isn’t simply whether machine translation is accurate. The question is whether the proposed workflow is permitted, necessary and controlled: what information goes out, which provider receives it, what the provider can do with it, and who inside the agency can access the result.
The checklist below turns those questions into decisions staff can apply to individual files. It doesn’t replace legal advice or a review of the agency’s contracts. It gives project managers and translators a repeatable way to spot issues and pause a job before confidential material reaches an unapproved service.
What uploading a client document to AI translation means¶
An AI translation upload is a processing event because the document leaves the agency’s immediate working environment and reaches a provider’s service. The provider may receive more than the words to translate: the file can contain names, contact details, metadata, comments, tracked changes, signatures or information that identifies people through context.
An agency doesn’t avoid responsibility just because a staff member clicked the upload button or because the service describes its process as automated. GDPR roles depend on what each organisation does with personal data. Where the agency determines the purpose and means of processing and a supplier processes data on its behalf, the processor relationship needs review.
The contract between the agency and its client matters alongside the provider’s terms. A privacy setting cannot grant permission that the client never gave. An NDA, service agreement, project instruction or sector rule may restrict disclosure to third parties, cloud services or subcontractors, even when the agency believes the vendor has strong safeguards.
The GDPR principles offer a useful starting point. Article 5(1)(c) says personal data must be “adequate, relevant and limited to what is necessary” for its purpose. Article 5(1)(e) sets a storage limitation principle, and Article 5(1)(f) requires appropriate security. The GDPR text in force as of February 2026 provides the legal wording; agencies should check applicable amendments and national law before relying on it.
The GDPR says personal data must be “adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed.”
That principle has a direct operational consequence: don’t send an entire client file if the translation task needs only an extract. Remove unnecessary identifiers and material, and keep the purpose of the upload clear. Minimising the file doesn’t remove the need for permission or vendor checks; it reduces the amount of data exposed if the processing is permitted.
A useful way to explain the risk to staff is to separate three questions. First, is the content confidential or personal? Second, is this particular provider allowed to receive it for this purpose? Third, are the provider’s processing and retention terms acceptable for this client and project? A yes to one question doesn’t settle the others.
A translation upload can expose more than the sentence being translated¶
A source file often carries information that isn’t visible in a clean text extract. Word comments can name reviewers; tracked changes can preserve deleted language; document properties can include an author; a scanned page can show a signature or an address in a margin. A contract appendix may identify a person even if the main text uses a code name.
Consider a client asking for a translation of a short letter. The letter itself may contain only a reference number, but a page header might reveal a hospital, legal firm or business unit. Uploading the full file to preserve layout can expose those details unnecessarily. A safer workflow asks what the translator and tool actually need, then removes or masks material that doesn’t contribute to the translation.
Client concern about who works on a document isn’t theoretical. In a LinkedIn post describing a client’s concern, a translation professional reproduced the words:
“It’s highly confidential and we want to know who’s seeing and working on the document”
The comment is an individual anecdote, not survey evidence, but it captures a useful test for agency procedures: can the project manager explain who can see the source file, including providers and subcontractors? If the answer is unclear, the team doesn’t yet have a defensible upload decision.
The agency’s pre-upload confidentiality checklist¶
A checklist works only if staff can use it before they send a file. Build a short intake step into quoting or project setup, then require a pause when a document falls outside the agency’s approved categories. Keep the decision record with the project rather than relying on someone’s memory of a vendor page.
- Confirm the client’s permission. Check the service agreement, project instructions and NDA for limits on cloud processing, subcontracting or disclosure. Ask the client when the wording is unclear. A tool’s configuration cannot amend the agency’s contract.
- Classify the material. Record whether the file contains personal data, sensitive or restricted information, privileged material, confidential business information or a combination. Use the client’s classification where one exists.
- Check the intended purpose. State why the file would go to AI translation: a draft for human post-editing, a terminology check or another defined task. Don’t use client content for unrelated experiments.
- Minimise the source. Send only the pages, fields and identifiers needed for the translation. Remove redundant metadata, comments and unrelated attachments where the project permits.
- Check the specific product and account. Consumer and business plans, API services and document features may have different terms. Verify the exact service the employee will use, not just the provider’s general privacy statement.
- Review processor and subprocessor arrangements. Identify the legal entity handling the data, its subprocessors and their roles. Check that the contract describes the processing and safeguards needed for the agency’s situation.
- Check location and transfers. Record where the service processes or stores data and what safeguards apply if data moves across borders. A provider’s headquarters alone doesn’t answer where processing happens.
- Confirm retention and deletion. Find out what happens to the source, translation, logs and backups after the task. Record deletion timing and whether the agency can control or request deletion.
- Set access and review controls. Limit internal access to the project team, keep the result in approved storage and require a human to check the translation before delivery.
- Record approval and escalation. Log the provider, tool version or service, project classification, permission basis, reviewer and any exception. Route uncertain or high-risk cases to the person responsible for privacy or legal review.
The sequence matters. A vendor review doesn’t override a client’s restriction, and redaction doesn’t turn an unauthorised upload into an authorised one. Start with the contract and data classification, then decide whether the vendor and workflow fit.
GDPR Article 28(1) requires a controller to use processors that provide sufficient guarantees to implement appropriate technical and organisational measures. The European Data Protection Board’s Opinion 22/2024, adopted in October 2024, discusses obligations connected with processors and subprocessors. Agencies should confirm current supervisory guidance and assess the provider rather than treating marketing language as proof.
What should the vendor review record contain?¶
A compact record makes recurring reviews easier and gives a project manager something concrete to check. Capture the provider’s legal entity, relevant service, processing purposes, subprocessors, processing locations, transfer safeguards, retention and deletion behaviour, permitted use of submitted content, security controls and the date the terms were checked.
The EDPB’s 2024 opinion says controllers should have the identity and contact details of processors and subprocessors readily available, and processors should proactively provide and keep that information current. A vendor list that names only a parent company or hides downstream providers behind a vague description may not give the agency enough information to assess the chain.
Separate confirmed facts from unanswered questions. For example, a record can state that the provider’s published terms explain retention, while marking deletion of backups as unconfirmed. That distinction stops an assumption from becoming an internal “fact” simply because it has been copied into a checklist.
A clear record also helps when a provider changes terms or adds a subprocessor. Assign someone to review material changes and keep the project team informed. If a service’s terms change, re-check whether the approval still fits the client contract and the agency’s data classification.
How to assess the tool, account and processing terms¶
A translation tool’s name isn’t enough to approve an upload. Providers may offer a free consumer service, a paid business product, an API and document features under different conditions. The agency should inspect the terms for the exact product and account in use, and retain the version or date checked.
Read the data processing agreement (DPA) alongside the service terms. A DPA is a contract setting out how a provider processes personal data for a customer. The agency should check whether the parties’ roles are described correctly and whether the agreement covers the processing the team plans to perform. A DPA doesn’t make every use of a service appropriate: client permission, purpose, lawful basis and security still matter.
Review the following points in plain language:
- Permitted use: Can submitted source text, translation output or prompts be used to train or improve services, or for another purpose? Does the answer differ between products or account types?
- Retention: How long does the provider hold submitted content, results, logs and backups? Does deletion happen automatically, on request or under different rules for different data?
- Subprocessors: Which organisations can access or process the content? Can the agency see their names and locations, and how will it learn about changes?
- Processing location: Does the provider state where each part of the service is processed? Can the customer select a region, and does that setting cover the feature actually used?
- Transfer safeguards: If personal data moves across borders, what contractual or legal safeguards apply? Ask the privacy lead to assess whether those safeguards fit the agency’s situation.
- Security controls: Check access management, encryption, organisational controls and the provider’s process for handling security incidents. Look for details that can be assessed, not assurances without supporting terms.
- Deletion and return: Confirm what the agency can delete, when deletion takes effect and what happens to copies the service keeps for operational reasons.
- Product scope: Confirm whether the review covers text translation, file translation, glossaries, user accounts and any connected storage or collaboration feature.
Provider differences matter. A free text box and a business API may not have the same retention or data-use rules. One provider may state that content is used only to return a translation, while another service may describe temporary processing for service improvement. Don’t assume that the word “AI” or “translation” implies one standard privacy model.
Is a service’s statement that it doesn’t train on uploads enough?¶
No. A no-training statement answers a limited question about one possible use of submitted content. It doesn’t by itself tell the agency who processes the file, where processing occurs, how long data is retained, which security controls apply or whether the client permits disclosure.
A vendor may also distinguish between products. Staff need to check the exact service name, plan and workflow rather than applying a statement about one API to a free website or a different feature. Keep a copy of the relevant terms or a dated review note so the approval has an evidence trail.
A careful review doesn’t need to guess what a provider does behind the scenes. It should record what the provider says, where the statement appears and which questions remain open. If key terms are missing, contradictory or hard to verify, pause the upload and choose a workflow whose conditions the agency can assess.
How should agencies handle cross-border processing?¶
A cross-border workflow can involve more than the provider’s main office. Processing may take place in a different region, and subprocessors may operate in other locations. Record the relevant locations and transfer safeguards from the vendor’s current documentation, then assess them against the client’s terms and applicable law.
A location setting may apply only to a specific endpoint or product tier. Don’t infer that choosing a region controls every feature, log or support process. Ask the provider to explain what the setting covers, and don’t upload restricted material until the agency can confirm that the chosen service meets the requirement.
The EDPB Opinion 22/2024 is relevant to processor and subprocessor oversight, but it isn’t a substitute for a service-specific review. Record the question, evidence and decision; escalate uncertain transfer issues to the agency’s privacy or legal contact.
Minimise and protect documents without breaking the translation¶
Data minimisation means sending only the information needed for the stated task. GDPR Article 5(1)(c) sets that principle; it doesn’t say that an agency should remove context that the translator needs to produce a correct result. Redaction must balance privacy with linguistic meaning and document integrity.
A practical method is to separate the source into necessary content and avoidable identifiers. If a contract clause can be translated without a person’s full name, replace the name with a stable placeholder such as [PERSON_A]. If account numbers aren’t needed for grammar or terminology, remove or mask them. Keep a protected mapping between placeholders and original values inside the agency’s controlled environment.
Stable placeholders matter because repeated names need to remain consistent. Replacing a company name one way on the first page and another way later can confuse the translation or its reviewer. Maintain a substitution list locally, limit access to it and restore the original details only after the translated text has been checked.
Metadata deserves its own check. Before submission, inspect comments, tracked changes, document properties, hidden sheets, headers, footers and attachments. Exporting a clean copy can help, but the person preparing it should confirm that the output still contains all text needed for the translation. A file that looks clean on screen may still include hidden content.
Anonymisation and pseudonymisation aren’t interchangeable. Removing direct identifiers may still leave context that allows someone to identify a person. A rare job title, location, event and date can point to an individual when combined. Treat redacted text as potentially identifiable unless the agency has assessed the risk of re-identification.
GDPR Article 5(1)(e) says personal data should be kept in identifiable form for no longer than necessary for its processing purpose, subject to the regulation’s exceptions.
For an agency, the principle applies to the whole workflow, not just the upload screen. Keep source files and translations only for the period needed for the project, contractual duties and applicable legal obligations. Set deletion responsibilities for working copies, exported files and local placeholder maps, and make sure staff know which approved storage location to use.
A recurring edge case is a document that can’t be usefully redacted. A medical report, legal pleading or signed declaration may rely on names, dates and relationships throughout. If removing those details would undermine accuracy, don’t create a false sense of safety by masking a few fields. Route the file to an authorised workflow that can handle its classification and contractual restrictions.
Build approval into the agency workflow¶
A confidentiality checklist shouldn’t live only in a policy folder. Put it where staff make the upload decision: intake, project assignment or a tool-use approval step. The person handling the file should be able to answer whether the client permits AI or cloud processing, which classification applies and which service is approved for it.
Use a tiered rule rather than a blanket “AI allowed” policy. Ordinary material may fit an approved service after a routine check. Contractually restricted, privileged or highly sensitive material should go only through a workflow explicitly authorised for that class. If a project’s classification is unclear, hold the file and ask the project manager or privacy lead to decide.
The European Commission says AI Act Article 4 requires providers and deployers to take measures supporting AI literacy among staff and others who operate or use AI systems on their behalf. The Commission’s AI literacy FAQ, checked as of February 2026, reports that Article 4 entered into application on 2 February 2025. Agencies should check the latest FAQ and any legal amendments before relying on that information.
The European Commission says Article 4 requires “a sufficient level of AI literacy of their staff and other persons dealing with AI systems on their behalf.”
Training can turn that broad duty into practical habits. Show staff how to distinguish approved accounts from consumer tools, recognise restricted content, strip unnecessary metadata, use placeholders and escalate unclear permissions. Explain how to check retention and where to record an approval. Training should match employees’ roles and experience, not assume everyone understands the same technical terms.
Human review remains part of the confidentiality process. A reviewer should check that placeholders have been restored correctly, that sensitive information hasn’t been copied into comments or notes, and that the final document is stored and shared through the approved route. Translation review doesn’t repair an unauthorised upload, but it can catch handling errors before delivery.
What should happen when a provider or project changes?¶
An approval is tied to a specific workflow, not to a provider name forever. Re-check the decision if the provider changes its terms, adds a subprocessor, changes a processing location, introduces a new feature or alters retention. Re-check it as well when the client changes its instructions or the project receives a new type of document.
Set an escalation route for a suspected disclosure or misdirected upload. Staff should know whom to contact, what facts to preserve and how to stop further sharing. The agency should follow its incident process and relevant legal and contractual duties; the checklist is not a substitute for that response.
Keep the review record proportionate. A simple project may need a short note linking to an existing vendor approval. A restricted or unusual document may need a documented decision by the person responsible for privacy or legal review. The record should say what was approved, for which purpose and under which conditions.
An agency can also make the policy easier to follow by maintaining a short approved-tools register. The register should identify permitted services and account types, the data categories each may handle, the review date and the person responsible for updates. A staff member shouldn’t have to infer approval from an old email or from a colleague’s personal account.
The most common practical failure is a mismatch between policy and habit. A rule may prohibit free tools, yet staff may paste a paragraph into a personal account because a deadline is close. Make the approved route accessible, explain why the restriction exists and give people a clear way to request an exception. A prohibition without a usable process encourages workarounds.
Common confidentiality mistakes and how to avoid them¶
A frequent mistake is treating a provider’s privacy page as the agency’s permission. The vendor can describe its own processing, but it can’t decide whether a particular client has agreed to that processing. Check the agreement and project instructions first; ask the client when the terms don’t answer the question.
Another mistake is approving a provider once and assuming every product works the same way. A free web service, an enterprise account and an API may have separate retention, training, location and contractual terms. Record the actual product and account, not merely the provider’s name.
Redacting a name and calling a file anonymous creates another risk. Context can identify someone even when direct identifiers are gone. A contract describing a unique transaction or a clinical report describing an uncommon event may remain identifiable. Use “pseudonymised” or “redacted” where appropriate, and don’t claim anonymity without a real assessment.
Agencies also sometimes focus on text while overlooking the file. Comments, tracked changes, metadata and attachments can disclose information that doesn’t appear in the main body. Add a file-cleaning step before upload and check the exported version rather than assuming that a quick visual scan is enough.
A retention promise doesn’t automatically mean the agency can forget about its own copies. Source documents may remain in a project folder, local downloads or email attachments after the service deletes its copy. Assign responsibility for agency-side storage and deletion as well as vendor-side retention.
Finally, don’t confuse translation quality with permission. A tool can return a fluent draft while the upload still violates a client restriction. Translation accuracy, confidentiality, lawful processing and contractual permission are separate checks. A good workflow records each decision instead of allowing one successful result to stand in for all of them.
Before the team sends its next document, ask one simple question: can the project manager explain what leaves the agency, who receives it, why the upload is allowed and when the data will be removed? If the answer is incomplete, stop and resolve the gap before proceeding.
FAQ¶
Can a translation agency upload client documents to free AI translation tools?¶
Only after checking the provider’s current terms, the client contract, any NDA and the applicable legal basis. Free and paid services can have different data-use rules, so a free tool shouldn’t be treated as suitable by default.
What should an agency check in an AI translation tool’s data processing agreement?¶
Check the provider’s legal entity, processing instructions, security measures, subprocessors, processing locations, transfer safeguards, retention and deletion rules, incident arrangements and permitted use of submitted content. Confirm that the agreement covers the exact service and workflow the agency plans to use.
Does GDPR require a data processing agreement with an AI translation provider?¶
Where a provider processes personal data on the agency’s behalf, GDPR processor requirements apply. The agency should confirm the parties’ roles and required contractual arrangements for its specific workflow.
How can an agency anonymise client documents before machine translation?¶
Remove unnecessary identifiers and metadata, and replace names or account numbers with stable placeholders where translation quality permits. Treat the result as potentially identifiable unless re-identification risk has been assessed.
What should an AI translation confidentiality checklist include?¶
Include client permission, data classification, minimisation, vendor and subprocessor review, processing location, transfer safeguards, retention, access controls, human review and a clear incident route. Keep a record of who approved the workflow and what conditions apply.