In most cases you'll be fine, if the user holds reset while powering down, or if the board has hardware to disable RAM on power failure. But there are still more unpredictable factors, like what can happen if the NES has a dirty connector, or the NES gets bumped while it's on. If CPU runs some garbage as code, it only takes one stray write to hose your data.
The solution I would recommend, if preserving the data is important enough, is doing a CRC on the save data, and storing multiple copies in RAM. If the CRC fails, there's a good chance you can load one of the backups.
Like Guntz mentioned, MMC6 is one mapper that has battery-backed RAM dedicated to saving (much smaller though, and built-in to the mapper). From what I understand, games like Star Tropics would enable the backup RAM only when saving data, so it's RAM is almost always disabled. I would imagine a game like Genghis Khan (which has 2 8kB RAMs) does something similar. It's always possible to throw hardware at the problem, just costs a bit more to make the cart. For a "modern" NES game, I would recommend using FlashROM to save. It's much harder to corrupt, because every write requires an unlock sequence. There's still the problem of a user powering down while a write is happening, but little else to worry about.
If you're in the early stages of development, it's probably better to worry about a more robust save system later on, it's something that should be easy to change, if you have a little bit of a system to it. I'd say basically to only write your actual save data all at once, and when manipulating it, do it on a temporary copy in another part of RAM. You'll be able to get it working, data corruption in SRAM is just a fact of life (at work I repair/refurb a Z80-based system with a similar setup, and see it all the time), every NES game dealt with it in some way, except I guess the few that threw more hardware at the problem.
-------------------------