Let me start by first defining what I think an RFI or "Request for Information" is.  An RFI is different from a Request for Proposals (RFP) which is different from a Request for Quotes (RFQ).  As you go from RFI to RFQ to RFP, customer requirements become clearer and more specific.

Here are some poorly formed examples...  Customer is thinking about making widgets, isn't sure how to make them, and wants to know if widgitizers even exist in the marketplace = RFI.  Customer has some specific requirements relating to known widgitizers and wants to understand prospective vendors' capabilities and prices = RFP.  Customer wants an Acme Widgitizer Deluxe Model XYZ with 7x24x365 maintenance and wants specific pricing from 3 distributers that it has previously done business with = RFQ.

In other words, RFIs are used when the customer has extremely vague requirements and wants to determine what's out in the marketplace—it's an "exploratory" tool.  In some cases, an RFI is a precursor to an RFP, where the RFI is used to help create more specific requirements after the customers has received informational responses from the RFI responses.

Sometimes companies use RFIs are used to obtain information from suppliers so that the company can determine how to develop or do something in-house.  That's an ethical no-no in the world of procurement.  For example, let's say that your customer is considering developing some sort of software system, but hasn't done a great job of developing requirements.  Your customer decides that s/he wants to know what vendors are doing in this area.  You release an RFI to the marketplace.  Suppliers respond, they ask questions to try and hone in on the customer's requirements, you have the suppliers in to conduct demos, and you receive thoughtful and well-developed responses to the RFI.  Your customer takes the RFI responses, uses the cost information to build its business case to develop the system inhouse, picks and pulls the best or most desirable system requirements from each of the RFI responses to develop the customer's own requirements.  The suppliers that responded did so in good faith, they spent time (and money) trying to understand the customer's requirements, and they crafted an appropriate response to try and address the needs of the customers.  Well, what your customer did wasn't very nice and it's downright unethical.

If that's not enough for you, there are some self-serving reasons why you don't want to release an RFI if you know that your customer has no intention to ever buy whatever the subject matter is from a supplier.  The first is, as a procurement professional, it's a waste of your time to work on something your customer should be doing.  You're doing their work by proxy.  Using the example above, instead of releasing the RFI, you should have been hunting down consultants to contract with so that your customer could figure out their requirements on his or her own (and at his or her expense, not your salary budget's expense).  Second, you know the suppliers will get their claws into you and the customer and that, at some point, you'll have to hang tough with the suppliers because you know there will never be any business for them.

If you're faced with this situation, explain to your customer why it's unethical.  Also, explain to them that you're not going to be the one responsible for trying to beat the suppliers off of the customer—they're going to be on their own to shake off those pesky suppliers.

I'm all about customer service, but if you know that there isn't a snowball's chance in hell that your customer will ever buy the subject matter of the RFI, push back on your customer and get him / her to do the right thing.