A permitting AI ingests applicant Social Security numbers without a data-minimization review. What should the auditor recommend first?

The auditor should first recommend evaluating whether SSNs are necessary inputs and applying data minimization before allowing continued model use of that field. Permitting AI that ingests applicant Social Security numbers without a minimization review creates high-sensitivity exposure that may be unnecessary for the decision task. Privacy and data governance for civic AI require asking whether each field is needed, proportionate, and protected—not defaulting to retaining SSNs in encrypted storage with audit logging just to preserve traceability for future permit eligibility reviews.

Retaining SSNs in encrypted storage with audit logging to preserve traceability for future permit eligibility reviews fails because encrypted storage and logging do not minimize the AI input; they only secure a field that may not be necessary at all. Masking SSNs in staff permit dashboards while continuing to supply original values to the model training dataset fails because masking in dashboards does not remove SSNs from the model pipeline, so the high-sensitivity field still reaches the training data without a necessity review. Hashing SSNs to generate consistent permit applicant identifiers for deduplication while maintaining existing collection workflows fails because hashing still collects and uses SSNs without first asking whether they are necessary; it perpetuates collection instead of applying minimization.

Exam caveat: minimization decisions must be recorded against the actual model features and business rules—removing SSN from a form while a batch job still joins it from another system does not minimize AI inputs. Operational check: map permitting AI feature inputs to data elements, require a written necessity rationale for SSN (or removal plan), and verify production pipelines no longer pass SSN once deemed unnecessary.