Quick answerBeing publicly visible is not the same as being offered for this specific use, so default to not pulling it in automatically. If you do use public social or web data to personalize service, disclose that you do it, in plain language, before or at the point it is used, and give the customer a simple way to opt out. Treat data the customer explicitly connected themselves as a completely different, already consented category, and never mix the two under one internal policy.
Why public visibility is not the same as consent for this use
A social media profile being publicly visible means it was shared with a general audience for a general purpose, not that the person expected a company they do business with to pull it into a support conversation. The legal and ethical bar for using public data is lower than for private data, but it is not zero, and the gap between what is technically accessible and what a customer would consider appropriate is exactly where most complaints in this area originate. Treat public accessibility as a necessary condition for using the data, not a sufficient one.
Where this is different from a customer connected account
This is a meaningfully different question from governance for third party accounts a customer explicitly connects to your agent, where the customer took an affirmative action, understood what they were sharing, and can revoke access through a clear mechanism. Pulling from a public profile the customer never connected to anything skips that affirmative step entirely, which is exactly why it needs its own, more conservative policy rather than inheriting the connected account policy by analogy. It is also a different consent question from whether conversations the customer already had with the agent can be reused as training data, since that is about reusing data you already legitimately collected, not about reaching out to pull in new data from a public source.
What a defensible use actually looks like
If there is a legitimate use case, for example recognizing that a customer publicly posted about a specific product issue so the agent can proactively acknowledge it, the disclosure has to come before or at the moment of use, not buried in a privacy policy nobody reads. Something as simple as the agent stating plainly that it noticed the public post and asking if the customer wants to talk about it, rather than referencing the post's contents without explanation, keeps the interaction from feeling like unexplained surveillance.
From the team
We build production AI systems for startups.
LLM pipelines, RAG, and agent workflows that hold up under real traffic — not just in the demo.
The line between personalization and something that reads as creepy
The same underlying data pull can land as either helpful or unsettling depending entirely on how it is surfaced. Referencing a customer's public job title to route them to the right team reads as reasonable. Referencing an offhand personal detail from an old public post, unprompted, in an unrelated conversation, reads as invasive even though both examples technically use public information. Build review guidance around this distinction explicitly, since a policy that only checks whether data was public will approve both examples equally, which is the wrong outcome for the second one, and a public misstep of this kind can escalate quickly into the same territory as a viral social media moment when an AI agent makes a public mistake.
How this should interact with your personalization infrastructure
If your agent already has a memory and personalization layer, keep public web derived signals in a separately tagged category from data the customer explicitly provided or connected, with its own retention and deletion rules. Mixing the two into one undifferentiated personalization profile makes it much harder to honor a deletion request cleanly, since you would have to disentangle explicitly provided data from scraped public data after the fact instead of by design.
FAQ
Does this apply to information a customer put in their own account profile with your company?
No, that is first party data the customer gave you directly and is governed by your existing account data policies, not this framework.
Should the agent ever proactively mention something from a customer's public profile without being asked?
Only with clear, upfront disclosure that this is a practice you engage in, and only for uses tightly connected to the service itself, not general personalization for its own sake.