IA & Njaboot

Protecting privacy requires understanding the complete data flow. Hiding a name or using a model locally does not automatically resolve every privacy risk.

Takeaway yu am solo

• Map all processing and retention locations.
• Minimize information for the task.
• Verify controls on derived data as well as originals.

Identify what enters the system and what can be inferred from it. Prompts, documents, images, voice recordings, tool results, and usage logs can all contain personal information. Record which providers and internal services process each category. Collect only what the task needs and set a retention policy. Separate temporary context from saved memory, analytics, debugging logs, and training use. Users should be able to understand the relevant settings without relying on an assistant’s unsupported statement about its own behavior. Apply access controls to original and derived data. Search indexes, embeddings, cached responses, and exported reports can reveal information even after the original upload is removed. Test deletion and account isolation through the actual application. Assess technical privacy claims carefully. De-identification and synthetic data can have limitations, while formal methods such as differential privacy depend on their mechanism and parameters. Review the intended use, threat model, and applicable requirements with appropriate expertise when handling consequential data.

1. Suppose a team needs a sample message to test classification. The original includes a full address, order number, and unrelated medical detail.
2. Replace or remove fields that are unnecessary for the test, using clearly fictional placeholders.
3. Keep any remaining real information under the documented access and retention controls instead of assuming the sample is anonymous.

This hypothetical exercise reduces unnecessary exposure without claiming that simple redaction proves anonymity.