Open Source AI Compliance Checklist

How to Use This Checklist

Start with the inventory: Document every AI model and open source component currently in use — production, development, and pilot. Include licence type, deployment context, and data exposure.
Apply the three-tier policy: Classify each component as Permitted, Restricted, or Prohibited using the policy matrix. Restricted items require legal sign-off before deployment.
Generate your SBOM: Use the SBOM requirements section to ensure every pipeline produces a machine-readable bill of materials.
Set up regulatory monitoring: Use the calendar to track compliance deadlines across all applicable jurisdictions.
Add sector overlays: If you operate in healthcare, financial services, or government, complete the relevant sector addendum.
Build your sprint plan: Use the implementation planner to assign owners and deadlines for each compliance workstream.

Brand commitments behind this checklist

Open source is not a regulatory exemption. An AGPL-licensed model used in a high-risk application faces identical EU AI Act obligations to a proprietary one. "But it is open source" is not a defence in court, before a regulator, or in front of your board. Score the licence and the use case, not just the licence.

Three tiers, four jurisdictions, three sector addenda — and a date stamp on every claim. AI regulation moves quarterly. The number of California AI laws, the size of the Hugging Face model count, the latest Octoverse secret-leak figure all shift between annual reviews. Treat every quantitative claim as a snapshot and re-verify before each annual policy refresh.

Section 1: AI Model & Component Inventory

Open Source AI Inventory

Document every AI model and open source component in use. 34% of GitHub repositories lack licence files entirely (Black Duck OSSRA 2024 edition) — assume nothing. Re-verify against the latest OSSRA report before each annual review; the figure shifts year to year.

Model Inventory

Model / Component	Source	Licence	Version	Use Case	Deployment Context	Policy Tier

Inventory Completeness Check

All production AI models documented with licence type?

All development/pilot AI models documented?

Transitive dependencies identified for each model?

Training data provenance documented where available?

Open source vs. open weight distinction confirmed for each model?

Models without licence files flagged for legal review?

Section 2: Three-Tier Licence Policy Matrix

Licence Classification Policy

Classify every licence into one of three tiers. Enforce through automated scanning, not documentation alone.

Permitted: MIT, Apache 2.0, BSD 2-Clause, BSD 3-Clause — standard attribution only. No legal review required.

Restricted: GPL v2, GPL v3, LGPL, MPL 2.0, Custom AI Licences (Llama, Mistral, RAIL) — requires legal review before adoption.

Prohibited: AGPL in commercial products, any licence with unacceptable use-case restrictions, unlicensed components.

Policy Configuration

Licence	Tier	Key Obligation	Patent Grant?	Copyleft?	GPL v2 Compat.?
MIT	Permitted	Copyright notice	No (implicit)	No	Yes
Apache 2.0	Permitted	NOTICE file, change docs	Yes (defensive)	No	No
BSD 2/3-Clause	Permitted	Copyright notice	No	No	Yes
GPL v2	Restricted	Source disclosure	Implicit	Strong	—
GPL v3	Restricted	Source disclosure	Explicit	Strong	No
LGPL	Restricted	Modification disclosure	Varies	Weak (file)	Yes
MPL 2.0	Restricted	File-level disclosure	Yes	File-level	Yes
Llama Community	Restricted	Usage thresholds, use-case limits	Custom	Custom	No
AGPL v3	Prohibited	Network source disclosure	Explicit	Network	No
No Licence	Prohibited	All rights reserved by default	None	N/A	N/A

Compatibility Conflict Check

Verify these common conflict scenarios in your stack:

No GPL v2 + Apache 2.0 combinations in the same linked work?

No GPL v2-only + GPL v3 combinations without explicit bridging?

No AGPL components in commercial/SaaS products?

Custom AI licence usage thresholds checked against actual commercial usage?

All "open source" AI models verified as genuinely open source vs. open weight?

Section 3: SBOM Requirements

Software Bill of Materials

Mandatory for federal contractors (Executive Order 14028). Rapidly becoming an enterprise procurement requirement. Automate SBOM generation in every CI/CD pipeline.

SBOM Coverage Assessment

Pipeline / Product	SBOM Format	Generation	Frequency	Storage	Status

SBOM Completeness Checklist

SBOM generation automated in CI/CD pipeline?

Using a standard format (SPDX or CycloneDX)?

Transitive dependencies included (not just direct)?

Model weights and training data lineage documented?

Fine-tuning provenance tracked (triggers upstream derivative obligations)?

SBOMs stored and versioned alongside releases?

SBOM review integrated into deployment gates?

Vulnerability Monitoring

Severity	Response SLA	Escalation To	Patch Process	Current Tool
Critical (CVSS 9.0+)
High (CVSS 7.0–8.9)
Medium (CVSS 4.0–6.9)
Low (CVSS 0.1–3.9)

Scanning Tool Coverage

Static licence scanning integrated (FOSSA, Black Duck, FOSSology)?

Dynamic transitive dependency analysis enabled?

Secrets scanning active (GitHub detected ~39M secret leaks in 2024 per Octoverse 2024 secret-leak report; verify current edition before annual policy refresh)?

CVE monitoring with alerting (Dependabot, Snyk, OSV Scanner)?

Human review process for custom AI licences and dual-licensed components?

Section 4: Regulatory Monitoring Calendar

Multi-Jurisdiction Compliance Tracker

Build for whichever jurisdiction is strictest, then work backwards to see what the others let you skip.

Key Regulatory Deadlines

Jurisdiction	Regulation / Requirement	Deadline	Impact on Open Source
EU	AI Act — Prohibited practices	Feb 2025	No open source exemption
EU	AI Act — GPAI obligations	Aug 2025	Models >10²⁵ FLOPs: no exemption
EU	AI Act — High-risk systems	Aug 2026	Full compliance required
EU	Cyber Resilience Act	2027	OSS with commercial monetisation
US	EAR — AI model weight controls	Active	ECCN 4E091; OSS generally exempt
US	NIST AI RMF + GenAI Profile	Voluntary	De facto for federal contractors
US	California AI laws (18 bills, 2024 session)	Most effective Jan 2025	Transparency, data protection; verify against current CA legislative tracker before each annual policy refresh
China	CAC GenAI registration	Active	Required for Chinese public users
China	Network Data Security Regs	Jan 2025	24-hour breach notification
India	DPDPA implementation	TBD (rules in draft)	Cross-border data transfers

Jurisdiction Applicability Check

EU users? → EU AI Act + GDPR obligations apply

U.S. federal customers? → NIST RMF + EAR export controls apply

China market product? → CAC registration required

Indian user data? → DPDPA compliance required

Regulatory monitoring assigned to a named individual (not "the legal team")?

Quarterly regulatory change review scheduled?

Section 5: Sector-Specific Addenda

Complete the addendum for each sector in which you operate. Sector obligations stack on top of the baseline compliance above.

Healthcare — FDA · HIPAA · IEC 62304

Open source components in healthcare AI need complete dependency documentation, reproducible builds, and a defined CVE response process within regulatory timeframes.

AI in medical decision-making reviewed against FDA draft guidance (Jan 2025)?

Predetermined Change Control Plans (PCCPs) in place for model version updates?

PHI exposure assessed — was the model trained on data that could include PHI?

Business Associate Agreements (BAAs) in place for all AI vendors processing PHI?

IEC 62304 SOUP provisions satisfied — full dependency traceability for Class C software?

Reproducible builds documented for all open source AI components?

CVE response process defined within FDA-required timeframes?

Healthcare-Specific Notes

Financial Services — SOX · PCI DSS · SEC

"It's free/open source" is not a SOX control. Open source vulnerability disclosure timelines create PCI exposure that commercial vendors typically manage for you.

SOX Section 404 internal controls address open source governance?

Documented processes for licence compliance, security evaluation, and change control?

PCI DSS 12-requirement framework applied to payment systems using open source?

CVE-to-patch gap managed — SLA for open source vulnerability patching defined?

SEC AI transparency requirements reviewed for algorithmic trading / investment advice?

"AI washing" risk assessed — marketing claims match actual open source tool capabilities?

SR 11-7 model risk management applied to open source AI in credit/trading/risk?

Financial Services Notes

Government — FedRAMP · Section 508 · CMMC

SBOM generation is a federal procurement requirement (EO 14028). Open source provenance documentation is required for FedRAMP, not optional.

FedRAMP authorisation at appropriate impact level for cloud-deployed AI?

Open source provenance documentation meets 3PAO evaluation requirements?

Section 508 / WCAG 2.0 Level AA compliance for citizen-facing AI applications?

Accessibility testing throughout development (not just at deployment)?

CMMC cybersecurity maturity requirements applied to open source supply chain?

SBOM generation meets EO 14028 federal procurement requirements?

Contribution policies defined for cleared personnel working on open source?

Government Notes

Section 6: Governance Maturity Scorecard

Rate your organisation's current state for each compliance area. Phase 1 = Ad-Hoc, Phase 2 = Policy-Driven, Phase 3 = Governed.

Section 7: Implementation Sprint Planner

Use this planner to move from Ad-Hoc (Phase 1) to Governed (Phase 3). Recommended timeline: 8 weeks from kickoff to operational compliance.

Notes & Action Items

Glossary

Definitions used throughout this checklist. These align with the canonical methodology article.

Three-Tier Policy Classification. Permitted (low-risk OSI-approved licences, internal use) → Restricted (custom AI licences like Llama 2/3, Mistral; conditional approval) → Prohibited (high-risk applications, copyleft incompatibilities, ECCN-controlled). Every open source AI artefact must be classified before adoption.

SBOM (Software Bill of Materials). A machine-readable inventory of every component in a software artefact. AI SBOM extends this to include training data sources, model lineage, and licence terms. Standards: CycloneDX, SPDX. Required by US Executive Order 14028 and emerging EU regulation.

GPAI (General-Purpose AI Model). Under EU AI Act Chapter V, an AI model trained on broad data and capable of performing a wide range of tasks. Obligations apply from August 2, 2025; systemic-risk threshold at 10²⁵ FLOPs (Art. 51) triggers additional requirements.

OSPO (Open Source Program Office). The internal organisational function that owns open source policy, compliance, and contribution strategy. Mature OSPOs operate the SBOM pipeline and licence-tier classification.

AGPL (GNU Affero General Public License). A strong copyleft licence that extends GPL's source-disclosure requirement to network use. Materially changes the compliance posture of any AI service offering — internal use is generally safe, customer-facing services are generally not.

OSI (Open Source Initiative). The standards body that maintains the official Open Source Definition and reviews/approves licences. "OSI-approved" is the floor for what counts as open source; many AI-specific licences (Llama 2/3, Mistral non-commercial variants) are NOT OSI-approved.

ECCN 4E091. The US Export Administration Regulations control number for AI model weights. Currently affects fewer than five models but establishes a precedent. Open source generally exempt when "published" and "publicly available," with carve-outs for neural geospatial analysis and specialised cryptography.

PCCP (Predetermined Change Control Plan). FDA mechanism for medical-device AI that allows pre-authorised model updates without re-certification. Critical for Healthcare sector addendum.

EU AI Act Penalty Tiers (Article 99). 7%/€35M turnover for prohibited practices (Art. 99(3)); 3%/€15M for high-risk system non-compliance and most provider/deployer obligation breaches (Art. 99(4)); 1%/€7.5M for supplying incorrect information to authorities (Art. 99(5)). Open source status does not reduce these penalties for the deploying organisation.

Evidence Base

This checklist is the operational layer of a published, sourced framework. The methodology, regulatory citations, and licence-tier rationale live in the canonical article below.

Canonical article: Open Source AI: Risk, Reward & The Compliance Reality — the full methodology, three-tier policy rationale, multi-jurisdiction analysis, and sector addenda.

Companion frameworks:

Minimum Viable Governance (MVG) — The 90-day organisational baseline this checklist plugs into
AI Vendor Scorecard — Apply the same governance lens to vendor-provided AI alongside open source
EU AI Act Strategic Guide — Article-level obligations referenced in the regulatory monitoring calendar
The Liability Ledger — How open source governance gaps compound into board-level liability

Key external sources: OSI Open Source Definition · EU AI Act consolidated text · NIST AI RMF · Black Duck OSSRA · GitHub Octoverse · EDPB Opinion 28/2024