ШІ для перекладів у компанії: як це працює на практиці

Правовий відділ польської виробничої компанії отримує для перекладу 200-сторінковий контракт з контрагентом з Японії. Термін: 48 годин. Зовнішнє бюро перекладів оцінює це в 4 тижні та кілька десятків тисяч злотих. Внутрішній перекладач англійської мови справляється з прозою, але технічна термінологія галузі та специфічні правові положення виходять за межі його компетенцій.

Це сценарій, який повторюється в сотнях компаній. ШІ для перекладів не усуває перекладачів, але змінює обсяг їхньої роботи: модель бере на себе 80-90% попереднього перекладу, спеціаліст переглядає та коригує, а все готове за частку початкового часу.

Google Translate та DeepL — це універсальні інструменти. Вони добре працюють для стандартних текстів, але мають три систематичні проблеми в корпоративному контексті.

Перша: відсутність знання внутрішньої термінології. Виробнича компанія має власні назви продуктів, технологічні процеси та абревіатури, яких немає в жодному загальному словнику. Переклад «попередній монтаж вузла C-27» загальною моделлю дасть випадковий результат.

Друга: відсутність узгодженості між документами. Якщо два відділи перекладуть одну й ту саму процедуру незалежно через Google Translate, вони можуть отримати різні версії тієї самої термінології. У технічній документації чи договорах це проблема.

Третя: RODO. Вставлення документів, що містять дані клієнтів, працівників або партнерів, у зовнішній API без договору доручення обробки (ст. 28 RODO) є потенційним порушенням. Більшість компаній робить це несвідомо.

Корпоративний пайплайн перекладів вирішує ці три проблеми завдяки комбінації: корпоративний глосарій у RAG, стилістичні та форматувальні інструкції в системному промпті та self-hosting моделей для конфіденційних документів.

Вхідний документ (PDF/DOCX/HTML/текст)
        │
        ▼
[Парсинг та сегментація — чанки для перекладу]
        │
        ▼
[PII masking — локально, перед виходом з інфраструктури]
        │
        ▼
[RAG lookup — корпоративний глосарій та доменна термінологія]
        │
        ▼
[LLM з термінологічним контекстом та стилістичною інструкцією]
        │
        ▼
[Guardrails — узгодженість термінології, відсутні фрагменти]
        │
        ▼
[Збірка та форматування вихідного документа]
        │
        ▼
Переклад для перевірки спеціалістом

Ключовий елемент — корпоративний глосарій. Він зберігає термінологічні пари (PL→EN, PL→DE тощо) разом з контекстом використання. Перед перекладом кожного сегмента система шукає релевантні терміни за допомогою семантичного пошуку та додає їх до промпту як обов’язкову термінологію. Модель тоді знає, що «C-27» — це власна назва продукту, а не хімічний код.

Глосарій є «живим»: щоразу, коли перекладач коригує термін, виправлення повертається до індексу. Система вчиться з кожної корекції без повторного тренування моделі.

Не всі документи мають однаковий профіль ризику та складності. Впровадження варто починати з категорій, де ROI високий, а ризик помилки низький.

Правові та фінансові документи потребують перевірки спеціалістом незалежно від якості моделі. Human-gate перед відправкою є тут вимогою, а не опцією.

BLEU score та інші автоматичні метрики мало говорять про якість у корпоративному контексті. Дві компанії з однаковим BLEU можуть мати абсолютно різні рівні задоволеності перекладачів.

Метрики, які мають практичне значення:

Показник пост-редагування (PE rate): скільки відсотків речень перекладач змінив після отримання попереднього перекладу. Для хорошої системи з корпоративним глосарієм PE rate нижче 20% є досяжним для стандартних текстів. Вище 40% — сигнал, що або глосарій бідний, або стилістична інструкція потребує корекції.

Узгодженість термінології: скільки відсотків корпоративних термінів було перекладено відповідно до глосарію. Вимірюється автоматично шляхом порівняння з глосарієм після перекладу.

Час до прийняття: скільки часу перекладач витрачає на документ, перекладений ШІ, порівняно з перекладом з нуля. Реальна економія часу, виміряна за кілька тижнів роботи, дає основу для розрахунку ROI.

Показник відмов: скільки документів перекладач повернув для повторного перекладу моделлю (замість самостійного редагування). Високий показник відмов сигналізує про проблеми з відповідністю моделі стилю або мовній парі.

Системи з observability експонують ці метрики за мовною парою, категорією документа та файлом. Через 3-4 тижні видно, де інвестиції в глосарій дають найбільший ефект.

Переклад — це перенесення контенту на іншу мову. Локалізація — це адаптація контенту до культури, правового контексту та очікувань цільового ринку. Компанії, які плутають ці два процеси, отримують технічно правильний переклад, який не продається і не залучає.

Приклади:

• Маркетинговий матеріал, перекладений з польської на англійську для ринку Великої Британії, може містити жарти або культурні відсилання, які не працюють для британської аудиторії.
• Регламент, перекладений на мову ринку Німеччини, може бути лінгвістично правильним, але не враховувати специфіку споживчого права в Німеччині.
• Ціни, вказані в PLN, перераховані на EUR калькулятором, можуть не відповідати реальним ринковим цінам.

ШІ добре справляється з перекладом. Локалізація вимагає додаткового кроку: або системної інструкції з культурними вказівками для кожного ринку, або перевірки носієм мови зі знанням локального ринку. Пайплайн перекладів ШІ може вбудовувати культурні інструкції для відомих ринків, але остаточне рішення щодо культурної адаптації має належати людині.

Переклад корпоративних документів — це частий вектор несвідомого порушення RODO. Документи містять персональні дані клієнтів, працівників, контрагентів. Надсилання їх до зовнішнього API без договору доручення обробки (ст. 28 RODO) є порушенням.

Чотири технічні вимоги для відповідних систем перекладів:

PII masking перед перекладом: імена, адреси, номери PESEL, номери документів, електронні адреси замінюються токенами перед надсиланням тексту до моделі. Після перекладу токени замінюються назад. Presidio або spaCy NER можуть зробити це локально.

Self-hosting для конфіденційних документів: договори, документи HR, листування з клієнтами ніколи не повинні потрапляти до зовнішніх API без PII masking та договору доручення. Локальні моделі (через Ollama на власній інфраструктурі) усувають цю проблему для мовної пари, для якої якість локальної моделі є достатньою.

Логи з мінімальним PII: система логує метадані перекладу (мовна пара, час, кількість токенів, результат guardrails), а не вміст документа. На вимогу доступу або видалення даних можливо пов’язати сесію перекладу з користувачем без зберігання вмісту.

DPIA для конфіденційних категорій: медичні документи, документи щодо генетичних або біометричних даних, документи щодо політичних поглядів або віросповідання вимагають DPIA перед впровадженням пайплайну перекладів. Обов’язки компаній у 2026 році щодо AI Act та RODO розглядає стаття AI Act та RODO 2026.

Корпоративний пайплайн перекладів має цінність лише тоді, коли він вбудований в існуючі процеси. Перекладачі не повинні вручну копіювати текст до інтерфейсу і назад.

Типові точки інтеграції:

Плагін для MS Word / Google Docs: виділіть текст, натисніть «Перекласти корпоративно», результат з’являється в документі з можливістю прийняття або відхилення. Інтеграція через API, плагін простий у створенні.

Інтеграція з CMS: для компаній, що перекладають контент на вебсайт, пайплайн може автоматично запускати переклад після публікації контенту базовою мовою. Після людської перевірки контент публікується іншими мовами.

Webhook при нових документах: n8n або подібний агент автоматизації відстежує папку з документами для перекладу, запускає пайплайн, надсилає результат перекладачеві з проханням перевірити.

Інтеграція з системою ERP або DMS: для компаній з великими обсягами документів пряме API між системою управління документами та пайплайном перекладів усуває ручні кроки.

Кожна інтеграція має дотримуватися принципу human-gate: переклад ШІ є робочою версією, а не готовим документом. Автоматичне надсилання перекладу клієнту без перевірки є репутаційним та правовим ризиком.

Вартість залежить від обсягу документів, мовних пар та обраної архітектури. Пілотний проект для однієї мовної пари (наприклад, PL→EN) для однієї категорії документів (наприклад, описи продуктів) зазвичай займає 3-6 тижнів і має значно нижчий поріг входу, ніж повноцінна багатомовна система.

Орієнтовні сигнали, що ROI позитивний:

• Компанія перекладає понад 50 сторінок на місяць зовнішньо або внутрішньо.
• Час від отримання документа до готового перекладу перевищує 3 робочі дні.
• Термінологія неузгоджена між відділами або між мовними версіями одного документа.
• Перекладачі витрачають понад 30% часу на пошук та уніфікацію термінології замість перекладу.

Калькулятор ROI дозволяє ввести реальні цифри та побачити очікуваний термін окупності. Finder автоматизації покаже, які процеси перекладу у компанії мають найвищий потенціал автоматизації.

Опишіть свій поточний процес перекладів та тип документів, а модель запропонує архітектуру пайплайну та пріоритети впровадження (playground: PII маскуються, нульова ретенція):

Ні в короткостроковій перспективі, особливо для документів з високими правовими або фінансовими наслідками. ШІ бере на себе попередній переклад та стандартизацію термінології, а перекладач зосереджується на пост-редагуванні, культурній локалізації та перевірці змісту. У компаніях з регулярним обсягом перекладів це означає, що один перекладач може обробити в кілька разів більший обсяг. Для простих документів (FAQ, описи продуктів, внутрішня вікі) роль людини може зводитися до швидкої перевірки, а не повного перекладу з нуля.

За допомогою корпоративного глосарію, інтегрованого з пайплайном RAG. Глосарій містить термінологічні пари з контекстом використання (наприклад, «попередній монтаж» → «pre-assembly», контекст: виробництво) і шукається семантично перед кожним сегментом перекладу. Кожна корекція перекладача повертається до глосарію як новий приклад. Через кілька тижнів система оперує термінологією, яку компанія фактично використовує, а не загальнословниковою. Узгодженість між документами з різних відділів і різних дат значно зростає.

Це залежить від архітектури. Надсилання документів, що містять персональні дані, до зовнішніх API без договору доручення обробки (ст. 28 RODO) є невідповідним. Відповідний пайплайн вимагає: PII masking перед перекладом, договору DPA з постачальником API, якщо використовуються хмарні моделі, або self-hosting моделей для конфіденційних документів. Для документів, що містять дані особливих категорій (медичні, фінансові, HR), потрібна DPIA перед впровадженням.

Найвищу якість перекладів ШІ забезпечує для пар з великою кількістю тренувальних даних: англійська, іспанська, французька, німецька, китайська, арабська, італійська, португальська. Польські переклади в парах з англійською та німецькою мають високий рівень для більшості доступних моделей. Пари з рідкісними мовами або вузькоспеціалізованою термінологією потребують більше роботи з глосарієм і частіше мають вищий показник пост-редагування. Для мовних пар з низькою якістю загальних моделей варто розглянути спеціалізовані моделі або збагатити глосарій прикладами з відповідних документів. Детальний підхід до систем, що підтримують багато мов, описано в статті багатомовний асистент ШІ.

З аудиту обсягів: скільки сторінок на місяць перекладає компанія, якими мовними парами, які типи документів домінують. Далі оцінка глосарію: чи має компанія існуючий словник термінології? Навіть Excel з 200 записами — хороша відправна точка для побудови RAG на термінології. Пілотний проект починається з однієї мовної пари та однієї категорії документів з низьким ризиком (FAQ, описи продуктів). Через 4-6 тижнів ви матимете реальні дані про показник пост-редагування та термін окупності, перш ніж масштабувати. Методологія всього процесу впровадження ШІ у компанії описана в статті план впровадження ШІ крок за кроком.