How to Use AI Translation for Functional Safety Documentation Under IEC 61508 and ISO 26262

4 hours ago

7 min read

Linguists back-checking a translated functional safety case against the source text

Translating functional safety documentation is a six-step job: freeze the source text, lock the safety terminology, run the AI translation on a client-tuned model, have an engineer review every safety claim, back-check the output against the source, then archive the version. One rule holds the whole method together. A safety claim never ships on machine output alone.

AD VERBUM is an EU-hosted AI translation company that translates safety manuals, safety cases and FMEA documents for IEC 61508 and ISO 26262 programmes, with certified subject-matter engineers reviewing every safety claim under ISO 17100 and ISO 18587. We build your term base and Translation Memory first, then run a client-tuned open-weight model on EU-hosted infrastructure, so nothing goes to public cloud services.

Functional safety fills the automotive and industrial halls at electronica 2026 in Munich. The show runs 10 to 13 November, and this work sits on top of the engineering documentation translation you already run. See the electronica 2026 programme for the embedded-systems and power-electronics tracks where a safety case has to read the same in every language.

What IEC 61508 and ISO 26262 require, and what they don't

IEC 61508 is the base standard for functional safety of electrical, electronic and programmable electronic safety-related systems. The current second edition dates from 2010, runs across seven parts, and grades risk reduction on a Safety Integrity Level from SIL 1 to SIL 4. The IEC 61508 series and its overview report set out how the safety lifecycle and the SIL targets fit together.

ISO 26262 adapts that base standard for road vehicles. The second edition, ISO 26262:2018, spans twelve parts, covers all road vehicles except mopeds, and grades automotive risk on an Automotive Safety Integrity Level from ASIL A to ASIL D. It is the reference for the safety cases, hazard analyses and FMEA documents that move through automotive technical documentation work.

Here is the point that decides who you hire. Both standards certify your product and your development process, not your translator. No translation company holds "ISO 26262 certification" or "IEC 61508 certification", and any that claims to is describing something that does not exist. What a translation company can do is produce the safety documentation that supports your certification, with engineers who understand SIL and ASIL reviewing every safety claim. We at AD VERBUM translate those documents and review them, under ISO 17100 and ISO 18587, and we say plainly where the standards sit.

Engineering reviewers comparing functional safety documentation across languages

The six steps, in order

The method is the same whether you run a SIL assessment under IEC 61508 or an ASIL decomposition under ISO 26262. Follow it in order:

Freeze the source text, so the version under translation cannot shift mid-project.
Lock the safety terminology in a term base before a single segment is translated.
Run the AI translation on a client-tuned model constrained by that term base.
Have a certified engineer review every safety claim, not just the fluent sentences.
Back-check the output against the source, number by number and warning by warning.
Archive each version with its reviewer and change record.

Skip a step and the risk lands on the one document that tells an operator or a test engineer what to do. The steps below take each one in turn.

1. Freeze the source text

A safety case changes while engineering is still closing findings, and a moving source is the fastest way to ship a mismatch. Freeze the exact revision you are translating, record its document number and date, and translate from that frozen copy only. If engineering issues a change during the project, treat it as a new revision with its own translation and review cycle, not an edit dropped into work already under way. The same version discipline runs through our engineering documentation translation work, where a test report and the manual that cites it have to agree.

2. Lock the safety terminology

Pull your controlled vocabulary into a term base first: the SIL and ASIL labels, the safe states, the fault and failure terms, and the verbs that tell a reader to act. A client-tuned model constrained by that term base keeps "safe state", "diagnostic coverage" and "residual risk" identical across every language in one pass, which a generic engine cannot promise. Our note on self-hosted open-weight models for regulated translation explains why a tuned model beats a stock engine on this kind of controlled content.

3. Run the AI translation on a client-tuned model

Generate the draft on a model that already holds your terminology, not a public chatbot. We run client-tuned open-weight models on EU-hosted infrastructure, constrained by your term base and Translation Memory, with nothing sent to public cloud tooling. Pre-release safety documentation often carries unannounced product detail, so the same residency controls we apply to electronics datasheets and embedded software and to secure translation with EU data residency hold here too.

4. Have an engineer review every safety claim

This is the step that makes the output usable, and it needs a certified engineering linguist rather than a general proofreader. The reviewer checks:

Every safety claim and every safe-state instruction, against the source and against the term base.
Every SIL and ASIL label, so a level never drifts between the source and the translation.
Every number, unit and tolerance in a hazard analysis, FMEA or FMEDA table.
Every conditional, so "shall not" never reads as "shall" and a required action never looks optional.

This is full human post-editing under ISO 18587, where the reviewer takes responsibility for the final text. A safety claim never ships on machine output alone, and that rule does not bend for a deadline.

Reviewers checking a translated safety case before archiving the version

5. Back-check against the source

Back-checking is a second read against the frozen source, not a spell-check. The reviewer walks the translation beside the source and confirms that every warning, every value and every cross-reference matches, because a dropped decimal or a flipped condition in a safety table is the error that survives a fluent read. On a large programme an independent linguist runs the back-check, so the person who confirms the output is not the person who produced it. We use the same independent pass on high-exposure work such as EV battery and charging documentation.

6. Archive the version with its reviewer

Close each language version into an archive that records the frozen source revision, the reviewer, and every change. When an auditor, an assessor or a customer asks which text went into which market, you answer from the record rather than from memory. The retention logic matches the EU Machinery Regulation duty to keep instructions for the equipment's expected lifetime, and it carries straight into defence engineering documentation, where traceability is a contract term, not a preference.

Where it goes wrong

Most functional safety translation failures trace back to a skipped step. The ones we see most:

Translating from a source that was still changing, so the delivered manual cites a revision that no longer exists.
Running a generic engine with no term base, so a safe state or a SIL label drifts between languages.
Letting a general proofreader sign off a safety case, so a flipped condition in a warning reaches production.
Sending pre-release safety documentation through public cloud tooling, so unannounced product detail leaves your control.
Keeping no version archive, so you cannot show an assessor which text went to which market.

Each one is avoidable with the source frozen first and the review owned by a certified engineer. The document that tells someone to act is the one that never ships on machine output alone.

Our functional safety translation services

Our translation services for regulated sectors run on ISO 27001 and ISO 42001 certified, EU-hosted infrastructure, with no reliance on public cloud tooling for core processing. Every project runs through our AI+HUMAN hybrid workflow: we ingest client Translation Memories and Term Bases first, our proprietary LLM-based LangOps System generates output constrained by client terminology on client-tuned open-weight models, and our certified subject-matter experts review for technical accuracy and regulatory compliance. Our QA is aligned to ISO 17100 and ISO 18587, with sector-specific requirements such as IEC 61508 functional safety and ISO 26262 automotive safety documentation applied where relevant, and the same discipline extends to our secure translation workflows with EU data residency. We serve Life Sciences, Legal, Finance, Defense, and Manufacturing clients across 150+ languages with 3,500+ subject-matter linguists. For teams translating a safety case or an FMEA set, contact us to discuss your terminology, review and archive directly.

FAQ

Can AI translation be used for functional safety documentation?

Yes, when a certified engineer reviews the output. AI document translation produces the draft fast, but under the full human post-editing discipline of ISO 18587 a qualified reviewer takes responsibility for the final text. A safety claim never ships on raw machine translation alone.

Does IEC 61508 or ISO 26262 certify a translation company?

No. IEC 61508 and ISO 26262 certify the client's safety-related product and development process, not a translation provider. No translation company holds "IEC 61508 certification" or "ISO 26262 certification". What a provider can hold is ISO 17100 and ISO 18587, and supply engineers who review every safety claim.

What is the difference between SIL and ASIL?

SIL, the Safety Integrity Level from 1 to 4, comes from IEC 61508 and applies across electrical, electronic and programmable electronic safety systems. ASIL, the Automotive Safety Integrity Level from A to D, comes from ISO 26262 and applies to road vehicles. ISO 26262 is the automotive adaptation of IEC 61508, so the concepts align while the labels and the lifecycle differ.

Which functional safety documents need translation?

Typically the safety manual, the safety case, hazard and risk analyses, FMEA and FMEDA tables, verification and validation reports, and the safety-related sections of the user instructions. Any document that states a safety claim or tells a reader to act is translated and then reviewed by a certified engineer.

Why does the source text have to be frozen before translation?

Because a safety case keeps changing while engineering closes findings, and a moving source produces a translation that cites a revision that no longer exists. Freezing the exact revision, with its document number and date, is the first step, and any later change is handled as a new revision with its own review cycle.

Is machine translation output acceptable for a safety case?

Not on its own. Machine or LLM output can be the draft, but ISO 18587 requires full human post-editing by a qualified reviewer who takes responsibility for the result. For a safety case that means a certified engineer checks every safety claim, every SIL or ASIL label, and every number against the frozen source.