A housing-eligibility AI control design looks strong on paper, but auditors find the control has never been tested in operation. What distinction should the report emphasize?

The report should emphasize that design adequacy differs from operating effectiveness: AI controls must be tested in practice, not only documented. Housing-eligibility AI may have strong written procedures for overrides, exception handling, and review sampling, but without operating tests—walkthroughs, samples, evidence that controls fire when eligibility decisions are made—auditors cannot conclude the control works. Municipal assurance standards separate “designed well” from “operating as designed over time.” Relying on a SOC 2 Type I report to confirm consistent operation across the audit period fails because a Type I report describes control design at a point in time, not observed operating effectiveness over the period under live caseloads. Treating policy walkthroughs combined with design checklists as evidence of operating effectiveness fails conceptually: walkthroughs and checklists verify design and procedure, not whether the AI eligibility control actually fired consistently on live decisions. Treating vendor model validation documentation as independent reperformance of live housing eligibility determinations fails because model validation assesses the model itself, not the authority's day-to-day operating effectiveness in production; controls must still be tested against live eligibility determinations. Exam caveat: a single happy-path test is weak evidence; sampling should include exceptions, denials, and override paths where control failure most harms applicants. Operational check: request operating-test workpapers (sample size, period, exceptions found, remediation) for housing AI controls and flag any control rated effective based solely on policy text or vendor letters.