Які відомості заборонено передавати штучному інтелекту: поради щодо безпечного використання ШІ без ризику витоку особистої та професійної інформації -- online.ua

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

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

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

Чому завантаження файлів у ШІ може бути ризиком

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

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

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

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

Який намір пошуку пов’язаний з цією темою?

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

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

Які дані не варто передавати ШІ

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

Не варто передавати у публічні ШІ-сервіси:

* дані паспорта, ідентифікаційний номер, реквізити документів;

* місця проживання, контактні номери телефонів, особисті електронні адреси;

* платіжні картки, рахунки, міжнародний банківський номер (IBAN), фінансові звіти;

* паролі, тимчасові коди, токени доступу, ключі API;

* аналізи здоров'я, медичні висновки, записи про хвороби;

* інформація про дітей, членів родини, клієнтів, пацієнтів, співробітників;

* повні договори з реальними сторонами, сумами й умовами;

* бази клієнтів, експорти CRM-систем, контактні списки;

* комерційні пропозиції з цінами, маржею, знижками;

* внутрішні політики, інструкції, звіти, плани продажів;

* програмний код закритого продукту;

* ключі доступу, конфігураційні файли, журнали з адресами серверів;

* обмін інформацією з адвокатами, фінансовими установами, бізнес-партнерами або державними органами;

документи, що підпадають під угоду про нерозголошення (NDA) або мають маркування "конфіденційно".

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

Чому "звичайний документ" може нести ризики?

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

Наприклад, у стандартному листі для клієнта можуть міститися:

* ім'я та посада конкретної людини;

* найменування підприємства;

* основа питання;

* внутрішня ціна;

* дедлайн;

* правила надання знижки;

* вразливий аспект у переговорах;

* деталі майбутньої угоди.

У випадку задачі "покращити ввічливість листа" чат-боту не потрібно знати справжнє ім'я клієнта, загальну суму, номер угоди чи адресу доставки. Їх можна замінити на загальні терміни: "Клієнт 1", "Фірма 2", "сума угоди", "дата доставки", "номер документа".

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 жовтня.

Стало: "Клієнт А, представник компанії Б, просить додаткову знижку за договором на постачання обладнання до визначеної дати".

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

Що варто замінювати:

* ПІБ → "Клієнт А", "Працівник Б";

* назви підприємств → "Фірма A", "Союз B";

* телефоны → "[телефон]";

* адреси → "[локація]";

* суми → "[сума]" або умовний інтервал;

* номери договорів → "[номер договору]";

* використати → "[дата]", якщо конкретна дата не є необхідною;

* банківські реквізити → "[банківські реквізити видалено]";

* медичні дані → узагальнений опис без ідентифікації;

* код із прихованими даними → код без токенів, ключів або внутрішніх URL-адрес.

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

Особисті дані: чому важливо дотримуватися обережності в їх використанні.

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

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

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

Робочі документи: що особливо небезпечно завантажувати

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

Найбільш небезпечні робочі документи:

* договори до підписання;

* правові висновки;

* комерційні оферти;

* фінансові моделі;

* звіти про реалізацію;

* бази даних клієнтів;

* документи, що стосуються співробітників;

* внутрішні демонстрації;

* коди продуктів;

* налаштування серверів;

* лог-файли з токенами;

* матеріали під NDA;

* матеріали, пов’язані з обороною, безпекою, охороною здоров'я, фінансовими установами та державними структурами.

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

Коди, ключі API та технічна документація.

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

Перед тим, як надіслати код, необхідно усунути:

* Ключі доступу до API;

* токени доступу;

* особисті ключі;

* кодові слова;

* database connection details

* внутрішні гіперпосилання;

* Адреси IP

* імена замовників;

* секрети з .env;

* приватні репозиторії;

* інформація з журналів виробництва;

* алгоритми з комерційною чутливістю.

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

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

Специфічний ризик: введення команд через підказки у документах і веб-сторінках.

Не всі ризики пов'язані з тим, що користувач сам передає секрети. Є ще prompt injection -- ситуація, коли шкідлива інструкція захована у файлі, вебсторінці, листі, зображенні або іншому зовнішньому контенті, який аналізує ШІ. Модель може сприйняти цю інструкцію як частину завдання й поводитися непередбачувано.

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

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

Як підприємствам забезпечити безпечне впровадження штучного інтелекту

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

Основні принципи політики компанії повинні враховувати наступні запитання:

* які сервіси штучного інтелекту є дозволеними;

* які дані можна передавати;

* які відомості підпадають під заборону;

* як приховати особисті дані в документах;

* хто погоджує роботу з клієнтськими даними;

Чи є можливість завантажувати файли?

* чи допускаються доповнення та плагіни;

* хто має доступ до історії чатів;

* як зберігаються та видаляються запити;

* як перевіряти відповіді ШІ;

* хто несе відповідальність за помилку в створеному тексті;

Які дії слід вжити, якщо помилково завантажено конфіденційний файл?

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

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

Практичний чекліст перед завантаженням у ШІ

Перед кожним запитом виконайте швидку перевірку:

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

Як коректно скласти запит, не розкриваючи інформацію

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

Замість: "Ось договір із ТОВ "Ромашка" на 3,8 млн грн, перевір ризики".

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

Ось медичний звіт про мою дитину, з вказаними прізвищем, ім'ям та датою народження. Можеш роз'яснити отримані результати?

Зрозуміліше: "Роз'ясни, будь ласка, на загальному рівні, що можуть означати ці показники без визначення конкретного діагнозу. Я планую звернутися до лікаря для отримання медичної консультації."

Замість: "Ось експорт CRM з клієнтами, знайди сегменти".

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

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

Що робити, якщо конфіденційний файл вже був завантажений?

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

Алгоритм дій:

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

Звичайні помилки, які роблять користувачі

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

Друга помилка -- залишати імена, телефони, адреси, суми, реквізити й номери документів там, де вони не впливають на відповідь.

Третя помилка полягає в використанні особистого акаунту для ведення робочих документів. Це може призвести до виникнення неконтрольованого каналу витоку інформації для компанії.

Четверта помилка – вважати, що "це лише чернетка". На етапі чернетки можна знайти найцінніші аспекти: позиції учасників, вразливі місця, внутрішні коментарі, правки, ціни та можливі ризики.

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

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

Сьома помилка -- не перевіряти відповідь. ШІ може помилятися, вигадувати факти, неправильно трактувати документ або пропонувати юридично ризиковані формулювання.

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

Резюме

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

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

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

FAQ

Які дані не можна передавати штучному інтелекту?

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

Чи є безпечним завантаження документів до ChatGPT або подібних чат-ботів?

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

Чи застосовуються мої запити для навчання штучного інтелекту?

Умови можуть варіюватися залежно від сервісу. OpenAI підкреслює, що бізнес-рішення, такі як ChatGPT Business, Enterprise, Edu та API, за замовчуванням не використовують дані користувачів для навчання моделей. Користувачі особистих робочих просторів мають можливість відключити використання нових розмов для вдосконалення моделей.

Чи буде достатньо лише прибрати ім'я з документа?

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

Чи дозволено передавати робочі документи штучному інтелекту?

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

Чому ризиковано завантажувати базу даних клієнтів?

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

Чи можна давати ШІ код?

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

Що таке ін'єкція запитів?

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

Як анонімізувати файл перед завантаженням у ШІ?

Видаліть все, що не стосується задачі. Змініть реальні імена на "Клієнт А", назви компаній на "Компанія X", суми на "[сума]", а телефони та адреси замініть на відповідні позначки. Приберіть реквізити, номери документів, паролі, токени, внутрішні посилання та інші зайві деталі.

Що слід зробити, якщо я ненавмисно завантажив секретний документ?

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