A city open-data team strips direct identifiers before sending a dataset to a cloud EDA assistant. What control against data exposure is this?
Select an answer to reveal the explanation.
Short Explanation
Before the cloud assistant sees the table, peel off the name tags. Stripping direct identifiers is basic exposure control for AI-assisted analysis. Raw identity fields and personal consumer uploads are how civic data leaks start.
Full Explanation
Stripping direct identifiers before sending a dataset to a cloud EDA assistant is an exposure-reduction control: names and other direct identifiers are removed so AI-assisted analysis proceeds with less personal data than the source extract contains. Open-data and analytics teams use minimization to shrink breach and contract risk when third-party or cloud tooling is involved. The practice is necessary hygiene, though not always sufficient alone against re-identification via quasi-identifiers.
Maximizing re-identification by keeping full names in every row fails because it needlessly expands exposure for exploratory analysis that rarely requires identity. Emailing the raw extract to a personal consumer AI account fails by concept and policy: personal accounts bypass enterprise DPAs, logging, and retention limits. Disabling all access logs for cloud analysis sessions fails because accountability and investigation depend on telemetry when civic data leaves the usual warehouse path.
Exam caveat: Removing direct identifiers is not full anonymization; rare attributes and linkages can still re-identify. Cloud EDA still needs approved vendors, BAAs/DPAs where applicable, and purpose limitation.
Operational check: Apply an identifier-stripping checklist before any cloud assistant upload, prefer aggregates when possible, keep session logs enabled, ban personal consumer accounts for city extracts, and review outputs for residual identifying echoes before sharing.