Yeah, I've had stuff like this happen too... What I tend to do to get around it is to have everything set up so that when instantiating there's a check in place before going to the state that fires off the event.
So, for example, say I'm fetching a monster from the pool... But it needs to get information from the pooling controller such as who the main target is, roughly where it is, what kinds of animations/effects/particles it has to have on it and that kinda stuff.
The first thing I'll do is add in a set of actions that I want it to do before getting told to "activate." Since this object needs to get information fed to it from other systems, I'll have the string of states that it has to go through (That aren't reliant on other data being sent to it) so that is finished... Then I'll have it wait on the end of this particular string of actions with the last state having a transition that isn't "finished." so, for example, it'd be "Initialize." (you could make the initialize a global transition as well but that may not be the most ideal method for all situations since a global transition can be called from any point in the FSM whereas a transition in the state itself (aka, not global) has to be in that particular state for that transition to be actioned. So, this way I can be sure that it's not being initialized prematurely...
And when I want to get that transition fired off, I use the send event action. You can make it use non-global transitions as well because afaik it's basically that one FSM shouting at the other FSM the word "Initialize" (or whatever transition you use.) So if there are no global transitions with that and it's not in that particular state when the action gets fired off, it won't go to it's initializing states until it's there.
TL-DR: I'd use a non-global transition to control the flow so that it isn't being activated prematurely before any data can be sent to it that it may need.