A housing authority uses synthetic tenant profiles for model evaluation alongside a smaller set of real PII records. How should these be reflected in the AI data inventory?
Select an answer to reveal the explanation.
Short Explanation
Fake profiles and real tenant files are not the same drawer. Label synthetic evaluation data apart from genuine PII so handling rules stay honest. Mixing them under one casual tag is how temporary tests become permanent privacy headaches.
Full Explanation
Housing-authority AI data inventory must classify and track synthetic evaluation profiles separately from real tenant PII used in testing because the two classes carry different legal, retention, and handling obligations. Separate tracking keeps minimization honest, prevents synthetic labels from laundering real PII, and ensures access controls and disposal schedules match actual sensitivity. Merge under one unrestricted public label to simplify storage collapses protections and can expose tenant identifiers under a false public tag. Inventorying only synthetic profiles while ignoring real PII because evaluation is temporary leaves the highest-risk data untracked precisely when copies proliferate for testing. Treating all evaluation data as non-assets until production cutover invents a grace period that security lifecycle management does not recognize; test PII is still an asset. Exam caveat: synthetic data can still re-identify or encode real distributions, so separation does not mean zero controls—only appropriately distinct classification and tracking. Operational check: maintain inventory fields for data type (synthetic vs real), linked system, owner, classification, and retention; spot-check evaluation buckets to ensure real tenant PII is not mixed unlabeled with synthetic profiles.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.