AI governance is being built by compliance teams. What does quality lose because of that?

[brijeshdeb]

Describe the enquiry

Nobody put quality engineering in charge of AI governance. That decision happened the same way most bad structural decisions happen: by default, by assumption, by the time the governance function was already built and the org chart was already drawn.

I've spent the last few years working with large organisations deploying AI systems. In almost every case, the governance conversation is owned by legal, risk, or compliance. Sometimes an ethics board. Occasionally a dedicated AI safety function reporting somewhere into the C-suite. Almost never quality engineering. I want to understand whether that's a structural mistake. Because I think it is.

Here's what compliance-led governance actually does. It asks whether requirements were met at a specific point in time. It documents that the system was assessed. It satisfies the regulator. It builds the audit trail. All of this is necessary. None of it is quality engineering. Those are not the same discipline, and the industry keeps treating them as if they are.

Compliance is a point-in-time discipline. You check against criteria, document the outcome, file the result. The system that was compliant at deployment stays compliant in the filing cabinet even if the real-world system has drifted significantly from what was assessed. Compliance frameworks weren't designed to track that drift. They weren't designed to ask whether the system is still behaving six months later the way it was when someone signed off on it.

Quality engineering, built properly, is not a point-in-time activity. It asks whether the system reliably does what it's supposed to do for real users in real conditions, including conditions nobody anticipated when the test plan was written. It builds mechanisms to detect when the answer has changed.

We are not doing that for AI systems. Not at scale. Not consistently. The profession that is built to do exactly that is largely absent from the room where these decisions are being made. The practical consequences are visible if you look for them.

Guardrails get designed and validated against scenarios the engineers themselves wrote. Which means the failure modes they didn't imagine are also the ones the guardrails don't cover. The people whose job is to think of the scenarios engineers miss are not in that room.

Risk classifications get produced as static documents before deployment and never revisited as actual usage evolves. A system classified as limited risk based on its intended context may be operating in significantly higher-risk conditions months later because users found applications the designers never planned for. The document says nothing about this.

Explainability layers get built to satisfy a regulator. Nobody checks whether the explanation is actually useful to a real decision-maker, or whether someone using it to decide whether to trust the system's output is making a better decision than they would without it. Explainability as a compliance artifact and explainability as a quality property are completely different things. Most governance frameworks are pursuing the first while claiming to deliver the second.

I'm not saying compliance teams are doing something wrong. They're doing exactly what compliance teams are designed to do. The problem is that what they're designed to do is not quality engineering. The gap between those two things is where AI deployments are quietly going wrong.

The question I can't resolve cleanly is why quality engineering isn't in this conversation. Is it that we haven't made the case in terms governance decision-makers understand? Is it a vocabulary problem, that compliance teams have regulatory language that gives them authority in this space and we don't have an equivalent? Is it a timing problem, governance frameworks were being built and we arrived late? Or is it something older and harder to fix: a structural undervaluation of quality as a discipline that predates AI governance entirely and is simply reproducing itself in a new context? I suspect all four are true to some degree. I'd like to understand what this community has actually observed.

Collaboration

I'm putting this argument to the community because I want it stress-tested, not validated.

If the framing is wrong, I want to know where it breaks. Is the compliance versus quality engineering distinction as clear as I'm drawing it? Are there governance models where the two genuinely overlap in ways that make this a false separation?

If you've seen this play out in practice, in any direction, examples are welcome. Organisations where quality engineering was present in governance design. Organisations where it tried and failed. Organisations where compliance-led governance worked better than I'm suggesting it should.

If you've thought about this from a research or organisational theory angle, I'm particularly interested in whether there's existing work on how professional disciplines claim governance territory, and whether quality engineering's absence here follows a known pattern or is something specific to how AI governance has been constructed.