This sounds to me like not a failure of automation as such, but of process/knowledge management by the team that builds the automation. No process is permanently exempt from entropy.
Totally agree, and i've seen this many times (and have had my teams "clean up" after others). however, what can help mitigate - maybe not fully prevent - in some cases are the following 2 approaches:
1. Build automation so that it is NOT such a blackbox. I even go so far as to build automation with scripting languages...that allows myself/my team to at least peek at the source code to see what is happening.
2. And, of course documentation. i know this is simplistic of me to state...but it is invaluable nonethelss. I should also clarify that i mean there should exist documentation both for users, or by extension those who benefit from the automation, as well as, for developers/sys admins/sys maintainers (say, within the code itself).
After a process gets automated, people forget the details of how to do the work manually. Now, when the automation breaks (and it will break at some point. It takes a huge amount of work to make these things failsafe and scripting doesn't really encourage robustness) -- no one remembers the details and fixing the issue is more difficult and requires specialized knowledge that is no longer common in the organization.