A buyer submits a fair-housing complaint. The investigator asks for every communication your brokerage had with that person — emails, texts, call recordings, and anything logged in the CRM. The deal fell apart 18 months ago and the agent who handled it left the company eight months back. What your system produces at that moment is determined entirely by decisions you made long before the complaint arrived.
Ai tools are now writing qualification notes, summarizing calls, scoring leads, and logging reasons why a prospect was or was not moved forward in the pipeline. Those outputs are records. They carry the same compliance weight as a hand-typed agent note, and in many cases more, because they are timestamped, structured, and far easier for an investigator to read.
What counts as a record
Any Ai-generated output that gets stored in your CRM is a business record. That includes call summaries written by a voice Ai after a conversation ends, qualification scores and the reasoning behind them, auto-populated fields like "buyer readiness" or "intent tier," and any tag or label the system applied to a contact.
Say a brokerage runs 40 inbound buyer inquiries a week through an Ai qualification agent. The agent scores each lead and writes a two-sentence summary of why the score landed where it did. Over a year, that is roughly 2,000 Ai-authored notes sitting in the CRM. Each one is a potential exhibit.
The Fair Housing Act prohibits differential treatment based on race, color, religion, national origin, sex, familial status, and disability. An Ai note that reads "low urgency, budget unclear, low follow-up priority" is neutral on its face. But if a pattern emerges — if that phrasing appears significantly more often for buyers with names or area codes associated with a protected class — the note becomes evidence of a discriminatory pattern, even if no agent ever consciously applied that logic.
What investigators actually request
In a housing discrimination investigation, regulators and plaintiffs' attorneys typically request the full contact record for the complainant, all records for a comparison group of similarly situated buyers during the same period, any rules or logic that govern how your Ai system assigns scores or categories, and audit logs showing when records were created, modified, or deleted.
That last item is where most brokerages are unprepared. CRMs store what a record says now. Many do not preserve a reliable history of what it said six months ago, who changed it, or whether a field was written by a human or an Ai. When a regulator asks and you cannot answer, the absence of records is itself a problem.
The audit trail your system needs
Every Ai-generated output stored in a CRM should carry three pieces of metadata: the timestamp of creation, an indicator that the content was Ai-generated rather than human-authored, and an immutable log entry that cannot be edited after the fact.
Immutability matters because a brokerage that modifies records after a complaint is filed faces obstruction exposure on top of the original claim. If your CRM allows agents to overwrite Ai-generated notes without leaving a revision history, you have a gap worth closing now, before any complaint arrives.
Some brokerages solve this by writing Ai outputs to a read-only audit table in a separate database, with the CRM displaying a copy for agents to work from. The agent's edits live in one place; the original Ai output lives in another. When a regulator asks, you can produce both and show exactly what changed and when.
What the Ai logic itself needs to show
If you are using an Ai system to score or categorize buyers, the criteria driving those scores should be documented. Not the model weights — you likely do not control those — but the inputs the system uses and the outputs it produces. What fields feed the score? What language in a transcript triggers a "low priority" tag? Can you demonstrate that none of those inputs correlate with protected-class characteristics?
This is not a hypothetical concern. Lead scoring systems trained on historical conversion data can inherit historical patterns if the training data reflects past discriminatory practices. Knowing what your system uses as inputs, and reviewing its outputs periodically for disparate impact, is the kind of due diligence that holds up when a complaint arrives. Have your broker and legal counsel review the criteria before you deploy and on a regular schedule afterward.
Where to start
Pull one week of Ai-generated CRM notes from your current system and read them as if you were an investigator. Check whether the language is neutral, whether the reasoning references anything that could correlate with protected-class status, and whether the records include a creation timestamp and an Ai-authorship marker. If any of those are missing, that is your first fix — not to hide anything, but to build the kind of record that can defend you when you have done nothing wrong.