A housing authority adds RLHF-style preference data that rewards faster case answers more than eligibility accuracy. What alignment risk should the security lead highlight?

RLHF-style preference data is an alignment steering mechanism: labels teach the housing-authority model which behaviors to prefer. If graders reward faster case answers more than eligibility accuracy, optimization will favor brevity and speed over careful eligibility guidance on high-impact housing decisions. The security lead should highlight that mis-specified preference objectives can systematically misalign the customized model away from accurate determinations residents rely on for benefits and housing access.

Preference optimization does not automatically encrypt eligibility determinations—that confuses alignment training with cryptographic controls. Claiming RLHF always disables hallucinations is false; preference tuning can improve or degrade truthfulness depending on what humans reward. Preference datasets are not cosmetic UI themes; they change ranking or reward models that alter generation behavior for municipal casework.

Exam caveat: Alignment quality tracks the incentive structure in human feedback. Speed, tone, and "helpfulness" rewards without accuracy and refusal criteria are classic sources of alignment drift in civic assistants. Do not confuse RLHF mechanics with encryption, UI configuration, or a blanket hallucination cure.

Operational check: Redesign preference rubrics so eligibility correctness, citation of policy, and safe refusal outweigh raw latency. Audit a sample of ranked pairs for speed-bias, retrain or re-rank with corrected labels, and evaluate the housing chatbot on held-out eligibility scenarios measuring both accuracy and time. Document who may edit preference data and protect those labels as alignment-critical assets.