Why can't we run AI on a quantum computer? An experiment, not a claim of quantum advantage
What actually happened when a trained variational circuit ran on real IBM hardware: the accuracy table, the noise that damaged confidence but not verdicts, and the prediction that turned out wrong.
The question was simple enough to be embarrassing: can you actually run the machine-learning part of a real system on a quantum computer? Not a toy, not a diagram in a paper — a classifier doing a job, on hardware, with a number at the end.
The answer turned out to be yes, you can, and it does not help. That is the whole result, and the interesting part is everything that had to be built to be confident it is the result rather than an artefact.
The setup
The task is network intrusion detection on NSL-KDD, a standard research benchmark for classifying network events as attacks or normal traffic. A classical autoencoder compresses each event’s features down to four numbers, and a four-qubit variational circuit makes the final call on those four numbers.
Four qubits is not a limitation to apologise for. It is the point. A circuit that small can be simulated exactly, run on real hardware without heroics, and compared against a classical equivalent without the comparison collapsing into a difference of scale.
The comparison is where most quantum machine-learning demonstrations quietly go wrong. Quantum simulation is slow, so the quantum model gets trained on less data — and is then compared against a classical model trained on everything, which makes any result meaningless in whichever direction it lands.
So the experiment includes a fairness twin: a classical head trained on the identical four compressed features, on the identical reduced ten-thousand-row diet, with the same training budget. Same funnel, same food, same time. Only the final decision-maker differs. That twin is the most important thing in the project, and it is not a quantum component at all.
The numbers
On the official KDDTest+ split, never shuffled:
- Logistic regression, all 122 features, full training set: 75.5%
- Four-feature bottleneck with a classical head, full training set: 73.8%
- Fairness twin — classical head, reduced 10,000-row diet: 73.6%
- Quantum head — four-qubit circuit, reduced 10,000-row diet: 74.2%
The honest comparison is the last two rows: 74.2% against 73.6%. The quantum head matched its twin. It did not beat plain logistic regression, which sits above both while using thirty times as many features and a fraction of the effort.
That is a result worth stating clearly, because the temptation to dress it up is real. A 0.6 point gap over a fairness twin is not a quantum advantage. It is two approaches performing about the same on a problem that did not need either of them.
The part that was actually interesting
The useful findings were not about accuracy at all, and I would have missed them entirely if accuracy had been the only thing measured.
Noise damaged the confidences and left the verdicts alone. Under realistic simulated noise, the circuit’s probability outputs became badly distorted while most of its actual attack-or-normal decisions stayed intact. If you only look at accuracy, noise appears survivable. If you look at the probabilities, they are close to meaningless. Which of those matters depends entirely on whether anything downstream uses the confidence — and in a real security pipeline, something usually does.
Error mitigation repaired the confidences, not the accuracy. That is a narrower and much more useful claim than error mitigation normally gets. It fixed the thing that was broken and left the thing that was not broken alone, which is exactly what it should do and not at all how it tends to be described.
Writing the prediction down first
Before the hardware run, a prediction was written down and committed to the repository: what the real quantum processor was expected to do relative to the simulation.
The trained circuit angles then ran on IBM’s ibm_marrakesh backend — a 156-qubit Heron r2 device — across 300 events and 183 seconds of billed QPU time, with job identifiers retained.
The hardware contradicted the prediction. The real device behaved considerably better than the “realistic” noise model I had been simulating against, which meant months of simulated pessimism had been calibrated against something more pessimistic than reality.
Without the pre-registered prediction, that would have been a pleasant surprise and then a forgotten one — the kind of thing you absorb and quietly stop mentioning. Because the guess was written down first, being wrong became a recorded finding rather than a mood. This is the single practice from the whole experiment I have carried into everything else I build.
What this is not
It is not a demonstration of quantum advantage, and the project says so in its own summary. It is one device family, one benchmark dataset, one circuit design, one problem. None of it generalises, and I would not want a number from it quoted as though it does.
The dataset is a research benchmark, not live traffic. The quantum head trained on a reduced diet — the twin shares that handicap, which makes the comparison fair without making the diet less of a limitation on the whole exercise.
What I would defend is the method rather than the result. Build the fair comparison before you need it. Measure the thing you did not expect to care about. Write down what you think will happen, then keep the note when you are wrong. None of that is specific to quantum computing, which is probably why it was the part worth learning.
The experiment page lists the sources, including the public repository where the accuracy table, the circuit and the pre-registered prediction all live.