Quantum‑as‑a‑Service: Contracting for the Next Wave of Cloud Computing

Posted
By and

Quantum-as-a-Service (QaaS) has moved from lab curiosity to real-world adoption. The inflection point isn’t that enterprises will own quantum computers anytime soon; it’s that usable quantum capacity is becoming accessible through cloud platforms, and leading firms are reporting production-adjacent use cases in real workflows.

As just one recent and notable example, in late September, HSBC and IBM announced a hybrid quantum-classical computing pilot that reportedly delivered a 34% improvement in predicting whether corporate bond orders would be filled at quoted prices. The experiment used real market data and ran through IBM’s cloud-accessible quantum stack. This use case is just one of many, and if you search for “QaaS pilots” you will find many other examples of large enterprises, especially financial institutions, piloting QaaS applications.

This momentum aligns with industry research, which continues to flag finance as among the earliest sectors to capture value from quantum, alongside chemicals, life sciences and mobility. The thrust of that work is not “magic computers,” but targeted optimization and sampling routines integrated into classical computing models.

For business, legal and procurement teams, that shift changes the posture from permissive, “use at your own risk” pilots to negotiated, risk-allocated contracts suitable for production-adjacent analytics.

The remainder of this article provides a brief primer on how QaaS works, how QaaS differs from SaaS/IaaS, and the contracting issues entities should consider when embarking upon a QaaS journey. (For background on the technology and its implications for encryption, see our companion article here.)

What QaaS Is (and Isn’t)
At its simplest, Quantum-as-a-Service lets companies run experiments on a quantum computer without owning one. Through a cloud platform, a user can send a computation request (similar to an API call) to a remote quantum processor hosted in a secure data center. The platform runs the calculation and returns the results through the cloud. In practice, this means a business can test quantum algorithms or optimization problems on remote, third-party hardware using a familiar cloud-based interface.

What distinguishes QaaS from other cloud services is the underlying physical hardware. Instead of spinning up virtual machines or containers, the service connects you to a specific quantum device, and different devices may differ in speed, stability and error rates. Those differences affect how reliable or repeatable results are, which has important implications for contracting and risk allocation.

Hyperscale platforms may broker multiple hardware options—for our purposes, we’ll refer to three of the major categories of quantum computing technologies: superconducting, trapped-ion and neutral-atom processors. Each technology resides at a different stage of maturity and offers different advantages among such vectors as speed and accuracy.

(For more information regarding the nuances among these three major quantum computing technologies, and how seemingly magic processes turn the measurement of single atoms or electrical currents into mathematical models that can be interpreted by classical computers to simulate real-world problems, click the following: superconducting, trapped-ion, neutral atom.)

Finally, two operational realities significantly differentiate QaaS from conventional cloud.

  • Devices drift. They are calibrated frequently, and their properties change over time. Much of the hardware and technology associated with quantum computers are dedicated to try and “control” the system in which measurements are made (e.g., keep things extremely cold), attempting to bring stability to nature’s natural disorder.
  • Outputs are probabilistic. Stabilizing results typically means sufficient sampling and, in some cases, enabling error-mitigation features

These are not edge technicalities. As noted below, they inform what one can promise (or disclaim) in a contract.

Why QaaS Isn’t Just Another “aaS”

Hardware maturity and vendor concentration. Unlike typical SaaS, the device matters—a lot. Qubit count, connectivity, native gates (the basic movements a quantum computer can perform naturally), and calibration history influence performance and reproducibility. Brokered access routes customers to a short list of vendors, and available devices differ by geography and program. Contracts should therefore treat target hardware (and acceptable substitutes) as material to the service description.

Auditability and reproducibility. Because outputs are statistical and sensitive to noise and drift, reproducibility across time and devices isn’t guaranteed unless you control for shot counts, random seeds, error-mitigation settings, and calibration snapshots (i.e., settings that tell the quantum computer how many times to run your experiment, how to keep the randomness consistent, how to correct for noise, and how to account for the machine’s condition at the time). Your agreement should require job-level meta data to support model-risk review and audit.

Export‑control and encryption posture. The regulatory backdrop has tightened. In 2024, the U.S. Department of Commerce’s Bureau of Industry and Security (BIS) adopted new quantum‑related controls via an interim final rule. The U.S. Department of Treasury finalized outbound‑investment regulations capturing certain quantum information technologies, effective January 2, 2025. In parallel, NIST recently approved the first post‑quantum cryptography standards (FIPS 203/204/205), and the Office of Management and Budget’s M‑23‑02 memo continues to drive federal (and increasingly private‑sector) migration planning. These developments flow directly into data‑location, provider selection and crypto‑agility requirements in QaaS agreements.

Immature, non‑standard terms. Market contract terms for QaaS are not yet standardized (an understatement). Don’t assume SaaS-style warranties. Many offerings remain “preview” or “experimental,” and published performance metrics (Service Levels/SLAs) often cover control-plane/simulator availability, not hardware performance. In light of this, it is important to consider bespoke service definitions and risk allocation terms rather than boilerplate cloud terms.

What to Get Right in the Contract

Describe the service with precision. A QaaS deal should read less like a generic SaaS Agreement and more like a platform and device schedule. It is important to:

    • Identify the specific hardware and QaaS platforms (e.g., “Quantinuum H‑series trapped‑ion QPU via Azure Quantum”) and, as applicable, permissible substitutes;
    • State whether simulators (software that imitates a quantum computer but isn’t one) may be used and for which phases (e.g., tuning, back‑testing). In those phases, you’re testing the model, not the machine. Understand when you need an actual quantum device to guide decisions and require it; and
    • Be aware that these machines are retuned often, so numbers can change. Tie any promised characteristics to the device type and its normal calibration range, not a single day’s figure.

Ask for operational transparency, not miracles. Providers will be loath to warrant the accuracy of computational outcomes, and given today’s devices, they probably shouldn’t. What you can reasonably ask for is a paper trail for every run. A provider should document which machine was used, the software version, when the machine was last calibrated, when your job ran, how many “shots” were used, the random seed (so results can be reproduced), and any error-mitigation settings for each executed job. You will need this information to verify results and respond to questions from regulators. If a quantum cloud provider publishes device‑property and mitigation controls, that should be reflected in your reporting and audit rights.

Handle data like sensitive IP. Your code, the rewritten versions that the platform makes to run on its hardware, and the run logs can give away crucial information as to how your model works. What steps you took, the dials that were turned, and the size of the problem could be enough information for someone to copy your strategy. Treat circuits and logs as trade secrets and limit human access at both the platform and hardware level. Restrict the provider from using your data to train or improve their services unless you approve such use, and set your own retention and export rules for records. Be aware of provider defaults; the agreement should be harmonized with your information governance requirements, not a vendor’s default position.

Geography is not a footnote. Devices may be globally distributed, and not every device is available in every region. Accordingly, data‑location and execution‑location require explicit treatment. Customers should expressly address permitted jurisdictions, approval rights for routing jobs to devices in non‑approved locations, and export/sanctions screening controls.

Right‑size the risk allocation. If the service is labelled “preview” or “experimental,” a blanket “use at your own risk” clause may be acceptable only for exploratory R&D. Once the output influences production‑adjacent analytics (e.g., pre‑trade scoring, stress testing), bespoke risk allocation and performance metric terms become important. Remember: even where an SLA exists, it may measure API uptime, not the actual performance or output of the quantum computer (the part you actually care about the most).

Flow down crypto‑agility. QaaS often sits in a hybrid workflow with classical computing, storage and messaging. Your agreement should require suppliers to publish and maintain a clear transition plan for switching their control planes, APIs and storage to quantum-safe encryption. That plan should follow recognized standards and timelines (e.g., NIST’s post-quantum standards and the Office of Management and Budget’s guidance) and give you advance notice so the transition will not disrupt operations.

Summary
QaaS is moving from experiments to production-adjacent analytics, and the difference between promise and payoff now lives in the contract. Outcomes are materially machine-dependent and drift with calibration, so your agreement must treat the device, not just the API, as the service. It is important to translate technical realities into business controls: Ensure clarity about what you’re buying, accountability for how it runs, safeguards for the data and methods it touches, and a clear path forward as standards and security evolve.

RELATED ARTICLES

Why Your Organization Should Be Thinking About Quantum Computing and the Future of Encryption

BIS Imposes New Export Controls on Quantum, Semiconductor and Additive Manufacturing Technologies