AI translation vendor security checklist: 10 questions to ask before you buy

Three years ago, security questions about translation tools came up maybe once a year, usually from a bank. Now they show up in ordinary sales conversations. Agencies tell us their clients want to know exactly what happens to a document after upload: which servers touch it, which AI models see it, how long it sits in storage, and who can read it along the way. If you buy an AI translation tool without those answers, you inherit the risk on your client's behalf. This AI translation vendor security checklist covers the ten questions we ask before trusting any tool, and the answers that should make you walk away.

Why an AI translation vendor security checklist beats gut feeling

Most agencies pick tools the way most people pick software: a trial, a few test files, a look at the pricing page. Output quality gets real scrutiny; many teams already run candidates through test documents and dedicated QA tools before committing. Security gets a glance at the vendor's trust page, if it gets anything at all.

That worked when translation tools were desktop software. It stops working the moment client content flows through third-party AI APIs. Your NDA with the client has no exception for subprocessors you forgot to ask about. If the vendor stores documents indefinitely on a server you've never heard of, that becomes your breach when it surfaces, not just theirs.

We watched one mid-sized agency lose a pharmaceutical prospect over exactly this. The client's procurement team sent a standard security questionnaire. One item asked which AI services would process their content and under what data terms. The agency couldn't answer, because its MT setup had grown organically: some projects went through a paid API, some through whatever free tool each linguist preferred. The deal died there. Not because the agency had leaked anything, but because it couldn't demonstrate control.

A written checklist fixes the asymmetry. Vendors publish marketing pages, not data flow diagrams, so unless you ask precise questions you get reassuring generalities. Asking every vendor the same ten questions gives you comparable answers, a paper trail for your own clients' audits, and a fast way to tell the vendor who has thought about this from the one improvising on the call.

One limitation up front: a checklist is not legal advice. If you handle regulated content, medical records, or financial disclosures, run the vendor's answers past a lawyer before signing. The checklist tells you what to ask. It doesn't tell you what your specific contracts require.

Questions 1–3: where your documents actually go

1. Which subprocessors handle our document content?

Every AI translation vendor sits on top of other companies: a cloud host, one or more LLM providers, maybe an OCR service, an email provider, an error-tracking tool. Under GDPR Article 28, a vendor processing personal data on your behalf must have written agreements with its subprocessors and be able to name them. Ask for the current subprocessor list. A vendor that can't produce one either hasn't documented it or doesn't want you to see it. Both are answers.

2. Is our content used to train AI models?

This is the question your clients will ask you, so get it in writing. The answer usually splits by access type. Major API providers state that content sent through their APIs is not used for model training by default, while consumer-facing free tools often reserve broader rights in their terms. A vendor built on API access can usually pass that guarantee through to you, but "we use OpenAI" is not the same as "your data is excluded from training under our agreement with OpenAI." Ask for the exact clause in their terms that covers it.

3. Where is the data processed?

Geography matters for EU clients and anyone under data residency obligations. If document content leaves the EU for processing, the transfer needs a legal basis such as standard contractual clauses. You don't have to become a privacy lawyer here. You need the vendor to name the processing regions and the transfer mechanism, in writing, so you can hand that answer to a client's DPO instead of guessing.

Questions 4–5: data retention and deletion

4. How long is our content stored, and can we change that?

Every tool stores something: uploaded files, translated output, logs, sometimes cached segments. What matters is the default retention window, whether it's configurable, and whether the answer covers all the places content lives. Application databases are the easy part. Backups, LLM provider logs, and error-tracking snapshots are where retention promises quietly fail. Some API providers offer zero-retention arrangements for eligible customers; if your clients need that level, ask whether the vendor actually has one in place rather than assuming.

5. What happens when we ask you to delete a project?

Deletion sounds binary. It rarely is. We sat in on a vendor call with an agency where the vendor confirmed, confidently, that deletion was immediate. Pressed on backups, the story changed: deleted records persisted in encrypted backups for another 90 days. That's a defensible design, but it's a different answer, and the agency's government client needed the real one. They ended up negotiating a contract addendum that stated the full deletion timeline, and it satisfied the client's auditor precisely because it was specific.

Ask for the deletion timeline including backups, whether deletion is self-serve or requires a support ticket, and what confirmation you receive when it completes. If the vendor offers a data processing agreement, retention and deletion terms belong there, not in an email thread you'll never find again.

Questions 6–7: what SOC 2 and ISO 27001 actually tell you

6. Do you have a SOC 2 report, and is it Type II?

SOC 2 is an audit framework from the AICPA that examines how a company handles security, availability, and confidentiality. Type I says the controls existed on a single day; Type II says they operated over a period, usually six to twelve months. Type II is the one that means something. Ask to review the report under NDA and read the scope, because a report covering the marketing website but not the translation pipeline tells you little.

Smaller vendors often don't have SOC 2 yet, since audits cost real money. That isn't automatically disqualifying. A small vendor that answers the other nine questions precisely, in writing, can be a safer bet than a large one waving a three-year-old certificate. Treat certification as evidence, not as the verdict.

7. Which certifications and laws actually apply to you?

Two things to untangle here. ISO 27001 certifies an information security management system, and like SOC 2 its value depends on scope, so ask what the certificate covers. ISO 42001, published in late 2023, does the same for AI management systems and has started appearing in enterprise procurement requirements for AI vendors.

GDPR works differently: there is no official GDPR certificate, so "GDPR compliant" on a website is a claim, not a credential. The practical test is whether the vendor will sign a data processing agreement, name its subprocessors, and support data subject requests. A vendor that advertises full compliance but has no DPA on offer has answered your question, just not the way they intended.

Questions 8–9: who can see your documents and how keys are stored

8. Who at your company can access customer documents?

Somebody at the vendor can read your files. That's almost always true: support staff debugging a failed job, engineers investigating an error. The real question is whether that access is controlled and logged. Ask whether support access requires customer consent, whether it's recorded in an audit log, and whether contractors face the same scrutiny as employees. Vendors with real controls answer this quickly because they've been asked before. Long pauses are data.

9. How do you protect stored API keys and credentials?

This one matters most when the tool follows a BYOK model, where you bring your own OpenAI or other LLM API key. BYOK has real advantages for agencies: your translation traffic runs under your own agreement with the model provider, which simplifies the training and retention questions above and gives you direct usage visibility. It also means the vendor stores a credential that can spend your money. Ask how keys are encrypted at rest, who can decrypt them, and whether the key ever appears in logs or error reports.

If you're still deciding which engine to put behind that key, we compared the main options in our piece on DeepL API vs OpenAI API vs Google Translate. The security answer and the quality answer are separate decisions, and it helps to make them separately.

Question 10: what happens when something goes wrong

10. Describe your last security incident and how you handled it.

Not "do you have an incident response plan." Everyone says yes to that. Ask them to walk you through a real incident, or a tabletop exercise if they've never had one. You're listening for specifics: how it was detected, who was notified, what changed afterward.

There's a regulatory floor underneath this. Under GDPR, a processor must notify the controller without undue delay after becoming aware of a personal data breach, and controllers have 72 hours to report qualifying breaches to their supervisory authority. Your contract should reflect that chain, because a vendor's slow notification becomes your slow notification to your client.

In practice, "without undue delay" is vague enough to argue about, so ask the vendor to commit to a concrete notification window in the contract, 24 or 48 hours from awareness is common, and to name the channel they'll use to reach you. An incident email sent to a generic inbox nobody monitors satisfies the letter of the agreement and fails you completely. Agencies with several tool subscriptions keep a small internal register of who to contact at each vendor when something breaks, which sounds bureaucratic until the day it saves an afternoon of panicked searching.

How the vendor answers is signal in itself. In our experience the trustworthy answer sounds slightly boring: dates, process, a postmortem. The worrying answer is confident and vague, "we take security extremely seriously," with no mechanics behind it. Teams that have thought hard about failure describe it comfortably. Teams that haven't, reassure.

A related check that costs nothing: look for a public status page and a security contact, such as a security@ address or a disclosure policy. Their absence proves nothing, but their presence usually correlates with a vendor that expects to be held accountable.

How to use the checklist without stalling your procurement

None of this needs to add weeks to buying a tool. The agencies that run this well send the questions to the vendor before or during the trial, not after they've already fallen for the product. Written answers arrive while you're testing output quality, and by decision time you have both halves of the picture.

Here are the ten questions in one place, ready to paste into your vendor evaluation document:

1. Which subprocessors handle our document content?
2. Is our content used to train AI models, and where is that stated in your terms?
3. In which regions is our data processed, and under what transfer mechanism?
4. What is the default retention window, and is it configurable?
5. What is the full deletion timeline, including backups?
6. Do you have a SOC 2 Type II report we can review under NDA?
7. Which certifications apply (ISO 27001, ISO 42001), what is their scope, and will you sign a DPA?
8. Who at your company can access customer documents, and is that access logged?
9. How are stored API keys and credentials protected?
10. Describe your most recent security incident or tabletop exercise.

Score the answers on a simple scale: documented, verbal only, or no answer. Anything load-bearing should be documented. Attach the written responses to the contract, then re-run the checklist once a year and after any major architectural change the vendor announces, because subprocessor lists change more often than contracts do.

The payoff arrives the next time a client sends you a security questionnaire. Instead of a scramble across email threads and support chats, you forward answers you already hold. One agency we know now includes its vendor security answers in every enterprise proposal by default. On at least one bid, that page was the difference: they were the only bidder who could say where the client's documents would go.