I came out with this conclusion:
When writing requirements
If the client DOES NOT demand to use some secondary actor (some existing third services, databases…)
Then using the secondary actor is a design decisión and we should not think about this when writing requirements. We should only model how the users use the system (its goals) and detail this interaction.
During design phase the proper people will think about what tools and external services will be used in order to deliver the requirements.
If the client DEMANDS to use some secondary actor (some existing third services, databases…)
If the secondary actor behaviour impact in how the system interacts with the primary actor I would add the secondary actor to the use case diagram and include it in the use case specification.
If the system should communicate some event to the secondary actor during the realization of some use case (triggered and carried out by a primary actor) I Will write this requirement as a note in the use case specification.
If the secondary actor does not impact in how the system interacts with the primary actor I will write that the system should use some existing third service/system (as it is demanded by the client) as a non functional requirement but wont add this actor to the use case diagram or any use case specification.
When writing design
When designing use cases specification (a RUP activity) with UML diagrams I will describe the relevant external systems the system under construction uses and how the system integrates with this secondary actors.