Чого ніколи не слід ділитися з чат-ботами ШІ

Коротке правило

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

Це не означає, що кожен AI-чатбот небезпечний. Це означає, що їх слід розглядати як потужні онлайн‑інструменти, а не як безпечні сховища. Якщо вам потрібен більш широкий посібник із налаштувань, прочитайте Налаштування конфіденційності AI-чату. Якщо ваш ризик пов'язаний з інструментами, користувацькими діями або конекторами, поєднайте цей посібник з Чи безпечні GPT, агенти та MCP-конектори? .

Чого ніколи не слід ділитися з AI-чатботами

Нижче наведені категорії — найпоширеніші випадки, коли люди надмірно діляться в AI-чатах. Деякі з них очевидно чутливі. Інші здаються нешкідливими, поки контекст не перетворить їх на проблему приватності, юридичну або безпекову.

1. Паролі, облікові дані для входу та коди відновлення

Ніколи не вставляйте паролі, одноразові коди, резервні коди, посилання для скидання, сесійні токени або секретні відповіді. Це безпосередні матеріали для доступу до акаунтів. Якщо потрібна допомога, використовуйте плейсхолдери на кшталт [PASSWORD] or [2FA CODE] і опишіть ситуацію, не ділячись справжнім секретом.

2. API-ключі, приватні ключі, токени та інші секрети

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

3. Банківська, карткова та платіжна інформація

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

4. Державні документи, податкові декларації та офіційні документи

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

5. Медична, пов’язана зі здоров’ям, та надто особиста інформація

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

6. Конфіденційні робочі документи та внутрішня бізнес-інформація

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

7. Дані клієнтів, працівників та будь‑які ПІІ, пов’язані з реальними людьми

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

8. Контракти, юридичні проекти та матеріали, що покриваються NDA

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

9. Чутливий вихідний код, внутрішня архітектура та деталі безпеки

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

10. Будь‑що, що відкрито через підключені інструменти, агенти, застосунки або інтеграції, які ви не повністю розумієте

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

Приклади сірої зони

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

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

Класифікація даних перед вставленням

Практичний спосіб зменшити помилки — класифікувати інформацію перед тим, як вирішити, чи має її бачити AI-чатбот. Проста модель із чотирьох рівнів підходить для багатьох команд: Public, Internal, Confidential, та Restricted.

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

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

Що робити натомість

Хороша новина: AI все ще може бути корисним без доступу до сирого секрету, сирого контракту або сирого файлу клієнта.

Спочатку редагуйте (redact)

Видаліть імена, секрети, ідентифікатори, номера рахунків, внутрішні URL-адреси та непотрібні метадані. Замініть їх на плейсхолдери, наприклад [CLIENT_NAME], [API_KEY], [INTERNAL_URL], або [EMPLOYEE_EMAIL].

Підсумуйте замість завантаження сирого матеріалу

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

Використовуйте безпечні внутрішні посилання та довірені робочі процеси

Якщо ваше питання дійсно про налаштування, почніть з Налаштування конфіденційності AI-чату. Якщо питання про ризики інструментів, перегляньте Чи безпечні GPT, агенти та MCP-конектори? . Якщо питання про те, як працюють зовнішні інструменти, фонова інструкція з Model Context Protocol (MCP) допоможе прояснити межу довіри. Якщо вам потрібен швидший спосіб вирішити, з яким рівнем даних ви маєте справу, спочатку скористайтеся Пояснення класифікації даних перш ніж щось ділитися.

Бізнес проти персональних акаунтів

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

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

Швидкий чекліст перед вставленням чого-небудь

• Чи ідентифікує це реальну особу прямо чи опосередковано?
• Чи спричинить витік фінальну, юридичну, приватну або безпекову шкоду?
• Чи знаю я, чи це публічно, внутрішньо, конфіденційно чи обмежено?
• Чи покриває це NDA, політика компанії або професійна конфіденційність?
• Чи можу я спочатку редагувати імена, ідентифікатори, секрети та подробиці акаунтів?
• Чи можу я поставити питання без сирого документа або файлу?
• Чи використовую я затверджений бізнес-акаунт замість персонального?
• Чи увімкнені зараз додаткові інструменти, застосунки, агенти або коннектори?

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

Офіційні посилання та додаткова література

• OpenAI: Поширені запитання про використання даних у споживчих сервісах
• OpenAI: Поширені запитання про елементи керування даними
• Anthropic Privacy Center: Чи використовуються мої дані для навчання моделей?
• Google: Центр конфіденційності для застосунків Gemini
• Google Workspace: Як Gemini у Workspace захищає ваші дані
• Microsoft: елементи керування конфіденційністю Copilot
• Mistral: Чи можу я відмовитися від використання моїх вводів або виводів для навчання?
• OWASP: Топ‑10 для застосувань на базі LLM 2025
• NIST: Визначення персонально ідентифікованої інформації
• FTC: Поради щодо запобігання крадіжці особистості

Поширені запитання