In practice, a use case represents a set of behaviors of a system under consideration and the relation with the actors involved in that context. So in principle it's external actors, humans or systems.
Internal interactions that occur within the system are in general modelled with other representations, such as a sequence diagram, a communication diagram or an activity diagram.
The UML standard is more flexible in its specifications:
When a use case applies to a subject, it specifies a set of behaviors
performed by that subject, which yields an observable result that is
of value for actors or other stakeholders of the subject.
The words in italic are refined with the following explanations:
A subject of a use case could be a system or any other element
that may have behavior, such as a component or class.
An actor models a type of role played by an entity that
interacts with the subjects of its associated use cases (e.g., by
exchanging signals and data). Actors may represent roles played by
human users, external hardware, or other systems.
Note that the word "may" is to be understood in the sense of RFC 2119 (i.e. a possibility, not an exhaustive limitation).
So in theory you coud very well have a use case diagram with the subject being a component of your system, and the actor being another component that interacts with it. There are forever very few situations where this representation is preferred to the other type of behavioral diagrams mentioned above. It could make sense for example:
- if you'd represent a game engine, that interacts both with external players and internal components acting as players, and interacting with the game engine in the same way as a human player.
- a multi-agent system composed of relatively independent interacting "agent" components, if you wanted to give an overview of the intent of the agents interacting within the system, before digging in more precise interactions.