Приватність і дані: чого не вставляти в ШІ
Розмови з інструментами ШІ здаються приватними, але дані потрапляють до зовнішнього сервісу. Тому добре мати звичку: спершу подумай, що вставляєш.
Чого не вставляти
- Паролів, ключів API, токенів доступу та файлів з обліковими даними.
- Персональних даних: імен з адресами, номерів документів, телефонів, е-мейлів клієнтів.
- Документів, що становлять комерційну таємницю або охоплені угодою про конфіденційність.
- Повних баз даних і журналів, у яких можуть ховатися дані користувачів.
- Чужого коду, якщо ви не маєте дозволу на його обробку зовнішніми сервісами.
Як робити це безпечно
- Замініть дані вигаданими. Замість справжньої адреси е-пошти впишіть
jan@example.com. - Тримайте секрети поза кодом. Використовуйте змінні середовища й простежте, щоб файл із ними не потрапив до репозиторію.
- Вставляйте мінімум. Зазвичай досить одного фрагмента й повідомлення про помилку.
- Перегляньте результат перед надсиланням. Шукайте ключі, адреси й назви приватних серверів.
Налаштування сервісу
Перевірте в умовах і налаштуваннях, чи можуть розмови використовуватися для вдосконалення моделей, як довго вони зберігаються і чи можна їх видалити. Правила різняться між сервісами й тарифами, а корпоративні облікові записи часто мають окремі умови.
Коли ключ усе ж витік
- Негайно анулюйте його й згенеруйте новий.
- Перевірте, чи його не збережено в історії Git або не опубліковано на сайті.
- Загляньте в журнали сервісу, якого стосувався ключ, чи немає нетипової активності.
Власні проєкти й дані інших людей
Якщо ви створюєте сайт, що збирає дані (форма, реєстрації, облікові записи), ви відповідаєте за їх захист. Збирайте лише потрібне, інформуйте користувачів і перевірте правові вимоги, чинні у вашій країні, наприклад GDPR у Європейському Союзі. Цей текст не є юридичною порадою.
Більше про помилки коду та захист: ризики коду, згенерованого ШІ.
