AI Governance for Housing Authorities: A Practical Playbook

Why Housing Authorities Are a Special Case

A public housing authority sits at the intersection of some of the most sensitive data categories in government: Social Security numbers, income and household composition, criminal history, disability accommodations, and immigration status for mixed-status families. This data is protected not by one law but a stack of them, including HUD program requirements under 24 CFR, the Privacy Act where applicable, and state privacy statutes such as the CCPA for agencies serving California residents. Any AI tool that touches applicant or tenant records inherits all of those obligations.

Small and mid-size authorities usually don't have a dedicated AI or privacy office. That's not a reason to wait on governance, it's the reason to keep governance simple and enforceable. A two-page policy that staff actually follow beats a fifty-page framework that sits in a binder. The goal is not to block AI adoption; it's to make sure adoption doesn't create a fair-housing complaint, a data breach, or a HUD finding six months from now.

Start With NIST AI RMF, Not a Blank Page

The NIST AI Risk Management Framework (AI RMF 1.0) gives public agencies a vendor-neutral, no-cost structure organized around four functions: Govern, Map, Measure, and Manage. You don't need to adopt all of it on day one. For a housing authority, the practical entry point is Govern (who owns AI decisions and how they're documented) and Map (what AI is actually in use and what data it touches).

Concretely, this means keeping an AI inventory: every tool in use, what it's used for, what data it ingests, whether it was procured through IT or brought in informally by a program office, and who approved it. Most authorities are surprised at what turns up in this exercise, chatbots used to draft eviction notices, resume screeners in HR, translation tools fed with case notes. NIST's framework doesn't require a specific technology stack; it requires that you can answer basic questions about any AI system before it touches a tenant record.

Building the AI-Use Policy

Your policy should answer five questions in plain language: what tools are approved, what data may never be entered into them, who approves new tools, how incidents get reported, and how decisions involving AI output get reviewed by a human before they affect a resident. Avoid drafting a policy that only addresses generative AI chatbots; screening algorithms, risk-scoring tools in fraud detection, and automated waitlist management all count as AI systems under this policy and need the same scrutiny.

A core provision every authority needs is a PII boundary rule: no tenant PII, case notes, or application data may be entered into a public or consumer-grade AI tool (the free version of a chatbot, for example) unless that tool has a signed data processing agreement and has been vetted through your intake process. This single rule prevents the most common and most damaging failure mode, a caseworker pasting a family's file into a public chatbot to draft a letter faster.

• Inventory: list every AI tool in use agency-wide, including shadow IT
• Data boundary: define what data classes may and may never be processed by AI, and where
• Approval path: name who signs off on a new tool before it touches resident data
• Human review: require a person to review any AI output that affects eligibility, benefits, or enforcement
• Incident reporting: define what counts as an AI-related incident and how fast it must be escalated

Vetting AI Tools Before They Go Live

Vetting doesn't need to be a procurement marathon. A short intake form answered by the vendor, or by IT staff evaluating an internal build, should cover: where data is stored and processed, whether the vendor trains its models on your data, what the data retention and deletion terms are, whether the system logs its decisions in a way that can be audited later, and whether the vendor can point to independent security controls such as NIST SP 800-171 compliance for handling sensitive but unclassified information.

For any tool that influences a decision about a person, waitlist prioritization, fraud flags, rent calculations, income verification, add a fair-housing checkpoint. Ask the vendor directly whether the tool has been tested for disparate impact across protected classes, and ask to see documentation, not marketing language. If a vendor cannot describe how their model was validated for bias, that's a disqualifying answer for anything touching housing decisions, not a minor gap to note and move past.

Fair Housing and Disparate Impact: The Real Risk

The Fair Housing Act's disparate impact standard applies to algorithms exactly as it applies to human decision-makers. A screening tool that uses proxies like zip code, name patterns, or eviction records can reproduce discrimination even when no one intended it and even when the tool never uses race as an input. HUD has signaled continued interest in algorithmic screening tools used by housing providers, and an authority that deploys one without documentation of testing is exposed regardless of intent.

Practically, this means every AI system involved in eligibility, screening, or enforcement needs a written record of what it was tested against, what outcomes it produced across demographic groups where data allows, and what the fallback is when the tool's confidence is low or the case is unusual. Automated denial with no human path to appeal is a governance failure waiting to become a legal one.

Staff Training and the Human-in-the-Loop Requirement

Policy on paper does nothing without training that meets staff where they work. Effective training for a housing authority covers three things in under an hour: which tools are approved and which aren't, what data can never be typed into a chatbot, and how to flag something that looks wrong in an AI-assisted decision rather than assuming the system knows best. Refresher training tied to any new tool rollout matters more than an annual compliance module nobody remembers.

This is also where VAERESOURCE's own approach to trusted AI comes from direct experience building these systems for federal and public-sector clients. We design AI-assisted workflows to be auditable by default, meaning every recommendation a model makes is logged with its inputs and can be traced after the fact, fail-closed, meaning the system defers to a human or blocks action when it's uncertain rather than guessing, and human-in-the-loop for anything that affects a resident's eligibility, benefits, or housing status. Governance frameworks like NIST AI RMF work only when the underlying system is actually built to support them, not bolted on after deployment.