Чи навчається корпоративний ШІ на даних компанії: що перевірити в тарифі та договорі

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

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

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

Коротка відповідь і межі тарифу

Питання «чи навчається ChatGPT Enterprise або Claude for Work на наших даних» зазвичай звучить як одне. Насправді за ним три різні ситуації, і правила в кожній свої.

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

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

Особистий акаунт. Якщо працівник відкриває ШІ-сервіс зі свого приватного акаунта, корпоративні гарантії на цю розмову не поширюються. Переносити умови споживчого акаунта на Enterprise чи API некоректно, і навпаки. Тому питання «який тариф обрати» не можна відокремити від питання «чим працівники користуються вже зараз».

Ще одне застереження стосується назв. Тарифи в постачальників перейменовують і об'єднують. Орієнтуйтеся не на назву в рахунку, а на два факти. Перший: чи належить ваш акаунт до бізнесових продуктів у документації постачальника. Другий: чи підписані відповідні умови. Фіксуйте дату, коли ви це перевірили. Для нашого дослідження це 11.10.2026. Перевірені під час підготовки матеріалу довідкові статті Anthropic мали версії від 18.08.2026 і 01.07.2026, а сторінки OpenAI динамічні й не мали фіксованої дати.

Чотири різні дії з даними, які не можна змішувати

Фраза «наші дані в безпеці» часто описує один з чотирьох процесів. Обіцянка постачальника зазвичай стосується лише одного з них. Розділімо їх.

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

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

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

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

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

Навчальний приклад: один договір, три маршрути

Цей сценарій вигаданий і потрібен лише для ілюстрації. Менеджер завантажує в корпоративний ШІ-чат договір з постачальником і просить виписати умови оплати та штрафні санкції. Щоб звірити реквізити, модель через конектор звертається до CRM і підтягує картку контрагента. Відповідь вийшла вдалою, і менеджер ставить їй позитивну оцінку з коментарем.

Для людини, яка відповідає за дані, тут не одна подія, а три незалежні маршрути:

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

Що обіцяють OpenAI та Anthropic: порівняння правил

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

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

Окремо про ZDR (Zero Data Retention, режим нульового зберігання). Це не синонім відмови від навчання. Відмова від навчання описує, чи йдуть ваші дані на покращення моделі. ZDR описує умови зберігання і, за документацією OpenAI, стосується визначених можливостей API. Тобто він доступний не для кожного сценарію. Якщо ваша архітектура розраховує на ZDR, перевірте кожну функцію, яку ви вмикаєте, а не лише назву режиму.

Де виникають винятки

Більшість неприємних сюрпризів з'являються не в основному правилі, а у винятках. Ось п'ять місць, які варто перевірити першими.

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

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

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

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

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

Що перевіряє адміністратор перед підключенням

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

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

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

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

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

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

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

Як ухвалити рішення: паспорт дозволеного сценарію

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

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

Що зробити найближчим часом:

1. Випишіть два-три реальні сценарії, у яких працівники вже використовують або хочуть використовувати ШІ.
2. Для кожного намалюйте маршрути даних, як у прикладі з договором: діалог і файли, інтеграції, зворотний зв'язок.
3. Заповніть таблицю правил постачальника з прямими посиланнями та датою перевірки. Невідомі значення позначте як відкриті питання.
4. Перевірте адміністративні налаштування: зворотний зв'язок, конектори, ролі, видалення.
5. Оформіть паспорт кожного сценарію і призначте власника, який повторно перевірить умови до визначеної дати.

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

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