You do not even need a randomized IV if you already have a randomized secret key that changes for every message. So any answer will not be fundamentally wrong, as there are no security requirements for the IV. However, I would suggest your read this answer provided by our friendly bear before you meet a less friendly BEAST.
However, I would not include the IV with the AES input key for one particular reason: it would not be compatible with any hardware or HSM (or any other keystore) that performs key wrapping (i.e. encryption of a key with a wrapping key, in your case the RSA public key). So if you ever decide you need that, you'd have to change the protocol. Otherwise you'd have to decrypt and store the key in software. This is not a huge issue to be honest, as the data will be in memory anyway, but it is something to consider.
If you insist on a random IV then you could use e.g. a hash over the wrapped key (i.e. the RSA ciphertext) as IV, or you could derive it from the wrapped key material itself (using a Key Derivation Function or KDF). The latter is probably one of the approaches used by most cryptographers here, even though it is harder to understand and implement (e.g. RSA-KEM, then HKDF-Extract, then 2 times HKDF-Expand - once for the key, once for the IV - although this is probably not compatible with much hardware either).
As indicated in the comments, having an authenticated message is often pretty important. That would usually require sign-then-encrypt, which is however vulnerable to padding oracle attacks on both PKCS#1 and CBC if you are planning to use that mode. If you only consider one reciepient and confidentiality and integrity then encrypt-then-sign may work better for you.
This does of course also require a (trusted) RSA key pair at the receiver, in the end it is all about key management.