It depends on the mode of operation and the padding method (if used).
CTR, OFB, and CFB modes will always produce a plaintext length after decryption that is equal to the original, even if an incorrect key or IV is used.
Authenticated encryption modes are specified to return no plaintext if the key is incorrect or the ciphertext has been tampered with.
For other modes that require padding (CBC, PCBC, ABC, etc), the implementation can produce results that are unexpected if not coded properly. The unpadding algorithm may be separate from the cipher, and may not have knowledge of the block size of the cipher, and allow removing 240 bytes of padding, even though the block size for AES is only 16 bytes. This may be incorrect to you, but not to the code. It also depends on the padding method used, and if the unpad code explicitly checks for correctness of the padding bytes before removing them.
ISO/IEC padding starts at the end and goes backwards till it finds a 1 bit, then removes that and the 0 bits at the end. An incorrect key will probably result in a longer decrypted plaintext using the wrong key than the original.
ANSI and PKCS padding uses the final byte as the amount of bytes to truncate, but are specified differently as to the content of the other padding bytes. Implementations may not even look at those other bytes, and only read the final byte for the padding byte count, which can have a value of 0 to 255, most likely resulting in a shorter decrypted plaintext using the wrong key than the original. It is improbable the rest of the padding bytes will match the padding mode specification, and if they are checked, the unpad code may simply return all the plaintext.