Штучний інтелект зручно просити скоротити документ, виправити лист, підсумувати договір, проаналізувати таблицю, знайти помилки в коді або підготувати відповідь клієнту. Саме в таких побутових робочих задачах найчастіше й виникає ризик: людина завантажує у чат-бот повний файл, хоча для відповіді достатньо одного абзацу без імен, номерів, адрес, сум, паспортних даних і деталей угоди.
Проблема не в самому факті використання ШІ, а в тому, які дані потрапляють у запит. У 2025 році аналіз реальних запитів до інструментів ШІ, про який повідомляла Tele2, показав: чутливі корпоративні дані були більш ніж у кожному п’ятому завантаженому файлі. Серед них траплялися програмний код, клієнтська інформація та внутрішні документи компаній.
Безпечне використання ШІ починається з простого правила: перед відправленням тексту або файлу потрібно прибрати все, що не потрібне для виконання задачі. Чат-боту не потрібні реальні ПІБ, телефони, адреси, банківські реквізити, паспортні номери, медичні дані, внутрішні ціни, паролі, токени доступу або повна база клієнтів, щоб відредагувати стиль листа чи зробити коротке резюме.
Чому завантаження файлів у ШІ може бути ризиком
Коли ви вставляєте текст у чат-бот або завантажуєте документ, ви передаєте інформацію зовнішньому цифровому сервісу. Далі все залежить від конкретного інструменту: його політики конфіденційності, налаштувань облікового запису, типу тарифу, умов зберігання даних, доступу адміністраторів, журналювання, підрядників, інтеграцій і можливості використання даних для покращення моделей.
Національний центр кібербезпеки Великої Британії радить не включати чутливу інформацію в запити до публічних великих мовних моделей і не надсилати такі запити, які створили б проблеми у разі публічного розкриття. NCSC також підкреслює: перед роботою з чутливою інформацією потрібно розуміти умови використання та політику конфіденційності сервісу.
Для приватного користувача ризик може виглядати як витік номера паспорта, телефону, адреси, медичного діагнозу або фінансових даних. Для компанії — як розкриття клієнтської бази, комерційної пропозиції, договору, коду, внутрішньої інструкції, стратегії, фінансового плану або деталей перемовин.
Окремий файл може здаватися безпечним. Але кілька дрібних фрагментів легко складаються в повну картину: хто клієнт, яка ціна, які умови, хто ухвалює рішення, які слабкі місця в договорі, які технології використовує компанія та де зберігаються її дані.
Який пошуковий інтент має ця тема
Інтент змішаний: інформаційний, інструкційний і безпековий. Користувач хоче зрозуміти, які дані не можна давати ШІ, чи небезпечно завантажувати документи в ChatGPT або інші чат-боти, як анонімізувати файл, чим відрізняється публічний сервіс від корпоративного рішення, як працювати з робочими матеріалами без витоку та які помилки найчастіше роблять працівники.
Тому відповідь має бути практичною: не залякувати ШІ, а дати чітку систему перевірки даних перед відправленням.
Які дані не варто передавати ШІ
Найризикованіші дані — ті, які можуть ідентифікувати людину, дати доступ до грошей або акаунтів, розкрити комерційну таємницю, порушити договір про нерозголошення або створити юридичні наслідки.
Не варто передавати у публічні ШІ-сервіси:
паспортні дані, ІПН, номери документів;
адреси проживання, телефони, особисті електронні пошти;
банківські картки, рахунки, IBAN, фінансові виписки;
паролі, одноразові коди, токени, API-ключі;
медичні аналізи, діагнози, історії хвороби;
дані дітей, родичів, клієнтів, пацієнтів, працівників;
повні договори з реальними сторонами, сумами й умовами;
клієнтські бази, CRM-експорти, списки контактів;
комерційні пропозиції з цінами, маржею, знижками;
внутрішні політики, інструкції, звіти, плани продажів;
програмний код закритого продукту;
ключі доступу, конфігураційні файли, журнали з адресами серверів;
листування з юристами, банками, партнерами або держорганами;
документи під NDA або з позначкою “confidential”.
OWASP відносить розкриття чутливої інформації до ключових ризиків LLM-застосунків. До такої інформації належать персональні дані, фінансові деталі, медичні записи, конфіденційні бізнес-дані, облікові дані безпеки та юридичні документи.
Чому “звичайний документ” теж може бути небезпечним
Найчастіше люди бояться передавати ШІ паролі або карткові дані, але спокійно завантажують договори, комерційні листи, резюме, службові нотатки, таблиці, протоколи зустрічей і чернетки презентацій. Саме такі файли часто містять більше чутливої інформації, ніж здається.
Наприклад, у звичайному листі клієнту можуть бути:
ім’я та посада конкретної людини;
назва компанії;
суть проблеми;
внутрішня ціна;
дедлайн;
умови знижки;
слабке місце в перемовинах;
деталі майбутньої угоди.
Для задачі “зроби лист ввічливішим” чат-боту не потрібна реальна назва клієнта, повна сума, номер договору й адреса доставки. Можна замінити їх на нейтральні позначення: “Клієнт А”, “Компанія Б”, “сума договору”, “дата поставки”, “номер документа”.
Tele2 у власних рекомендаціях описує саме цю проблему: користувач хоче виправити стиль листа або скоротити документ, але копіює весь текст, і разом із ним у систему потрапляють імена, телефони, адреси, фінансові дані та інша інформація, яка не потрібна для завдання.
Публічний чат-бот і корпоративний ШІ: у чому різниця
Публічний ШІ-сервіс — це інструмент, яким користувач користується самостійно, часто з особистого акаунта. Компанія може не бачити, які файли туди завантажують працівники, чи вимкнене навчання на даних, де зберігається історія, хто має доступ до чату та які сторонні розширення підключені.
Корпоративне рішення зазвичай має більше контролю: адміністрування користувачів, ролі, журналювання, обмеження доступу, політики зберігання, договір обробки даних, налаштування щодо навчання моделей, інтеграцію з внутрішніми системами та правила, хто може працювати з якими даними.
OpenAI, наприклад, зазначає, що за замовчуванням не використовує дані з ChatGPT Enterprise, ChatGPT Business, ChatGPT Edu, ChatGPT for Healthcare, ChatGPT for Teachers та API Platform — включно з введенням і виведенням — для навчання або покращення моделей. Компанія також вказує на шифрування даних у стані зберігання та під час передавання.
Це не означає, що будь-який корпоративний ШІ автоматично безпечний для всього. Організація все одно має визначити, які категорії даних дозволено обробляти, хто має доступ, які інтеграції ввімкнені, скільки часу зберігаються запити, чи ведуться журнали, як працює видалення та що відбувається з файлами після завершення задачі.
“Мої дані підуть у навчання моделі?” — правильне питання, але не єдине
Багато користувачів зводять ризик до одного запитання: чи навчиться модель на моєму документі. Насправді це лише один із можливих сценаріїв. Навіть якщо сервіс не використовує дані для навчання, вони можуть тимчасово зберігатися для роботи сервісу, безпеки, журналювання, підтримки, аудиту або виконання функцій акаунта.
OpenAI у довідкових матеріалах зазначає, що у ChatGPT Business, ChatGPT Enterprise, ChatGPT Edu та API Platform введення й виведення за замовчуванням не використовуються для навчання моделей; для особистих робочих просторів користувачі можуть вимкнути використання нових розмов для покращення моделей.
Тому перед роботою з чутливими матеріалами потрібно перевірити ширший список:
чи використовується контент для навчання;
чи можна вимкнути навчання;
скільки часу зберігаються запити;
чи доступні чати адміністраторам;
чи є історія розмов;
чи передаються дані третім сторонам;
чи є розширення, плагіни, конектори;
чи можна видалити файл і чат;
чи є договірні гарантії для бізнесу;
чи відповідає сервіс вимогам вашої організації.
Як працює “тест публічності”
Перед тим як завантажити документ у ШІ, поставте собі питання: чи буде прийнятно, якщо цей текст побачить стороння людина. Якщо відповідь негативна, файл потрібно скоротити, знеособити або не передавати взагалі.
Тест публічності не означає, що дані справді стануть публічними. Він допомагає швидко оцінити наслідки. Якщо витік документа може нашкодити людині, компанії, клієнту, угоді, репутації, фінансам або безпеці, такий документ не підходить для необдуманого завантаження в публічний чат-бот.
Практична формула:
Що саме я хочу отримати від ШІ?
Який мінімальний фрагмент потрібен для цієї задачі?
Які дані можна прибрати або замінити?
Чи є в тексті інформація інших людей?
Чи маю я право передавати цей документ сторонньому сервісу?
Що буде, якщо цей фрагмент побачить хтось поза моєю організацією?
Якщо на будь-якому етапі виникає сумнів, краще підготувати безпечну версію файлу.
Як анонімізувати документ перед ШІ
Анонімізація — це не просто замінити ім’я на ініціали. Завдання — прибрати або замаскувати всі фрагменти, за якими можна прямо чи опосередковано ідентифікувати людину, компанію, угоду, систему або внутрішній процес.
Приклад безпечнішого підходу:
Було: “Олександр Коваленко, фінансовий директор ТОВ «Альфа», просить знижку 12% за договором №45/26 на постачання обладнання до 20 жовтня”.
Стало: “Клієнт А, представник компанії Б, просить додаткову знижку за договором на постачання обладнання до визначеної дати”.
Для редагування стилю цього достатньо. ШІ може зробити текст ввічливішим, структурованішим і зрозумілішим без реальних назв, сум, номерів і дат.
Що варто замінювати:
ПІБ → “Клієнт А”, “Працівник Б”;
назви компаній → “Компанія X”, “Партнер Y”;
телефони → “[телефон]”;
адреси → “[адреса]”;
суми → “[сума]” або умовний діапазон;
номери договорів → “[номер договору]”;
дати → “[дата]”, якщо точна дата не потрібна;
банківські реквізити → “[банківські реквізити видалено]”;
медичні дані → узагальнений опис без ідентифікації;
код із секретами → код без токенів, ключів і внутрішніх URL.
Європейська комісія пояснює принцип мінімізації даних так: персональні дані мають бути адекватними, релевантними й обмеженими тим, що потрібно для конкретної мети; за замовчуванням компанії мають обробляти тільки ті дані, які потрібні для передбаченої цілі, і надавати доступ до них обмеженому колу осіб.
Персональні дані: чому з ними потрібно бути особливо обережними
В Україні персональні дані захищені законом. Закон “Про захист персональних даних” регулює правові відносини, пов’язані із захистом і обробкою персональних даних, і спрямований на захист права на невтручання в особисте життя. У ньому також зазначено, що не допускається обробка даних про фізичну особу, які є конфіденційною інформацією, без її згоди, крім визначених законом випадків.
Для користувача ШІ це означає просту річ: якщо у файлі є дані іншої людини, не варто автоматично вважати, що ви можете передати їх будь-якому онлайн-сервісу. Особливо це стосується HR-документів, резюме, медичних довідок, клієнтських заявок, договорів, сканів документів, дитячих даних, фінансових анкет і внутрішнього листування.
Безпечніший підхід — працювати з узагальненою версією. Наприклад, замість реального резюме працівника передати структуру без імені, телефону, адреси, місця проживання, фото, посилань на профілі та колишніх роботодавців, якщо ці дані не потрібні для конкретного завдання.
Робочі документи: що особливо небезпечно завантажувати
У компаніях найбільший ризик створює “тіньове використання ШІ”: працівники користуються особистими акаунтами, щоб швидше виконати роботу, але не перевіряють, чи дозволено це політикою безпеки. Так у чат-боти потрапляють комерційні пропозиції, клієнтські листи, договори, коди, презентації для інвесторів і внутрішні таблиці.
Найризикованіші робочі файли:
договори до підписання;
юридичні висновки;
комерційні пропозиції;
фінансові моделі;
таблиці продажів;
клієнтські бази;
документи з персоналом;
внутрішні презентації;
коди продуктів;
конфігурації серверів;
лог-файли з токенами;
матеріали під NDA;
документи щодо оборони, безпеки, медицини, банків, державних систем.
CERT-EU попереджає, що використання безплатно доступних закритих AI-моделей може створювати ризики для чутливих даних у запитах: користувачі можуть ненавмисно вводити конфіденційну або персонально ідентифіковану інформацію, а без належної анонімізації та захисту такі дані можуть бути використані неправомірно або розкриті через витік.
Код, API-ключі та технічні файли
Розробники часто використовують ШІ для пошуку помилок, рефакторингу, документації та генерації тестів. Це корисно, але саме технічні файли можуть містити найкритичніші секрети: ключі доступу, токени, адреси внутрішніх серверів, назви бакетів, облікові записи, структуру бази даних, конфігурації CI/CD і логіку закритого продукту.
Перед відправленням коду потрібно прибрати:
API-ключі;
токени доступу;
приватні ключі;
паролі;
connection strings;
внутрішні URL;
IP-адреси;
назви клієнтів;
секрети з .env;
приватні репозиторії;
дані з production-логів;
комерційно чутливі алгоритми.
Краще ставити задачу ШІ не через повний проєкт, а через мінімальний відтворюваний приклад. Наприклад: “Ось спрощена функція без реальних даних. Поясни, чому вона повертає помилку”. Такий підхід зменшує ризик витоку й часто дає точнішу відповідь.
OWASP радить для LLM-застосунків застосовувати очищення даних, строгі перевірки введення, контроль доступу за принципом найменших привілеїв, обмеження джерел даних, токенізацію та редагування чутливого контенту перед обробкою.
Окремий ризик: prompt injection у файлах і вебсторінках
Не всі ризики пов’язані з тим, що користувач сам передає секрети. Є ще prompt injection — ситуація, коли шкідлива інструкція захована у файлі, вебсторінці, листі, зображенні або іншому зовнішньому контенті, який аналізує ШІ. Модель може сприйняти цю інструкцію як частину завдання й поводитися непередбачувано.
OWASP пояснює, що непряма prompt injection виникає, коли LLM приймає дані із зовнішніх джерел, наприклад сайтів або файлів, а в цьому контенті є інструкції, що змінюють поведінку моделі. Наслідки можуть включати розкриття чутливої інформації, маніпуляцію відповідями, несанкціонований доступ до функцій або виконання дій у підключених системах.
Для звичайного користувача це означає: не варто бездумно давати ШІ доступ до пошти, диска, CRM, календаря, репозиторію або месенджера з широкими правами. Якщо інструмент має агентні функції — може надсилати листи, змінювати файли, створювати задачі, робити запити до бази — потрібно обмежити права й вимагати підтвердження перед важливими діями.
Як компанії організувати безпечне використання ШІ
Повна заборона ШІ часто не працює: працівники все одно шукатимуть спосіб пришвидшити роботу. Краще дати дозволений інструмент, правила й навчання.
Мінімальна політика для компанії має відповідати на такі питання:
які ШІ-сервіси дозволені;
які дані можна передавати;
які дані заборонені;
як анонімізувати документи;
хто погоджує роботу з клієнтськими даними;
чи можна завантажувати файли;
чи дозволені розширення й плагіни;
хто має доступ до історії чатів;
як зберігаються й видаляються запити;
як перевіряти відповіді ШІ;
хто відповідає за помилку в згенерованому тексті;
що робити у випадку помилкового завантаження чутливого файлу.
NIST AI Risk Management Framework створений для добровільного використання організаціями й має допомагати враховувати довіру, ризики, оцінювання та управління під час розробки, використання й оцінки AI-систем. У 2024 році NIST також випустив профіль для генеративного ШІ, який допомагає організаціям визначати специфічні ризики таких систем і дії для управління ними.
Для бізнесу корисно не просто написати “не передавати конфіденційні дані”, а дати приклади: що робити з договором, клієнтським листом, резюме, таблицею, кодом, фінансовою моделлю, медичним документом або внутрішньою презентацією.
Практичний чекліст перед завантаженням у ШІ
Перед кожним запитом пройдіть коротку перевірку:
Чи потрібен ШІ весь файл?
Чи можна дати короткий фрагмент?
Чи є в тексті персональні дані?
Чи є дані інших людей?
Чи є фінансова інформація?
Чи є комерційні умови, ціни, маржа, знижки?
Чи є паролі, токени, ключі, внутрішні посилання?
Чи є медичні, юридичні або банківські дані?
Чи є NDA або позначка конфіденційності?
Чи дозволяє компанія використовувати цей ШІ-сервіс?
Чи вимкнене використання даних для навчання, якщо це потрібно?
Чи можна виконати задачу на знеособленому прикладі?
Якщо хоча б один пункт викликає сумнів, потрібно відредагувати документ до безпечної версії або скористатися корпоративним інструментом із належними умовами.
Як правильно формулювати запит без розкриття даних
Найкращий запит до ШІ — той, у якому є достатньо контексту для відповіді, але немає зайвих чутливих деталей.
Замість: “Ось договір із ТОВ «Ромашка» на 3,8 млн грн, перевір ризики”.
Краще: “Ось знеособлений фрагмент договору постачання. Перевір логічні ризики, нечіткі формулювання, конфліктні умови та місця, де варто звернутися до юриста”.
Замість: “Ось медичний аналіз моєї дитини з ПІБ і датою народження, поясни результат”.
Краще: “Поясни загальною мовою, що можуть означати такі показники без встановлення діагнозу. Я звернуся до лікаря для медичного рішення”.
Замість: “Ось експорт CRM з клієнтами, знайди сегменти”.
Краще: “Ось знеособлена таблиця без імен, телефонів, електронних адрес і назв компаній. Проаналізуй структуру сегментів за умовними параметрами”.
Такий підхід залишає користь ШІ, але зменшує обсяг переданих даних.
Що робити, якщо чутливий файл уже завантажили
Якщо ви випадково завантажили у ШІ документ із персональними, фінансовими або робочими даними, не варто просто закрити вкладку й забути. Потрібно діяти залежно від рівня ризику.
Порядок дій:
Видаліть файл і чат, якщо сервіс це дозволяє.
Перевірте налаштування використання даних для навчання.
Змініть паролі, токени або API-ключі, якщо вони потрапили в запит.
Повідомте відповідальну особу в компанії, якщо це робочий документ.
Зафіксуйте, що саме було передано.
Оцініть, чи були там дані клієнтів, працівників, партнерів або пацієнтів.
Перевірте політику сервісу щодо видалення й зберігання даних.
Не завантажуйте той самий файл повторно.
Підготуйте знеособлену версію для подальшої роботи.
Якщо ризик високий, залучіть фахівця з кібербезпеки або юриста.
Якщо в запиті були ключі доступу, їх потрібно вважати скомпрометованими. Недостатньо видалити чат — ключі треба відкликати й видати нові.
Типові помилки користувачів
Перша помилка — завантажувати повний документ замість потрібного уривка. Для більшості задач достатньо частини тексту.
Друга помилка — залишати імена, телефони, адреси, суми, реквізити й номери документів там, де вони не впливають на відповідь.
Третя помилка — користуватися особистим акаунтом для робочих документів. Для компанії це створює неконтрольований канал витоку.
Четверта помилка — думати, що “це просто чернетка”. Чернетки часто містять найцінніші деталі: позицію сторін, слабкі місця, внутрішні коментарі, правки, ціни й ризики.
П’ята помилка — передавати код разом із секретами. API-ключ у фрагменті коду може бути небезпечнішим за сам код.
Шоста помилка — бездумно підключати ШІ до пошти, диска або CRM. Чим ширші права інструмента, тим вищі наслідки помилки.
Сьома помилка — не перевіряти відповідь. ШІ може помилятися, вигадувати факти, неправильно трактувати документ або пропонувати юридично ризиковані формулювання.
Восьма помилка — не читати політику сервісу. У різних інструментів відрізняються правила зберігання, навчання, видалення, доступу до даних і використання сторонніх постачальників.
Висновок
ШІ може бути корисним помічником для текстів, таблиць, коду, аналізу документів і щоденних робочих задач. Але його не можна використовувати як бездонну скриньку, куди без підготовки завантажують усе підряд. Найчастіший ризик виникає не через складну хакерську атаку, а через звичайну дію користувача: скопіювати повний файл, не прибравши зайві дані.
Безпечна практика проста: перед відправленням залишайте тільки те, що потрібно для задачі, видаляйте персональні й фінансові дані, замінюйте реальні імена та компанії умовними позначеннями, не передавайте паролі, ключі, клієнтські бази, внутрішні документи й матеріали під NDA. Для роботи з корпоративною інформацією використовуйте затверджені інструменти з належними правилами доступу, зберігання й навчання моделей.
Головний тест перед запитом: чи буде шкода, якщо цей фрагмент побачить стороння людина. Якщо так — документ потрібно знеособити, скоротити або взагалі не передавати у публічний ШІ-сервіс.
FAQ
Які дані не можна передавати штучному інтелекту?
Не варто передавати паспортні дані, ІПН, банківські реквізити, паролі, API-ключі, медичну інформацію, адреси, телефони, дані дітей, клієнтські бази, договори з реальними сторонами, внутрішні документи, комерційні умови, закритий код і матеріали під NDA. OWASP відносить такі категорії до чутливої інформації, розкриття якої може створити приватні, фінансові, юридичні та бізнес-ризики.
Чи безпечно завантажувати документи в ChatGPT або інший чат-бот?
Це залежить від типу акаунта, налаштувань, політики сервісу й змісту документа. Для публічних LLM NCSC радить не включати чутливу інформацію в запити й не надсилати те, що створило б проблеми у разі розкриття.
Чи використовуються мої запити для навчання ШІ?
Умови залежать від сервісу. OpenAI зазначає, що бізнес-продукти на кшталт ChatGPT Business, Enterprise, Edu та API за замовчуванням не використовують введення й виведення для навчання моделей, а користувачі особистих робочих просторів можуть вимкнути використання нових розмов для покращення моделей.
Чи достатньо просто видалити ім’я з документа?
Ні. Потрібно прибрати всі ідентифікатори: телефони, адреси, пошти, номери документів, реквізити, точні дати, назви компаній, номери договорів, суми, унікальні обставини й інші деталі, за якими людину або угоду можна впізнати.
Чи можна передавати ШІ робочі документи?
Можна тільки в межах правил компанії та з урахуванням конфіденційності. Якщо документ містить клієнтські дані, ціни, договори, внутрішні коментарі, код, комерційну стратегію або персональні дані працівників, його потрібно знеособити або використовувати затверджений корпоративний ШІ-інструмент.
Чому небезпечно завантажувати клієнтську базу?
Клієнтська база містить персональні дані, комерційну інформацію, історію взаємодії, фінансовий потенціал і структуру бізнесу. Її передавання сторонньому сервісу без належних підстав може створити ризик витоку, порушення договорів, шкоди репутації та проблем із захистом персональних даних.
Чи можна давати ШІ код?
Можна працювати зі спрощеними фрагментами без секретів. Перед відправленням потрібно видалити API-ключі, токени, паролі, приватні URL, IP-адреси, назви внутрішніх систем, клієнтські дані, production-логи та комерційно чутливу логіку.
Що таке prompt injection?
Prompt injection — це спроба змінити поведінку ШІ через спеціальні інструкції у запиті або зовнішньому контенті. OWASP пояснює, що непряма prompt injection може бути захована у файлах, сайтах або зображеннях і призводити до розкриття чутливої інформації, маніпуляції відповідями або несанкціонованих дій у підключених системах.
Як анонімізувати файл перед завантаженням у ШІ?
Залиште тільки інформацію, потрібну для задачі. Замініть реальні імена на “Клієнт А”, компанії — на “Компанія X”, суми — на “[сума]”, телефони й адреси — на позначки, видаліть реквізити, номери документів, паролі, токени, внутрішні посилання та зайві деталі.
Що робити, якщо я випадково завантажив конфіденційний файл?
Видаліть чат і файл, якщо це можливо, перевірте налаштування приватності, змініть паролі й відкличте токени, якщо вони потрапили в документ, повідомте відповідальну особу в компанії та зафіксуйте, які саме дані були передані. Якщо ризик високий, варто залучити фахівця з кібербезпеки або юриста.
