The answer might depend on what exactly you mean by "it", but in any case I'm inclined to disagree. Perhaps you can call using Rust "avoiding responsibility" for memory safety errors, but I don't think that's a particularly useful thing to say since you can say something similar about using calculators/theorem provers for avoiding math errors, FEA for avoiding simulation/math errors, etc. Sure, you're not actually responsible for putting pencil to paper and writing out the algebra/matrix manipulations/theorem derivations/etc., but it's far from unusual to consider using those tools the "responsible" choice where their reliability and/or effectiveness over human work is well established.

In addition, there's almost always something more going on than using a particular tool and you're generally still going to be responsible for that other stuff anyways. For example, if you're working on something critical and high-integrity you're responsible for the end product functioning as intended no matter how exactly you go about doing that. Using something like SPARK might be a smart way to go about that, but you still need to have processes before using SPARK (e.g., verifying the specifications you're going to implement are what you intend) and processes after using SPARK (e.g., verifying what you implemented is actually what you intended, that the product is indeed working as expected, etc.). If a bug in SPARK results in something unintended happening, you may not be responsible for the faulty proof itself but that's only one failure out of multiple in the entire pipeline - for example, you can't pin a failure to catch the error in testing on SPARK.