Looking at it from a business perspective, I don't think this is a matter of obligation. Since the project has not been confirmed yet, and no contract has been signed, you are not obliged to provide anything.
However, it is in your interest to present your [potential] client with whatever you think will optimize your chances of getting the contract.
I think that since the client has its own IT department, it may be interested in more technical details than other clients, as it has more relevant experience, and (at least believes he) has more tools to evaluate you as a service provider by you answering those questions.
I also think that by building a rapport with the head of IT, by engaging him in an amicable and serious conversation, even if you don't provide concrete answers to his specific questions (since you did not yet put in your full effort on thinking about them) and only giving him your state of mind and thoughts about your possible architecture, you would be able to convince him that you will be able to come up with satisfying results, and continuous communication on progress.
What the head of IT is probably most anxious about is that he outsources work he knows he is capable of doing to someone else. This is loss of control on his side. His worst case scenario is that at the end of this project, X months from today, he will be left with a dwindling budget, and lousy code he will have to clean up and re-write.
If you give him sense of control by open communication, he will be more receptive to letting you have your contract, and will also reflect less stress on you while the project is in progress.