AI Data & Privacy interview questions
AI Data & Privacy questions a AI engineer can be asked, from first job to senior. Open one to see the strongest answer and why it works.
Before your code sends a user’s text to a hosted model API, what questions do you ask about that data?
The strongest answer: What is in it — personal details, health or financial data, credentials, a customer’s confidential material; whether the task needs it at all; and where it ends up: the provider, our logs, our traces. Then I send the minimum
Why it works: Exactly — classify, minimise, and know every place the text lands. A model call is a transfer of data to a third party, plus copies in your own logs.
- A model call is a data transfer.
- Classify what is in the text.
- Send only what the task needs.
- Know every place it is stored.
You need an LLM to summarise support tickets that contain names, phone numbers and the odd card number. How do you handle the personal data?
The strongest answer: Detect it before the call: what the task does not need, like card numbers, is dropped; the rest become stable placeholders, mapped back on our side. I test the detector on real tickets because it misses things
Why it works: Exactly — minimise first, pseudonymise the rest, keep the key at home, and measure the detector rather than trust it. Stable placeholders keep the summary readable.
- Redact before the call, not in it.
- Drop what the task does not need.
- Placeholders out; the mapping stays home.
- Measure what the detector misses.
For debugging, your service logs every prompt and completion in full. What is the privacy problem, and what do you do about it?
The strongest answer: Those logs are now a second store of personal data. I set a retention period, restrict who can read them, redact on write where I can, keep a sample rather than everything, and make sure deletion requests reach them
Why it works: Exactly — debugging is a legitimate purpose, but it needs limits: how long, who, how much, and a deletion path. Otherwise the log outlives every promise the product makes.
- Prompt logs are a personal-data store.
- Set retention and restrict access.
- Redact on write; sample, don’t hoard.
- Make deletion requests reach the logs.
Your RAG product serves many companies from one vector index. How do you guarantee one tenant never sees another tenant’s content?
The strongest answer: The server applies the tenant filter from the authenticated session on every query — or tenants get separate namespaces — never from the prompt or a model-supplied argument. Memory and caches follow the same rule, with cross-tenant tests in CI
Why it works: Exactly — isolation is an authorisation decision, so code makes it from the session, below the model. A test that tries to cross the line keeps it true after the next refactor.
- Tenant isolation is authorisation, not relevance.
- Filter from the session, server-side.
- Cover memory, caches and logs too.
- Test cross-tenant access in CI.
You are choosing a hosted model provider for a feature that handles customer data. What do you check in their data terms before you sign?
The strongest answer: Whether our data trains their models, opt-in or opt-out; what is retained, how long and why; whether zero retention is available to us; sub-processors and regions — all in the contract, not a blog post
Why it works: Exactly — training use, retention, zero-retention options, sub-processors and location differ by provider, by product tier and over time, so you read the agreement you are actually signing.
- Read the data terms you actually sign.
- Training use: opt-in or opt-out?
- Retention, zero-retention, sub-processors, region.
- Contract and DPA, not a web page.
An enterprise customer in the EU will sign only if their data “stays in the EU”. Your product calls a hosted model, keeps embeddings in a vector store and traces every request.
What has to be true before you can say yes?
The strongest answer: Every stop on the path is in region: the inference endpoint, anything the provider retains, our vector store, traces, backups and eval sets — backed by contract, per-tenant regional routing, and honesty about any gap
Why it works: Exactly — residency is a property of the whole data flow, including the copies nobody thinks of. Map it, contract it, route it, and tell the customer plainly where you cannot meet it yet.
- Residency covers the whole data path.
- Map inference, retention, stores, traces, backups.
- Get regions and sub-processors in writing.
- Say plainly what cannot comply.
A bank wants your AI feature, and its security and privacy teams will review it before any contract. Sales asks you what to prepare, and hopes a one-page summary will do.
What do you expect to have ready, and what do you refuse to gloss over?
The strongest answer: A data-flow map naming every provider, the DPA and sub-processors, retention and deletion, tenant isolation, access control with audit logs, an admin off-switch for AI — and straight answers about what we have not built
Why it works: Exactly — enterprise reviewers want to trace their data end to end and see who can touch it. An admitted gap with a date attached survives review; a discovered omission does not.
- Show the data flow; hide nothing.
- Name every provider and sub-processor.
- Prove isolation, access control and audit.
- State gaps honestly, with a plan.