For sure, I mean you can route to anything you want. The Gateway is powerful that way. :-) But the trouble comes with trying to route back to the original policy if that's needed, without affecting the other services which also use that policy/API that you said already exists. I don't think going down that route would be a good solution, as it would likely just introduce other complexities.
For your use-case, I strongly encourage the use of encapsulated assertions or policy fragments (probably policy fragments in this case is more useful to you) as the solution. Not only will it make it easy to debug in the future if any bad things happen, but it turns this into a long-term reusable item which gives it far more usability. Ultimately, if you already have a service/API that you need that now is needed by more than one service, then it means it should be a policy fragment as that is the exact use-case it was created for. So in that case, you should actually be turning your existing one into a policy fragment rather than feeling the need to duplicate it.
With that said though, if you want to take the "safe" route where you're not interfering with what's already there (in case this is why you may be hesitant to take this approach), you can always leave what you have and just duplicate the service you have now that you want to route to and then turn THAT one into a policy fragment, so that you're not interfering with any other operations. From there, you can then slowly migrate others to use the new policy fragment if it makes sense for your environment at that time and then finally remove the other one that you're wanting right now to route to.
I hope the above paints a bit of a better picture for you as to why everyone on here is so far recommending policy fragments. It truly is the best option in your case, based on what you've expressed so far detail-wise. Anything else will just lead to further complications down the road whenever troubleshooting is needed, not to mention possible performance degradation. I say performance degradation because if you go the routing path, then you're adding the extra overhead of a route when it wouldn't even be part of the equation if you had it as part of a policy fragment instead, so you immediately save that second or so from the routing part in comparison, which ultimately leads to performance improvements using a policy fragment.