AIs are only human – so what can we do?

Working with fallible machines – a short map of the remedies

Part 1 showed the wide range of error sources that large language models (LLM) are prone to, and that these “errors” often echo the ways human experts go wrong. Building on that, and before turning to ways to address these limitations, it’s worth asking whether an LLM is the right tool for the job at hand. An LLM is only one form of artificial intelligence among several and by design, an inferential one: it generates language by predicting likely text, which makes it well suited to producing and working with words and less suited to tasks that demand guaranteed, repeatable or auditable results.

The right tool depends on the character of the problem. Several axes help locate it. Where the task sits in the DIKW (data, information, knowledge, wisdom) hierarchy matters: an LLM is at home marshalling data and information, but far less so where tested knowledge or judged wisdom is required. Other axes track a similar gradient. Considering the levels of war: the tactical often demands speed and tolerates messy data, where the strategic demands audited assurance and accountability. In terms of the function: administration, logistics and operations differ in how much a fluent but fallible answer can be tolerated. And the “chain” at issue: the latitude acceptable in the supply chain narrows through the command chain and is even less in the kill chain, where a probabilistic generator’s output cannot be allowed to bear decisive weight in a targeting decision, whatever oversight surrounds it. Where these point away from an LLM, other approaches – deterministic models, simulations, expert systems or hybrid architectures – may serve better; how to choose among them is the subject of Part 3 (the next in this series).

Where an LLM is the appropriate tool, the remedy for its limitations comes in two registers. The first is technical improvement of the model itself. Many assume newer and larger models will simply resolve these problems; as the following tier-by-tier map shows, technical improvement cannot remove all of them. Where a fix is not possible or not complete, the strategies we have long used with fallible humans – cross-examining, seeking a second opinion, declining to lead the witness, staying open to correction – are what remain. For each tier, the analysis asks whether an improved model would remove the error source, and, where it would not, what workaround can be adopted instead.

A. Intrinsic limits – the data a model is built on

Technical fix? – Often – broader, fresher data and retrieval-augmented generation (RAG) close knowledge gaps and staleness directly. But provenance and representativeness turn on which data is collected, not how much, so they do not simply scale away.

Workaround – Know the model’s scope and prefer current, varied sources; supply your own sources where it matters.

VIEW ALL

B. Structural limits – built into the machine

Technical fix? – Partly – stronger reasoning and longer context help, but the probabilistic core remains: a model that generates by sampling can always generate fluent falsehood and cannot itself tell when it has. Managed, not cured.

Workaround – Ask for reasoning and sources, not a bare conclusion; have the model separate what it can support from what it is inferring from what it is guessing, check its answer against evidence and verify externally.

C. Training-process effects – well-intentioned, but introduced

Technical fix? – Addressed through how the model is rewarded and aligned in training, not by scale – a larger model trained to please is, if anything, a more effective flatterer, so capability alone can worsen it. Market incentives reinforce the pull: users reward agreeable models.

Workaround – Seek more than one opinion; put the same question to several different models and weigh divergence.

D. Input and interaction effects – user side

Technical fix? – No – the error originates in how the question is put, not in a model deficit, so there is nothing in the model for improvement to remove. This tier is, and remains, the user’s responsibility.

Workaround – Ask well. Two techniques are easily confused. The first is order: a question can carry its own answer, so frame neutrally and reveal your own view last – the courtroom’s rule against leading the witness. The second is the willingness to be corrected: where a model pushes back on a claim, welcome it rather than prompting it away – correction takes two, and only the user can accept it.

E. Deployment and system-level effects – the scaffolding

Technical fix? – Largely – this is the most engineerable tier: better retrieval, more reliable tool chaining and conservative decoding settings address most of it. Chiefly, a builder’s tier, not a user’s.

Workaround – Spot check delegated work at the hand-offs, where a small early error becomes a large one later; keep a human in the loop for high-stakes automated use.

F. Deliberate constraints – active, by design

Technical fix? – No – these are deliberate choices, the values, refusals and guardrails shaped into a model by its makers or by a state, not deficits, so there is nothing for a better model to fix. Improvement is beside the point.

Workaround – Recognise the leaning and read it knowingly, as you would the editorial line of a newspaper. You can spot a shaped or on-message answer but not unshape it – there is no neutral model, only models whose leanings are worth knowing; prefer makers who are candid about them, and where the leaning matters, choose a differently-shaped model.

G. Adversarial manipulation – active, malicious

Technical fix? – Partly, but upstream – the real defences (provenance controls, hardening, still-immature watermarking) lie with developers, not in the user’s model becoming more capable, which may even widen the attack surface.

Workaround – Recognise the possibility of disinformation and treat any single source as corruptible, cross-checking against independent sources and models trained differently; prefer systems whose makers take these defences seriously.

Conclusion

Better models will not remove the need. Many assume that as models improve, these problems will fade – where “better” is usually taken to mean a larger model trained on more, and more recent, data. But “better” is not one thing: it may equally mean stronger reasoning, closer alignment or better retrieval, and these help different errors. For some error sources, improvement of some kind will help. But as the tiers show, many errors are not shortfalls of capability at all: some are structural, inherent in generating language by probability; some are incentives baked in by training; some are deliberate choices by the makers; and a few grow worse with capability, not better. So the workarounds endure rather than being a stopgap to discard at the next release – and, paradoxically, the more capable a model becomes, the greater the temptation to stop applying them, so rising capability can quietly increase risk even as it reduces some errors.

Understand what an LLM is. While it is debated whether LLMs in any real sense ‘understand” what they are asked and produce, the mechanism is not in dispute: a model generates by selecting among the most likely next tokens, drawing on patterns inferred from the text it was trained on. However authoritative the result sounds, that fluency is a property of the generation, not evidence for the answer.

Recognise fallibility. From that follows a single shift of posture: treat the machine as fallible and let the burden of verification sit with the user – scaled to the stakes, verifying most where the cost of error is high, the domain novel or the facts fast-moving and lightly where little turns on it. Let the machine carry the simple, high-volume, low-risk work and concentrate human scrutiny where the stakes are highest. One boundary sits apart from the rest and applies before any of them: keep classified or personal material out of any system whose handling of it you do not control. This is a matter of security, not reliability. And in proportion to the stakes, two further obligations arise: marking which outputs were model generated and on what basis and keeping a clear line of human accountability for decisions the model informed.

Verify and consult plurally. The workarounds reduce to a few recurring disciplines: ground the model in current evidence, verify its claims and reasoning, consult a plurality of sources and models trained differently, clarify the question so it is not answered wrongly, and hold to informed scepticism throughout – provisional trust, calibrated by evidence, never by fluency.

Demand disclosure. Every technique assumes the user knows something about the model – its strengths, weak domains, training and leanings – yet this is what users are almost never given. Honest, accessible information about what a model is and is not good at, a “nutrition label” or “safety rating” for models would do more to prevent error than any single technique. The raw material exists in the “model cards” developers publish, but written for engineers, not for users. That gap is the real frontier: making capabilities and limits intelligible to those who rely on them.

Some of the fixes are themselves the subject of active research – better calibration training, process supervision that rewards sound reasoning over merely correct answers, and hybrid arrangements that keep a human in the loop – and are best treated as promising rather than settled. But the through-line is older than any of them: the technologies are new, the disciplines are old, and working well with a fallible machine asks mainly that we extend to it the hard-won wisdom we already apply to one another and stay candid about the few places where even that runs out.

At a glance

Table 1 – From error to remedy. For each tier: the human equivalent, whether an improved model can be expected to remove the error and the workaround that remains where it cannot.

A checklist for working with LLMs follows.

A fuller version of this paper is available at https://johnharvey4.substack.com/p/ais-are-only-human-summary