Конфіденційність документів клієнта в AI-перекладі: чекліст

47 сторінок договору, таблиця з іменами працівників і прохання клієнта «перекласти якнайшвидше» - такий файл може опинитися у вікні машинного перекладу за кілька хвилин. Але швидкість не відповідає на головне запитання: чи має агенція право передати документ цьому постачальнику і що той робитиме з його вмістом?

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

Чому завантаження документа є окремим рішенням про обробку даних¶

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

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

У дописі про занепокоєння клієнтів щодо конфіденційності автор наводить такий приклад (джерело допису):

“It’s highly confidential and we want to know who’s seeing and working on the document”

Простими словами: матеріал конфіденційний, і клієнт хоче знати, хто його бачить і з ним працює. Це особистий професійний приклад, а не результат репрезентативного опитування. Але він добре показує, чому клієнту потрібен прозорий перелік людей і постачальників, які мають доступ.

Агенції варто розділяти три питання, які часто зливають в одне:

1. Чи потрібне AI-опрацювання саме для цього завдання? Якщо перекладач може виконати роботу без стороннього сервісу, передавання даних може бути зайвим.
2. Чи можна передавати саме цей матеріал? Перевір договір із клієнтом, NDA, правила відповідної галузі та правову підставу.
3. Чи підходить постачальник для цієї категорії даних? З’ясуй умови обробки, правила доступу, субпідрядників, місця обробки, строки зберігання й порядок видалення.

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

Стаття 5(1)(c) GDPR вимагає, щоб персональні дані були «adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed» - достатніми, доречними й обмеженими тим, що потрібно для мети обробки. Для перекладацької агенції це означає просту річ: передавай лише ті частини тексту та ідентифікатори, які потрібні для перекладу (стаття 5 GDPR).

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

У договорі й робочих правилах варто також з’ясувати, кому належать перекладацькі матеріали й пам’ять перекладу: хто є власником Translation Memory - агенція чи клієнт. Права на мовні активи й конфіденційність - різні питання, але в умовах співпраці вони часто йдуть поруч.

Чекліст перед завантаженням клієнтського файла¶

Перевірка перед завантаженням має бути короткою, але обов’язковою. Менеджеру проєкту не треба вгадувати, що дозволив клієнт, а перекладачеві - шукати умови постачальника в останню хвилину.

Відкрий цей чекліст перед новим типом завдання або перед роботою з новим постачальником.

1. Визначте, які дані містить документ¶

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

Не називай документ «безпечним» тільки тому, що в ньому немає очевидного імені. Номер справи, адреса, посада, дата події чи поєднання кількох непрямих ознак теж можуть допомогти встановити особу. Знеособлення зменшує ризик, але не гарантує, що людину неможливо впізнати.

2. Перевірте дозвіл клієнта й договір¶

Знайди відповідні умови в договорі, NDA, замовленні або інструкціях клієнта. Перевір, чи дозволені хмарні сервіси, автоматизована обробка, передавання субпідрядникам і машинний переклад.

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

3. Установіть роль агенції та постачальника¶

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

Стаття 28(1) GDPR вимагає від контролера залучати обробників, які надають достатні гарантії щодо технічних та організаційних заходів. Європейська рада із захисту даних також наголошує, що оцінювати потрібно постачальника та відповідних субобробників, а не покладатися на рекламні заяви (Opinion 22/2024 Європейської ради із захисту даних).

4. Перевірте, що постачальник робить із вмістом¶

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

Окремо уточни, чи однакові правила діють для вебверсії, API, корпоративного плану й окремих функцій. У межах одного постачальника різні сервіси можуть відрізнятися за використанням тексту, строками зберігання, місцем обробки та контролем доступу.

5. Перевірте субпідрядників і місця обробки¶

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

Європейська рада із захисту даних зазначає, що контролери мають легко отримувати ідентифікаційні дані й контакти всіх обробників та субобробників. Обробники, зі свого боку, мають надавати цю інформацію й підтримувати її актуальність (Opinion 22/2024). Початковий список не замінює процесу оновлення.

6. Зрозумійте строк зберігання та видалення¶

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

Стаття 5(1)(e) GDPR установлює принцип обмеження зберігання: персональні дані не мають залишатися у формі, що дає змогу ідентифікувати людину, довше, ніж потрібно для мети обробки, з урахуванням передбачених регламентом винятків (стаття 5 GDPR). Внутрішній графік агенції має узгоджуватися з договором і вимогами до зберігання матеріалів.

7. Перевірте заходи безпеки й доступ¶

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

Стаття 5(1)(f) GDPR вимагає належного рівня безпеки. Зокрема, дані треба захищати від несанкціонованої чи незаконної обробки, випадкової втрати, знищення або пошкодження (стаття 5 GDPR). Самих слів «корпоративний рівень безпеки» замало, щоб зрозуміти, чи підходить сервіс агенції.

8. Визначте порядок перевірки результату¶

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

Як оцінити постачальника, угоду та налаштування¶

Угода про обробку даних (DPA) - це документ про умови, за якими постачальник обробляє персональні дані від імені клієнта або іншого контролера. Сам факт, що документ має таку назву, ще не доводить належної відповідності. Важливо, що саме в ньому написано, чи збігаються умови з реальним сервісом і чи виконує постачальник свої зобов’язання.

Не зупиняйся на запитанні «чи є у вас DPA?». Попроси актуальну версію, з’ясуй, хто підписує її від імені постачальника, і звір умови з тим, як команда планує користуватися інструментом.

Перевір такі пункти:

Цей перелік допоможе провести практичну перевірку, але не замінить юридичного висновку. Вимоги залежать від ролей сторін, типу даних, договору, юрисдикції та конкретної послуги. Європейська рада із захисту даних радить не покладатися на загальні заяви постачальника, а перевіряти його зобов’язання й субобробників (Opinion 22/2024).

Передавання даних між країнами перевіряй окремо. Запиши місце обробки й з’ясуй, які гарантії застосовуються на кожному етапі, а не лише де розташований головний офіс компанії. Якщо до обробки залучено субпідрядника, маршрут даних і правові підстави мають охоплювати й його.

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

Заведи запис для кожного постачальника, який можна буде повторно перевірити. Збережи дату останнього перегляду умов, ім’я відповідального працівника, посилання на документи й рішення про класи матеріалів, які дозволено передавати. Якщо умови змінилися, команда має розуміти, чи можна продовжувати роботу, чи треба призупинити завантаження до нового погодження.

Про те, як узгодити інструменти й робочі правила розподіленої команди, читай у матеріалі про інструменти та процеси remote-first перекладацького агентства. Для побудови внутрішніх процедур стане в пригоді й документування SOP для перекладацького агентства.

Мінімізація даних: що прибрати перед машинним перекладом¶

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

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

Для знеособлення заміни ім’я на стабільну позначку на кшталт [PERSON_1], а номер рахунку - на [ACCOUNT_1], якщо переклад цих значень не потребує. Використовуй одну позначку для тієї самої людини в усіх фрагментах, інакше перекладач може сплутати учасників.

Перед завантаженням перевір:

• імена, адреси, телефони, електронні адреси та підписи;
• номери рахунків, справ, договорів і клієнтські ідентифікатори;
• назви внутрішніх проєктів, продуктів і підрозділів;
• коментарі, виправлення, приховані аркуші та вкладені елементи;
• властивості файла, назву документа й імена авторів;
• фрагменти, які не потрібні для перекладу цього замовлення.

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

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

Деідентифікація - не те саме, що анонімізація. Якщо за контекстом документа можна визначити людину, видалення імені не усуває персональних даних. Перевір ризик повторної ідентифікації, особливо якщо файл містить рідкісну посаду, конкретну дату або опис унікальної події.

Стаття 5 GDPR формулює принцип мінімізації так:

“adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed”

Це нагадування, що мінімізувати потрібно не лише імена. Обсяг, деталізація й добір частин документа мають відповідати меті обробки (стаття 5 GDPR). Якщо для перекладу потрібні два розділи, не завантажуй цілий архів листування.

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

Коли AI-переклад не підходить і як побудувати альтернативний процес¶

Не використовуй AI-інструмент для конкретного документа, якщо агенція не має дозволу на передавання, не може перевірити умови постачальника або не здатна забезпечити потрібний рівень контролю. У такому разі не шукай навмання інший безплатний сервіс - зміни маршрут завдання.

Ось проста модель для ухвалення рішення:

1. Звичайний матеріал без конфіденційних обмежень. Перевір умови інструмента й договір, а потім працюй лише за дозволеним процесом.
2. Документ із персональними чи комерційно чутливими даними. Передавай його тільки після перевірки правової підстави, договору, DPA, субпідрядників, зберігання й безпеки.
3. Матеріал із високою чутливістю або прямою забороною на хмарну обробку. Використовуй погоджений клієнтом процес без відповідного стороннього сервісу.
4. Документ, для якого недостатньо даних, щоб оцінити ризик. Призупини завантаження й передай запит відповідальному за приватність або юридичне погодження.

Не кожен документ можна безпечно знеособити. У контракті імена сторін можуть визначати зміст зобов’язань, а контекст медичного висновку - розкривати особу навіть після видалення очевидних ідентифікаторів. Спирайся на класифікацію та умови клієнта, а не на припущення, що заміна імені автоматично розв’язує проблему.

Агенції потрібен зрозумілий шлях для ескалації запитань. Менеджер проєкту має знати, до кого звертатися, якщо клієнт не вказав дозволені інструменти, договір сформульовано нечітко або постачальник змінив умови. Без відповідальної людини працівники ухвалюватимуть рішення під тиском дедлайну.

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

Додай у картку проєкту поля для класифікації даних, дозволених засобів обробки, погодження клієнта, обраного постачальника й строку видалення. Якщо команда працює з різними субпідрядниками, правила доступу до матеріалів мають бути частиною ширшої системи управління постачальниками: читай як побудувати пул фрилансерів і процес vendor management.

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

Типові помилки агенцій і навчання команди¶

Одна з найчастіших помилок - дозволити працівникам самим обирати інструмент, коли файл уже надійшов і дедлайн тисне. Тоді виникає спокуса завантажити документ одразу, а умови постачальника перевірити вже після передавання даних.

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

Не думай, що після натискання кнопки завантаження вся відповідальність переходить до постачальника. Агенція має перевірити, чи має право передати матеріал, чи відповідають гарантії постачальника вимогам і чи правильно команда користується сервісом. Договір із постачальником не замінює зобов’язань перед клієнтом.

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

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

Європейська комісія пояснює: стаття 4 Акта про штучний інтелект зобов’язує постачальників і розгортувачів AI-систем уживати заходів, щоб персонал та інші люди, які працюють із системами від їхнього імені, мали достатній рівень грамотності у сфері AI. Комісія повідомляє, що стаття почала застосовуватися 2 лютого 2025 року (запитання та відповіді Європейської комісії про грамотність у сфері AI). Це не готова навчальна програма для агенції, але до неї можна включити дозволені інструменти, заборонені категорії даних, знеособлення, строки зберігання, ескалацію та людську перевірку.

Не обмежуйся одноразовою презентацією. Записуй дату навчання, аудиторію й теми, а після зміни інструмента або умов постачальника пояснюй команді, що змінилося. Працівник, який пам’ятає старі правила, може несвідомо продовжити завантажувати матеріали за неактуальним процесом.

Перед FAQ перевір головне запитання клієнта: хто бачить документ? Відповідь має спиратися на актуальний перелік працівників і постачальників, договірні умови та конкретний маршрут обробки, а не на здогад менеджера.

Часті питання¶

Чи може перекладацьке агентство завантажувати документи клієнтів у безплатні AI-перекладачі?¶

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

Що перевірити в угоді про обробку даних AI-постачальника?¶

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

Чи вимагає GDPR угоди про обробку даних із постачальником AI?¶

Якщо постачальник обробляє персональні дані від імені контролера як обробник, стаття 28 GDPR передбачає договірні умови для такого процесу. Визнач фактичні ролі сторін і перевір, чи відповідає угода реальному використанню інструмента.

Як знеособити документ перед машинним перекладом?¶

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

Що має містити чекліст конфіденційності для AI-перекладу?¶

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