ISP is an interesting principle because the benefits (or rather the costs of ignoring it) are generally small, but the cost of implementation is also small.
The kind of problem that might occur is if, at some point, you want multiple strategies for getting an internal interface, but only one for getting an external interface (or vice versa).
And you're immediately going to think "no, that's not going to happen," but I'll warn you that I did exactly that very recently and got bitten by it.
I was getting two pieces of data from a web service and thought "well if they change the service, I'm going to have to change both clients. So why worry? An obvious truism, you might imagine.
And then they gave me a CSV file for one half of the data, which was faster and contained more data. I wanted, for a time, to be able to switch between the two, while we made sure the CSV file filled all our needs. But I still wanted to get the other half of the data from the same place.
So, now I really want to break that down into three classes, but to do that was a pain because I only had one interface. The solution is simple enough, but it caused me pain in my unit tests.
I wished I'd followed ISP in that case, even though the cost was fairly low, and kicked myself cause you have to ask ... why didn't I? There is zero cost to having two interfaces to one service class for two different client classes.