A building inspection division builds a simple permit-status FAQ bot and must decide which case fields to send to the model. What privacy practice should guide that design?

Data minimization is the privacy practice that should guide how the building inspection division designs its permit-status FAQ bot: send the model only the fields required to answer status questions, and omit unnecessary personal identifiers such as homeowner contacts, photos, and full case narrative. For a simple civic FAQ—Is the permit issued? What is the next inspection date?—a permit identifier, status code, and narrowly scoped dates usually suffice. Keeping prompts lean reduces the blast radius if logs, vendor telemetry, or a compromised session expose the interaction, and it aligns municipal AI use with purpose limitation expected in public-sector privacy programs.

Sending the full inspection casefile for maximum context fails the minimization test by design. Extra contact data and dwelling photos are not needed for status answers and become unnecessary PII in the AI pipeline. Disabling logging and audit trails does not implement minimization; it destroys accountability for who prompted the system and what resident data was involved, which municipal oversight and incident response require. Publishing every field to an open data portal before prompting conflates transparency with oversharing: open-data programs redact and aggregate for a reason, and dumping case-level identifiers into a portal does not justify stuffing them into a model prompt.

Exam caveat: minimization is about least data for the stated civic purpose, not about starving the model of every identifier—task-necessary permit keys can remain when they are required to retrieve status. Operational check: inventory fields in the FAQ prompt and retrieval path, tag each as required versus optional for status answers, remove or tokenize optional PII, and confirm retention on prompt logs matches the city’s records and privacy rules before go-live.