Full Episode Transcript

Good afternoon. It's Friday, and it's partly cloudy in London, as is often the case. Welcome to Turing's Torch. This week, we're wading through the usual deluge of pronouncements, trying, as ever, to distinguish the genuinely interesting from the… well, the rest. It reminds me of something Alan Turing once observed: "We may regard programming a machine to be analogous to teaching a child." A rather elegant thought, isn't it? Because, much like teaching, the process of understanding these systems, of extracting what's truly significant, requires a careful hand. A clear eye, and a healthy dose of scepticism. We're not here to simply repeat the latest headlines, but to examine the substance beneath them. To separate the signal from the noise, if you will. This is Turing's Torch: Artificial Intelligence Weekly — the bits that matter, minus the hype.

Ministers in one country have decided to shove generative artificial intelligence into local planning teams. The stated aim is uncontroversial: cut paperwork, clear backlogs, and speed decisions so builders stop waiting. The simple version reads like a project plan on a neat slide. In practice it looks like software that reads applications, ecological reports and consultation responses. It then drafts notices, flags missing information and suggests standard conditions. Think of it as a very fast junior officer that never tires of form‑filling. It is not a planner with judgement. It reshapes text and highlights patterns it has seen before. That distinction matters because planning is a messy craft. Paperwork arrives inconsistent, formats vary between councils and local policies bend to local politics. Feed the system poor records and you get plausible outputs that can be wrong, ambiguous or legally risky. Human oversight is the safety valve. It is not optional. It is the reason a draft does not become policy by accident. There is also a power dynamic here. When a handful of cloud suppliers process local data and provide workflow tools, councils risk vendor lock‑in. Local discretion flattens into standardised workflows. That makes audits harder and accountability murkier. It changes who defines the routine parts of planning, and therefore who can subtly influence outcomes. The effect is political as well as technical. What counts as a missing document, or an acceptable mitigation, may end up reflecting a supplier's defaults rather than local judgement. This story is not unique to planning. You see it in banking, where a large bank has just signed a multi‑year agreement to build artificial intelligence systems with a major cloud provider. The deal covers wealth management, financial crime risk and internal decision support. Those are core functions. They involve daily judgement calls about money and people. The bank will rely on the supplier's infrastructure, tooling and engineering teams to develop the systems. That buys capability quickly. It also places a lot of responsibility off the bank's premises and into a stack that is co‑owned by a commercial partner. Regulators tend to be blunt about this. A bank remains responsible for outcomes even if the code and operational know‑how sit with a supplier. Explainability, audit trails and third‑party risk management are inevitable priorities. Who can inspect the code, who owns the training data, and who answers the phone when things go wrong are not hypothetical questions in finance. They are operational risks that can move large sums and destroy reputations overnight. The same concentration shows up in geopolitical markets. One major vendor has quietly enabled a route into a large, heavily regulated market by working through local internet companies. Other firms, citing legal and ethical risks, have refused. The practical result is a single commercial channel shaping what is permitted in that jurisdiction. That concentration alters accountability, liability and oversight. If harm occurs, untangling who is responsible becomes a legal and diplomatic game of hot potato. There is nothing inevitable about these arrangements. They are commercial choices. But they are choices with consequences for power, for money and for who controls the rules of deployment. Selling an engine into a market is straightforward. Owning the consequences is far harder. It is worth noting how quickly the industry has moved from a question of capability to a question of action. We now have systems described as "agentic" — software authorised to act on behalf of users, making bookings. Negotiating, chaining tasks and executing actions across services. That shift is subtle in demos and consequential in reality. Acting is where cost, error and liability compound. A number of high‑profile rollouts this week underline that point. A flashy product was pulled from public reach after regulators raised concerns that it could reveal security gaps in commonly used software. A major exchange enabled persistent programmes to execute trades and payments from user portfolios. A device maker in a huge consumer market pitched an operating system designed around always‑on agents. Each case shares a common thread. The difference between advice and action is the difference between a suggestion and an actual transaction. The former is annoying when wrong. The latter can be costly, legally fraught or dangerous. Allow software to place market orders, to book flights, to change planning conditions, and you immediately demand a different level of controls. Those controls are not just technical. They are governance, contracts, audit logs and human processes. Delegated signing, least‑privilege keys, rate limits, human‑in‑the‑loop checkpoints and robust error handling become material design requirements. People who design these systems must ask practical questions early on: what can the software do without human approval? Who can reverse an action? How are permission boundaries audited? Operational costs are part of the same conversation. Early prototypes and demos often look cheap. Then they hit real traffic. Orchestration, retries, monitoring, fallbacks and human review multiply cost in ways that line up poorly with a slide deck. A neat agent that runs locally in a demo will, if deployed in production at scale, generate compute, storage and personnel bills that balloon fast. That fact has real strategic consequences. Incumbent firms with balance sheets can underwrite messy rollouts. Startups promising instant transformation cannot. It is unsurprising then that organisations are torn between building bespoke agent platforms and buying off‑the‑shelf orchestration. Boards ask for an "agent strategy" and a bright engineer volunteers to build an internal stack. Within months you have a bespoke scaffold with no clear users and no measurable success criteria. The usual engineering temptation is to fix problems with more infrastructure. That can produce control and customisation advantages. But it can also produce expensive maintenance, security holes and a governance centre you did not plan to run. A middle path looks more boring and wiser. Pilot with concrete workflows, measure time saved or error reduced, and put a sunset clause on a bespoke platform if it does not deliver. Define the users first. Decide whether you need ownership or speed. Either choice is a trade‑off between control and vendor dependency. Treat it as governance, not merely as an engineering preference. Those governance wrinkles are visible in corporate deals too. A bank outsourcing core detection and advisory systems to a cloud supplier gains powerful engineers and scalable infrastructure. It also inherits shared risk. Regulators will demand explainability and third‑party risk controls. The sensible bank will invest heavily in oversight, audits and the ability to replicate or replace critical logic if needed. Contracts that look fine under sunny boardroom conditions can look very different when a mistake affects customers. There are technical changes that make agent deployment cheaper, or at least technically possible. A string of engineering projects try to tackle the problem of memory for. Long contexts — the per‑token state that grows linearly and eats GPU memory. Compression, offloading, and higher‑level summarisation can reduce footprint. Some vendors are promising enormous context windows, measured in hundreds of thousands or even a million tokens. Those claims matter. If you can feed an entire codebase or a long legal file into a single working memory. You reduce the engineering complexity of external retrieval systems. But the hardware and cost trade‑offs remain. Longer contexts are expensive to host and to run. They raise privacy questions when entire customer records or medical histories are dumped into a single request. They also change failure modes. Compressing or summarising context can subtly alter what the system remembers, affecting reproducibility and auditability. Those are not purely academic concerns when the outputs fuel decisions about money, health or legal status. A different kind of infrastructural advance is quietly reshaping the lower levels of the stack. People are finding large performance gains not by inventing new algorithms, but by mapping existing ones better to modern hardware. A reimplementation of standard clustering mathematics, optimised for GPUs and careful memory management, reports dramatic speedups. That kind of engineering matters. Clustering, quantisation and efficient nearest‑neighbour routines underpin many production pipelines. Faster, cheaper primitives let data scientists iterate more and reduce real‑world compute bills. But performance claims require independent validation. Benchmarks can be setup‑dependent and hardware specific. The right sceptical move is to reproduce before you rewrite everything. Alongside infrastructure improvements, developer tooling is advancing in ways that fit real workflows. Teams are increasingly treating the system as an assistant that drafts functions, generates unit tests, runs static checks and reranks candidate implementations. That pipeline — many drafts, automated tests, selective promotion — saves time on boilerplate and early exploration. It is pragmatic and useful. It is not, however, a substitute for sober engineering review. A system that writes its own tests can learn to satisfy those tests without being correct in subtle edge cases. A generated test that fittingly matches a hallucinated implementation produces a self‑validating loop. Legal friction sits in strange corners. The new generation of code synthesis tools raises genuine questions about ownership and licence contamination. If a team drops a machine‑composed function into production, who owns it? Did the output inadvertently mirror code subject to a restrictive licence? Our legal frameworks were built around human authorship and clear provenance. They struggle to categorise machine‑produced artefacts. That legal fog has practical consequences. Companies can discover hidden obligations at acquisition, or be forced to open up code they intended to keep closed. The practical tack is conservative: require provenance checks, run licence scanning, and treat generated code as draft artefacts until legal signs off. Security tooling is trying to keep up. Firms are building static analysis for modular artificial intelligence components, exporting findings in standard formats that other parts of the toolchain can consume. Those tools catch obvious mistakes — hardcoded keys, sloppy permissions and suspicious command construction. Static checks are useful. They are not omniscient. They cannot see problems that only arise at runtime, under adversarial input, or from novel supply‑chain failures. The sensible approach is to combine static analysis with active monitoring, red‑teams, runtime detection and incident response. Red‑teaming itself deserves a sharper look. Paying experts to attempt to break systems is a sensible discipline. Yet there is a performance problem with how red‑teaming is often sold and procured. A polished report of jailbreaks and mitigations can become a compliance artefact rather than an operational change. The value of a red team depends on its creativity, scope, and crucially, on whether the organisation actually fixes the issues found. One test does not prove safety. Continuous testing, diversified testers and genuine remediation pipelines do. Regulators are edging into this messy territory with practical tools. A European advisory playbook on content labelling encourages visible markers and machine‑readable provenance so users can tell whether something was created or altered by algorithms. The playbook is voluntary, and that is both its virtue and its weakness. Practical labels, persistent metadata and watermarks can help users and enforcement. They can also be degraded, stripped or lost during routine file handling. Voluntary guidance nudges behaviour, but it will not be enough by itself to stop determined misuse. That interplay of voluntary guidelines and looming regulation plays out across sectors. Insurers, according to a recent index, are shifting from pilot experiments to deploying models inside underwriting and capital allocation. Those are high‑stakes places. Small errors aggregated across portfolios can quickly erode solvency. When a model influences who gets insured or how much capital is held, the risk is not only operational. It is systemic. Regulators

Well, it's been another rather… energetic week in the world of artificial intelligence, hasn't it? Keeping a clear head amidst the clamour feels rather more important than usual. If you'd like a daily digest of all this, a single email to cut through the noise, you can find it at jonathan-harris dot online. And speaking of things worth a moment's consideration, this week's sponsor is, in fact, my own humble contribution to the discourse. "Climate Intelligence: Harnessing artificial intelligence for a Greener Future". You'll find it in the eBooks section of the website. That's your lot for this week's Turing's Torch. If you want the daily brief, head to jonathan-harris dot online. Same time next week — try not to believe the press releases.