This is hard enough when maintaining an ElasticSearch instance and keeping it in sync with the main database. Doing it with an LLM sounds like even more of a nightmare.
Consider the case of public GitHub repositories. There are millions of them, but each one could become private at any time. As soon as it's private, then it shouldn't appear in search results (to continue the ElasticSearch indexing analogy), and presumably it also shouldn't influence model output (especially if the model can be prompted to dump its raw inputs). When a repository owner changes their public repository to be private, how do you expunge that repository from the training data? You could ensure it's never in the training data in the first place, but then how do you know which repositories will remain public forever? You could try to avoid filtering until prompt time, but you can't prompt a model with the embeddings of every public repository on GitHub, can you?
> Dr. Chandra discovers that HAL's crisis was caused by a programming contradiction: he was constructed for "the accurate processing of information without distortion or concealment", yet his orders, directly from Dr. Heywood Floyd at the National Council on Astronautics, required him to keep the discovery of the Monolith TMA-1 a secret for reasons of national security. -- Wikipedia.
Just saying.
The question is, are you ever going to run an LLM on data that only the user should have access to? People are missing the point, this is not about your confidential internal company information (although it does affect how you use LLMs in those situations) it's about releasing a product that allows attackers to go after your users.
The problem isn't that Bard is going to leak Google's secrets (although again, people are underestimating the ways in which malicious input can be used to control LLMs), the bigger problem is that Bard allows for data exfiltration of the user's secrets.