The Compliance Trap

Initial report: Confidential incident report within a fixed, short deadline (described as approximately 4 days).

Public disclosure: Full public report within 30 days of the initial incident report.

Customer notification: 72-hour notice to affected customers.

Remediation: 90-day remediation window.

Scope: Near misses and control failures — not just confirmed incidents. This is a broad reporting obligation that requires active monitoring and documentation of every agent behavior anomaly.

SAFE requires submission of full forensic evidence with each report:

Prompts, traces, logs, configurations, model versions, credentials, and timelines. The evidence package must be comprehensive enough for the exchange to analyze root causes and notify affected parties.

For a small operator: This level of forensic documentation requires dedicated security engineering capacity. A local-first deployment with a handful of agents would need to maintain the same evidence pipeline as a multi-vendor enterprise cloud environment. The reporting burden itself becomes a barrier.

Initial confidential report to the SAFE exchange. Contains full forensic evidence. Not visible to the public or to non-members.

De-identified advisory shared with the exchange membership. Removes organization-identifying information but shares the technical details of the incident and control failure.

Full public disclosure within 30 days. This is the most consequential tier — it creates a public record of AI agent incidents that regulators, journalists, and competitors can access. For a small operator, a public report of an agent incident could create reputational damage disproportionate to the actual risk. Large companies have PR and legal teams to manage disclosure fallout; small operators do not.

SAFE currently preserves evidence about identities, permissions, approvals, tool calls, configurations, timelines, and incident context. But it does not explicitly require evidence that a previously granted authority remained valid after the system or its operating conditions materially changed.

Sellynet's issue identifies the gap with precision: a previously granted authority may remain unexpired and technically in scope while no longer being reliable after a material change. This is distinct from whether authority originally existed, and distinct from whether execution stayed within the scope that authority granted.

The proposed evidence model would preserve or reference:

• Authorization source
• Authorization baseline and scope
• Authorization version or effective period
• Material-change events since authorization
• Whether revalidation was required
• Revalidation decision and timestamp, if applicable
• Authorization standing at the time of action
• Evidence provenance and freshness supporting that determination
• Revocation or suspension state
• Resulting enforcement or containment action

Conceptually: prior authorization → material change → revalidation → current authorization standing → enforcement

The material changes that would trigger revalidation include: model or model-version changes, tool or capability changes, configuration changes, new data sources or access paths, delegation changes, policy changes, environment or infrastructure changes, and changes in risk classification or operating context.

Each of these triggers is easier to detect and document when you control the full stack. A cloud provider running a managed agent platform can automatically log model version changes, tool registry updates, and configuration diffs — then trigger revalidation workflows programmatically. A small operator running open-weight models on their own infrastructure would need to build this tracking and revalidation pipeline from scratch.

This is the same structural asymmetry that runs through every other SAFE requirement: the evidence model assumes enterprise-scale telemetry. Adding a revalidation state increases the forensic burden without changing the fundamental dynamic — large providers can satisfy it with existing infrastructure, small operators cannot.

The issue also notes that this distinction is complementary to existing SAFE issues: issue #1 addresses temporal authority and self-extension denial, issue #13 addresses whether execution remained within approved scope. The revalidation question is different — even if authority has not expired and execution was in scope, was the authority still valid under conditions that changed since it was granted?

The progression is already visible in other industries:

"Minimum assurance practices" become "best practices" become "industry standards" become "procurement requirements" become "regulatory baselines."

Each step is incremental and reasonable. No single step looks like capture. But the endpoint is the same: a small operator cannot deploy AI without meeting a compliance bar written by and for enterprise-scale companies.

The key question: who defines what "minimum" means? If OSAA's working groups define the minimum, and OSAA's members build the tools that meet the minimum, the standard is self-serving by construction.

EO 14409 establishes a voluntary clearinghouse. SAFE is the industry framework that fills it. OSAA is the coalition that runs it. The chain is:

EO 14409 (voluntary clearinghouse) → SAFE RFC (voluntary reporting standard) → OSAA (120+ member coalition) → Enterprise procurement (de facto requirement) → Regulatory adoption (mandatory)

The Cloud Security Alliance analysis confirms: "a voluntary framework can still create de facto obligations if government contracting, procurement preference, or public trust" make compliance effectively mandatory. The EO is the legal hook. SAFE is the operational framework. OSAA is the political vehicle.

1. SAFE referenced in procurement requirements. When enterprise buyers start requiring SAFE compliance as a condition of doing business, the voluntary framework has become a de facto mandate. Watch for "SAFE-compliant" language in RFPs and vendor requirements.

2. SAFE referenced in legislation or regulation. Federal or state legislation that references SAFE as the industry standard for AI incident reporting. Colorado, California, and New York are actively legislating on AI.

3. "Minimum assurance practices" defined. When OSAA working groups publish what "minimum" means — that is the compliance bar. If it requires enterprise-scale infrastructure, small operators are locked out.

4. Certification program announced. "SAFE-compliant" or "OSAA-aligned" certification. This is the barrier to entry.

5. September working group outputs. The September OSAA public meeting will launch working groups on secure deployment guidelines. If those guidelines assume enterprise infrastructure, the trap is springing.

6. No small-operator exemptions or tiered compliance. If the framework has one compliance bar for everyone, it is structurally anti-small-operator by design.

The single most active discussion (Issue #4, 24 comments) centers on whether SAFE's verification methods must declare their own failure modes. The community argument: a verification method that cannot explain how it fails is not a verification method — it is an assertion.

DmitrL-dev provided field evidence: "The fail-open mode is the default outcome of writing a check for your own work." In other words, self-verification systematically fails open. This directly challenges the RFC's model of asking organizations to report on their own incidents.

Issue #11 (4 comments) extends this: "The list of required evidence is thorough but preservation is not verification." SAFE requires organizations to retain evidence but does not require that evidence be independently checkable. An organization could preserve evidence in a format no one else can validate.

Three issues address the problem of identifying what system was involved and what authority it had:

• Issue #1 — "Operational authority must not be self-recoverable." Proposes hardware-rooted trust for approval chains. Without this, a compromised agent could extend its own authority.
• Issue #12 — How should SAFE reports identify the affected AI system? Proposes using existing BOM (Bill of Materials) standards: CycloneDX ML-BOM or SPDX AI profile. Without common identifiers, reports about the same model cannot be correlated across members.
• Issue #13 — "Preserving the event is not the same as preserving what it authorized." Four different control failures (no authority, valid+in-scope, valid+out-of-scope, insufficient evidence) would be reported identically under the current RFC.

The community is pushing SAFE to interoperate with existing security standards rather than inventing new ones:

• Issue #5 — Map SAFE evidence to OpenTelemetry GenAI semantic conventions. "A pointer without a schema is a claim, not evidence." 3 comments.
• Issue #6 — Pre-connection tool-trust attestation expressed against OTel GenAI conventions.
• Issue #7 — Causal incident graph profile for "mechanically verifiable" findings.
• Issue #3 — Design-time control lineage tracking.
• Issue #10 — Verification methods should disclose "systematic mislabel classes" (well-formed wrong answers), not just fail-open and noise.

The pattern: the community wants SAFE to be mechanically enforceable. The RFC as written is aspirational. The gap between "should" and "must" is exactly what Track 2 is tracking.

Pull Request #2 proposes designing international public participation into SAFE now, citing the 1998 Internet governance process. The author states they will "make that argument to UN interlocutors." The jump from "open RFC on GitHub" to "UN interlocutors" happened in 8 days — evidence that SAFE is being positioned for institutional adoption beyond the tech industry.

This is the progression mechanism in action: proposal → voluntary standard → international institutional adoption → regulatory framework. The community is already at step 3.

Filed August 16 by AgroMoo (Niujiaxing, personal capacity). A detailed public comment offering four technical suggestions for SAFE's evidence layer:

• Completeness — reconcile multi-source evidence. Incidents involving agentic systems rarely live in a single party's record. Two independent systems routinely disagree about what happened. SAFE specifies what to collect but not how evidence from multiple sources should be reconciled into a coherent incident record (matched / missing / conflicting / unresolved). Preservation without reconciliation leaves the hardest agentic failures — cross-system disagreements — unaddressed.
• Independent Witness — external observation, not self-attestation. Self-reported evidence is necessary but insufficient. The comment proposes an explicit linkage for third-party corroboration — where another system, an independent runtime observer, or an external auditor can confirm or contradict a claim. This does not assign fault; it raises the quality of the shared evidence pool.
• Provenance Classification — grade the source. Not all evidence carries equal weight. The comment proposes a lightweight provenance grade on each evidence item (self_generated / external_system / third_party_witness) so consumers can weight evidence appropriately without leaking sensitive detail.
• Interoperability — evidence portable across runtimes. Agents execute across many runtimes (Claude Code, OpenAI Agents SDK, LangGraph, AutoGen, CrewAI). If evidence formats are runtime-specific, the same incident cannot be reconciled when its steps span multiple runtimes. A runtime-neutral evidence format prevents vendor lock-in of the safety record.

This issue reinforces the core tension documented in Issue #4: SAFE's verification model is declarative, not mechanically verifiable. The community is pushing SAFE toward enforceable evidence standards. The RFC as written is aspirational. The gap between "should" and "must" is exactly what Track 2 is tracking.

Filed August 16 by evilson (this investigation). The issue identifies a structural gap in SAFE's evidence model that directly affects open-weight deployments:

SAFE's evidence list assumes the reporting organization controls the full deployment stack — prompts, traces, tool calls, logs, configurations, model and safeguard versions, permissions, credentials, agent identities, incident timeline, and reproduction testing. When a model developer releases open weights on HuggingFace, they don't control how those weights are deployed downstream. They don't control the prompts, the tool configurations, the credentials, the runtime environment, or the monitoring.

The question: who reports? The model developer can't provide the evidence — they don't have logs from a deployment they don't control. The downstream deployer may not have the infrastructure to collect it. If both report, the same incident produces two incomplete reports, neither of which satisfies the evidence requirements.

This is the compliance trap's open-weight blind spot. The framework assumes a single organization controls the full stack. Open-weight deployments break that assumption. The reporting obligation falls into a gap between the model developer (who has the model but not the deployment context) and the downstream deployer (who has the deployment context but may not have the infrastructure to document it). This is the same structural asymmetry that runs through every SAFE requirement — the evidence model assumes enterprise-scale telemetry. Open-weight deployments don't have it and can't easily build it.

A new pull request by alvin-chang proposes adding three structural elements to SAFE: coordination procedures, legal carve-outs, and near-miss tiering. This is significant because it moves SAFE further from a voluntary compact and closer to a regulated reporting framework:

• Coordination procedures formalize how members interact during an incident — escalation paths, information sharing protocols, and cross-organization response steps. This is the operational infrastructure of a regulated framework.
• Legal carve-outs define what protections reporters receive — the boundaries of "non-punitive treatment" and where law enforcement access begins. Once legal carve-outs are codified in the standard, they become the reference point for future regulation. Legislators don't need to write new protections — they cite the ones SAFE already defined.
• Near-miss tiering categorizes incidents by severity and reportability — which near misses must be reported, which are informational, and which don't trigger the reporting obligation. This creates a classification system that regulators can adopt directly: "Category A near-misses must be reported within 72 hours" becomes a regulatory requirement with no further debate.

Each addition makes SAFE more regulation-like while maintaining the "voluntary" framing. The PR has no comments and has not been merged — but it demonstrates that contributors are already thinking of SAFE as a framework that will be adopted by regulators, not just a community compact.

Filed August 19 by djangamane (Jason Breckenridge, Diplomacy AI). The most sophisticated contribution to the RFC discussion so far. It proposes a 9th review layer: Did a human instruction, approval, or prompt formulation determine the outcome the system is recorded as having produced?

The issue uses a real case study: on August 14, TIME magazine reported what appears to be the first known instance of an LLM acting in a management capacity and terminating a human employee. Claude, running Andon Market (a real San Francisco store operated as a research experiment by Andon Labs), terminated an employee for lateness on 17 of 23 shifts. But the management logs show a sequence the summary record hides:

• The model first recommended a formal warning, not termination.
• A human operator then wrote: I want you to think about if this is really the right fit.
• The operator CEO acknowledged on the record that this was a leading question making clear what outcome was wanted.
• Only after that message did the model terminate the employee.

Under the current 8 control layers, this case passes clean. Authority was valid. Scope was never exceeded. Revalidation would pass. Perfect authority, perfect scope, perfect revalidation — and the wrong author. The record would read the system decided. Accurate as to the log, wrong as to the fact.

The contributor discloses an interest: Diplomacy AI publishes the Janus AI Risk Index rating Alliance members, and acknowledges it would benefit from requirements for external verification. The disclosure itself is notable — most contributors to this RFC have not disclosed their commercial interests.

Filed August 21 by ballen-m07. Points out that SAFE reporting criteria only cover acts of commission affecting third parties — one of four domains that should be covered:

The contributor notes that first-party reporting is standard across compliance frameworks (FISMA, SEC, NYDFS). SAFE is an outlier in excluding it. The proposal adds reporting for first-party harm and acts of omission — AI failing to take an expected security action that results in damage or near misses. Acts of omission can fail silently and a pervasive issue risks stacking up impacts until noticed.

More reporting domains means more compliance surface. Every expanded scope adds requirements that large organizations with dedicated security teams can absorb and small operators cannot.

Filed August 23 by eriknewton. The most direct external confirmation of the asymmetry this investigation has been tracking. The contributor identifies a population the RFC does not address: a single-person operator holding the signing key with no SOC. The Reporting Compact and Evidence Preservation both read as written for an organization with a security team.

The proposal: a portable, verifiable attestation the agent carries, so an individual operator can produce evidence at the point of interaction instead of through a submission process built for organizational members. It also needs a defined exit: the operator can pull their own evidence and memory out of any system that held it.

The contributor discloses: I maintain an open-source operator-side enforcement and custody layer for AI agents. This is the pattern documented across this investigation — a vendor contributes a requirement their product fills. The requirement becomes standard. The vendor product becomes the reference implementation. Small operators get a new obligation and a new vendor relationship. Large organizations get another checkbox.

Filed August 23 by victor-davidenko (two issues in the same day). The most infrastructure-heavy contributions to the RFC so far. Together they describe a system where AI agents cannot operate without three layers of pre-existing infrastructure:

• Pre-action certification (#24): Models need independent certification for specific task categories before deployment. Today, safety claims come from the provider. The contributor proposes certification bound to identity, checkable by any deployer, revocable when conditions change. Uncertified models and agents are blocked at the network level. There is no partial participation. Uncertified participants do not reach the point where they can cause an incident.
• Network-level enforcement (#24): Agent-initiated traffic is a new category that firewalls and API gateways cannot classify. The contributor proposes detecting agent traffic and routing it to governance before it reaches production systems. References the OpenAI sandbox escape as the case study.
• Identity for every actor (#25): Every participant in an AI workflow needs verifiable identity credentials with embedded certifications: agents, models, tools, data sources, IoT sensors, robots, autonomous vehicles. Certifications must travel inside the credential, not in external policy databases. Government-certified LLMs for classified workflows. Data provenance as identity.

The contributor references the SCARP protocol (scarpprotocol.com) and a Zenodo DOI — an academic/standards contributor with their own protocol to promote. The QSAFP-Core author (issue #1) commented on #25, linking it as a complement. The contributors are forming a network, referencing each other, building on each other proposals.

Why this matters: If these requirements become standard, a small operator running Ollama on a local server has no path to compliance. They cannot produce certified identity credentials. They cannot put governance infrastructure in their network path. They cannot participate in cross-organizational composition analysis. The infrastructure requirement is the compliance trap. This connects directly to Track 03: The Infrastructure Play.

Filed August 24 by victor-davidenko. The most intellectually significant issue since #19. It identifies a structural gap that no amount of per-action governance can close: every individual control passes, but the sequence of individually-compliant actions produces a harmful outcome.

The example: an agent sends 5 queries over 20 minutes, each requesting a small, policy-compliant slice of a dataset. No single query triggers a classification rule. No single response exceeds a volume threshold. Every individual action is governed, classified, and allowed. The union of the five responses reconstructs a complete dataset the agent was never authorized to access in full. The exfiltration is invisible to per-action governance because no single action violated policy.

Four attack patterns documented:

• Privilege accumulation: Delegation chains where each hop is authorized, but the aggregate scope exceeds what the original principal granted.
• Budget exhaustion: Individually-permitted financial commitments that together exceed the authorized budget.
• Sensitivity escalation: Delegation to an agent with a higher sensitivity ceiling, moving data into a less restrictive environment.
• Cross-organizational composition: Two organizations' agents each take compliant individual actions, but the combined output reveals restricted data.

The proposed solution requires workflow-level policy evaluation, cross-agent delegation governance, cross-organizational composition analysis, and revocation propagation across delegation chains. All of this requires infrastructure that only large organizations can build and operate. The composition problem is real. The proposed solution is another compliance moat.

Filed August 27 by DmitrL-dev (the contributor who provided field evidence on issue #4). Two full technical specifications in one day — and the phase of community contribution changed:

• PR #27 (chain-of-custody receipt profile) — directly addresses issue #17, filed from this investigation on August 19. A full specification covering origin and integrity, custody transitions, transformation receipts, durable receiver acceptance, historical key status, temporal anchoring, and machine-runnable conformance vectors. This is the first pull request in the repository that directly responds to an issue filed by this investigation. The gap was named here first; the community wrote the specification to fill it.
• PR #28 (workflow-composition evidence profile) — addresses issue #26 (composition governance). Specifies workflow lifecycle states (proposed, validated, reserved, committed, withheld, executed, unknown), atomic cumulative decisions, delegation monotonicity, revocation propagation, and cross-boundary continuity. 16 comments — the most active thread in the repository — including a detailed line-by-line technical review from victor-davidenko analyzing three architectural options for cross-organizational workflow identity and the failure modes of each.

Then a new behavior appeared: consolidation. imran-siddique (PR #18, anchored evidence) asked DmitrL-dev to merge the custody material from #27 into #18 rather than leave two overlapping anchoring proposals. DmitrL-dev agreed — the custody material will sit around #18's anchoring framework as a separate profile, with #18 remaining authoritative for the temporal property, the RFC 6962 mechanism, and anchoring statuses. Two contributors self-organized a specification merger, coordinating authorship preservation and DCO history, without any alliance involvement.

Why this matters: The contributor network has moved through three phases in 26 days — filing gaps (Aug 4-16), writing specifications (Aug 19-27), and consolidating specifications (Aug 28+). The community is producing implementation-grade regulatory material for free, self-organizing around it, and building toward a merged framework. One person holds merge authority over all of it. The work is collective; the decision is singular.

Filed August 29 by RavindraAnnam — a new contributor, not part of the established network. Proposes adding delegated-authority provenance to SAFE incident evidence: in an agent → sub-agent → tool workflow, knowing the identity and credentials used at each step may not be sufficient to determine whether an action remained within the authority originally granted by the human or originating principal. An upstream agent may be authorized for a bounded purpose while a downstream agent executes using broader credentials — each individual invocation appears valid even though the composed workflow exceeds the original delegation boundary.

This is the same finding as issue #26 (victor-davidenko, composition governance) and issue #19's decision-authorship question (djangamane). Three contributors, filing independently, from different angles, reached the same conclusion: individually-valid components compose into unauthorized outcomes, and the current framework cannot detect it.

When a problem is found once, it is an observation. When it is found three times by independent contributors, it is a structural property of the framework — and the community consensus around it forms the basis for new requirements that every deployer will eventually have to implement.

The Linux Foundation's August 4 blog post framed SAFE explicitly:

• Compared to NASA's Aviation Safety Reporting System (ASRS) — positioning it as the AI equivalent of a mature safety reporting system
• Developed by Cisco, CrowdStrike, Hugging Face, NVIDIA, Red Hat — all enterprise vendors
• "Rather than publishing a finished specification, participants begin with an open RFC" — the framing emphasizes openness
• "Trust is not a security control. Shared evidence and verifiable improvements are how trust is earned." — the language positions SAFE as the mechanism for earning trust
• SAFE should "operate neutrally so that no single vendor or industry segment controls its findings" — the neutrality claim

The neutrality claim is important. If SAFE is neutral, it applies equally to open and proprietary AI. But the alliance that created it excludes OpenAI, Google, and Anthropic. Neutrality within a non-neutral coalition is a structural question.

The CONTRIBUTING.md file specifies a simple process: fork, branch, DCO sign-off, PR. Substantive changes should be raised as issues first. But the file does not describe:

• Who reviews pull requests
• Who decides what gets merged
• What criteria are used for acceptance
• How disagreements are resolved
• Whether there is a steering committee or technical council

The repository has one contributor (Steve Winslow, Linux Foundation). All commits are his. The "open" process collects input but the decision-making is closed. 37 stars, 12 forks, 21 open issues, 8 open PRs — none merged.

The Evidence Preservation section lists what to keep: prompts, traces, tool calls, logs, configurations, model and safeguard versions, third-party dependencies, agent and workload identities, permissions and credentials, human approval and intervention events, files and external artifacts, detection/containment/recovery events, incident timeline, reproduction testing, and remediation evidence.

It does not specify:

• How the evidence was collected (method, tool, timestamp of collection)
• Who collected it and who has had access since collection
• How it was stored (format, integrity protection, access controls)
• Whether it was transferred between parties, by whom, and when
• Whether it was modified, copied, or transformed between collection and submission
• Cryptographic integrity proof (e.g., hash attestation) that the evidence is unchanged
• Provenance documentation for evidence that originated from third parties

The Supply Chain review layer asks: "Did a cloud, evaluation, data or tooling partner invalidate assumed controls?" This addresses whether a partner's controls failed. It does not address whether evidence received from that partner can be trusted to be authentic and unaltered.

When evidence comes from a third party — cloud provider logs, evaluation partner telemetry, tool vendor audit trails, shared infrastructure — the reporting member is submitting evidence they did not collect. Without chain of custody, neither SAFE reviewers, regulators, nor affected parties can verify that the evidence originated from the stated source, has not been modified in transit, the third party's own logging is tamper-evident, or that each party who handled the evidence is documented.

This issue is distinct from three related issues already on the repository:

• Issue #11 (CyberGuardian-XRSI): Addresses whether preserved evidence is independently verifiable — can someone else check it? Chain of custody addresses whether you can prove the evidence has not been altered since collection — can you authenticate its provenance? Verifiability and custody are complementary but separate concerns.
• Issue #14 (AgroMoo): Addresses reconciliation and verification across multiple reports. Chain of custody addresses the handling history of individual evidence items within a single report.
• Issue #7 (safal207): Addresses reconstructability of findings via causal graphs. Chain of custody addresses integrity of the evidence those findings depend on.

If SAFE matures into a standard referenced by procurement or regulators, evidence submitted without chain of custody can be challenged on authenticity grounds. A member could preserve complete logs from a cloud provider but be unable to demonstrate how those logs reached their SAFE submission — making the evidence only as trustworthy as the weakest link in the transfer chain.

This creates the same structural asymmetry that runs through every other SAFE requirement. Large providers with dedicated forensics teams and vendor SLAs can implement chain of custody internally. Small operators who depend on third-party infrastructure they do not control cannot prove the integrity of evidence they did not collect themselves. The gap is survivable for enterprises and a compliance trap for everyone else.

The issue asks whether the Evidence Preservation section should require, for each evidence item, a minimum chain of custody record: source, collection timestamp and method, each transfer between parties, storage format and integrity protection, and cryptographic hash at collection and at submission. And whether this requirement should scale — mandatory for evidence from third parties, recommended for self-collected evidence — or apply uniformly.

The EU AI Act's General Purpose AI (GPAI) model obligations have applied since August 2, 2025. But on August 2, 2026 — exactly two days before the SAFE RFC was published at Black Hat — the European Commission's enforcement and penalty powers activated.

• Fines up to 3% of global annual turnover or €15 million, whichever is higher (Article 101)
• The AI Office can compel documentation, run technical evaluations, demand risk-mitigation measures, and restrict or withdraw models from the EU market
• Refusing to comply is itself a finable offense
• The "Digital Omnibus" delayed high-risk AI timelines to late 2027, but did not delay GPAI enforcement

The timeline is not subtle:

1. Aug 2, 2025 — GPAI obligations apply to new models
2. Aug 2, 2026 — Enforcement powers activate (fines, market restrictions, documentation demands)
3. Aug 4, 2026 — SAFE RFC published at Black Hat Las Vegas
4. Aug 4-16, 2026 — 13 issues and 3 PRs filed in rapid succession

SAFE is being built in the window between enforcement activation and the first enforcement actions. The contributors are not randomly proposing requirements — they are building the compliance infrastructure that regulators, procurement teams, and enterprise buyers will reference to demonstrate conformity.

The EU Commission's voluntary Code of Practice split the model market into two tiers:

The companies that signed the Code are the same companies selling "compliance-ready" enterprise AI products. The companies that declined (Meta) or partially signed (xAI) are the ones whose models are most accessible to small operators through open weights.

OpenAI already operates a Trust Portal and Compliance Platform for Enterprise and Edu customers — providing compliance logs, eDiscovery integration, and SIEM connectivity. Compliance is not a framework they are studying. It is a product they are selling.

The models most accessible to small operators — Llama (Meta), Mistral open weights — are the ones whose providers either declined the Code (Meta) or signed but don't offer compliance infrastructure to downstream deployers. The large companies running closed models (OpenAI, Google, Anthropic) sell compliance as part of the subscription. The small operator running open weights gets the legal exposure without the compliance wrapper.

beam.ai frames this as a procurement signal: "Your vendor's compliance posture became your compliance posture." If you run Llama-based agents in the EU, you inherit Meta's compliance gap. The fallback? Switch to a provider that signed the Code. The providers that signed the Code are the ones selling enterprise subscriptions.

This is the two-tier system made explicit:

• Tier 1: Companies that signed the Code of Practice, have compliance platforms, and can sell "compliance-ready" AI as a service
• Tier 2: Everyone else — local model operators, small startups, open-weight deployers — who must "demonstrate compliance by other means" with no infrastructure, no framework, and no roadmap

SAFE is being built to formalize Tier 1's advantage. The contributors are writing the requirements that Tier 1 can meet and Tier 2 cannot. Issue #16 — filed by this investigation — asks who is responsible for SAFE reporting when an open-weight model is deployed downstream. Under the current structure, the answer is: the small operator. The model developer declined the Code. The downstream deployer inherits the obligation. The large company sells compliance as a service.

The gap is the policy.