A defensible translation file contains six things: a hash of the exact source document, the method used to produce the draft including engine and version, the glossary or term base version applied, the identity and qualification of the reviewer, the changes made at review, and a dated sign-off. Retain those and you can answer the only questions a regulator or auditor actually asks — who is accountable for this text, and could you produce it again the same way. Retain none of them and the strength of the translation itself becomes irrelevant, because nothing about it can be evidenced.
This guide covers what goes in each field, why supervisors frame the question as accountability rather than automation, and what it costs to assemble this after the request arrives rather than before.
The Six Records, and What Each One Answers
Treat these as columns in a register, not as a document. Each exists to close a specific line of questioning.
Record | The question it closes |
|---|---|
Source hash | Was this translated from the document you are showing me? |
Method, engine and version | How was the draft produced, and can that be reproduced? |
Glossary version | Which terminology decisions were in force at the time? |
Reviewer identity and qualification | Who is accountable, and were they competent to be? |
Changes made at review | Was the review real, or nominal? |
Date and sign-off | When did this become the approved version? |
Six fields, all machine-capturable, all small. A register covering three years of a bank's regulatory filings fits comfortably in a spreadsheet. The reason organisations do not have one is almost never storage cost — it is that nobody owned the decision to start.
Source Hash: Fixing Which Text Was Translated
The hash looks like the most technical field and is the least interesting to compute and the most useful to have. Take a SHA-256 of the source file at the moment it enters the workflow and store the digest with the record.
Its job is to defeat a specific and common failure: the source document changed after translation and nobody noticed. A schedule was updated, a signature page was swapped, a revised annex went out under the same filename. Eighteen months later you are asked whether the German version corresponds to the executed English original, and without a digest the honest answer is that you believe so.
Two practical notes. Hash the file you actually translated, including any pre-processing output such as OCR text extracted from a scan, and record both digests if they differ. And store the source file itself, not only its hash — a digest proves identity, but it cannot reconstruct a document you have deleted.
Method, Engine and Version: The Repeatability Field
Record what produced the draft, at a level of detail that would let a competent person reproduce it: the platform, the model or engine identifier, its version, and the configuration that materially affects output — glossary enforcement on or off, formality setting, source language declared rather than detected.
This is where teams over-think the privacy angle and under-record the substance. Naming your engine in an internal register is not a disclosure risk; it is the field that turns "we translated it with AI" into a statement with content. Engines change constantly, and a document translated in March 2025 cannot be regenerated identically in 2027 unless you know which version ran.
If your process maps to ISO 18587, the standard covering post-editing of machine translation output, say so and say which post-editing level you applied. Do not cite ISO 17100 for this workflow — that standard excludes machine-translation post-editing from its scope, and an auditor who knows the standards will notice.
Glossary Version: The Field Everyone Omits
Terminology decisions are the substance of regulated translation, and they move. A defined term is agreed, a statutory citation convention is settled, a party name is fixed, and three months later someone adds forty entries for a new matter.
Without a version stamp, a discrepancy between two documents translated six months apart looks like an error. With one, it is a documented change in a controlled resource — a different conversation entirely. Version the term base, stamp the version into the record, and keep the entry history: who added a term, when, and on whose authority. Export in an interchange format such as TBX under ISO 30042 so the resource is not trapped in a vendor's database.
This is also the record that makes glossary enforcement worth paying for. Terminology control in legal and financial translation covers how the enforcement itself works; the versioning is what makes it evidence.
Reviewer Identity, Qualification and What Changed
Two fields that belong together, because one without the other is weak.
Identity means a named individual, not a vendor. "Reviewed by a certified language services provider" answers nothing; a supervisor cannot examine a company. Record the person, their working languages, their relevant qualification or bar admission, and their relationship to you — employee, contractor, vendor staff.
The change record is the field that distinguishes review from rubber-stamping. Retain the redline, or at minimum a count and category of edits: terminology corrections, numeric or figure corrections, mistranslations, formatting repairs. A file showing a reviewer who consistently returns documents with zero changes is worse than no record at all, and it is a pattern that internal audit finds quickly.
Categorised edits earn their keep twice over. They evidence review, and in aggregate they tell you where your pipeline is actually weak — which language pairs, which document types, which terminology gaps.
Why Supervisors Ask About Accountability, Not Automation
There is a persistent belief that a regulator's first question will be whether AI touched the document. In examination practice the questions run the other way: who is responsible for this output, and what controls sit around the process that produced it.
That framing is visible in the instruments themselves. The GDPR is built on an accountability principle — you must be able to demonstrate compliance, not merely achieve it — and requires records of processing activities. DORA obliges financial entities to maintain a register of information covering contractual arrangements with ICT third-party providers, which is precisely what a translation platform is. The NIST AI Risk Management Framework organises itself around govern, map, measure and manage rather than around permitted techniques.
None of these prohibits automation. All of them ask you to show your working. A machine-first workflow with a complete register is a stronger position than a human-only workflow with nothing retained — and teams that grasp this stop arguing the wrong case.
The Retrofit Problem
The cost curve here is unforgiving, and it is the reason to build the register before you need it.
Assembling the record contemporaneously costs close to nothing: the workflow already knows the file, the engine, the glossary version and the reviewer, and writing six fields to a log is a background task. Assembling it after a request means interviewing people about work they did two years ago, reconciling filenames against email threads, guessing which glossary was live, and asking a reviewer to confirm from memory that they checked something. Some of it is unrecoverable, and the gaps are exactly where the questioning concentrates.
A related thread on how IT teams evaluate document translation services shows the procurement version of the same lesson: the questions that get asked before approval are the ones that would be painful to answer afterwards. The teams that come out of an audit cleanly are not the ones with the best translations. They are the ones who decided, before anything went wrong, that the record was part of the deliverable.
Making the Record a By-Product
The design goal is that nobody has to remember to do this. If producing the audit record is a separate task, it will be skipped under deadline pressure, which is when it matters most.
Practical shape: the platform emits the source hash, engine, version and glossary version automatically at job completion; the reviewer's sign-off in the review interface writes identity, timestamp and edit summary; the record lands in a register keyed on document ID with retention matched to the underlying document, not to the translation. Bluente exposes this through its document translation API, so the metadata flows into your own matter-management or GRC system rather than living in a tool your auditor has never heard of.
Then test it. Pick three documents from last quarter and try to reconstruct their provenance from the register alone. Whatever you cannot answer is the field you are missing, and you have found it in a dry run instead of a deadline.
Sources and Further Reading
DORA — digital operational resilience for the financial sector
Document translation services, r/sysadmin — what IT and procurement teams ask before a translation tool is approved
Related Reading
Last reviewed 24 August 2026 by the Bluente document engineering team, who build and test the pipeline described here. This describes published regulatory instruments and standards in general terms and is not legal advice; your obligations depend on your sector, jurisdiction and supervisor.
The record costs nothing while the work is happening and a great deal afterwards. Try BluTranslate free.