The only way to do it is to branch on whether or not the character is locally controlled by the player, is a local player controller, or if the pawn is player controlled. There are a number of different types of objects a sound can play on, and you’ll have to check for locality for each of them.
API functions to look at are the following:
/** Returns whether this Controller is a locally controlled PlayerController. */
UFUNCTION(BlueprintCallable, Category="Pawn")
bool IsLocalPlayerController() const;
/** @return true if controlled by a local (not network) Controller. */
UFUNCTION(BlueprintPure, Category="Pawn")
virtual bool IsLocallyControlled() const;
bool FGameplayAbilityActorInfo::IsLocallyControlledPlayer() const;
Then, once you’ve determined if the actor/character/controller/pawn is local, you’ll need to play the appropriate sound. You’ll either want to create a BP struct or some other way to hold the local-sound vs non-local sound for a given event. It’s probably best to wrap the call to PlaySound* (or SpawnSound*) type calls in your own project’s BP library to do the appropriate checks before playing the sound.
This is roughly the paradigm we use for our own internal games. We rarely call PlaySound or SpawnSound calls directly from BP and instead call our own project-level wrappers that do a bunch of state checks, etc. We make use of SoundCue parameter and distance based crossfades. The data for that is also setup in C++ project-level wrappers to those calls.