Undefined rules by stakeholders

Do you have an ordered Product Backlog? This should make clear the items that need to be well defined to better mitigate risk when Sprint Planning.

You may also consider the team's confidence level in getting these requirements before they become impediments should they be planned into a Sprint.  

Are those uncertainties transparent to all stakeholders; particularly those investing in the product?

Is the potential impact on being able to provide an acceptable return on investment also transparent?

Is there a Product Owner who understands the situation well enough to accept accountability for the delivery of value?

Are there parts of the product that are already well enough defined, that you can start work on the first increment?

For instance, if the uncertainty in your example is about whether the minimum age is 18 or 21, and the maximum age is 50, 65, or 80; then you already know that people aged 21–50 will be eligible.

It might make sense to focus the first sprint around potential customers who fall within the known demographics.

the product doesn't has the complete definitions by the business areas or the stakeholders so I'm looking for an advice about if I can start with the planning if I don't have those complete definitions.

Would you expect to have those complete definitions prior to starting, or would you expect the work to emerge, Sprint by Sprint as new things are learned? If a complete definition was possible, what advantage would Scrum bring to product development?

Thanks Ian, Simon and Tony, I'm gonna try to answer all your questions/comments :)

For this project I'm the product owner and the stakeholders involved knows this situation. I mean, they know because they're directly participating in the gaps of the product's definition. At the moment I don't have the budget and authorization to continue with the project so I'm taking advantage of this to move forward with the gaps of the product's definition before the first sprint planning.

I have an story map with prioritized epics however with other projects it always happen to me that the devop team said to me  "We cannot move forward because there are undefined parts in the product", they talk about parts of the product usually define by business areas (actuarial team, investment team, leal team, etc) 

I want define this gaps while the sprints are running with the devop team & stakeholders but I usually get the comment that I just mentioned to you and then looks like the devop team can't do something until I feel the gaps :( 

Why don't you start talking to the Development Team and have them identify the gaps and help you order the backlog in a way that you can incrementally close the gaps while the Development Team incrementally builds the solution? 

This is from the Scrum Guide section that describes the Product Owner role (emphasis added by me)

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

• Clearly expressing Product Backlog items;
• Ordering the items in the Product Backlog to best achieve goals and missions;
• Optimizing the value of the work the Development Team performs;
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
• Ensuring the Development Team understands items in the Product Backlog to the level needed.

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

Have the Development Team help you in all of those so that as a team you can determine the best way to make progress on the items. 

The range of age to contract this insurance is XX to XX years old

Honestly I think that is actually a very clear requirement.  There is no quarantee that those ages won't change over time and they seem like a great candidate for a configurable field via some type of admin interface.  Ask the Development Team if they fell they could start working based on that statement instead of assuming that they will ask for specifics. You may be surprised. 

Thank you Daniel, you were very helpful :) :)