A city business-license fraud model collects dozens of applicant attributes. After a privacy review, which redesign best applies data minimization?

Data minimization for a municipal business-license fraud model means retaining only applicant attributes that are necessary and proportionate to the stated fraud-detection purpose, then dropping unused personal fields from the training set after a privacy review. That redesign shrinks the civic privacy and breach surface: fewer sensitive columns travel through feature stores, notebooks, backups, and vendor transfers, and the city can demonstrate need-to-know alignment with privacy policy and records schedules. Keeping only fraud-relevant signals also reduces the chance that a compromised training pipeline exposes tax, health, or school-adjacent data that never belonged in the model. In practice, analysts document which fields contribute to fraud labels, retire speculative demographics, and retrain on the minimized schema so downstream embeddings and logs inherit the smaller footprint.

Replacing direct identifiers with salted hashes and retaining supporting attributes to preserve modeling flexibility fails minimization because salted hashing only pseudonymizes identifiers; it does not remove the unused personal attributes from the training set, so fields the fraud model never needed still travel through the pipeline. Encrypting applicant attributes at rest with AES-256 and controlling feature access through role-based permissions fails because encryption and access controls secure confidentiality of whatever is retained; they do not shrink what was collected or satisfy purpose limitation for fields the fraud model never needed. Scoping active training to current fraud indicators and retaining prior applicant snapshots to support future retuning fails because the minimization gain is undone if the retired fields still sit, fully populated, in prior snapshots the city keeps just in case.

Exam caveat: Minimization is not the same as salted hashing identifiers or encryption with role-based access controls, and it is not satisfied by fixing only new runs while prior applicant snapshots and backups keep the unused fields forever. Do not confuse "useful someday" research retention with purpose limitation for the production fraud model.

Operational check: After the privacy review, verify the training schema and feature-store definitions contain only approved attributes; confirm unused PII columns are dropped from pipelines, snapshots, and vendor exports, including historical copies; sample recent training runs for prohibited fields; and re-check encryption and access controls on the reduced dataset so minimization and confidentiality controls both remain enforced for the city license program.