Your question is misguided. Depending on your mode of operation, all five of those strings can still potentially be decrypted. To what, though, depends on the mode of operation.
AES, at its core, is a pseudorandom permutation that transforms a 128-bit input to a 128-bit output, given some key (128, 192, or 256 bits). Since the input size is equal to the output size and AES is reversible, this guarantees that all outputs map to some input given a particular key.
Modes of operation can affect this, however.
Given some modes, like CTR mode, a change to a single byte of the ciphertext will "randomly" permute that byte and only that byte in the plaintext. This is likely trivially bypassable (e.g., attack at dawn
becomes at\u034ack at dawn
).
In CBC mode, PKCS7 padding is used, and its value is checked for validity upon decryption. There's slightly over a $\frac{1}{256}$ chance of a random byte change corresponding to a valid padding, in which case the ciphertext will still decrypt. In this event, only the modified block will be "randomly" permuted, and later blocks will be mostly unchanged. In those later blocks, only bytes in the same position as the bytes modified in the earlier block will be changed, and they will be XORed by the same value that was used to change the originally-modified byte. This is likely trivially bypassable as well; the recipient can use this information to determine which byte was modified, and how, and then undo it and decrypt again.
In the event that valid padding was not produced, the decryption will "fail" in most software. This failure, however, is completely bypassable by a party with the correct key; they will in most cases simply have some extra padding on the end that needs to be stripped off manually.
I am unfamiliar with how byte errors will affect authenticated modes like GCM, EAX, and CCM. They will certainly fail to decrypt, as the authentication tag won't match. However, it may be possible for someone to bypass the authentication and decrypt the contents in a manner similar to the above.
TL;DR: Flipping bits in encrypted strings probably doesn't have the effect you think it does. In many cases, it does not render the plaintext irretrievable or unrecognizable. In many cases, it only slightly permutes the plaintext. In many cases, it only garbles a limited amount of plaintext. And at the worst case, a bit flip only requires an attacker to flip $len(ciphertext)$ bits before they come across the original plaintext. Your best bet is to simply not hand out cryptographic keys to people who shouldn't be able to decrypt the protected ciphertexts.