Meridian Line's safety-review summarizer ingests near-miss and injury narratives that name crew members and include passport numbers. Before those narratives are chunked and embedded into the retrieval index, what should the data engineering team do to satisfy Meridian Line's PII policy?
Select an answer to reveal the explanation.
Short Explanation
Masking has to happen before the personal data ever becomes a vector. Once a passport number is baked into an embedding, restricting the front door doesn't un-bake it, so scrub the Delta table first and only chunk and embed the masked version.
Full Explanation
PII protection in a GenAI application has to happen at the earliest point the data is durably captured, because anything embedded into a vector index is now retrievable by any query that reaches it. The correct move is to detect and mask PII fields, crew names and passport numbers, in the Delta table before chunking and embedding, so the vectors never encode the sensitive values. A system-prompt instruction not to repeat PII is unreliable: the model can still surface a value verbatim from retrieved context regardless of instructions, and the raw value still sits in the index and any downstream export. Restricting query access to the vector index is a useful layer but does not fix the underlying problem, since the raw PII is still stored and still exposed to the embedding model provider and anything else with access to the source table. Redacting after generation is the weakest option: the model has already been exposed to the raw PII during retrieval, and a post-hoc output filter only catches what it happens to recognize, not what actually left the source of truth. Exam framing: PII protection is a data-preparation-and-governance step applied before ingestion, not a prompting trick or an output-filtering afterthought.