A lead comes in through your website at 11 p.m. on a Tuesday. Your AI text agent responds within two minutes, qualifies the prospect, and logs everything — name, phone number, the questions they asked, the neighborhoods they mentioned, the price range they gave. The conversation lives in your workflow automation platform, your CRM, and a transcript archive your team barely knows exists.
Six months later, that same person sends a message: "Please delete all my information. I never want to hear from you again."
If your brokerage operates in California, Colorado, or another state with a consumer privacy law, that request may carry legal weight. Even where state law does not yet require it, ignoring a deletion request from someone who has already opted out is the kind of decision that tends to look bad in a complaint file.
Knowing what to delete — and what you are actually required to keep — is not a technology question. It is a compliance question that your AI setup has to be ready to answer.
What your AI workflow may be storing
Most brokerages that have added AI to their lead pipeline underestimate how many places a lead's data lands. A single inbound conversation can create records in the automation platform that triggered the response, the CRM the lead was pushed into, an SMS or email platform that sent follow-up messages, a voice or chat transcript archive, and any reporting or analytics dashboards that logged the interaction.
Say a team gets 40 leads a week. After six months, that is roughly a thousand contacts, each with a thread of activity scattered across multiple tools. When one of them asks to be deleted, "just remove them from the CRM" is not sufficient if their transcript still sits in a separate archive and their phone number is still in an active re-engagement sequence.
The first step is knowing what you have and where it lives. That is not a one-time audit — it is something your workflow architecture should make visible on an ongoing basis.
What you may be required to keep
Here is where it gets complicated. Real estate transactions and the activity around them are subject to record-keeping rules that can run three to seven years depending on the state and the nature of the interaction. Your broker or attorney can tell you exactly which records apply in your jurisdiction, but the general categories include signed agreements, any communication that documents a representation relationship, and records relevant to a Fair Housing audit.
That last one matters. If your AI system was involved in how a lead was qualified, routed, or communicated with, those records could be relevant to demonstrating that your process did not discriminate. Deleting them on request — even if the request itself is valid — could leave you without the documentation you need if a complaint is filed later.
This is not a reason to refuse deletion requests. It is a reason to build your AI workflow so that the records you are obligated to retain are separated from the personal data you can legitimately purge. Your broker or attorney should weigh in on exactly where that line sits.
Building for selective deletion
Most off-the-shelf automation tools are not designed for this. They log everything together, and there is no easy way to remove a phone number from a transcript while leaving the routing and qualification decision intact.
Brokerages that want to handle deletion requests responsibly need to think about this at the architecture level. That means structuring your AI workflow so that personally identifiable information — name, phone, email, address — is stored in a way that can be removed or anonymized independently of the operational record. A transcript that reads "lead qualified on price range and timeline, routed to agent A" is meaningfully different from one that also contains the person's full name and address.
This kind of design decision is much easier to make before you build than after you have 50,000 contact records sitting in a system that was never designed to accommodate it. The approach Real Estate AI Group takes with workflow builds is to map data flows before writing a single automation — not because it slows things down, but because retrofitting a data architecture after the fact costs far more in time and risk.
What an opt-out actually requires
An opt-out from a marketing list and a deletion request are different things, and your AI workflow needs to treat them differently. An opt-out means: stop contacting this person. That should suppress them from all active sequences immediately and flag them so they are never re-enrolled. A deletion request means: remove their personal data, subject to whatever retention obligations apply.
If your brokerage is in a state with a consumer privacy law, you likely have a defined window — often 30 to 45 days — to respond to a deletion request. Your system needs to be able to identify everywhere that person's data lives and confirm that what could be deleted has been deleted. That process should be documented.
Right now, most real estate AI setups have no process for this at all. The opt-out gets logged in the CRM, the marketing sequences stop, and that is considered the end of it. The transcript archive, the analytics platform, and the third-party enrichment data the workflow pulled in on day one are untouched.
Where to start
Before your next AI workflow goes live, map every system that will receive or store data from that workflow — not just the CRM, but the automation platform, transcript storage, analytics, and any enrichment tools. Document what each system keeps, how long it keeps it, and whether it can selectively delete or anonymize individual records. Then have your broker or attorney review that map against your state's record-keeping and privacy requirements. That single exercise will tell you more about your actual compliance posture than any policy document.