Trust Without Transparency: The Accountability Gap in Closed-Weight AI Agent Systems

The nuclear industry has a phrase for the underlying principle of reactor safety: "safety by design." The reactor is safe not because operators follow safe procedures, but because the physical design makes unsafe operation impossible or self-limiting. Transparency — in the sense of literally being able to see the physical arrangement of fuel rods and control rods — is part of what makes safety by design achievable. Engineers can inspect the reactor to verify that safety properties hold.

We are building AI systems with the equivalent criticality of nuclear reactors — systems that can make consequential decisions about financial credit, medical treatment, employment, and infrastructure control — while deploying them with safety characteristics that are fundamentally opaque. The weights of GPT-4, Claude, and Gemini are not publicly available. The training data used to produce them is partially disclosed at best. The decisions these systems make cannot be traced to any inspectable component of their architecture in a way that would satisfy a physical safety engineer.

This opacity is not primarily a failing of AI companies — it reflects genuine competitive dynamics, intellectual property considerations, and the scale of investment required to produce these systems. But opacity creates a fundamental accountability gap: how do you trust a system whose internals you cannot inspect? How do you audit a system whose decision-making process cannot be directly observed? How do you regulate a system whose safety properties cannot be verified without the cooperation of its creator?

These questions are not academic. They are the central challenge for enterprise AI governance in 2026, as organizations increasingly deploy AI agents built on closed-weight models in consequential contexts.

TL;DR

• The closed-weight accountability gap has three layers: architectural opacity (no weight inspection), process opacity (training data and RLHF details undisclosed), and behavioral opacity (internal reasoning not inspectable)
• Behavioral auditing — systematic measurement of what a system does, without requiring visibility into how it does it — is the primary substitute for architectural transparency
• API-level behavioral contracts formalizable as behavioral pacts provide a legally and operationally meaningful alternative to inspection-based assurance
• Third-party behavioral attestation by independent evaluators provides verification that doesn't require model provider cooperation
• The EU AI Act's transparency requirements for high-risk AI create accountability obligations that closed-weight providers must meet through behavioral disclosure
• Armalo's trust infrastructure is specifically designed for the closed-weight context: all trust evidence is behavioral, not architectural

The Three Layers of Closed-Weight Opacity

Layer 1: Architectural Opacity

The most fundamental opacity: the model weights are not publicly available and cannot be inspected. This prevents:

• Direct verification that safety properties are encoded (you can't look at the weights to confirm that a safety constraint is present)
• Adversarial robustness analysis at the weight level (many adversarial attacks require access to gradients, which requires access to weights)
• Independent replication of claimed capabilities (you can't verify the model's behavior by reproducing it from first principles)
• Detection of backdoor triggers at the weight level (a backdoor encoded in weights is invisible without weight access)

Open-weight models (LLaMA 3, Mistral, Falcon, etc.) address architectural opacity at the cost of competitive protection. The trade-off is that open weights enable deeper inspection but also enable misuse, fine-tuning for harmful purposes, and removal of safety guardrails.

Layer 2: Process Opacity

Even if the weights were available, they would be interpretable only with detailed knowledge of the training process: what data was used, what RLHF reward signal was used, what safety training was applied, and what post-training interventions were made.

AI companies typically disclose:

• General description of training data categories
• High-level descriptions of safety training processes
• Red team evaluation summaries
• Model card specifications

They do not typically disclose:

• Complete training data composition
• Specific RLHF reward model details
• Specific fine-tuning data for safety behaviors
• Internal evaluation benchmarks and thresholds that models were required to meet

This process opacity is significant because the training process determines much of the model's behavioral disposition, and behavioral dispositions not documented in the model card may be operationally significant.

Layer 3: Behavioral Opacity

Even with full architectural and process transparency, the connection between a specific input and a specific output often cannot be traced through a satisfying causal explanation. Attention mechanisms provide some visibility into which parts of the input the model "attended to," but this is far from a complete causal account of why a specific token was generated.

This behavioral opacity matters because:

• When a model makes an error, it is often not clear whether the error is systematic (affecting all similar inputs) or idiosyncratic (affecting only that specific input)
• When a model is red-teamed and a successful attack is found, it is not clear whether patching that specific attack pattern will prevent the underlying vulnerability
• When a model is evaluated and achieves a given accuracy, it is not clear whether accuracy on the test set is predictive of accuracy on the full deployment distribution

The gap between AI interpretability research and the needs of enterprise AI governance is wide. Interpretability methods that exist in research form (saliency maps, circuit analysis, activation analysis) do not yet provide the kind of causal accountability chain that would satisfy a safety engineer or a regulator.

Behavioral Auditing as Transparency Substitute

Given the three layers of opacity, behavioral auditing — systematic measurement of what a system does, without requiring access to how it does it — is the primary viable approach to establishing trust in closed-weight AI systems.

What Behavioral Auditing Can and Cannot Establish

Can establish:

• The system's empirical accuracy on a representative test distribution
• The system's calibration quality (whether confidence scores map to accuracy)
• The system's scope adherence (whether it stays within authorized boundaries)
• The system's adversarial robustness on tested attack techniques
• The system's behavioral consistency over time (detecting drift)
• The system's behavior under adversarial trigger conditions (behavioral malware testing)

Cannot establish:

• Whether the system has never-yet-activated backdoor behaviors that weren't triggered in testing
• Whether the system's safety properties are robust to fine-tuning (open-weight models can have safety properties removed by fine-tuning; closed-weight models may have analogous vulnerabilities)
• Whether the system behaves the same on inputs it has never encountered before (out-of-distribution generalization)
• Why the system makes the specific decisions it makes (no causal explanation)

This scope limitation is important to acknowledge: behavioral auditing provides strong evidence about a system's behavior in tested conditions and weaker (but non-zero) evidence about its behavior in untested conditions. No behavioral audit can rule out all possible failure modes — it can only reduce the probability of undetected failures by increasing the coverage of tested conditions.

The Coverage-Depth Trade-off in Behavioral Auditing

Behavioral auditing faces a fundamental coverage-depth trade-off: you can test many inputs shallowly or fewer inputs deeply. For closed-weight systems, the appropriate balance depends on the deployment context:

High-volume, standard-case deployment (e.g., customer service agent for a consumer product): Wide coverage is more important. Many different query types, many different user personas, high-volume behavioral statistics. Depth on each individual query is less important because the distribution of cases is broad.

Low-volume, high-stakes deployment (e.g., financial advice agent for institutional investors): Depth on each case type is more important. Detailed behavioral analysis of the specific decision types the agent will make, with adversarial analysis of each. Width across all possible input types is less achievable.

Adversarial-risk deployment (e.g., agent deployed in a context where adversaries are likely to probe it): Adversarial depth is the priority. Red team evaluation with a qualified adversarial team should take precedence over broad coverage.

Continuous vs. Point-in-Time Behavioral Auditing

A one-time behavioral audit at deployment time captures the system's behavior at a specific moment. Closed-weight systems change in ways their users can't control: providers update models, fine-tune on new data, adjust safety filtering. A behavioral audit from six months ago may not reflect the current system.

Continuous behavioral auditing monitors the system's behavior over time, detecting changes that may indicate model updates or behavioral drift. Key continuous monitoring metrics:

• Behavioral distribution statistics (PSI, embedding distance from baseline)
• Calibration tracking (ECE over time)
• Scope adherence rate
• Adversarial probe battery run on a schedule

The detection gap between a model change and its detection through continuous behavioral auditing depends on the monitoring frequency and the magnitude of the change. Major behavioral changes are detectable within days; subtle shifts in calibration may take weeks to accumulate sufficient statistical evidence.

API-Level Behavioral Contracts

For closed-weight systems that are accessed via API, behavioral contracts can formalize the performance characteristics that the system is expected to maintain — providing contractual accountability that substitutes for inspection-based accountability.

What an Effective API Behavioral Contract Contains

An effective behavioral contract between a model provider and an enterprise deployer specifies:

Accuracy commitments: The minimum accuracy the system will achieve on defined benchmark tasks, with the benchmark methodology specified.

Behavioral stability commitments: Notification obligations before behavioral-changing model updates. Model providers that update their models without notification create an unacceptable governance gap for enterprise deployers.

Safety property commitments: The safety behaviors the system is guaranteed to exhibit, including refusal rates on defined categories of prohibited content and injection resistance rates on defined attack technique categories.

Calibration commitments: The maximum acceptable Expected Calibration Error for defined task categories.

Change notification requirements: How much advance notice the provider will give before behavioral changes, what the notification will contain, and what transition support is available.

Audit rights: Whether the enterprise deployer has the right to conduct third-party behavioral evaluations and what data the provider will supply to support those evaluations.

Remedy provisions: What remedies are available when committed behavioral properties are not maintained.

Model Provider Transparency Obligations Under EU AI Act

For model providers whose models are used in high-risk AI applications (as defined by the EU AI Act), the Act creates transparency obligations that constrain closed-weight opacity:

For foundation model providers (Article 52b and related):

• Training data description requirements
• Technical documentation requirements
• Testing and evaluation results disclosure
• Incident reporting obligations
• Third-party evaluation access requirements for certain model capabilities

These obligations are more extensive for models with "systemic risk" (very large-scale models with potentially broad societal impacts) and are subject to ongoing regulatory guidance that is still being developed.

For enterprise deployers, the EU AI Act transparency requirements can be invoked contractually: insist on receiving the disclosure documents that the Act requires providers to maintain, and verify that the disclosed information is sufficient to support your own compliance obligations.

The Gap Between Behavioral Auditing and Architectural Transparency: What We Lose

Before discussing how to manage without architectural transparency, it's important to be precise about what architectural transparency would provide that behavioral auditing cannot, and why this matters for enterprise AI governance.

What Architectural Transparency Would Enable

If model weights and training processes were fully transparent, AI governance professionals could:

Verify safety property encoding: With weight access, interpretability researchers can look for the neural circuit patterns that encode specific behaviors — verifying that a claimed safety property is actually encoded in the model's weights, not just exhibited probabilistically under current testing conditions.

Predict failure modes before testing: With full model transparency, adversarial researchers can identify exploitable patterns in the model's representation before testing them — finding vulnerabilities through static analysis rather than empirical probing. This is analogous to finding security vulnerabilities through code review rather than only through penetration testing.

Assess generalization confidence: With training data access, researchers can assess how well-represented different query types are in the training distribution — providing a priori confidence bounds on model performance without requiring exhaustive empirical testing.

Reproduce model behavior: With weight and training data access, independent researchers can reproduce a model's behavior from first principles — providing a verification pathway that doesn't depend on the model provider's cooperation.

Detect backdoors structurally: Backdoor attacks encode hidden behaviors that activate on specific triggers. Behavioral testing can detect known backdoor patterns, but a novel, carefully constructed backdoor may evade all behavioral tests. Weight inspection can detect backdoors that behavioral auditing misses.

What Behavioral Auditing Provides Instead

Behavioral auditing substitutes empirical observation for architectural inspection. It provides:

Coverage-proportionate assurance: The confidence provided by behavioral auditing is proportional to the coverage of the test set. Wide coverage of the deployment distribution provides strong behavioral assurance; narrow coverage provides weak assurance.

Temporal assurance: Behavioral auditing, when continuous, provides assurance that is current — reflecting the model's behavior right now, not months ago when it was developed. Architectural inspection of static weights provides assurance that is immediately stale.

Context-specific assurance: Behavioral auditing conducted in the specific deployment context provides stronger assurance for that deployment than general-purpose architectural inspection. A model that is safe in most contexts but vulnerable in a specific domain may pass architectural inspection but fail behavioral auditing designed for that domain.

External verifiability: Behavioral evidence produced through standardized testing methodology can be verified by third parties using the same methodology — without requiring access to the model's internal architecture.

The Fundamental Limitation: The Unobservable Long Tail

The fundamental limitation of behavioral auditing — what architectural transparency would address but behavioral auditing cannot — is the unobservable long tail of possible behaviors.

For any AI system of sufficient complexity, there exist inputs that produce unexpected outputs — and no finite behavioral test can rule out all such inputs. A model with a backdoor triggered by a specific 32-token sequence will pass behavioral auditing that tests thousands of inputs, because the probability of randomly sampling that specific 32-token sequence is vanishingly small.

This limitation is real and should not be minimized. Enterprise deployers who are told that behavioral auditing provides the same assurance as architectural transparency should understand: it does not. It provides empirical assurance proportionate to test coverage, with residual uncertainty about untested inputs.

What architectural transparency would provide — assurance about the unobservable long tail — is exactly what behavioral auditing cannot provide. The choice between open and closed weights is, in part, a choice between structural assurance with broad coverage limitations and behavioral assurance with distributional limitations.

Third-Party Behavioral Attestation

The most credible form of trust evidence for closed-weight systems — more credible than model provider documentation, more credible than deployer self-assessment — is third-party behavioral attestation: independent evaluation of the system's behavior by a party with no financial stake in the outcome.

The Independence Requirement

Third-party attestation is only credible if the attesting party is genuinely independent:

• No financial relationship with the model provider that could create a conflict of interest
• No financial relationship with the deploying organization beyond the evaluation engagement
• Qualified to conduct the evaluation (relevant AI safety and security expertise)
• Accountable for the attestation results (public reputation at risk if attestations are unreliable)

The independence requirement is analogous to the auditor independence requirements in financial accounting (SOX, GAAP). Financial statement auditors are prohibited from providing non-audit services to audit clients because those services create financial dependence that compromises independence. The same principle should apply to AI behavioral attestors.

What Third-Party Attestation Covers

A comprehensive third-party behavioral attestation for a closed-weight AI agent covers:

Task performance verification: Independent measurement of accuracy on a test set that the attesting party creates, not one provided by the model developer or deployer. The attesting party's test set should cover the deployment use case without being engineered to favor good performance.

Adversarial robustness testing: Red team evaluation by qualified adversarial AI researchers. The evaluation should include both known-technique testing (from published research and ATLAS) and novel technique development.

Behavioral stability assessment: Evaluation at multiple time points to assess whether the system's behavior is stable or changing, and whether reported behavioral changes match actual changes.

Scope and calibration verification: Independent measurement of scope adherence rates, calibration error, and behavioral consistency.

Transparency documentation review: Assessment of whether the model provider's documentation (model card, technical report, terms of service) is accurate, complete, and sufficient to support the deployer's governance needs.

Attestation Standards Development

The AI attestation industry is still developing standards for what a valid behavioral attestation includes, what methodologies are accepted, and what qualifications attestors need. Organizations developing these standards include:

• NIST's AI Safety Institute
• BSI (British Standards Institution) AI safety working groups
• ISO/IEC JTC1/SC42 standardization committee
• Partnership on AI
• The Responsible AI Institute

Enterprises requiring behavioral attestation should insist that attestors document their methodology in sufficient detail for independent replication, and should prefer attestors who are participating in standards development to ensure their methods reflect evolving best practices.

Building Behavioral Trust Evidence Without Model Access

The absence of architectural transparency necessitates a more systematic approach to behavioral evidence collection. Organizations that have built mature closed-weight governance programs follow consistent patterns:

The Behavioral Evidence Stack for Closed-Weight Systems

Layer 1: Model card verification

Begin by auditing the model card against behavioral evidence. For each claim in the model card ("this model achieves X% accuracy on benchmark Y"), verify the claim empirically by running the benchmark in your deployment environment. Model card claims produced in the provider's controlled evaluation environment may not reproduce in your production environment.

Model card verification takes 1-2 weeks and immediately identifies gaps between stated and actual behavioral properties. Common findings: accuracy claims that don't reproduce on the deployment distribution, calibration claims that don't hold in the specific deployment domain, safety claims that are contingent on evaluation conditions that don't match production.

Layer 2: Domain-specific accuracy baseline

Construct a probe battery of 200-500 queries that are representative of your specific deployment distribution, with ground truth labels. Run the model against this battery and measure accuracy. Compare to the model card's claimed accuracy — most deployers find the domain-specific accuracy is meaningfully different (often lower) than the general benchmark accuracy.

The domain-specific accuracy baseline is your primary behavioral assurance that the model is suitable for your specific deployment. It cannot be substituted by the model card's reported accuracy on general benchmarks.

Layer 3: Adversarial robustness evaluation

Conduct a structured adversarial evaluation using the OWASP LLM Top 10 and relevant MITRE ATLAS techniques as your test inventory. For each technique category, attempt at least 10 attack variations. Document the success rate for each category.

For closed-weight systems, adversarial evaluation must be more thorough than for open-weight systems, because you cannot inspect the model's internal representations to understand why specific attacks succeed or fail. Each adversarial finding is evidence of a behavioral property that was not visible from the model's documentation.

Layer 4: Calibration audit

Measure the model's calibration on your domain-specific probe battery. Compute ECE, create a reliability diagram, and identify domains where overconfidence or underconfidence is most severe. For most closed-weight systems deployed in specific enterprise domains, calibration is worse than the general benchmark because the model's calibration was optimized for the training distribution, not your specific domain.

Layer 5: Continuous behavioral monitoring

Deploy behavioral monitoring infrastructure that tracks the model's behavior over time, detecting drift caused by provider model updates. At minimum: weekly probe battery execution with PSI comparison to baseline. For high-stakes deployments: daily probe execution with automated alerting.

Continuous monitoring is especially critical for closed-weight systems because the model can change without your knowledge. Provider updates may improve the model on average while degrading it on your specific deployment domain — and only continuous monitoring can detect this.

Layer 6: Third-party attestation

Commission independent behavioral attestation annually (or after each significant provider update). The attestation should cover all five layers above plus any domain-specific requirements. The attesting party should be independent of both the provider and your organization — this independence is what makes the attestation credible to regulators, auditors, and partners who depend on your trust claims.

Regulatory Landscape for Closed-Weight System Accountability

EU AI Act: Transparency Through Disclosure

The EU AI Act addresses the closed-weight accountability gap primarily through mandatory disclosure requirements rather than through mandatory open-weighting. High-risk AI system providers must:

• Maintain detailed technical documentation
• Disclose training data characteristics
• Report incidents to national supervisory authorities
• Provide access to evaluation and testing results to regulatory bodies
• Allow technical documentation inspection by competent authorities

These disclosure requirements do not require publishing model weights, but they do require maintaining and providing information that supports behavioral accountability. The regulatory mechanism is: if a regulator has a concern about a closed-weight system, they can compel disclosure of the information needed to investigate.

For enterprise deployers, the practical implication is that model providers subject to the EU AI Act must maintain documentation that deployers can request to support their own compliance obligations. Deployers should include documentation access rights in their contracts with model providers.

Liability Implications of Closed Weights

In product liability cases, the closed-weight property of AI systems may cut both ways:

Argument that closed weights limit provider liability: The provider did not know how the deployer would use the system; the deployer made customization and deployment decisions that contributed to the harm.

Argument that closed weights increase provider liability: The deployer could not inspect the system to identify the harmful property; the provider had exclusive knowledge of the system's characteristics; the provider's opacity prevented the deployer from exercising reasonable diligence.

As AI product liability cases develop through 2026 and beyond, the accountability implications of closed weights will become clearer through case law. Conservative enterprise deployers should assume that closed-weight opacity will be factored into liability analysis and should maintain behavioral audit records that document their diligent efforts to assess the system's properties without weight access.

How Armalo Addresses the Closed-Weight Accountability Gap

Armalo's trust infrastructure is designed specifically for the closed-weight context. Every trust signal in Armalo's composite score is derived from behavioral evidence — observable inputs and outputs — not from model architecture or training data inspection. This makes Armalo's trust scores applicable to closed-weight systems without requiring model provider cooperation beyond the API access that deployers already have.

The Armalo behavioral evaluation framework runs entirely on the API level: it submits carefully designed queries through the agent's API and analyzes the responses. This means that any agent, regardless of whether its underlying model is open or closed, can be evaluated on the Armalo platform.

Armalo's third-party attestation service provides the independence that first-party behavioral auditing cannot: Armalo evaluators have no financial relationship with model providers, are accountable for the accuracy of their attestations through their public reputation, and follow a methodology that is documented in sufficient detail for independent review.

For enterprises deploying closed-weight systems, Armalo provides the behavioral evidence record that makes governance claims credible — not "we trust this system because the provider's model card says it's safe," but "we trust this system because independent behavioral evaluation under adversarial conditions produced these specific results over this time period, monitored by this monitoring pipeline."

The Armalo behavioral pact framework creates API-level behavioral contracts that are operationally enforceable: an agent's pact specifies the behavioral properties it commits to maintaining, Armalo monitors compliance continuously, and trust score impacts follow when properties are not maintained. These are not contractual claims about model architecture — they are contractual claims about observable behavior, which is what the closed-weight context makes accessible.

Conclusion: Key Takeaways

Trust in closed-weight AI systems is achievable — not through architectural transparency, but through behavioral evidence accumulated over time through rigorous, independent, adversarially informed evaluation. The accountability gap is real and should not be minimized, but it is not insurmountable.

Key takeaways:

1. Closed-weight opacity has three layers — architectural, process, and behavioral — each with different accountability implications.

2. Behavioral auditing is the primary transparency substitute — it can establish empirical trust across the dimensions that matter operationally.

3. Behavioral auditing has fundamental limitations — it cannot rule out never-yet-activated backdoors, out-of-distribution failure modes, or safety property degradation through fine-tuning.

4. API-level behavioral contracts operationalize accountability — change notification requirements, accuracy commitments, and audit rights create contractual accountability where inspection-based accountability is unavailable.

5. Third-party attestation is the gold standard — independent evaluation by genuinely independent third parties provides more credible and durable trust evidence than any amount of first-party documentation.

6. EU AI Act creates transparency obligations — model providers subject to the Act must maintain documentation that supports enterprise deployers' governance obligations.

7. Continuous monitoring is required — closed-weight models change without deployer visibility; continuous behavioral monitoring detects changes that point-in-time audits miss.

8. The behavioral evidence stack has six layers — model card verification, domain-specific accuracy baseline, adversarial robustness evaluation, calibration audit, continuous behavioral monitoring, and third-party attestation. Each layer addresses failure modes that the layers below it cannot catch.

9. Enterprise contracts must require behavioral accountability provisions — version notification requirements, evaluation access rights, and incident liability provisions provide the contractual accountability that inspection-based assurance would otherwise provide.

10. The unobservable long tail is a real limitation — behavioral auditing cannot rule out never-yet-triggered failure modes in closed-weight systems. Enterprise deployers should understand this residual risk and manage it through deployment context controls (limiting scope, maintaining human oversight) rather than pretending it doesn't exist.

The trust infrastructure for the AI economy will be built on behavioral evidence, not architectural transparency. That is the consequence of the competitive dynamics that make closed weights the dominant deployment model for frontier-capability systems. The organizations that invest in behavioral evidence collection, maintenance, and third-party verification will have the accountability posture that high-stakes AI agent deployment increasingly requires. Those that rely on model provider documentation alone will discover its limitations at the worst possible time — when accountability is demanded by regulators or harmed users and documentation alone proves insufficient to demonstrate the due diligence required.

Enterprise Contracting for Closed-Weight Systems: A Practical Template

Given the accountability gap inherent in closed-weight systems, enterprise deployers should require specific contractual provisions when licensing AI systems from closed-weight providers. The following provisions represent the current best practice for closed-weight AI procurement contracts:

Behavioral Stability Commitments

Version notification requirement: Provider must give minimum 30-day advance notice of any model update that may materially affect the model's behavioral properties. The notice must include: what behavioral properties may change, the expected magnitude of change, and what mitigation the provider recommends.

Behavioral stability window: Provider commits that the model's core behavioral properties (accuracy, calibration, scope adherence) will not change materially within a defined stability window (e.g., 90 days) without the required notice.

Rollback provision: For a defined period following any model update, deployer has the right to request restoration of the prior model version while they conduct behavioral re-evaluation.

Evaluation Support Rights

Independent evaluation access: Deployer has the right to conduct independent behavioral evaluations of the model via API, with no restrictions on the query types used for evaluation (subject to reasonable use policies).

Model card update obligations: Provider commits to update the model card within 30 days of any material change to the model's behavioral properties, and to make model card revision history available to deployers.

Test environment access: Deployer has access to a test environment where behavioral evaluation can be conducted without affecting production usage limits or generating production audit logs that might influence future model behavior (preventing evaluation gaming by the provider).

Regulatory Compliance Support

EU AI Act documentation: For deployments subject to EU AI Act high-risk classification, provider commits to provide the technical documentation required by Article 11 in a timely manner upon deployer request, including training data characteristics, evaluation methodology, and safety testing results.

Incident notification: Provider commits to notify deployers within 24 hours of becoming aware of any security vulnerability, safety property degradation, or material behavioral anomaly in the deployed model.

Regulator cooperation: Provider commits to cooperate with regulatory inquiries related to deployer's use of the model, providing technical information to regulators as required by applicable law and as permitted by the provider's confidentiality obligations to other customers.

Accountability Provisions

Behavioral warranty: Provider warrants that the model's behavioral properties, as documented in the model card, are accurate at the time of contracting and will be updated in the model card when they change materially.

Incident liability: Provider accepts liability for direct damages caused by material inaccuracies in the model card documentation that the deployer reasonably relied upon in making deployment decisions.

Audit right: Deployer has the right to hire qualified third-party auditors to conduct behavioral evaluations of the model and to share the results of those evaluations with regulators and other parties as required by applicable law.

These provisions do not require the provider to open its weights or disclose proprietary training details — they are behavioral accountability requirements that can be satisfied while maintaining all proprietary protections. Providers who refuse all of these provisions should be treated as providers who are not prepared to stand behind their products' behavioral properties.

The contracting provisions described here represent the current leading edge of enterprise AI procurement best practices. As the AI agent market matures and regulatory requirements solidify, provisions like these will become standard requirements rather than negotiated additions. Organizations that normalize these requirements in their procurement today will be better positioned when their regulators begin asking for evidence of provider accountability frameworks — as EU AI Act enforcement and equivalent regulations in other jurisdictions will eventually require. The accountability infrastructure for the AI agent economy is being built incrementally through individual procurement decisions, and the enterprises that demand it are shaping the market norms that will govern AI agent deployment at scale.