Ask a popular chatbot where someone lives and it may answer with a current address, a spouses name, and a phone number, delivered in the confident tone of a system that has no idea it is reading out a strangers private details. The information did not come from nowhere. It came from the same broker ecosystem that feeds people search sites, scraped, licensed, and absorbed into training data and live retrieval indexes.
That origin decides the strategy. People who treat the chatbot as the source file complaints with a system that regenerates answers from its sources, and watch the details return. This guide explains how personal data reaches chatbot answers and the removal order that makes corrections stick.
Two pipelines feed chatbot answers about private people. Training data can include broker pages, people search profiles, and data dumps absorbed before any cutoff date, frozen into the model. Retrieval systems add the live web on top, pulling current broker and people search pages into answers at query time. The two need different handling: retrieval content changes when the source page changes, while trained in content persists until the model is updated or the provider applies a correction. Either way, the root supply is the broker layer, the aggregators that compile public records, purchases, and each others databases into the profiles chatbots learn to recite.
Ask the model to delete your address and it may agree warmly and answer without it for the rest of that conversation. A new conversation, a different phrasing, or another user can surface it again, because the systems memory of the chat is not the store the answer came from. Providers do operate correction and suppression channels, and those are worth using, especially where the output is wrong or creates a safety risk. But suppression at the model layer is a patch over sources that still publish the data and will feed the next model version. Anyone serious about removal treats chatbot correction as the last step, not the first.
Work the sources first. Run the standard broker sweep: identify every people search and aggregator profile carrying your details, file the opt outs, and keep the dated log that this work has always required. As profiles come down, retrieval based answers lose their supply within weeks. Then use each major AI providers privacy and correction channels for the trained in residue, citing the specific outputs, URLs where shown, and the fact that sources have been removed. Finish with monitoring: monthly checks of the obvious queries, your name plus city, name plus phone, name plus relatives, across the main chatbots, logged like broker rechecks, because both layers repopulate.
Some exposure is an annoyance; some is a danger. People fleeing abuse, public facing workers who are being harassed, and anyone whose address publication creates a physical risk should escalate differently: providers maintain priority channels for safety, and the documentation that helps is specific, the exact queries, the outputs, the harm. Broker removals in safety cases deserve the same urgency and the same paper trail. Where a chatbot states false information, a wrong employer, a fabricated record, correction requests should say so explicitly, because providers treat demonstrable falsehoods about a private person as a stronger case than accurate but unwanted data.
You can request correction or suppression through the providers privacy channels, and for retrieval based answers removing the source pages often removes the output. A chat level request alone does not delete anything durable, which is why source removal plus a formal provider request is the combination that holds.
Almost always from the broker ecosystem: people search profiles, data aggregator pages, and licensed datasets that were scraped or used in training, plus live retrieval from those same sites. Your address was published by brokers long before a chatbot repeated it; the chatbot is a new mouth for an old problem.
Retrieval based answers can improve within weeks of source removal. Trained in content waits on provider suppression, which is applied unevenly and can take longer, and model updates can reintroduce stale data. That is why monitoring on a schedule, with dated screenshots, is part of the process rather than paranoia.
Wrong information about a private person is often easier to get corrected than accurate information, because providers have accuracy commitments and the claim is verifiable. Document the exact false output, state the correct facts with evidence, and file through the providers correction channel. Keep the record; falsehoods that return after correction deserve escalation.