Handling personal data (PII) in LLM applications without it leaking where it shouldn't

Sending user PII to a third-party LLM API, logging it in plaintext, or letting it leak into a training set are three distinct risks. What to actually do about each.

Written by

Pranjul Rathour

GenAI Engineer at SCULT INDIA, based in Kanpur, India. Builds production RAG systems, fine-tunes open LLMs and ships agentic AI products; has mentored 200+ college developers. Open to GenAI roles, hackathon judging, mentorship sessions and guest talks.

pranjulrathour41@gmail.com LinkedIn GitHub X Instagram Bluesky Dev.to

Personal data in an LLM application creates three distinct risks that need three distinct fixes: sending it to a third-party API, logging it insecurely, and it accidentally leaking into any training data.

Three separate problems, three fixes

Sending to a third-party API: check the provider's data-handling policy, and redact or mask PII before sending when the task doesn't genuinely require it.
Logging: never log full prompts or responses in plaintext if they contain PII; log hashes, redacted versions, or restrict access to logs strictly.
Training data: if you ever fine-tune on real user data, scrub PII from the dataset first — a model can memorise and later regurgitate specific training examples.

The habit that prevents most mistakes

Ask, for every piece of data flowing through the system, whether it actually needs to be there in that form. Most PII exposure in student projects comes from data flowing further than the task required, not from a deliberate decision to expose it.

See secrets management for student projects.

— Pranjul Rathour, GenAI Engineer from Kanpur, India. Open to GenAI roles, hackathon judging, mentorship sessions and guest talks at any campus: pranjulrathour41@gmail.com.