Yes. Your translation business needs a short AI usage policy if you or your subcontractors use machine translation or AI with client work. It should state which jobs allow AI, which tools and accounts are approved, what information may be submitted, and who checks the translation before delivery.
This is a practical recommendation, not a claim that every translator has the same legal duty to publish a policy. A client contract may forbid machine translation even when a tool protects the text. A client may also permit it while still expecting you to take full responsibility for the finished translation.
The awkward job your policy must answer
Imagine a freelance translator receives a 900-word brochure at 16:00, with delivery due the following morning. The agency's instruction says “human translation”. The translator plans to use an AI draft, rewrite every sentence and submit polished copy. Would the agency consider that acceptable?
Without a written rule, both sides can think they have followed the brief. The translator may understand “human” to mean human-checked. The agency may have promised the client that no machine translation would be used. A strong final translation cannot resolve that mismatch after delivery.
Your policy should make the answer visible before anyone opens the file in an external tool. In this illustrative job, the instruction becomes: “No machine translation or generative AI processing of source text, reference files or translated text. Ask the project manager before using any automated language service.” Separately explain whether ordinary spelling checks and existing translation memories are allowed.
A translation memory is a collection of previously translated passages that can be reused. A computer-assisted translation tool, often shortened to CAT tool, helps translators work with those passages, terminology and project files. Do not treat every CAT function as AI. Equally, do not assume a familiar translation workspace has no external AI connection. Record what the actual workflow sends out.
For general staff conduct, start with the broader small-business AI policy guidance. The translation-specific work is deciding what your service promises mean at the point a translator starts a job.
Separate client permission, tool approval and release
These are three different decisions. Combining them into “AI approved” leaves gaps. Put three separate fields in the job brief, even if that brief is just a shared document.
| Decision | Evidence to record | What stops the job |
|---|---|---|
| Client permission | Contract or written instruction allowing the specified use | A prohibition, conflicting instructions or unclear permission |
| Tool and data approval | Exact service, account, permitted data and person approving it | An unapproved account or information outside its approved scope |
| Release approval | Named reviewer, checks completed and final file version | Unresolved meaning, terminology or formatting questions |
A paid tool does not supply missing client permission. A signed client instruction does not tell you how a supplier handles uploaded files. A successful upload does not establish translation quality. Require all three decisions for each relevant job.
Filled in for one routine job, the three fields fit in a few lines at the top of the brief (illustrative):
JOB 2611: kitchenware catalogue, 3,200 words, delivery Fri 12:00
Client permission: Machine translation plus full post-edit allowed
for catalogue text only (client email 14 Oct, saved in job folder).
Not allowed: the warranty insert (file 04), human translation only.
Tool and data: Agency's paid machine translation account, document
upload. Permitted: files 01-03 and the client glossary v6.
Not permitted: file 04, the client's pricing sheet.
Approved by: project manager, 15 Oct.
Release: Reviewer: second translator (in-house). Checks: meaning
against source, glossary terms, all numbers and units, layout in
the delivered file. Final file: 2611_catalogue_FINAL_v2.pdfThe detail that earns its place is the "not permitted" line in each field. Most mistakes on mixed jobs like this come from the one file that follows different rules, and a brief that names it stops it travelling with the rest.
The exact service matters. DeepL's privacy policy distinguishes its free translation service, where submitted content is processed to train and improve its systems, from DeepL Pro, where submitted texts are not used to train or improve its systems. Do not approve “DeepL” as a single, unspecified entry on your tool list.
Read the terms for the product and feature you will actually use. Include document uploads, saved glossaries and any connection through another supplier. For the detailed supplier checks, use the tutorial on putting client documents into AI translation tools. If client confidentiality terms or personal information make approval uncertain, involve your solicitor or data-protection adviser before uploading.
A four-person agency writes rules around twelve jobs
Here is an illustrative planning exercise. A four-person translation agency reviews its next twelve assignments: eight routine sales documents, two equipment safety documents and two contracts. It also uses three freelance translators. The owner wants a policy that works for all seven people without turning every routine sentence into an approval request.
The project manager checks the client instructions first. Six sales documents allow an approved machine-assisted process. Two have no clear instruction, so the agency requests clarification before using AI. It keeps the safety documents and contracts on a specialist human-led route while their client requirements and review arrangements are checked. That is a choice for this agency, not a universal ban on using technology for those document types.
For the six approved jobs, the brief names the approved service and account, the permitted source files, the client glossary and the reviewer. Freelancers must acknowledge the brief before receiving the full files. They cannot substitute a personal account because the agency's account is inconvenient or unavailable.
The owner reserves three hours of internal work: 45 minutes to inspect contracts and job types, 45 to write the rules, 30 to check the proposed tools, 30 to discuss examples with the team, and 30 to test the job brief. At an assumed internal cost of $35 an hour, that is $105 of staff time. Supplier subscriptions, specialist advice and linguistic review are separate costs. Three hours is a planning allowance for this example, not a promise that every policy can be completed that quickly.
During the first week, allow another five to ten minutes per job to complete the approval fields and resolve questions. That means 60–120 minutes across twelve jobs. Some of this replaces informal messages rather than adding entirely new work. Measure the difference instead of claiming it as a saving.
Suppose the pilot reveals that one freelancer cannot access the approved account and one brochure contains an unapproved client reference file. Both jobs pause before upload. The useful result is that the rule catches the uncertainty early. Do not measure success only by how many translations were produced faster.
After the pilot, the agency keeps a default route for the six routine jobs and an exception route for everything else. The project manager owns exceptions; the reviewer owns linguistic release. This prevents one person saying “the tool was approved” when another person asks who approved the finished wording.
A short policy with enough detail to use
The following is illustrative wording for that agency. Replace the role names, scope and approved-tool reference before using it. Have relevant client obligations checked rather than assuming a generic policy overrides them.
Purpose and scope. These rules apply to employees and subcontractors working with source text, translations, terminology lists, reference documents and client correspondence. They cover machine translation and generative AI, including services accessed through other translation software.
Job permission. Use AI only when the job brief records that the specified use is permitted. A missing field means ask the project manager. “Human translation” assignments follow the client's agreed definition; do not introduce an AI draft without written clarification.
Approved tools. Use only the service, account and features listed for the job. Do not switch to a personal or free account. Send only the information needed for the approved task. Keep unrelated client files out of the submission.
Client separation. Use only reference material authorised for the current client. Do not combine client glossaries, translation memories or examples into a shared AI resource without separate approval.
Review and release. A competent translator checks source meaning, terminology, numbers and omissions. Check the delivered layout too. Record the reviewer and final version. AI output must not be sent directly to the client without the agreed review.
Exceptions and incidents. Stop if instructions conflict, the approved service is unavailable or information goes to the wrong account. Tell the project manager promptly. Record what happened without copying confidential material into another unapproved service.
Records and review. Store the approval record with the job. Handle source files, outputs and working copies under the agreed retention schedule. Review this policy when client terms, tools or delivery methods change, and at the agency's scheduled quarterly review.
Keep the approved-tool list separate so you can update a product or account without rewriting every sentence. Include an owner and review date on both documents. An entry that says “approved last year” is weak evidence if the service, subscription or connection has changed.
For release checks beyond the policy wording, use a defined machine translation post-editing workflow. Post-editing means checking and correcting a machine-produced translation against its source, not merely making the result read smoothly.
Numbers are where smooth-reading output hides the worst errors, which is why the policy's review clause names them. In the catalogue job above, say the source language writes a full stop as its thousands separator, and the source lists a trolley's load capacity as "1.500 kg". An illustrative machine draft keeps the figure exactly as it was, so the English copy reads "Load capacity: 1.500 kg", which an English reader takes to mean one and a half kilograms. Nothing about the sentence looks wrong, and a reviewer reading for fluency will pass it. The reviewer who catches it is running a mechanical check: list every number in the source, list every number in the translation, and compare the two lists for count, value, separator and unit. Add a line to the approved-tool list for each language pair saying which separator convention applies, so the check isn't left to memory.
Three small decisions that need explicit wording
“No AI” must include the subcontractor's first step
Consider an illustrative 1,400-word laboratory procedure sent to a subcontractor. The brief prohibits machine translation, but the subcontractor's usual project setup includes an external pre-translation step. They have not consciously pasted anything into a chatbot, yet the process may still send the document outside the agreed route.
Add a job-start check: “Confirm that external AI and machine translation connections are not used for this assignment.” Ask the freelancer to describe the workflow, not just promise to “use AI responsibly”. If they cannot confirm what happens, hold the source files until the question is resolved.
A glossary can disclose more than a name
In a second illustrative case, a translator copies 38 approved product terms into a general reference list. Seven terms describe an unreleased spare part. Removing the client's name does not make those terms public. A future job could also inherit terminology that belongs to the wrong product.
The policy response is to keep the glossary in the authorised client or project location and record its permitted uses. Do not merge it into a general resource simply because the individual terms look harmless. Keep a separate, deliberately approved list for genuinely reusable public terminology. The tutorial on maintaining consistent translation terminology covers the working process.
Client wording should describe the service you will deliver
A vague illustrative quote says: “We may use AI to improve efficiency.” The client cannot tell whether that means brainstorming a public heading or submitting a confidential document to an external supplier.
A more useful version says: “For the three approved catalogue files, we propose machine translation using the service named in the project brief, followed by full review against the source by a translator. We will use your approved terminology list. The separate warranty document is outside this proposed process.”
This is a description for discussion, not a complete contractual clause. Ask the client to confirm the scope through your normal written approval process. Keep any required supplier agreement and data-processing arrangements separate. Do not call this “consent” as though one reply settles every possible data-protection question.
Test the rules when a deadline goes wrong
Run a short rehearsal with a fictional document. The approved service is unavailable, delivery is in two hours, and a freelancer offers to use their own account. A working policy produces an immediate answer: contact the project manager, use an approved fallback or renegotiate the deadline. It should not leave the freelancer to guess.
Then test an accidental upload. For example, a translator realises that a reference file went to the wrong service. Ask them to stop further processing, record the time, service, account and document category, and alert the named owner. Follow the supplier's deletion process where appropriate. Keep a record of actions, but do not promise that deleting a chat reverses every consequence of the upload.
The owner should assess the client commitments and seek advice on any notification duties. Staff should not improvise legal conclusions or quietly conceal the mistake. Keep the reporting route easy enough that people use it promptly.
At the end of the first month, inspect five completed jobs. Can you find permission, the approved tool route, the reviewer and the exact delivered version? Include one subcontracted job and one exception. If the evidence is missing, simplify the job brief or clarify who fills it in.
For the four-person agency, that first inspection might come out like this: three jobs complete on all four points; one subcontracted job with permission and tool recorded but no named reviewer, because the freelancer delivered straight to the project manager, who forwarded it; and one exception where the approval was given by phone and never written down. Neither is a scandal, and both are exactly what the check is for. The fixes are small: the brief template gets a "reviewer" field that can't be left blank before delivery, and the project manager agrees to confirm phone approvals with a one-line email saved to the job folder.
You do not need a long document to achieve this. You need rules that answer the actual choices a translator makes, and a record showing those choices were checked before client work left the business.
Further reads
- How Small Translation Agencies Build an AI-Assisted Workflow — Fit your policy into quoting, translation and delivery.
- Is Machine Translation Good Enough for Client-Facing Documents? — Decide which documents are suitable for machine translation.
- AI Acceptable Use Policy for a Small Professional Firm — Cover AI use beyond your translation work.
- How to Roll Out an AI Policy So Staff Actually Follow It — Make the rules usable during a busy working day.
- AI Translation vs Human Translators: What Documents Really Cost — Budget for review as well as the first draft.
- AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.
Sources: DeepL Privacy Policy, sections on free services and DeepL Pro, reviewed 27 September 2026. All agency scenarios, timings and costs are illustrative.