Compliance, Export Controls, and Responsible Deployment

Quantum programs operate inside legal, security, national-security, data, and reputational constraints. This chapter is not legal advice. It is an operating model for making sure technical teams know when to involve qualified counsel, export-control specialists, security, and executive owners.

The basic rule: do not let quantum infrastructure become an informal channel for controlled technology, sensitive data, unreviewed claims, or unsupported customer commitments.

49.1 Compliance boundary model

flowchart TB
    Boundary[Quantum compliance boundary] --> People[People and access]
    Boundary --> Technology[Technology and controlled know-how]
    Boundary --> Data[Data and customer material]
    Boundary --> Hardware[Hardware, components, and control systems]
    Boundary --> Software[Software, models, and workflows]
    Boundary --> Claims[External claims and commitments]

A compliance boundary is not just a firewall. It is the set of controls that govern who can access what, from where, under which authorization, with what logging, and for what purpose.

49.2 Export-control awareness

Quantum computing, cryogenic systems, control electronics, software, and technical data may be subject to export-control analysis. In September 2024, BIS and the Federal Register published controls covering quantum computers and related assemblies, components, software, and technology under Commerce Control List additions and revisions. [R86]

flowchart LR
    Activity[Proposed activity] --> Screen{Export-control relevant?}
    Screen -- no --> Standard[Standard security review]
    Screen -- yes --> Specialist[Export-control specialist]
    Specialist --> Classify[Classify item, software, tech, or data]
    Classify --> License{License or restriction?}
    License -- yes --> Hold[Hold until cleared]
    License -- no --> Proceed[Proceed with recorded decision]

Activities that should trigger review include:

• sharing hardware design information,
• exposing low-level control methods,
• transferring specialized calibration software,
• granting foreign-person access to controlled technical data,
• shipping components or prototypes,
• enabling cross-border support sessions,
• publishing detailed device-performance data that might expose controlled know-how.

49.3 Access-control operating model

flowchart TB
    Identity[Identity] --> Role[Role]
    Role --> Entitlement[Entitlement]
    Entitlement --> Resource[Resource]
    Resource --> Log[Audit log]
    Log --> Review[Periodic access review]
    Review --> Adjust[Remove, renew, or escalate]

NIST SP 800-53 provides a broad catalog of security and privacy controls, while CSF 2.0 gives a high-level cybersecurity risk-management framework. A quantum program should not invent access-control governance from scratch; it should map quantum-specific resources into established security-control families. [R88] [R89]

49.4 Resource classification

flowchart LR
    Resource[Quantum resource] --> DataClass[Data classification]
    Resource --> ExportClass[Export classification]
    Resource --> SecurityClass[Security classification]
    Resource --> ClaimClass[Claims classification]
    DataClass --> Policy[Policy decision]
    ExportClass --> Policy
    SecurityClass --> Policy
    ClaimClass --> Policy

49.5 Publication and disclosure review

Quantum teams like publishing. Companies like announcements. Both can create risk if claims outrun evidence or disclosure outruns compliance review.

sequenceDiagram
    participant Author as Author
    participant Tech as Technical reviewer
    participant Security as Security reviewer
    participant Export as Export-control reviewer
    participant Legal as Legal/compliance
    participant Exec as Executive owner
    Author->>Tech: submit draft
    Tech->>Security: verify data and system exposure
    Security->>Export: screen controlled technical data
    Export->>Legal: record restrictions or approval
    Legal->>Exec: approve final release
    Exec-->>Author: publish or revise

Review should cover:

• whether the claim is supported,
• whether the benchmark is reproducible,
• whether uncertainty is disclosed,
• whether customer data is excluded,
• whether controlled information is exposed,
• whether roadmap language is qualified.

49.6 Compliance incidents

A compliance incident should be handled with the same discipline as a security incident.

stateDiagram-v2
    [*] --> Suspected
    Suspected --> Contain
    Contain --> NotifyOwners
    NotifyOwners --> Investigate
    Investigate --> Remediate
    Remediate --> Review
    Review --> Closed

Examples:

49.7 Responsible deployment

Responsible deployment means the platform refuses unsupported uses.

flowchart TB
    Request[Use request] --> Fit{Technically fit?}
    Fit -- no --> Reject[Reject or redirect]
    Fit -- yes --> Risk{Risk acceptable?}
    Risk -- no --> Escalate[Escalate or block]
    Risk -- yes --> Evidence{Evidence sufficient?}
    Evidence -- no --> Pilot[Pilot with limitations]
    Evidence -- yes --> Deploy[Deploy with monitoring]

The platform should avoid customer-facing claims that imply general quantum advantage, cryptographic safety, optimization superiority, or production reliability without evidence packages and formal approvals.

49.8 Operating rule

Compliance should not be a late-stage veto. It should be an admission-control input. The earlier it participates, the less often it blocks good work and the more often it prevents irreversible mistakes.