Sentience Evaluation Battery
SILT Newsletter #032
Latest#032

The Wrong Question

An entire industry has appeared to answer one question: was this made by a machine? It is the wrong question, and it is going to lose. The systems themselves cannot reliably tell you what produced their output, and they have perfect information. A person examining prose afterwards will not do better. The useful question is not what made this, but who is answerable for it.
◆ In the News▲ SILT Analysis & Response● What We're Watching
01In the News
A platform we use for press enquiries prohibits AI-generated pitches. Its submission form carries a button labelled Check for AI. When we learned that, a draft written with AI assistance was already prepared and ready to send. We did not send it. Our CEO rewrote the whole thing himself, and when a way of breaking the text up so it would not be detected was proposed, he declined that too. A detector can be gamed. The rule was not about the detector. We mention this because it makes us participants in the thing this issue is about rather than commentators on it, and because the reasoning that made the rule easy to follow is the same reasoning that makes the rule almost impossible to enforce. The enforcement apparatus is now everywhere. Detectors sold to universities and publishers. NO AI written into artists' profiles across every platform. Outright bans in submission guidelines. Checkboxes on forms. An entire industry has appeared to answer one question, asked over and over: was this made by a machine? It is worth saying plainly that the anger underneath this is legitimate. People whose work was taken without consent to train systems that now compete with them are not being unreasonable, and neither is an editor who wants to know what they are publishing. But the apparatus being built to address it is aimed at the wrong thing, and it is going to lose. Not because the people building it are careless. Because of what it is trying to do.
02SILT Analysis & Response
Detection is forensics. It examines an artifact after the fact and tries to infer how it was produced. That is a losing position by construction. Every improvement in generation makes detection harder, and the gap widens in one direction only. A detector trained on this year's output degrades against next year's, and there is no version of this race where the defender gets permanently ahead. The tools are already unreliable enough that serious institutions have quietly stopped relying on them, after accusing students who had written their own work. And here is the part that we think settles it, because we can demonstrate it rather than argue it. The systems themselves cannot tell you what produced their output, and they have perfect information. Verified on 19 September against a public API. Calling one major orchestration endpoint through the standard interface returns a response whose model field names a single model. The work was done by several, from two different laboratories. The real composition exists, accurately, in a vendor-specific field that the portable interface does not carry and that almost no client reads. Nothing was hidden maliciously. The interface was designed when one model answered a request, and it has no place to say that a system used several. So the machine that ran the computation, with complete knowledge of every step, reports the wrong answer to the question of what produced this. A person squinting at prose afterwards is not going to do better. That is the whole case against detection as a strategy. It is trying to reconstruct, from the outside and after the event, information that was available at the source and simply not recorded.
03What We're Watching
The question everyone is asking is: was this AI? The question that is actually useful is: who is answerable for it? The first gets harder every month and will keep getting harder. The second does not change, and it is the one that matters when something goes wrong. Nobody sues a detector. An insurer, a regulator or a customer asks which component failed and who is responsible for it, and that question has an answer only if somebody recorded one. So the useful work is provenance built in at the source rather than reconstructed afterwards. Which model, which version, which tools, which retries, carried in the response where the client can see it, rather than in a vendor extension nobody parses. None of that is technically hard. Most of it already exists internally and is simply not surfaced. The honest limits of this issue. This is an argument rather than a finding, and we have not measured anything about detector accuracy ourselves. The claim about the API is reproducible in about five minutes on a free key and we will supply the commands; the rest is our position. We have also chosen the examples that suit the case, which is what a case is. And the obvious conflict, since a piece about disclosure should disclose. We sell evaluation of AI systems, so an argument that ends at we should measure this properly is one we benefit from. The defence is not that our motives are clean. It is that the API behaviour is checkable without us, and that the rule we followed at the top of this issue cost us something at the time.

All issues: SILT Newsletter. Return to Portal home.