Writing hand-rolled SQL to work with potentially-sensitive data is an escape hatch in internal systems.

It needs to be possible, of course.

But every time it happens it is kind of a bug; it's dangerous, expensive, error prone.

Like any escape hatch, you want to analyze the use cases that require use of the escape hatch and create safer / higher-level alternatives for those use cases.

Grow the overall use of the system while minimizing the number of times that people have to use the escape hatch.

For example, you could make derivative tables that denature the sensitive data (e.g. enforce some threshold of k-anonymity) that most of the internal users use, or create higher-level UIs that don't allow seeing individual data points.