Open Source as Regulatory Infrastructure: Where the Open/Closed Line Should Sit for AI Governance Tooling

Counts differ because each database indexes a different set of publications. We treat OpenAlex as the canonical count; Google Scholar is not shown (no API, and crawling it violates its ToS).

The EU Artificial Intelligence Act obliges providers and deployers of high-risk AI systems to generate, keep and hand over records: automatically generated logs, technical documentation, and information supplied to authorities on request. A market of "AI governance tooling" is forming to produce those records. This paper asks a narrow question that the Act does not answer: who can check such a record, and with what? If the only software able to read and verify an evidence record is sold by the party whose customer produced it, then regulators, notified bodies and affected persons depend on that vendor's goodwill, pricing and survival. We call this the verification asymmetry. We first set out, cautiously and from the primary texts, how EU law treats open source today: the AI Act's exclusions and carve-outs (Article 2(12), Article 25(4) as amended by Regulation (EU) 2026/1744, Article 53(2), recitals 89 and 102-104); the Cyber Resilience Act's definition of free and open-source software and its "open-source software steward" regime (Articles 3(14), 3(48), 24, 25 and 64(10)); and the one place we found where Union law requires open-source licensing of trust-critical software, the European Digital Identity Wallet (Article 5a(3) of Regulation (EU) No 910/2014 as amended). We then examine four precedents in which open verification became shared infrastructure - Certificate Transparency, ACME and Let's Encrypt, Sigstore, and reproducible builds - and identify what made them work, including the parts that have nothing to do with licensing. We compare three places a vendor could draw the line - everything open; open verification with commercial operation; closed with escrow and authority access - and their consequences for regulators, deployers, affected persons and vendors. We argue that the verification side (format specifications, verifier implementations, test vectors) has the economic character of infrastructure and should be open, while value-added operation can remain commercial, and we make recommendations to policymakers and standardisation bodies. The paper is conceptual: it reports no measurements and takes no position on any particular company's licensing decisions.