Compliant But Unsatisfactory: The Gap Between Auditing Standards and Practices for Probabilistic Genotyping Software

Angela Jin; Alexander Asemota; Dan E. Krane; Nathaniel D. Adams; Rediet Abebe

cs.CYApr 13, 2026

Compliant But Unsatisfactory: The Gap Between Auditing Standards and Practices for Probabilistic Genotyping Software

Authors: Angela Jin, Alexander Asemota, Dan E. Krane, Nathaniel D. Adams, Rediet Abebe

Organizations: University of California, Berkeley, Berkeley, California, USA · Wright State University, Dayton, Ohio, USA · Forensic Bioinformatic Services, Inc., Fairborn, Ohio, USA · ELLIS Institute; Max Planck Institute for Intelligent Systems; and Tübingen AI Center, Tübingen, Germany

Abstract

AI governance efforts increasingly rely on audit standards: agreed-upon practices for conducting audits. However, poorly designed standards can hide and lend credibility to inadequate systems. We explore how an audit standard's design influences its effectiveness through a case study of ASB 018, a standard for auditing probabilistic genotyping software -- software that the U.S. criminal legal system increasingly uses to analyze DNA samples. Through qualitative analysis of ASB 018 and five audit reports, we identify numerous gaps between the standard's desired outcomes and the auditing practices it enables. For instance, ASB 018 envisions that compliant audits establish restrictions on software use based on observed failures. However, audits can comply without establishing such boundaries. We connect these gaps to the design of the standard's requirements such as vague language and undefined terms. We conclude with recommendations for designing audit standards and evaluating their effectiveness.

Figures & tables

Figure 1. A simplified depiction of forensic lab use of probabilistic genotyping software to produce evidence in a criminal case. The goal of forensic DNA testing is to determine whether a person of interest (e.g., the defendant) could be the source of some or all of the DNA recovered from a crime scene. To this end, (A) a lab analyst first prepares two physical DNA samples: an evidence sample (e.g., a swabbing of a shoe collected as evidence) and a reference profile. (B) The analyst then runs the PGS with these DNA samples as inputs, along with other inputs chosen by the analyst. The software outputs a likelihood ratio (LR)—a statistic that describes similarities observed between the evidence sample and reference profile. (C) Before the LR is presented as evidence at trial, a court may conduct an admissibility hearing to determine whether the evidence is sufficiently reliable to be presented in front of a jury. (D) If the judge deems the evidence admissible, the LR will be presented as evidence at trial.

Figure 2. Summary of the gap between each ASB 018 goal (blue text starting with G: ) and the corresponding compliant but unsatisfactory audit practices (red text starting with P: ). We identify gaps between ASB 018’s envisioned practices and real-world audit practices for each of five stages of the audit process, which we draw from Ojewale et al. (2025) .

Appendix figures & tables1 asset

Supplementary material from the paper’s appendix.

Appendix

Line-level Req.	OCME v2.4 (2016)	CBI v2.5 (2018)	PBSO v2.6.2 (2019)	OCME v2.7 (2021)	MSP v2.9.1 (2024)
4.1	Introduction (p. 2)	Introduction (p. 2)	Introduction (p. 2)	Introduction (p. 1)	Introduction (p. 3)
4.1.3-a (i)	Exp. 2 (p. 3-5)	Sec. A (p. 4-5)	Sec. A (p. 5-7)	Exp. 2 (p. 4-6)	Sec. A (p. 5-7)
4.1.3-a (ii)	Exp. 4 (p. 7-17)	Sec. D (p. 7-32)	Sec. D (p. 8-15)	Exp. 4 (p. 14-25)	Sec. D (p. 13-29)
4.1.3-a (iii)	Exp. 4 (p. 7-17)	Sec. D (p. 7-32)	Sec. D (p. 8-15)	Exp. 4 (p. 14-25)	Sec. D (p. 13-29)
4.1.3-a (iv)	Exp. 6 (p. 19-22)	Sec. M (p. 52-55)	Sec. M (p. 25-31)	Exp. 6 (p. 28-30)	Sec. M (p. 64-66)
4.1.3-b	(p. 2, 40)	(p. 8, 56)	(p. 2, 31)	(p. 2, 64)	(p. 3, 14)

Appendix

Table 1. For each internal validation report, we document the page numbers of the internal validation report that contain text that satisfies our interpretation of each line-level requirement. When multiple sections of a report could satisfy our interpretation of a given line-level requirement, we document the page numbers for one of the sections. All page numbers refer to the numbered pages of the internal validation report. The OCME v2.4 audit report was updated in 2019 to correct transcriptional errors and improve the clarity of tables, figures and end notes—the original audit was completed in 2016.

Algorithmic Auditing

Algorithmic auditing evaluates whether automated systems are fair, reliable, robust, compliant, and accountable in their intended settings.

See all 142 papers

Governance-as-Code: Translating EU AI Act Technical Requirements into Executable Compliance Pipelines for Generative AI Systems
Sep 17, 2026Rudrendu Kumar Paul, Sourav NandyAlgorithmic Auditing AI Governance
Boston University, Boston, MA, USA
ASSERT: A Measurement Pipeline for GenAI Audits
Aug 14, 2026Riccardo Fogliato, Abhinav Palia, Xiawei Wang +11Generative AI Evaluation Algorithmic Auditing
Microsoft
Auditing the Audit: Five Failure Modes in Benchmark-Validity Audits
Jul 1, 2026Yanhang Li, Zhichao Fan, Zexin ZhuangAI Assurance Benchmark Auditing
Northeastern University, USA · University of Illinois Urbana-Champaign, USA · Southern Methodist University, USA

Sep 17, 2026J/K move · Enter open · S save

Governance-as-Code: Translating EU AI Act Technical Requirements into Executable Compliance Pipelines for Generative AI Systems

Rudrendu Kumar Paul, Sourav Nandy

Boston University, Boston, MA, USA

Algorithmic Auditing AI Governance AI Regulatory Compliance

Open paper AskPDF arXiv

The EU AI Act (Regulation 2024/1689) imposes technical obligations on high-risk AI providers, yet Articles 8-15 were drafted for predictive AI and leave seven technical gaps when applied to generative systems, spanning non-deterministic data governance, training-data provenance, continuous conformity, human oversight, open-ended robustness, emergent risk, and generative fairness. We deliver Governance-as-Code (GaC), a framework of 43 machine-checkable acceptance criteria across six compliance modules that run in a CI/CD pipeline and emit Article-indexed audit evidence, and we show the actual Rego policy code rather than merely describing it. Our central commitment is that the Act's open-textured standards ("appropriate levels," "possible biases") become declared, auditable numbers: robustness thresholds are derived from the provider's documented baseline and a state-of-the-art floor, and framing bias is collapsed into eight measurable proxies tested by counterfactual demographic probing. We also correct who owes what, since under Article 25 and Chapter V a downstream deployer relies on the upstream provider's Article 53 training-data summary and documents only the layers it controls, so GaC verifies that summary rather than demanding per-sample documentation the deployer never had. We validate on two enterprise deployments, a high-risk advisory chatbot and a limited-risk content generator, benchmarking against a manual expert audit rather than documentation artifacts that were never designed to enforce compliance. GaC reproduces all of the manual audit's findings, including three penalty-triggering violations, while cutting audit labor by roughly 75%.

Abstract

Algorithmic Auditing

Explore similar work

Governance-as-Code: Translating EU AI Act Technical Requirements into Executable Compliance Pipelines for Generative AI Systems

ASSERT: A Measurement Pipeline for GenAI Audits

Auditing the Audit: Five Failure Modes in Benchmark-Validity Audits