Question presented to candidate: "We want to use a hosted LLM to draft replies to customer support tickets. The tickets contain names, emails, phone numbers and sometimes card numbers, and legal is nervous. How would you design the system so we can use the model without mishandling personal data?"
What a strong answer should cover:
- Data minimisation first: send only what the task needs, and map every place the data goes (the provider, your logs and traces, caches, vector stores, eval sets), not just the API call
- Detection and redaction before the call: regex with validation (such as the Luhn checksum for cards), named-entity recognition, known values from your own database, and typed placeholders the model can still reason about, with a local mapping to rehydrate the reply
- The limits of redaction: free-text names and context leak, detectors have false positives and negatives, and pseudonymised data is still personal data under GDPR
- Provider and contract controls: retention and training terms, zero data retention and abuse-monitoring options, BAAs for health data, regional processing, and which features (files, batches, stored responses) keep data longer
- Your own side and the output side: scrubbed logs with keyed tokens instead of raw values, retention and deletion across every copy, and checking model output before it reaches a user or a log
Clarifying questions expected:
- Which kinds of data and which jurisdictions (GDPR, HIPAA, PCI DSS for cards)?
- Does the task actually need the personal data, or only its type (that an email exists, not what it is)?
- Which provider, and what contract terms or retention arrangements are already in place?
Code / implementation expected: Optional โ a redact, call, rehydrate pipeline with typed placeholders, or a data-flow diagram showing where personal data is stored.