Переводчику запретили загружать документ в онлайн-переводчик: своя модель

MAATRIX

Пришло письмо от юридического отдела заказчика: NDA прямо запрещает передавать материалы дела третьим лицам, включая любые облачные сервисы. А на столе — тридцать страниц договора, который нужно перевести к пятницу. Google Translate, DeepL, любой веб-переводчик — не вариант: документ технически покидает вашу машину и оседает на чужих серверах, а что происходит с ним дальше, вы не контролируете и не можете за это поручиться перед клиентом. Разберём, что на самом деле случается с текстом, если вставить его в форму на стороннем сайте, и как получить рабочий инструмент машинного перевода, который не отправляет ни строчки за пределы вашей собственной инфраструктуры.

Почему запрет на онлайн-переводчик — это не каприз заказчика

Когда юрист, служба безопасности или сам клиент прописывают в договоре запрет на «использование сторонних онлайн-сервисов для обработки документов», за этим обычно стоит конкретная причина, а не общая паранойя.

• Юридическая тайна и NDA. Адвокаты, нотариусы, патентные поверенные связаны профессиональной тайной по закону, а не по желанию. Передача текста договора или судебного документа в чужой сервис может формально считаться разглашением — независимо от того, читал документ живой человек или нет.
• Коммерческая тайна. Технические спецификации, финансовая отчётность, условия сделки M&A — всё это конкурентное преимущество компании. Утечка через логи стороннего сервиса — репутационный и финансовый риск для заказчика, а отвечать перед ним будете вы как исполнитель.
• Персональные данные. Медицинские заключения, кадровые документы, материалы по опеке — содержат персональные данные третьих лиц. Их обработка сторонним сервисом без согласия субъекта — уже вопрос не корпоративной политики, а закона о персональных данных.
• Договорные обязательства переводчика. Многие агентства и прямые заказчики включают в договор с переводчиком отдельный пункт о запрете CAT-плагинов и веб-сервисов с облачной обработкой — именно потому что такие случаи уже были, и кто-то уже разбирался с последствиями.

Смысл этих ограничений один: документ должен оставаться под контролем сторон сделки, а не путешествовать через инфраструктуру, условия использования которой вы в лучшем случае бегло просмотрели при регистрации.

Что происходит с документом в облачном переводчике

Технически, когда вы вставляете текст в форму публичного онлайн-переводчика или загружаете файл, происходит следующее: текст уходит на сервер провайдера сервиса, который физически может находиться в любой юрисдикции — не обязательно там, где действует ваш договор с заказчиком. Дальше — вопрос политики конкретного сервиса, и она не всегда прозрачна и не всегда неизменна:

• запрос и ответ могут временно или постоянно логироваться на стороне провайдера;
• бесплатные и часть платных тарифов в пользовательских соглашениях оставляют за собой право использовать переданный контент для улучшения моделей — то есть фрагменты вашего документа теоретически могут повлиять на будущие ответы сервиса другим пользователям;
• у вас нет технической возможности проверить, что происходит с копией текста после отправки — вы верите документу с условиями использования, а не видите инфраструктуру;
• при использовании через браузерное расширение или встроенный в CAT-инструмент облачный MT-модуль отправка может происходить автоматически, без явного клика «отправить» — переводчик иногда узнаёт об этом постфактум.

Важная оговорка: платные корпоративные тарифы крупных сервисов машинного перевода часто предлагают отдельные условия — без сохранения данных, с изоляцией клиента. Это реальная опция, и для части заказов она подходит. Но она требует доверия к формулировкам чужого договора и не решает случай, когда заказчик прямо требует, чтобы данные вообще не покидали инфраструктуру, которую контролирует он сам или подрядчик, которого он проверил.

Собственный сервер снимает именно этот вопрос: документ не покидает машину, которую арендуете и администрируете вы (или заказчик — если требование именно такое). Логирования на стороне третьей компании просто не существует, потому что третьей компании в цепочке обработки текста нет.

Локальная модель перевода: что это и зачем переводчику

Речь не о том, чтобы заменить вашу профессиональную экспертизу программой. Речь о вспомогательном инструменте: открытой модели машинного перевода, развёрнутой на вашем собственном сервере, которая делает черновой перевод — а дальше в дело вступаете вы с постредактированием, терминологической базой и знанием контекста, которое ни одна модель пока не заменяет.

Практическая логика простая:

1. Документ загружается на ваш сервер (по SSH, SFTP, через внутренний веб-интерфейс — вы выбираете канал).
2. Модель, развёрнутая локально, делает черновой перевод.
3. Вы получаете результат обратно и работаете с ним как с любым машинным черновиком — сверяете термины, переписываете формулировки, вычитываете.
4. Ни на каком шаге текст не покидает сервер, которым управляете вы.

Для этого используются открытые (self-hosted) модели машинного перевода — они разрабатываются и публикуются с возможностью запуска на собственном железе, в отличие от закрытых облачных API, которые в принципе доступны только «как сервис». Два практических пути:

• LibreTranslate — готовый self-hosted сервис с REST API, построенный на открытых моделях (в основе — наработки проекта Argos Translate). Разворачивается одной командой в Docker, отдаёт простой HTTP API, покрывает довольно широкий набор языковых пар «из коробки».
• Модели семейства NLLB (No Language Left Behind, разработка Meta) — более тяжёлый, но и более гибкий вариант: одна модель покрывает около двухсот языков и направлений, можно запускать через библиотеки инференса вроде CTranslate2, которые ускоряют работу на CPU без GPU.

Оба варианта — open source, оба можно поставить на арендованный VPS без согласований с внешним провайдером и без передачи данных куда-либо за пределы вашего сервера.

Как развернуть переводчик на своём сервере

Самый быстрый путь для старта — LibreTranslate в Docker. Пример минимального разворачивания:

docker run -d \
  --name libretranslate \
  -p 127.0.0.1:5000:5000 \
  -v libretranslate-data:/home/libretranslate/.local \
  --restart unless-stopped \
  libretranslate/libretranslate \
  --disable-web-ui false

Обратите внимание на -p 127.0.0.1:5000:5000 — порт пробрасывается только на локальный интерфейс сервера, наружу сервис не торчит. Доступ к нему вы организуете через VPN (WireGuard/OpenVPN) или SSH-туннель:

ssh -L 5000:127.0.0.1:5000 user@your-server-ip

После этого API доступен на вашей локальной машине как http://127.0.0.1:5000, но физически запрос всё равно обрабатывается на сервере — трафик идёт по зашифрованному туннелю, а не через публичный интернет в открытом виде.

Базовый запрос к API:

curl -X POST http://127.0.0.1:5000/translate \
  -H "Content-Type: application/json" \
  -d '{
    "q": "Текст документа для перевода",
    "source": "ru",
    "target": "en",
    "format": "text"
  }'

Для перевода целых файлов (docx, odt, pdf с текстовым слоем) в LibreTranslate есть отдельный эндпоинт /translate_file — он сохраняет часть форматирования, что удобно для черновой обработки многостраничных договоров.

Если нужен более широкий охват языков или выше исходное качество черновика, второй вариант — развернуть модель NLLB через CTranslate2. Это чуть больше ручной настройки (конвертация весов модели в формат CTranslate2, написание небольшого Python-скрипта для приёма текста и вызова модели), зато вы получаете контроль над конкретной моделью и её версией, а не только API поверх неё. Для такой конфигурации сервер с 4–8 ГБ оперативной памяти и современным CPU уже потянет работу без GPU — модели среднего размера из семейства NLLB рассчитаны и на CPU-инференс, просто медленнее, чем на видеокарте. Точная скорость зависит от объёма документа, длины предложений и загрузки сервера — здесь нет смысла обещать конкретные цифры, у вас они будут свои.

Если объём переводов большой и регулярный, GPU ускоряет обработку заметно, и тогда имеет смысл смотреть в сторону GPU-сервера для инференса LLM — но для типичного объёма практикующего переводчика (десятки, не тысячи страниц в день) обычного VPS с несколькими ядрами вполне достаточно.

Честно о качестве: чего ждать, а чего нет

Здесь важно не создавать себе и заказчику ложных ожиданий. Открытая модель, развёрнутая на своём сервере, — это не замена профессиональному переводу и не гарантированный аналог по качеству лучших коммерческих облачных сервисов машинного перевода, которые годами обучаются на огромных объёмах данных и постоянно дообучаются.

Что реально получаете:

• Черновой перевод для рабочего процесса, а не финальный текст под сдачу заказчику. Постредактирование остаётся обязательным этапом — как и при работе с любым MT-инструментом, включая облачные.
• Разное качество по языковым парам. Для распространённых направлений (например, английский—русский, английский—испанский) черновик обычно получается более пригодным к правке. Для редких языков и специфических пар результат может требовать значительно больше правки — модель просто видела меньше данных на этой паре при обучении.
• Слабые места на специальной терминологии. Открытые модели общего назначения не заточены под конкретную предметную область — юридическую, медицинскую, техническую. Термины часто придётся поправлять вручную или дообучать/донастраивать модель под свой глоссарий, что уже отдельная, более сложная задача.
• Зависимость от контекста. Модель переводит фрагмент, не видя документ целиком так, как видите его вы — с пониманием, о чём договор, кто стороны, какая логика статьи. Это ограничение любого MT-инструмента, не только вашего локального.

Честная формулировка для заказчика звучит примерно так: «Использую локальную модель как вспомогательный инструмент для черновой обработки — весь перевод проходит через моё редактирование, документ при этом не покидает защищённую инфраструктуру». Это ровно то преимущество, которое вы продаёте — конфиденциальность процесса, а не превосходство машинного перевода над профессиональной работой.

Отдельно стоит развеять и обратный миф — что «локальное» автоматически означает «полностью приватное» само по себе, без дополнительных настроек. Это не совсем так: сервер тоже нужно защищать — закрывать порты, шифровать диск, ограничивать доступ. Подробнее о том, где проходит граница между «стоит у меня» и «действительно приватно», — в разборе мифа о полной приватности локальной модели.

Как встроить локальную модель в рабочий процесс

Голый API — это только основа. Чтобы инструмент реально работал в практике переводчика, а не оставался игрушкой для тестов, его стоит встроить в привычный процесс:

• Подключение к CAT-инструменту. memoQ, Trados Studio, OmegaT и другие CAT-программы поддерживают подключение внешних MT-движков через API — обычно в настройках плагинов машинного перевода можно указать произвольный HTTP-эндпоинт вместо облачного сервиса по умолчанию. Указываете адрес своего сервера (через VPN-туннель) — и черновой перевод подтягивается прямо в интерфейс CAT-программы, сегмент за сегментом, без ручного копирования текста куда-либо.
• Память переводов остаётся при вас. Если вы уже ведёте TM (Translation Memory) годами, имеет смысл держать её на том же защищённом сервере, а не в облачном аккаунте CAT-программы — тогда и черновой MT, и накопленная память переводов физически находятся в одном контуре, который вы контролируете.
• Форматы файлов. Для docx, pptx, xlsx удобнее предварительно извлекать текстовый слой (через тот же CAT-инструмент или простой скрипт) и прогонять сегменты через API, а не пытаться скормить модели файл целиком — так сохраняется форматирование и структура документа.
• Дисциплина доступа. Раз весь смысл в конфиденциальности — сервер стоит настроить соответствующим образом: доступ только по SSH-ключу (не по паролю), порт API закрыт наружу и доступен только через VPN или туннель, диск сервера зашифрован, логирование запросов к API отключено или ограничено минимальными техническими метками без содержимого текста. Временные файлы после обработки документа стоит сразу удалять, а не оставлять «на всякий случай» — сам факт их существования на диске является дополнительным риском, даже если сервер ваш.
• Резервный канал на случай отказа. Локальный сервис может упасть или не справиться с редкой языковой парой — на этот случай держите под рукой профессиональный переводчик-человек (себя) как основной инструмент, а MT — только как ускоритель черновика. Полагаться на автоматику как на единственный путь получения перевода не стоит: это же логика, что и в любой профессии, где есть NDA — вы не можете позволить себе точку отказа без запасного варианта.

Похожая логика конфиденциальности встречается и у других профессий, работающих с закрытыми данными клиента — например, у юристов, которые обязаны хранить материалы дел под собственным контролем: разбор того, как это устроено технически, — в статье про адвокатскую тайну и файлы на своём сервере. Принципы там пересекаются: изоляция, отсутствие стороннего логирования, контроль над каналом доступа.

Если вы ещё не решили, оправдан ли переход на локальную модель именно в вашем случае — то есть сравниваете постоянные расходы на сервер с удобством облачного API там, где заказчик такого запрета не ставит, — стоит сначала прикинуть экономику и сценарии использования в материале локальная модель против облачного API: что выгоднее и когда. Для части заказов, где нет требования по конфиденциальности, облачный сервис действительно может быть проще и дешевле — держать локальный сервер имеет смысл именно тогда, когда данные заказчика реально нельзя передавать наружу.

Частые вопросы