Right. Or when you're introducing code to work around a known problem. Add a comment stating that it is a workaround, what problem it works around, when the problem is expected to be fixed, and, critically, how the reader can verify whether the problem exists anymore or not.
Make it easy to find out when it can be removed, in other words.
On one long-term project we even had special comments with an expiry date attached. Every time the build was running a script would scan all comments and print to output those comments that were expired to make sure someone revists them. And you could either remove, keep and extend expiry or modify that code, depending on context.
I guess it never crossed my mind I could do the same when creating company policies and processes.
I've even written a unit test that fails after a certain date with a descriptive message for this purpose. It's maybe more familiar to developers and already has tooling around it.
Make it easy to find out when it can be removed, in other words.