Britain put £5 million behind operational AI. Fund the failure plan too

THE SIGNAL IN ONE SENTENCE

Britain is putting public money behind AI that does things, not merely AI that suggests things. On October 21, Innovate UK opened the first phase of its BridgeAI Deployment Catalyst competition for operational systems. UK-registered AI small and medium-sized enterprises can apply for a share of a £5 million fund to prepare existing AI or machine-learning systems for real operational settings. The phrase operational systems matters. This strand is for AI whose primary purpose is to perform, control or coordinate activity inside workflows, software, equipment or infrastructure. It sits beside separate BridgeAI strands for decision-critical systems and assurance and compliance. In plain English, this is the lane where a model may eventually influence a factory line, energy operation, logistics network, clinical workflow, financial process or creative production system. A clever answer is not enough. Reliable integration and performance have to matter to the deployer. The verified funding details are narrower than a £5 million headline can make them sound. Phase 1 is a feasibility stage. Individual projects can request between £100,000 and £200,000, last three to five months, start by April 1, 2027 and end by August 31, 2027. The lead must be a UK-registered AI SME with an existing system at technology readiness level 5 or 6 and a functioning minimum viable product. Each consortium must include a UK-registered deployer, either a medium or large business or a UK-based public-sector organisation, plus at most one additional partner. The deployer must supply a meaningful operational setting and access to the people, data, workflows, systems or infrastructure required to assess the proposed deployment. The competition is not paying for an idea scribbled on a whiteboard. It excludes early-stage research, generic productivity tools, routine back-office automation and AI that sits at the edge of the deployer's core operation waving politely. Phase 1 asks teams to define an evidence-backed use case, assess supplier and deployer readiness, identify technical and governance barriers, plan later assurance work and demonstrate the system with representative data and systems in a representative operational environment. That is the verified programme. The Plain Signal argument begins where the grant language gets interesting. If the AI will perform, control or coordinate real activity, the failure plan is part of the product. It should be funded, designed, rehearsed and assessed with the same seriousness as the model. Operational AI does not fail only by producing a wrong prediction. It can miss a signal. It can act too late. It can act at the wrong scale. It can receive stale data. It can lose access to a dependent service. It can behave correctly while a sensor, database or workflow around it has changed. It can hand a human a warning that arrives after the useful decision window has closed. It can also fail quietly. Quiet failure is the dangerous cousin of the dramatic robot mishap. The dashboard stays green, the process keeps moving and the error accumulates in inventory, scheduling, maintenance, energy use or service quality. Nobody pulls an alarm because the system never declared that it had left the conditions it was tested for. The first deliverable should therefore be an operational envelope. Write down the conditions under which the AI is allowed to act. Name the input ranges, equipment states, data freshness limits, user roles, environmental conditions and confidence thresholds that define normal operation. Then define what the system does when any condition falls outside that envelope. Does it stop? Does it switch to a simpler rule? Does it return control to an operator? Does it freeze the last safe setting? Does it continue with reduced authority while raising an alert? There is no universal answer. A warehouse-routing tool and a clinical scheduling system should not share one generic emergency button. The answer has to fit the operation, the people affected and the time available to recover. The second deliverable should be an authority map. Operational systems often look like one product from the outside and behave like a chain of permissions inside. A model recommends an action. Middleware translates it. Another service schedules it. A machine, worker or application carries it out. The map should show where the AI can observe, recommend, approve, execute and override. It should name who can pause the system, who can restore it and who owns the decision when the model and operator disagree. Human oversight is useless if the human lacks time, information or authority. A supervisor who can technically cancel an action after a thirty-second approval screen is not meaningfully in control if the equipment moves in five seconds. An operator who receives a confidence score without the relevant sensor state is being handed responsibility without evidence. The third deliverable should be a rollback path. Software teams know how to restore a previous release. Operational AI can be messier because the system changes the world while it runs. A production schedule is rearranged. A battery is charged. A queue is prioritised. A shipment leaves the building. Some actions cannot be undone. The rollback plan must separate reversible software changes from irreversible operational consequences. Teams should test how long it takes to disable a model, restore a known configuration, reconcile actions already taken and return the operation to a stable state. They should measure recovery time with ordinary staff, not only the engineers who built the system. The fourth deliverable should be an incident grammar. Before a live deployment, partners should agree on what counts as a reportable event. A safety stop is obvious. A slow drift in forecast error may be just as important. So may an operator repeatedly overriding the system, a data source arriving late, a model behaving differently across sites or a worker inventing a workaround because the interface blocks the real job. The grammar should classify near misses as well as visible failures. Near misses are cheap evidence. Waiting for damage is an expensive way to learn. Every incident record should connect the input state, model and software versions, action proposed, action executed, human intervention, operational outcome and recovery steps. That creates a useful trail for debugging, assurance and future replication. The fifth deliverable should be a maintenance owner. AI projects enjoy a glamorous beginning. A pilot arrives with specialists, workshops and executive attention. Then the calendar moves on. Operational systems still need someone to watch data quality, dependencies, model performance, security patches, user behaviour and changes in the operating environment. The deployer needs the skills and budget to maintain the system after the grant-funded team leaves. That means naming an owner, a service level, an update policy, an escalation path and an end-of-life plan. It also means deciding who pays when the model needs retraining or the surrounding software changes. The sixth deliverable should come from workers. The competition requires access to relevant users and workflows. That access should not mean workers are observed for a week and then thanked in a slide deck. People who operate the process know which alarms are ignored, which exceptions happen every Friday, which data field is fiction and which manual shortcut keeps the service alive. They can identify failure modes that are invisible in a clean demonstration. Include operators in scenario design. Record where the system adds workload, shifts accountability or creates incentives to obey a poor recommendation. Test whether a person can challenge the system without being treated as the error. The seventh deliverable should be a public learning receipt. Innovate UK says the programme is intended to generate evidence and learning for wider adoption. Its delivery partners may turn agreed non-confidential lessons into case studies, guidance, tools and templates. That can be more valuable than another showcase saying an AI pilot was successful. A useful receipt would state what operating context was tested, what failed, what controls caught the failure, how people recovered, which metrics improved and which claims remain unproven. Sensitive details can stay private. The structure of the learning should travel. The programme has a three-phase ambition, but later money is not a promise. Innovate UK says Phase 1 projects may be invited to Phase 2 after review. Phase 2 has indicative funding of up to £1 million per consortium for deployment preparation. Phase 3 has indicative funding of up to £2 million for live deployment and replication. Those stages are subject to approvals, project performance, co-investment requirements and sufficient high-quality applications. No project has been selected by the October 21 opening. No system has been shown to work safely in production. The competition is an opportunity to build evidence, not evidence that deployment has already succeeded. That limitation is the reason to make failure planning visible now. Funding agencies can ask for a model card and receive a polished document. They can ask for a risk register and receive a spreadsheet with tasteful colours. The harder question is whether the consortium has rehearsed the moment when the system crosses its boundary during an ordinary shift. Make them demonstrate the handoff. Interrupt a data feed. Delay a sensor. Change a user role. Remove a dependent service. Feed the system an unfamiliar condition. Ask a trained operator to recognise the problem, take control, preserve evidence and recover the operation. Time it. Record it. Repeat it with someone who did not build the demo. That is not pessimism. It is deployment readiness. Britain is right to distinguish operational AI from generic office automation. Systems that coordinate real work deserve a funding path built around real environments, real deployers and real barriers. They also deserve a boring, legible answer to the most useful question in technology. What happens when this thing has a bad day?