Прибирайте персональні дані до запиту LLM
Мінімізація полів передує маскуванню, а відповідь теж потребує контролю.
Не надсилайте весь профіль
Для класифікації звернення модель може не потребувати імені, адреси та всього запису клієнта. Вибирайте поля явно, а локальний ID залишайте у своїй системі. Нове поле бази тоді не потрапить у prompt автоматично. Принцип мінімізації описано у статті 5 GDPR; застосовність закону залежить від обставин. Це не юридична консультація.
Заміни з обмеженою областю
Замініть непотрібні ідентифікатори placeholders на сервері. Для розробки використовуйте синтетичні приклади. Карту EMAIL_1 до справжнього значення тримайте окремо з обмеженим доступом, строком життя та областю дозволеного запиту. Не надсилайте її моделі й не записуйте до журналів. Псевдонімізація не гарантує анонімність: решта контексту теж може ідентифікувати людину.
Відновлення без розкриття
Відповідь моделі є недовіреними даними. Відновлюйте тільки очікувані маркери поточного запиту для отримувача з відповідним правом. Невідомий маркер не повинен витягувати чужий запис. Пропущені чи змінені placeholders обробляйте без розкриття. Журналюйте безпечну версію, не відновлений текст. Регулярні вирази охоплюють лише деякі формати телефонів і пошти, не всі імена та вільний текст.
Секрети й тести
Паролі, API-ключі, токени, сирі заголовки й рядки підключення не належать до prompt. Після розкриття секрету відкличте або замініть його через провайдера, не пересилаючи іншій моделі. Прочитайте умови конкретного API щодо збереження, навчання, видалення й логування. Перевірте свої retries, error tracking та діалоги. На штучних даних випробуйте імена, різні телефони, повтори та неочікувані маркери. Якщо безпечність вихідного запиту не підтверджено, не надсилайте його. Успішні приклади не доводять повного виявлення всіх ідентифікаторів.