The web-based app must have access to all of the data it needs to use to perform its function, so if you want it to check for duplicates, etc., the app must have access to all existing data in which it is to detect duplicates. All of that data must be copied to the app for use.
As a “public” app–an app that doesn’t require user login–you won’t have any level of trust in the user and can’t make a decision to withhold data according to who the user is. Because all software has bugs, we have to assume there are bugs in AppSheet that an attacker could use to access even hidden data. If your app has a copy of all the data, and an attacker has broken in, they could access that data.
That the app is/will be white label has no bearing, really.
So that’s what you have to consider. How sensitive is the data an attacker might get?
There are ways to structure data so that more-sensitive data is more protected than less-sensitive data. For instance, you could keep the more-sensitive data, like personal names, home addresses, phone numbers, and email addresses, in a table that filters out all rows, as @Aleksi suggested, but keeps less-sensitive data in unfiltered tables. That less-sensitive data would be available for the app to use.
Another option might be to detect and handle duplicates using workflows or reports, which run from the server and can access data the user cannot. There’s substantial complexity involved in this approach, but it’s not uncommon.