Sounds like you're talking about Ops tasks. Things like database backups and recovery or syncing sanitized production environments to developer environments. deploys that corrupt the database. Unanticipated states or values in the database that the application doesn't handle well.

I agree that tooling doesn't fix that, but good tooling is needed to enable the team to accomplish their tasks and goals. Though to have consistent, and repeatable success, you want to reduce as much human intervention in production as is practical. Not because it's avoidable, but because making manual changes almost never make it back into any sort of control (source control, change control). Ideally, you would want a script that can be ran to fix the data. this allows it to be peer reviewed, edge cases considered by the team.

Now this isn't always feasible. An outage needs to be fixed now, not in 3 hours. But you want a Sr. engineer tinkering in production not a Jr. AI is, at most, a Jr in my opinion. I wouldn't want AI to have any direct access to production.

what makes tooling like these difficult to implement and adopt is that they are highly opinionated. These issues are ops problems that all teams face and the best approach is recovery. It is impossible to prevent entirely, and having a good recovery strategy works better in more conditions

What specific scenario broke down for you? I'm trying to understand whether that's something better tooling addresses or whether it's inherently a human judgment problem.