Home > Uncategorized > Black box auditing is fine

Black box auditing is fine

February 15, 2024

Last week I read this paper entitled “Black-Box Access is Insufficient for Rigorous AI Audits” with some excitement, since I do black box algorithmic auditing at my company and I was looking forward to knowing what more I could do with even more access. Also, it was written by a bunch of smart people from MIT, Harvard, Northeastern, Stanford, and so on.

But I’m not very impressed! Actually I think this paper is a weird result of what happens when academics write about stuff that mostly happens outside of academia. In particular, and I’ll skip a lot of things, I want to focus on their section entitled “Limitations of Black Box Audits,” because of the five bullet points they include, they are all wrong. I’ll just go through them one by one:

1. Black-box methods are not well suited to develop a generalizable understanding.

Their argument here is that you don’t understand weird inputs that could lead to strange behavior. They argue it causes the black box auditor to rely on heuristics. But that’s not at all true! When I audit algorithms, either with private companies who provide the data, or follow my instructions, or with regulators or enforcement agencies that insist on the data from the companies deploying algorithms, we always use all of the historical data that we can get our hands on. In other words, we do not rely on heuristics or synthetic inputs, we instead see how actual people were actually treated by these systems. This is a much more thorough black box audit, and it doesn’t require “understanding,” which I think is a misleading and unattainable goal; even the coders don’t really “understand” algorithms (just ask them).

2. Black-box access prevents system components from being studied separately.

Yes, that’s true! And no, that’s not a flaw! Audits are not supposed to identify where things go wrong, they are supposed to decide whether something is going wrong. From the perspective of an auditor, if certain stakeholder groups (say, black patients in the case of Optum) are being treated badly, then that’s the point of the audit. The question of what exactly went wrong and when is the problem of the folks who set out to fix the problem, but they are not auditors.

3. Black-box evaluations can produce misleading results.

The example they give here is that an algorithm can pass statistical tests of non-discrimination but still have underlying flaws in reasoning. But I’d argue, as an auditor, we don’t actually care what the underlying reasoning looks like as long as it *consistently* passes the discrimination tests! Of course, it’s likely that there should be a battery of tests rather than just one. I’m happy to talk endlessly about how to design such a battery.

4. Black-box explanation methods are often unreliable.

Yes, true, but that’s because explanations of algorithms are almost always nonsense. I’d suggest you stop trying to understand “how an algorithm thinks” and start testing whether an algorithm is causing meaningful harm to stakeholders.

5. Black-box evaluations offer limited insights to help address failures.

True, but again, not a problem! If you want to be an engineer paid to fix problems, don’t call yourself an auditor. Indeed there would be a conflict of interest if that were the same job, because you’d be incentivized to find problems to fix, or to only find fixable problems, etcetera.

If one of the authors of this paper wants to discuss this with me, I’d be more than happy to. We could even have a public conversation, since I live in Cambridge!

Categories: Uncategorized
  1. rob hollander's avatar
    rob
    February 15, 2024 at 1:21 pm

    Their abstract reminds me of the confusion between technology and science that Chomsky frequently complains of when asked to comment on LLMs. Engineers develop technology to solve real-world problems. As long as the outcomes are the ones intended, their designs may be intuitive and efficient or not (I’m assuming that’s one reason why you say the explanations of them are nonsense). So it seems reasonable to me that the auditor should be checking the consistency of the real-world outcomes, not taking on the role of scientist to reverse engineer under the default assumption of maximal efficiency in the algorithm and then speculate on the possible flaws that might account for inconsistencies. However, I do worry that there will be ambiguities and confounds in the historical data the auditor relies on. The role of human preferences across a demographic might be such a confound requiring speculative and theoretic — iow scientific — interpretation of the data. 

    Liked by 1 person

  2. February 15, 2024 at 7:41 pm

    Not exactly the same thing, but the whole point of TDD (test-driven development in software) is to be agnostic about the implementation. The tests are there to see that the implementation works, and to support refactoring. “Knowing how it works” is fleeting, and not desirable.

    Liked by 1 person

  3. Gerald Carter's avatar
    Gerald Carter
    February 20, 2024 at 6:59 am

    Gre

    Liked by 1 person

  4. Gerald's avatar
    Gerald
    February 20, 2024 at 8:22 am

    Great points. For #3 – I can see both sides and it does give me pause. It’s like “checking a box” but not fixing the underlying issue. This could cause something more catastrophic in the future, especially in a high stakes use case. More batteries that can target the heart of it all seems appropriate here. 

    Liked by 1 person

    • February 20, 2024 at 8:33 am

      Well yes, it is, but I’d argue it always is. Even if you think you understand a system, you need constant monitoring because things change in weird ways. And if you can monitor a box to see that it remains consistently checked, that’s kind of all you can do.

      Liked by 1 person

  1. February 20, 2024 at 8:21 am
  2. February 21, 2024 at 1:52 am
Comments are closed.