First of all, a "legal" disclaimer: if your colleague has indeed done so, how is this relating to your company's security policies, and who is in charge of the latter? Two possible solutions would be to either go to your local ${BOFH} and seek assistance, or drop broad hints that you may do so (because "your workstation feels sluggish" for example) in the hope that your colleague will then proceed to undo the damage.
Also you ought to ask yourself how do you stand versus this colleague of yours - i.e., why did he/she do this? Is this kind of behaviour acceptable? How will he/she react to your investigating the situation should he/she realize it is happening? What will you do if you discover something, and what if you discover nothing?
A comprehensive answer isn't feasible for the reasons already indicated by Scott Pack, so this is my very narrow attempt.
If you need/want to take justice in your own hands, so to speak, be careful to do so in a way that is not incompatible with your company's security policies. For example, a dirty trick I confess playing to a colleague of mine oh so many years ago involved leaving available to "myself" (and whoever could impersonate me, i.e. him) an executable purporting to be a porn-joke-fun game. It actually was a "screamer" application, which was just borderline acceptable because I pretended to believe that he had been tricked by the same website that had tricked me. This kind of scheme is a variant of the "honey pot" and is often used with documents; basically you disseminate information (executables, documents, etc.) in such a way that anyone having improper access to them is bound to modify his/her behaviour in a recognizeable way. If the new behaviour involves lawbreaking, the information is called a sting and the one supplying it (i.e. you) might be prosecuted in some legislations.
A more direct way of collecting evidence would be to investigate the machine's own structure and behaviour. Hardware keyloggers are either keyboard replacements or small plugins that will be found along the keyboard cable (in more sophisticated setups, inside the keyboard itself). Software keyloggers are either realtime (i.e. they transmit keys via IP, usually via UDP, and are visible to LAN sniffers - you either see unexplained ESTABLISHED TCP connections to some strange place such as your coworker's workstation, or equally unexplained UDP traffic to same) or delayed. These last store their booty in hidden files either continuously, and you will see unexplained processes opening files using e.g. Process Explorer, or upon reboot or user logout. In this last case, the careless keyloggers can be recognized by inspecting any file that turns out to have been changed since last reboot/logoff. You could e.g. reboot twice, both opening and closing Notepad, one almost without using the keyboard, the second after writing (and not saving) some kilobytes of rubbish. Checking modified file times and sizes ought to offer some hints.
Another technique (which ordinarily requires starting from a known clean system, which yours definitely isn't) is to calculate an integrity signature from all system and nonsystem files (google e.g. "TripWire"). This will both help you ascertain further modifications (but remember that Windows Update usually keeps the system in a very fluid state :-) ) and pinpoint those files whose timestamps did not change while their contents did, which is typical of the more advanced keyloggers (you can hide from a timestamp check, but not from a MD5 check; the latter being very expensive and therefore rare, it makes sense to try to thwart the former).
Finally, keep a log of your accesses to your workstation and verify with the system's access logs whether there are discrepancies.
