There are two ways I can see for the RNG to be cooked. (For the record, I don't see any reason at all to suspect this of Intel, but I also think prudent cryptographic design requires us to think through what would happen if our RNG were flawed or backdoored.)
First, your RNG could not have enough entropy. That's what got the Netscape RNG many years ago, and also what is apparently behind all those RSA keys with shared prime factors that Lenstra et al and Henninger et al found a couple years ago. And it's what got the Taiwanese smart cards that have been in the news more recently. If you don't get enough entropy, then you will not get any security. You can imagine the Intel RNG having some kind of flaw or intentional weakness where it never gets more than, say, 40 bits of entropy, and then generates outputs using CTR-DRBG with AES (from SP 900-90).
Second, your RNG could have an actual trapdoor or an unintentional weakness. That's what's alleged to have with the Dual EC DRBG in SP 800-90. If an attacker knows the relationship between P and Q, and sees one full DRBG output, he can recover the future state of the DRBG and predict every future output. You can imagine something like this--the Intel RNG uses CTR-DRBG, but if it wired all but 40 bits of the key to some known values, then the outputs would pass statistical tests, but would be weak to an attacker who knew those bits.
In either case, if you used the RNG outputs directly, you would be vulnerable. In the first case, anything you do with the RNG outputs that doesn't add in some other entropy will be vulnerable, since the attacker can just guess the entropy and then generate everything himself. In the second case, you'd need to give the attacker a little output to run his attack on, but (depending on details of the backdoor) a couple IVs for the encryption algorithm might be enough to leak the secret.
The best way to avoid both of these potential attacks is to combine the Intel RNG outputs with OS-collected entropy. There are several ways to do this, but I think the best one is something you can find in SP 800-90--you can seed an RNG, and then keep generating outputs with prediction resistance.
a. Use /dev/random to get at least 128 bits of entropy, concatenate that with a few outputs from RDRAND, and use the result to seed a software instance of CTR-DRBG using AES.
b. Each time you get a request to generate some bits of output, you do the following:
(i) Get an output from RDRAND.
(ii) Reseed the CTR-DRBG instance using that output as the new seed material. (The previous state's entropy is preserved by reseeding, so this can't weaken what you already had.)
(iii)Generate your outputs.
If /dev/random gives you 128 bits of entropy and CTR-DRBG is secure, then you could let your attacker choose every value you get from RDRAND, and he couldn't make your random numbers any less secure.
If RDRAND is good, then the attacker could choose the bits you get from /dev/random and your random numbers would still be secure.
Alternatively, you could simply XOR RDRAND outputs with /dev/urandom outputs. It's easy to see that this can't be any weaker than the stronger of the two, as long as neither one is able to predict the other's values. That's discussed in the draft SP 800-90C.
Disclaimer: I'm one of the authors of the 800-90 standards, and the designer of CTR-DRBG.