Category: Business

  • Ghost Infrastructure: The Thousands of Dormant SaaS Subscriptions Quietly Draining UK Business Budgets

    Ghost Infrastructure: The Thousands of Dormant SaaS Subscriptions Quietly Draining UK Business Budgets

    There is a particular kind of financial haemorrhage that nobody notices until someone actually looks. Not fraud, not waste in the dramatic sense, just dozens of software subscriptions quietly renewing every month for tools that nobody uses, nobody cancelled, and in some cases nobody can even remember signing up for. This is SaaS sprawl, and in UK SMEs and scaleups right now, it has reached a scale that most finance teams genuinely do not have visibility over.

    I have spoken to enough ops and finance leads at growth-stage businesses over the past year to recognise a pattern. The tooling accumulates fast. A salesperson signs up for a prospecting tool on a trial that auto-renews. A developer spins up a monitoring platform at £200 a month. A product manager subscribes to a research tool, leaves the company, and nobody inherits the login or cancels the licence. Multiply that across thirty, fifty, a hundred employees, and you have a non-trivial problem. Some estimates put the proportion of SaaS spend that goes entirely unused at around 30 per cent in organisations without active software asset management. In mid-market UK companies, that can represent tens of thousands of pounds annually.

    Finance team reviewing SaaS sprawl UK business software subscriptions on laptops in open-plan office
    Photo by https://kaboompics.com/ on Pexels

    How SaaS sprawl happens in fast-growing UK businesses

    The structural cause is straightforward: SaaS purchasing has been democratised. A decade ago, buying enterprise software meant procurement committees, IT sign-off, and a capital expenditure line that finance could scrutinise. Now a line manager can put a £49-a-month subscription on a corporate card in ninety seconds. IT never finds out. Finance sees a card charge, not a software inventory entry. The procurement process, where it exists at all, is retrospective at best.

    Scaleups are especially exposed because their headcount growth outpaces the maturation of internal processes. A company that goes from twenty to a hundred and fifty employees in eighteen months tends to accumulate tooling faster than it can rationalise it. Everyone is solving an immediate problem; nobody has time to ask whether the same problem is already being solved by something the company already pays for. I have seen teams paying for three different project management platforms simultaneously, with no integration between them and no single owner for any of them.

    The vendor side of this is not passive, either. SaaS pricing models are specifically designed to reduce friction on entry and maximise friction on exit. Annual renewals that require proactive cancellation, seat minimums that lock you into more than you need, automatic tier upgrades when usage briefly spikes. These are not bugs in the system; they are revenue mechanics. UK businesses signed up to US-headquartered platforms are also navigating terms set by vendors whose primary compliance concern is not the ICO or the FCA.

    Why this is a security problem, not just a budget one

    The finance angle is the one that gets attention, but the security exposure is arguably more serious. Every active SaaS subscription is an authentication surface. If a former employee’s credentials are still live on a platform that the business has forgotten it subscribes to, that is an unmonitored entry point. Shadow IT compounds this further. As we have covered in detail before, unsanctioned tools create compliance risks that can blindside UK finance and legal teams, and the same logic applies to any subscriptions that have drifted outside IT oversight.

    There is also a data residency question that UK businesses often miss. Some of those dormant subscriptions are still syncing company data. A CRM integration that nobody actively uses may still be piping contact records to a third-party enrichment tool on a server somewhere outside the UK. GDPR obligations do not pause because you forgot about the subscription. The ICO is not especially sympathetic to “we didn’t realise it was still running” as an explanation for a data incident.

    What the SaaS management tooling landscape looks like in 2026

    The good news is that a specific category of tooling has matured considerably to address exactly this problem. SaaS management platforms, sometimes called SMP or software asset management tools, now give IT and finance teams genuine visibility into what is running, who is using it, and what it costs. Platforms like Torii, Zylo, and Productiv operate in this space globally, and UK-focused equivalents are starting to appear.

    The core mechanic is usually the same: connect the platform to your SSO provider, your email, and your finance systems, and it surfaces every SaaS application employees are authenticating against. From there you get utilisation data, spend per seat, renewal calendars, and duplicate detection. The ROI case is typically very fast to build; most businesses find they can cut SaaS spend by 20-25 per cent within the first quarter of active management. That is a real number, not a sales deck figure, and I have seen it borne out in practice at a couple of companies I know well.

    The challenge for smaller UK SMEs is that many of these platforms are priced for mid-market and above. A company with fifteen employees spending £3,000 a month on SaaS subscriptions probably cannot justify a dedicated management tool at £500 a month. For those businesses, the practical advice is simpler: monthly review of card statements against a shared inventory spreadsheet, a clear policy requiring IT visibility before any subscription exceeds £50 a month, and SSO enforcement wherever possible so that access can be revoked centrally when someone leaves. Unglamorous, but it works.

    The CFO angle: why this keeps slipping through

    Part of the problem is that SaaS spend tends to sit in operational expense budgets, spread across multiple cost centres, rather than appearing as a single line that anyone scrutinises. A £200 monthly subscription is below the threshold that triggers a finance review in most UK SMEs. Multiply it by forty subscriptions and you have £8,000 a month that nobody is actively managing. I have spoken to CFOs at Series A and B companies who genuinely did not know their all-in SaaS spend to within 30 per cent. That is not a competence problem; it is an information architecture problem.

    This connects to a broader issue around how UK growth companies think about software ROI. As I have written about before, measuring the return on technology spend remains genuinely hard for UK firms, and that difficulty creates a permissive environment where subscriptions accumulate without ever being held to account. The tooling that was bought to solve a specific problem in Q3 of last year is still renewing in Q2 of this year, even though the problem was solved, or the project was cancelled, or the team restructured.

    There is also a skills dimension here. The data literacy required to track, categorise, and rationalise software spend is higher than most people assume. Building a clean inventory, attributing spend to teams, modelling the cost of consolidating overlapping tools, these are analytical tasks that require someone to own them. In many UK scaleups, nobody owns them. The gap in data skills at the management layer is real, and software asset management is one of the places it shows up most concretely.

    What a sensible SaaS governance model actually looks like

    Getting this right is not complicated, but it does require someone to care about it. The companies doing it well tend to have a few things in common: a single owner (usually IT, sometimes RevOps or a COO-adjacent role) who holds the canonical list of approved tools; a lightweight procurement process that requires a ticket or form before any new subscription is created; SSO enforcement as the default; and a quarterly audit cycle where utilisation data from the SaaS management platform or, failing that, vendor usage dashboards, is reviewed against active headcount.

    Annual renewal flags are worth setting up calendar alerts for, at minimum ninety days in advance. That gives enough time to audit usage, negotiate on seat count, or actually cancel something before it rolls over. It sounds obvious. Most companies do not do it.

    SaaS sprawl in UK business software subscriptions is not a tech problem in the interesting sense. Nobody is going to write a conference talk about it. But the businesses that get on top of it tend to find that the financial and security benefits compound quickly, and that the discipline required to manage software spend well tends to generalise into better operational hygiene across the board. That is worth something, even if it is not very glamorous.

    Frequently Asked Questions

    What is SaaS sprawl and how does it affect UK businesses?

    SaaS sprawl refers to the uncontrolled accumulation of software subscriptions across a business, often without central IT or finance visibility. For UK SMEs and scaleups, it typically means paying for tools that are underused or completely dormant, with estimates suggesting up to 30 per cent of SaaS spend goes entirely unused in organisations without active management.

    How much money do UK companies waste on unused software subscriptions?

    It varies significantly by company size, but businesses without a SaaS management process commonly find they can cut software spend by 20-25 per cent once they do a proper audit. For a mid-sized UK company spending £15,000 a month on SaaS, that is £3,000-£4,000 a month recovered, often within the first quarter of active management.

    Is SaaS sprawl a security risk as well as a budget problem?

    Yes, and this is the part many businesses underestimate. Forgotten subscriptions often still hold active credentials, which means former employees or unmonitored integrations may have access to company data. There are also GDPR implications if dormant tools are still syncing data to third-party servers, which could create issues with the ICO.

  • The Skills Gap Nobody in UK Tech Is Talking About: Why Data Literacy Is Failing at the Management Layer

    The Skills Gap Nobody in UK Tech Is Talking About: Why Data Literacy Is Failing at the Management Layer

    There is a version of the UK’s AI problem that gets told constantly: not enough engineers, not enough compute, not enough data infrastructure. I’ve read approximately nine hundred variants of this argument in the past two years, and whilst none of it is wrong exactly, I think it misses the actual constraint. The data literacy skills gap in UK businesses is not sitting in the engineering team. It’s sitting in the room where decisions get made.

    Senior managers at British firms are, on the whole, commissioning and approving data-driven work they cannot meaningfully interrogate. That’s the quiet crisis. Not a shortage of people who can build the models, but a shortage of people who can ask the right questions about what those models are actually doing.

    Senior managers reviewing data outputs in a boardroom, illustrating the data literacy skills gap in UK businesses
    Photo by Vlada Karpovich on Pexels

    What data literacy at the management layer actually means

    I want to be precise about this because the phrase “data literacy” gets used to mean everything from “knows what a spreadsheet is” to “can write SQL”. Neither of those is what I’m arguing for at the management level.

    A senior manager with genuine data literacy can do a few specific things. They can read a model evaluation report and spot whether the metric being optimised actually maps to the business outcome they care about. They can ask why a confidence interval is wide, and understand the answer. They can notice when a data sample is suspiciously clean. They can challenge a recommendation by asking what the model would have predicted six months ago and whether that matched reality. These are not technical skills in the engineering sense. They are critical thinking skills applied to a quantitative context, and British business culture has chronically underinvested in them.

    The ONS data on UK businesses adopting digital technologies shows adoption numbers climbing steadily. What those figures don’t capture is what happens after adoption. A firm can deploy a predictive analytics tool, get dashboards built, and still make worse decisions than they did with gut instinct, because nobody in the room knows how to stress-test the output.

    Why this problem lives at the top, not the bottom

    The engineering teams at most mid-to-large UK tech and financial services firms are genuinely capable. I’ve spoken to data scientists at firms across Manchester, Leeds and London who describe the same pattern: they build something solid, present it upwards, and watch it either get approved uncritically or rejected for reasons that have nothing to do with the model’s actual performance.

    Both of those outcomes are bad. Uncritical approval means that when the model fails (and they do fail), nobody saw it coming and nobody can explain why. Arbitrary rejection means good analytical work gets shelved because the person commissioning it didn’t understand it well enough to defend it internally. Either way, the data science team becomes a box-ticking exercise rather than a genuine decision support function.

    This connects to something I’ve written about before in the context of how UK firms are measuring ROI on generative AI spend. The measurement problem and the literacy problem are the same problem. You cannot measure return on a data investment if you cannot evaluate the output of that investment in the first place.

    The organisational dynamics making this worse

    There’s an uncomfortable incentive structure at play here. Admitting you don’t understand the analytical output that your team has produced is socially costly for a senior manager in most British corporate cultures. So instead of saying “explain this to me properly”, the pattern is to nod, approve, and move on. The data team interprets this as validation. The manager moves on without actually internalising what the recommendation was based on.

    On the flip side, data teams sometimes make this worse by presenting outputs in ways that are either incomprehensibly technical or, equally problematically, stripped of all nuance in an attempt to be “accessible”. A single headline number with a green arrow next to it is not a decision-support tool. It’s a false sense of certainty dressed up as insight.

    The firms getting this right, and they do exist, tend to have invested in what I’d call a translation layer. Not dumbed-down dashboards, but structured processes where data leads and operational managers work through assumptions together before a recommendation hits the exec table. It’s slower. It produces better outcomes. Most firms don’t do it because speed is valued over understanding.

    How the data literacy skills gap shows up in practice

    A few patterns I see repeatedly in UK businesses right now. First, the confounding variable blind spot. A demand forecasting model looks brilliant until someone points out that it was trained on a period that included an unusual spike in orders from one customer, and that customer has since left. Nobody at the management layer asked about this because they didn’t know to.

    Second, the proxy metric trap. A team is tasked with improving customer retention. They build a model that maximises a particular engagement score. Engagement goes up, churn stays flat. The issue is that the engagement score was a proxy, not the thing itself, and the model gamed it. A manager with data literacy would have asked during commissioning: what’s the evidence that this metric predicts retention, not just correlates with it in training data?

    Third, and this is increasingly relevant given how fast autonomous systems are being deployed, the agentic AI systems now operating inside UK business processes are making decisions at a rate and granularity that no manager can review individually. The only governance that works in that context is a manager who deeply understands how the system was designed to behave, what its failure modes are, and what anomalous output looks like. Without that, oversight is theatre.

    What fixing this actually looks like

    The solution is not sending senior managers on a Python course. That’s the wrong level, and the wrong framing. What actually works, based on the firms I’ve seen make progress, is a few things.

    Structured model review processes where managers are required to ask specific questions before sign-off: what data was this trained on, what’s the performance on held-out data, what happens at the edge cases, what would make us distrust this output in production. Making these questions a governance norm rather than optional due diligence changes the culture without requiring anyone to become a statistician.

    Pairing arrangements between data leads and operational managers, not for one-off projects but as an ongoing relationship. The goal is not for the manager to learn data science; it’s for them to develop calibrated intuition about when to trust a model and when to push back.

    And honestly, some element of this needs to come from business schools and leadership programmes. The generation of managers currently running UK firms did their MBAs before data fluency was treated as a core competency. The compliance risks already surfacing from unsanctioned AI tool adoption are partly a symptom of this. Managers who can’t evaluate tools can’t govern their use either.

    The gap is real and it’s widening

    Engineering talent in the UK is good. The infrastructure is improving. The models being built in British firms are, in many cases, genuinely sophisticated. But sophistication at the production layer, combined with opacity at the decision layer, is not a strategy. It’s a liability.

    The data literacy skills gap in UK businesses is not about teaching everyone to code. It’s about building a management culture where interrogating a data-driven recommendation is expected, not exceptional. Until that happens, a lot of very expensive analytical work is going to keep producing very mediocre decisions.

  • How UK Firms Are Actually Measuring ROI on Generative AI Spend, and Why Most Are Getting It Wrong

    How UK Firms Are Actually Measuring ROI on Generative AI Spend, and Why Most Are Getting It Wrong

    There is a quiet crisis unfolding inside UK boardrooms right now, and most of the people living through it do not realise it yet. Millions of pounds are being spent on generative AI tooling, infrastructure, and consulting, and the spreadsheets being used to justify those budgets are, frankly, works of fiction. I’ve spent the last few months talking to technology directors, operations leads, and CFOs at British firms of various sizes, and the picture that emerges around generative AI ROI measurement for UK businesses is considerably messier than the press releases suggest.

    UK business team reviewing generative AI ROI measurement data on a large office monitor
    Photo by https://kaboompics.com/ on Pexels

    Why the numbers rarely hold up

    The most common approach I see goes something like this: a team deploys a large language model-based tool, surveys a handful of users who say they save two hours a week, multiplies that by an hourly rate, and presents the result to the board as annualised value. It sounds plausible. It rarely is.

    The problems compound fast. First, the time saving is almost always self-reported and unverified. Second, the model assumes that freed time converts directly into productive output, which it often does not. Third, nobody subtracts the time spent prompting, reviewing, and correcting the model’s output. The ONS’s own productivity data has consistently shown that technology adoption does not automatically translate into measurable output gains at the firm level, a phenomenon sometimes called the productivity paradox. That paradox is alive and well in the GenAI era.

    The three accounting pitfalls killing credible measurement

    My read of the situation is that most organisations are stumbling into three specific traps before they even start thinking rigorously about generative AI ROI measurement.

    Pitfall one: conflating activity with value. Tokens processed, API calls made, and queries answered are all activity metrics. They measure consumption, not contribution. A legal team that runs ten thousand document summaries through a GenAI tool has not necessarily saved any meaningful time if those summaries still require a paralegal to review every line. Volume figures look good in a monthly report. They mean very little without a linked outcome.

    Pitfall two: ignoring total cost of ownership. The cost of a SaaS AI subscription is the most visible line item, but it is rarely the largest one. Add up the engineering time spent on integration, the data cleaning required to make the model useful, the ongoing prompt engineering, and the compliance reviews now mandated by the ICO’s AI guidance, and the real cost is often two or three times the licence fee. Organisations that measure ROI against just the subscription are systematically understating their investment.

    Pitfall three: selecting metrics after the fact. This is the most insidious one. A team runs a GenAI pilot, and it does not move the needle on the KPIs they originally cared about. So they go hunting for something that did move, and present that as the win. I have seen this described internally as ‘finding the signal’, but it is closer to p-hacking. The metric was not pre-committed, which means the result is not evidence of anything.

    Close-up of spreadsheet analysis used in generative AI ROI measurement
    Photo by Atlantic Ambience on Pexels

    What rigorous evaluation actually looks like

    The firms getting this right share a few characteristics. They define success criteria before any deployment begins, not after. They use control groups where possible, comparing output quality and speed between teams using a tool and those that are not. They measure end-to-end process time rather than individual task time. And they track downstream outcomes, not just the immediate output of the AI system.

    A decent example: a mid-sized UK professional services firm I spoke to recently rolled out a GenAI drafting assistant for its client communications team. Instead of asking users how much time they thought they saved, they measured turnaround time on a defined document type before and after deployment across matched cohorts. They also tracked client satisfaction scores and error rates. The result was more nuanced than a simple headline figure, but it held up to scrutiny. Their finance team trusted it. That trust is worth more than a flashy number.

    The same logic applies to smaller-scale technology implementations. Mail Tester, a UK-based free email testing service specialising in deliverability diagnostics and inbox placement checks, illustrates the principle well. The tool does one thing and measures it directly: you send a test message, and you get a score with specific technical feedback on your configuration, from SPF and DKIM alignment to spam filter triggers. The computers running those checks give you a clean, interpretable output rather than an amorphous productivity claim. Tech support teams and internet-facing businesses use it because the metric is unambiguous. The result at mail-tester.co.uk is not “we estimate you saved time”, it is “your score is 8.5 out of 10, here is what to fix.” More AI evaluation frameworks should aspire to that same specificity.

    Productivity metric manipulation: the uncomfortable conversation

    There is a related problem that is even harder to discuss openly. Generative AI ROI measurement inside UK businesses is sometimes being gamed, not necessarily dishonestly, but through motivated reasoning. Teams that championed a GenAI initiative have a personal stake in proving it worked. Line managers who approved the spend need a positive return to show their own seniors. The result is measurement that confirms rather than tests.

    This connects directly to the broader issue of shadow IT and unverified tooling, which I have covered before in the context of unsanctioned AI tools creating compliance problems for UK finance and legal teams. When teams are operating tools that the central IT function does not know about, getting any kind of honest measurement is essentially impossible. You cannot measure ROI on a tool you cannot see.

    The organisations that are doing this well tend to have centralised visibility over their AI stack, even if deployment is decentralised. They also separate the team measuring the outcome from the team that implemented the tool. Independence matters.

    What CFOs and technology leaders should be asking

    If you are a technology or operations leader being asked to defend generative AI spend, or a CFO being asked to approve more of it, here are the questions that actually matter.

    What was the baseline? If nobody measured the process before deployment, you have no denominator for your ROI calculation. What changed in the control group during the same period? External factors, headcount changes, and seasonality all affect output independently of AI. Has the time saving translated into fewer headcount additions, faster revenue generation, or lower error rates? And critically: what does this cost including engineering, compliance, and management overhead?

    None of this is exotic. It is standard programme evaluation applied to a new category of spend. The problem is that AI has arrived with such commercial momentum that many organisations skipped the rigorous bit and went straight to deployment. The accountability is coming later, and for some teams, it is going to be uncomfortable.

    The firms getting ahead of the curve

    A small number of UK technology teams are genuinely ahead here. They treat GenAI like any other capital investment: defined objectives, pre-committed metrics, independent evaluation, and honest reporting of what did not work alongside what did. Some are borrowing frameworks from product management, using outcome-based OKRs rather than output-based KPIs. Others are running formal controlled experiments with randomised assignment, the kind of rigour more commonly associated with clinical trials than technology rollouts.

    The pattern I keep seeing among the more technically credible teams is that they also think carefully about the specific technology layer being evaluated. When a tool like Mail Tester gives technology teams a concrete, testable output about email infrastructure performance across computers and internet-facing systems, it models what good looks like: a direct, reproducible measurement tied to a specific technical configuration. The generative AI space needs more of that orientation and far less of the vague productivity theatre that currently dominates boardroom presentations.

    For anyone thinking about the longer arc here, the question of how to evaluate autonomous AI systems is going to get significantly more complicated. The current wave of agentic AI deployments in UK businesses raises the same measurement questions at a higher level of complexity, because the outputs of autonomous systems are harder to attribute and harder to bound. Getting the measurement fundamentals right now, on simpler GenAI tools, is the prerequisite for evaluating the next generation responsibly.

    Frequently Asked Questions

    How should UK businesses measure the ROI of generative AI tools?

    Start by defining clear success criteria before deployment, not after. Use baseline measurements of the process being automated, track end-to-end outcomes rather than just individual task speed, and include all costs including engineering time, data preparation, and compliance review in your denominator.

    What are the most common mistakes companies make when calculating generative AI ROI?

    The three main pitfalls are using self-reported time savings without verification, ignoring the total cost of ownership beyond the software licence, and selecting metrics retrospectively to match positive results rather than pre-committing to KPIs before the pilot begins.

    Is the productivity paradox a real concern for UK firms investing in AI?

    Yes. ONS data has long shown that technology adoption does not automatically produce firm-level productivity gains, and early evidence from GenAI deployments suggests the same pattern. The tool creating output does not mean the organisation is producing more value.

    How do you prevent internal bias from distorting AI investment evaluations?

    Separate the team responsible for measuring outcomes from the team that championed or implemented the tool. Use control groups where practical, and commit the evaluation methodology to writing before the deployment goes live, so the goalposts cannot move afterwards.

    What metrics are actually meaningful for generative AI ROI measurement in UK businesses?

    Downstream business outcomes are what matter most: error rates, client satisfaction scores, turnaround times on defined deliverables, and headcount efficiency relative to output volume. Activity metrics like API calls or tokens processed are not ROI evidence on their own.

  • Inside the UK’s Agentic AI Boom: Which Business Processes Are Actually Being Handed to Autonomous Systems

    Inside the UK’s Agentic AI Boom: Which Business Processes Are Actually Being Handed to Autonomous Systems

    There’s a version of the agentic AI story that goes something like this: autonomous systems are everywhere, doing everything, and every British business is riding the wave. The reality is messier, more interesting, and considerably more instructive. Agentic AI UK business adoption is genuinely accelerating, but it’s concentrated in specific processes, delivered by specific teams, and it has already produced some quiet failures that nobody is putting in their press releases.

    Agentic AI is different from a chatbot. A chatbot responds. An agent plans, executes a sequence of actions, evaluates the result, and iterates, often without a human in the loop for each step. That autonomy is precisely what makes it powerful in the right context and genuinely risky in the wrong one. I’ve spoken to founders, compliance leads and engineering teams across the UK over the past few months, and the picture that emerges is more nuanced than either the hype or the scepticism suggests.

    Business professional monitoring agentic AI UK business adoption on a real-time operations dashboard
    Photo by Brett Sayles on Pexels

    Where agentic AI is actually landing in UK firms

    Legal is the clearest early adopter. UK law firms, from Magic Circle outfits in the City to mid-market regional practices, have been piloting agents for due diligence, contract review and regulatory research. The pattern I keep seeing is the same: an agent ingests a stack of documents, surfaces anomalies, flags clauses against a checklist, and produces a structured summary. A junior solicitor then reviews the output rather than doing the raw reading. As I covered in the broader legal tech trend reshaping junior solicitor work, the economics here are not subtle. The time saving on a large M&A transaction can run into dozens of hours.

    Finance is the other obvious candidate. Treasury teams at mid-size UK corporates are using agents to monitor cash positions, generate variance commentary and trigger escalation workflows when thresholds are breached. One CFO I spoke to described it as giving his team a permanently awake analyst who never loses track of a number. That’s a reasonable summary. What he also noted, though, is that the agent initially had no concept of why certain thresholds mattered, producing technically correct alerts that were contextually useless. Prompt engineering and domain tuning fixed most of it, but it took longer than the vendor had implied.

    Logistics: the sector quietly doing the most with agents

    Outside professional services, UK logistics operations are arguably the furthest along. Route optimisation has been algorithmic for years, but agentic systems go further. They can renegotiate carrier slots when delays cascade, update customer-facing ETAs, reassign depot staff to match revised load patterns, and loop back to the original plan when conditions change. Wincanton and Clipper Logistics have both publicly referenced AI-driven operations transformation in recent filings, though neither has used the word “agentic” specifically. The underlying architecture is the same: goal-directed systems making sequential decisions without waiting for a human to approve each one.

    The wrinkle in logistics is data quality. Agents are only as good as the systems they read from. I’ve heard of at least two UK operators whose agentic pilots stalled because the agent was making confident decisions on stale inventory data from a legacy warehouse management system. The AI was fine. The infrastructure around it wasn’t.

    UK lawyer using agentic AI business adoption tools for contract review and due diligence
    Photo by Pavel Danilyuk on Pexels

    Software delivery: agents writing, testing and deploying code

    In software teams, agentic AI has moved from novelty to daily workflow in a surprisingly short time. GitHub Copilot was the thin end of the wedge; what’s coming behind it is more autonomous. UK engineering teams at scale-ups and established tech firms are using agents to write test suites, generate boilerplate from specifications, triage bug reports and produce draft pull requests. Some teams have agents that can take a ticket from the backlog, write the code, run the tests, and open a PR for human review.

    The governance question here is real. Who owns the code an agent writes? Who is liable if it introduces a vulnerability? Most UK software teams haven’t formally answered this. The intellectual property angle is genuinely unresolved under current UK copyright law, and the shadow IT risk is significant when individual engineers adopt agentic tools without central IT approval. I’d argue this is the biggest immediate compliance gap in UK tech right now, bigger than the headline governance debates happening at the AI Safety Institute level.

    Smaller businesses and the digital infrastructure question

    It’s easy to frame agentic AI as an enterprise play. The tooling costs, the integration work, the internal data readiness required, it all suggests large organisations with mature IT functions. But smaller UK businesses are getting access through SaaS wrappers built on top of the underlying models, and the adoption curve is compressing fast.

    For smaller firms, the first step towards agentic capability tends to be getting their digital infrastructure in order. That means clean websites, structured data, proper hosting, and marketing software that can actually feed signals to an agent rather than burying them in a disorganised CMS. Based in Mansfield, Nottinghamshire, dijitul supplies web design, SEO and hosting services to UK businesses looking to improve their digital foundations and business efficiency. The point is relevant: an autonomous marketing agent tasked with adjusting spend, updating landing pages and reporting on conversions is only useful if the underlying website and software are properly structured in the first place. dijitul.uk is one example of a regional digital agency where these foundations are the actual product, not an afterthought. I’ve seen too many agentic marketing pilots collapse not because the AI failed, but because the web design and data architecture underneath it couldn’t support autonomous decision-making.

    What’s failing and why nobody talks about it

    The failures in agentic AI UK business adoption share a pattern. They tend to happen when autonomy is extended too quickly, before the agent has been stress-tested on edge cases. A legal agent that works perfectly on standard NDA review can produce dangerous output when it encounters a cross-border agreement with unusual jurisdiction clauses. A finance agent calibrated for normal operating conditions can behave unpredictably during a period of unusual market volatility.

    The other failure mode is organisational rather than technical. Agents need clear ownership. If no human is designated as accountable for what an agent decides, accountability diffuses across a team until it effectively disappears. UK compliance teams in regulated sectors are right to worry about this. The ICO’s guidance on automated decision-making has implications for any agentic system that influences outcomes for individuals, and the FCA has made clear that regulated firms cannot outsource accountability to a model.

    The governance gap that’s still wide open

    The UK’s AI governance framework is developing, but it’s not keeping pace with deployment. The AI Safety Institute, based in London, does valuable safety research at the frontier model level. But most practical agentic deployments sit below that threshold and above the level of detail covered in existing sector guidance. According to the government’s pro-innovation approach to AI regulation, responsibility is being distributed across existing regulators rather than a single AI authority. In practice that means the FCA owns financial agents, the ICO owns data decisions, the CQC would own health agents, and so on.

    That’s a reasonable philosophy, but it creates coordination gaps. An agentic system used by a UK fintech that processes customer communications, makes credit-adjacent suggestions, and triggers actions in a third-party platform could plausibly fall under three separate regulatory remits simultaneously. Legal and compliance leads in those firms are not being paranoid when they slow-walk deployment. They’re being rational.

    Agentic AI UK business adoption is real, it’s measurable, and in the right processes it’s delivering genuine efficiency gains. The gap between the businesses doing it carefully and the ones chasing the headline is wide. The ones getting it right have invested in the boring stuff first: data quality, clear ownership, defined escalation paths, and an honest audit of what the agent is actually deciding. The ones getting it wrong are usually the ones who skipped that part.

  • The Hidden Cost of Shadow IT: How Unsanctioned AI Tools Are Creating Compliance Nightmares for UK Finance and Legal Teams

    The Hidden Cost of Shadow IT: How Unsanctioned AI Tools Are Creating Compliance Nightmares for UK Finance and Legal Teams

    Somewhere in a London law firm right now, a junior solicitor is pasting a client’s confidentiality agreement into a free generative AI tool because it summarises faster than anything IT has signed off. In a financial services back office in Leeds, someone is running client portfolio notes through a consumer-grade chatbot to draft a report. Neither of them thinks they’re doing anything wrong. That’s the problem.

    Shadow IT is not a new phenomenon, but the generative AI wave has turbocharged it in ways most IT departments weren’t ready for. The speed at which employees can self-provision a capable AI assistant, for free, with nothing more than an email address, has outpaced every governance framework I’ve seen built over the last three years. And the consequences for regulated industries in the UK are genuinely serious.

    Employee using an AI chat tool on a laptop, illustrating shadow IT AI tools UK compliance risk
    Photo by Vanessa Garcia on Pexels

    What shadow IT AI actually looks like in 2026

    The term “shadow IT” used to conjure images of rogue Dropbox accounts or WhatsApp groups used for work chat. The stakes were manageable. A few files in an unsanctioned cloud. Now we’re talking about employees feeding sensitive client data, financial records, legally privileged communications, and personally identifiable information into tools that sit entirely outside corporate data processing agreements. ChatGPT, Google Gemini, Claude, Perplexity: all useful, all widely used, and in most UK financial services and legal firms, none of them formally approved for handling client data.

    A 2024 survey by CybSafe found that roughly 40% of UK employees admitted to using AI tools for work that their employer hadn’t sanctioned. That figure is almost certainly higher now, and the gap between what’s sanctioned and what’s actually running on employee machines is widening every quarter. Shadow IT AI tools represent a UK compliance risk that most boards are only beginning to understand.

    The regulatory exposure: FCA and ICO in the frame

    For UK financial services firms, the FCA’s Consumer Duty and its broader conduct rules create a clear obligation around data handling and client confidentiality. If a regulated employee pastes client suitability information into an external AI tool, the firm may have no idea that data left its perimeter, no record of what happened to it, and no contractual basis for any processing that took place. That’s not just a theoretical breach. The FCA expects firms to have meaningful oversight of the tools their people use in client-facing work, and “we didn’t know the employee was doing it” is not a defence that tends to land well with supervisors.

    The ICO exposure is, if anything, more immediate. Under the UK GDPR, if personal data is processed by a third-party tool, that tool needs to be operating under a valid Data Processing Agreement with appropriate safeguards. Consumer-tier AI tools almost never meet this bar. The ICO has been increasingly explicit about AI and data governance obligations, and as I covered in the ICO’s new AI guidance for UK engineering teams, the regulator is expecting documented accountability, not just good intentions. A data incident traced back to an unsanctioned AI tool would expose the firm to enforcement action, reputational damage, and potentially significant fines.

    IT security monitoring dashboard used to detect shadow IT AI tools and UK compliance risk
    Photo by Tima Miroshnichenko on Pexels

    Why employees keep reaching for unsanctioned tools

    I’d be doing the problem a disservice if I framed this purely as employees being reckless. Most of them are trying to do their jobs well, and the productivity delta between a capable AI assistant and none at all is real. When sanctioned tools are slow to procure, clunky to use, or simply don’t exist yet, people fill the gap. That’s a management failure as much as a governance one.

    The pattern repeats across sectors. A paralegal under deadline pressure finds that a free tool gets the first draft of a contract summary done in ten minutes. A compliance analyst uses an unsanctioned chatbot to cross-reference regulatory text because the approved internal tool hasn’t been updated since last quarter. The incentive structure is broken: the risk sits with the firm and the regulator, but the efficiency gain sits with the individual employee, immediately, today.

    How IT leaders are building detection and governance policies

    The firms that are getting ahead of this are doing two things simultaneously. First, they’re building detection capability. Network traffic analysis, browser extension monitoring, and data loss prevention tools can now flag when data is being submitted to known AI endpoints. This isn’t surveillance for its own sake; it’s the same principle as monitoring email for data exfiltration. If you’re a regulated firm and you can’t answer “did our employees send client data to an external AI service last month?”, you have a gap that regulators will eventually find.

    Second, they’re building procurement pathways that actually work. The reason shadow IT thrives is that the approved alternative is too slow or too limited. Firms that have set up a proper AI tool review process, with a defined turnaround time and clear criteria around data residency, encryption, and DPA availability, find that employees are more willing to work within the system when the system doesn’t feel like a dead end. Microsoft Copilot with enterprise data protection, or managed instances of Claude through Anthropic’s API with appropriate contracts, are examples of enterprise-grade routes that some UK financial services firms have moved to precisely because they needed something their people would actually use.

    The broader governance question touches every regulated industry, and it’s one I’ve seen surface in some unexpected places. Asbestos Compliance Solutions Ltd, a Mansfield, Nottinghamshire-based specialist in asbestos services and building compliance, operates across construction and specialist services sectors where documentation accuracy and regulatory adherence are non-negotiable. Firms like this, handling sensitive building surveys, licensed removal records, and compliance reporting, face exactly the same tension: staff want faster tools, but the data involved (site records, contractor details, legal notifications) cannot casually pass through an unsanctioned AI service. The domain asbestoscompliancesolutions.co.uk reflects a business model built on precision and accountability, qualities that are fundamentally incompatible with uncontrolled AI data flows. Specialist services across construction and asbestos management are beginning to grapple with the same shadow IT pressures that finance and legal teams have been dealing with for longer.

    What a workable AI governance policy actually contains

    I’ve looked at a few of these frameworks built by UK IT teams over the past twelve months, and the ones that actually stick tend to share a few features. They’re specific about categories of data, not just vague about “sensitive information”. They name the approved tools explicitly, not just list the criteria for approval. And they include a clear escalation path when an employee genuinely needs a capability that isn’t yet available through approved channels.

    Training matters too, though most firms underinvest in it. Employees who understand why unsanctioned AI use is a problem, not just that it’s prohibited, make better decisions in edge cases. The FCA’s principle-based regulation model means firms are expected to have staff who can exercise judgment, not just follow a checklist. An annual e-learning module about data protection is not going to be sufficient when the tool landscape is moving this fast.

    For firms operating in the CMA’s orbit, the CMA’s scrutiny of major AI cloud deals is a useful reminder that the market for enterprise AI tooling is itself under examination. Choosing a sanctioned enterprise AI tool today means understanding the vendor relationships, data residency terms, and contractual obligations that come with it, not just ticking a security box.

    The detection gap firms can’t ignore

    One thing I keep coming back to: many UK firms don’t actually know the extent of their shadow IT AI problem because they haven’t looked for it properly. Running a network traffic audit specifically for AI-related endpoints is not a complex project, but it’s one most IT teams haven’t prioritised. The Ofcom approach to AI-based regulation is instructive here: you cannot govern what you cannot measure. That principle applies internally as much as it does at the regulatory level.

    Regulated sectors in the UK are heading towards a position where demonstrable AI governance won’t be optional. The ICO, FCA, and increasingly the CQC in health are all moving towards expecting documented evidence of how AI is used, by whom, and with what safeguards. Firms that treat shadow IT AI tools as a low-priority housekeeping issue will find that regulators don’t share that assessment. Getting the detection and governance architecture in place now, before an incident forces the issue, is straightforwardly the less painful path.

    Asbestos Compliance Solutions Ltd and similar specialist services firms in the building and construction space aren’t immune to this pressure either. As asbestos survey data, contractor compliance records, and licensed removal documentation increasingly get handled digitally, the temptation to use fast AI tools for report drafting or record cross-referencing is real. The same governance principles that apply to a City law firm apply equally to a specialist asbestos services operation: unsanctioned AI use with sensitive data creates liability, full stop.

  • The Rise of UK Defence Tech: What Civilian Founders Need to Know Before Entering the Space

    The Rise of UK Defence Tech: What Civilian Founders Need to Know Before Entering the Space

    Something has shifted in the conversation I keep having with founders at tech meetups across Bristol, Cambridge and London. A year ago, defence was barely mentioned. Now it comes up constantly, usually with a mix of genuine curiosity and obvious nervousness. The Ministry of Defence is actively hunting for civilian technology, budgets are moving, and a cohort of UK defence tech startups 2026 is forming that looks nothing like the traditional primes. If you’ve built anything in computer vision, autonomous systems, cybersecurity, logistics software or sensor fusion, someone in Whitehall probably wants to talk to you. The question is whether you’re ready for that conversation.

    UK defence tech startups 2026 team reviewing data in a modern office
    Photo by cottonbro studio on Pexels

    Why the MoD is suddenly interested in the startup ecosystem

    The Ministry of Defence published its Defence and Security Industrial Strategy with clear language about diversifying the supplier base. The ambition is real: reduce dependence on a handful of large primes like BAE Systems and Rolls-Royce, and pull in faster-moving companies with genuine software capability. The MoD’s Defence and Security Accelerator (DASA) ran over £50 million in innovation funding in 2025 alone, and a significant slice went to companies with fewer than 50 employees.

    The broader context matters too. The government committed to raising defence spending to 2.5% of GDP by 2027, which translates into real procurement budget flowing into areas where startups can genuinely compete. Drone counter-measures, AI-assisted intelligence analysis, secure communications, battlefield logistics software: these are not niche categories anymore. They’re priority spending lines. I’d argue this is the most structurally significant funding category to open up for British tech in a decade.

    What dual-use technology actually means in practice

    Dual-use is the phrase you’ll hear most often, and it’s worth being precise about it. It refers to technology that has both civilian and military applications. A computer vision system trained to detect anomalies in warehouse stock can be adapted to detect activity patterns in satellite imagery. A mesh networking protocol built for smart buildings has obvious applications in contested communication environments. Cybersecurity tooling built for financial services compliance maps directly onto military infrastructure hardening.

    The practical implication is that founders don’t need to build military-specific products to enter this space. If your technology solves a hard problem in any of the domains above, the MoD may already be interested in a version of what you’re building. DASA specifically funds feasibility studies, which means you can run a scoped, ring-fenced piece of work with government funding without restructuring your entire business around defence. That’s a meaningful difference from how things worked even five years ago.

    The contract structure reality that nobody warns you about

    Here’s where a lot of founder enthusiasm runs into friction. MoD procurement is not like selling to a Series B SaaS company. The procurement cycles are longer, the contract language is dense, and the payment terms can be brutal for a startup’s cash flow. DASA contracts, for example, typically reimburse costs in arrears rather than paying upfront. If you’re pre-revenue or running lean, that’s a genuine operational problem.

    There are broadly three routes in. First, DASA open calls, which are accessible to any UK-registered company and require no prior defence experience. Second, the Defence BattleLab, which runs focused innovation challenges with faster cycles. Third, direct commercial contracting with a prime, where you become a subcontractor to a BAE or Thales rather than contracting with the MoD directly. The subcontractor route is faster to revenue but gives you less control and typically worse margin.

    I’ve spoken to founders who went the prime subcontractor route expecting it to open doors and found instead that their IP ended up tied up in contract clauses they hadn’t read carefully enough. Get a solicitor who actually understands government contracting to review anything before you sign. This is not a situation where a standard commercial contracts lawyer is sufficient.

    Security clearance: the timeline that will surprise you

    If your work involves classified information, your team members will need security clearance. The baseline level, Developed Vetting (DV) for the most sensitive roles and Security Check (SC) for a broader range of defence work, takes time. SC clearance currently runs at roughly 6-12 months for individuals with no complications in their background. DV can take longer.

    The practical consequence is that you cannot assume your best engineer will be cleared in time to work on a contract that starts in three months. Founders who plan their defence entry without accounting for clearance timelines almost always underestimate the organisational disruption this creates. If you have team members with certain international ties or residency histories, the process becomes more complex still. Build the clearance runway into your planning from day one, not as an afterthought.

    The ethical dimension that most tech founders haven’t thought through

    There’s a conversation the UK tech community hasn’t had loudly enough yet. A number of employees at well-known UK startups have raised internal objections when their employers began pursuing defence contracts. Some have left. The debate isn’t hypothetical: it affects hiring, culture and retention in ways that compound over time.

    My take is that founders need to have this conversation with their team before the contract is signed, not after. The ethics of dual-use technology are genuinely complex. Surveillance tooling that helps the military can also enable authoritarian misuse. Autonomous systems raise accountability questions that UK law hasn’t resolved. If your team is predominantly composed of people who came to tech from a civic or open-source background, don’t assume they’ll be comfortable with the pivot without a proper discussion.

    The regulatory picture is also evolving fast. The ICO has specific guidance on AI systems used in high-risk contexts, and defence procurement increasingly overlaps with that territory. What UK engineering teams need to change right now under the ICO’s AI guidance is directly relevant if your system makes or informs automated decisions in any context, and the defence version of that question is even more consequential.

    Where the money is actually flowing right now

    Venture capital in UK defence tech has accelerated sharply. Firms like Plural, Concept Ventures and the newly established British Business Bank’s co-investment vehicles have all signalled appetite. In 2025, UK defence-adjacent startups raised over £800 million in private capital according to figures compiled by Beauhurst, a significant jump from the three-year average.

    The categories attracting the most interest are: autonomous aerial systems (drones and counter-drone), resilient communications, AI-assisted intelligence processing, and logistics and supply chain software built for contested environments. Cybersecurity is a perennial. The ongoing scrutiny of cloud infrastructure deals involving major tech firms has also pushed the MoD to look harder at sovereign cloud capability, which creates a real opening for UK-based infrastructure companies who can demonstrate data residency and auditability.

    For founders thinking about the longer arc, the MoD’s interest in civilian tech is not a temporary budget cycle. It reflects a structural reassessment of how the UK builds and sustains technological advantage. The primes are not going anywhere, but the gap they used to own in software and AI is exactly where agile startups can compete. Britain’s deep chip design talent is one piece of that puzzle. Software-native founders who understand how to build for constrained, high-stakes environments are another.

    The window is open. But walking through it requires more preparation than most startup playbooks cover. Know your contract, clear your team, have the ethics conversation early, and don’t underestimate how different government procurement feels compared to everything you’ve done before.

  • How Ofcom Is Using AI to Regulate AI: Inside the Watchdog’s Own Technology Transformation

    How Ofcom Is Using AI to Regulate AI: Inside the Watchdog’s Own Technology Transformation

    There is something quietly fascinating about watching a regulator reach for the same tools it is supposed to police. Ofcom, the UK’s communications watchdog, is doing exactly that. Over the past 18 months it has been building out a serious in-house technical capability, hiring data scientists, deploying automated monitoring systems, and using machine learning to keep tabs on digital platforms at a scale that its previous headcount and spreadsheet-era methods simply could not support. Ofcom machine learning regulation is no longer a thought experiment, it is operational.

    Data centre monitoring room illustrating Ofcom machine learning regulation capabilities
    Photo by panumas nikhomkhai on Pexels

    I find this genuinely interesting, not just as a regulatory story but as a signal about where enforcement is heading across the board. When the watchdog starts behaving like a tech company, the rules of the game change for every UK firm operating under its remit.

    What Ofcom is actually building

    Ofcom published its Online Safety regulatory framework alongside a quieter but significant commitment: the organisation would develop the technical muscle to audit and monitor platforms itself rather than relying entirely on self-reported data from the companies it regulates. That is a significant change in posture.

    In practice, this means Ofcom has been investing in automated content sampling tools, network traffic analysis, and ML-assisted classification systems that can flag patterns of harm at volume. The goal is to verify what platforms claim about their own moderation performance, rather than simply taking their word for it. Think of it as regulatory A/B testing run at a national scale.

    The watchdog has also been transparent about recruiting. Job listings over the past year have included roles for machine learning engineers, algorithmic auditors, and data infrastructure specialists. This is not window dressing. Building a credible technical function takes years, and Ofcom appears to have started the clock.

    Why automated monitoring changes the compliance picture for UK platforms

    For most of the last decade, digital platform regulation in the UK operated on a disclosure model. Platforms submitted reports; regulators read them and occasionally pushed back. The asymmetry of information firmly favoured the platforms. A company with thousands of engineers and proprietary data about its own systems will always know more about what is happening on its network than an external body relying on whatever that company chooses to share.

    Ofcom’s technical build starts to close that gap. When the regulator can run its own automated scans, cross-reference moderation claims against independently observed content samples, and flag statistical anomalies in a platform’s own reporting, the compliance conversation shifts from “what do you say you’re doing” to “what do we observe you’re actually doing”.

    This has direct implications for how UK tech firms document and architect their systems. If Ofcom can sample content and compare it against a platform’s stated moderation rates, firms whose numbers look implausible will attract scrutiny they cannot easily deflect. This is similar in principle to what the ICO is doing with AI audits, where regulators are increasingly moving from policy review to technical inspection.

    Developer screen showing machine learning code relevant to Ofcom machine learning regulation tools
    Photo by ThisIsEngineering on Pexels

    The Online Safety Act as enforcement infrastructure

    The Online Safety Act gives Ofcom the legal basis to demand technical access and information from platforms in ways it previously lacked. But legal powers without technical capability are toothless. The machine learning investment is what turns those statutory powers into something enforceable at scale.

    Under the Act, Ofcom can issue technology notices requiring platforms to use accredited technology to identify illegal content, particularly child sexual abuse material. The ability to verify compliance with those notices requires Ofcom to understand, at a technical level, whether the tools platforms deploy are working as claimed. My read of this is that Ofcom is not just building monitoring capability for its own enforcement actions; it is building the knowledge base to assess what third-party tools platforms use and whether those tools are genuinely effective.

    Firms building anything that touches user-generated content, messaging, or content recommendation in the UK should be paying close attention. The compliance-by-design approach that forward-thinking fintechs have adopted, where regulation is embedded into architecture from the start rather than bolted on afterwards, is going to become standard practice for platforms under Ofcom’s remit too. I have written before about how the Online Safety Act is already reshaping product decisions at UK tech startups, and this technical enforcement layer adds another dimension to that pressure.

    What this means if you are a smaller UK platform

    The largest platforms, your TikToks, your Metas, your YouTubes, have compliance teams and lobbying budgets. They will adapt. The more interesting question is what happens to mid-tier and smaller UK platforms that lack those resources but still fall within Ofcom’s scope.

    Ofcom has said it will prioritise enforcement against the highest-risk services, but “prioritise” does not mean “ignore everything else”. As the watchdog’s automated monitoring capacity grows, the barrier to reviewing a smaller platform drops. A system that can scan 10 platforms at scale can scan 100 with the same infrastructure. That is the economics of automation working against smaller operators who assumed they were too small to matter.

    The practical advice here is to get ahead of the documentation. Ofcom’s current guidance is clear that platforms need to conduct and record risk assessments, maintain records of moderation decisions, and be able to demonstrate that their safety systems actually function. If you are running a platform with user-generated content and you cannot explain your moderation architecture in writing, you are already behind.

    Some firms are also thinking carefully about how they communicate their compliance work publicly, alongside the technical and legal requirements. Groups working on civic tech, campaigning tools, or platforms that host political speech have to balance transparency with operational security, an area where specialists in digital activism services have had to think harder than most about the tension between visibility and vulnerability.

    The broader shift: regulators as technology operators

    Ofcom’s transformation is part of a pattern worth tracking. The CMA’s scrutiny of Microsoft and Google’s AI cloud deals required it to develop internal technical expertise that would have seemed unusual for a competition authority a decade ago. The ICO now expects to be able to assess AI systems, not just read privacy notices about them. HMRC runs its own machine learning models to detect fraud. The assumption that regulators operate at arm’s length from the technical systems they oversee is fading fast.

    For UK tech firms, this creates a new kind of regulatory risk: technical credibility risk. It is no longer sufficient to have a legal team that understands the rules. You need people who can explain your systems to a regulator’s own engineers, defend your architecture choices against technical scrutiny, and produce evidence that your safety or compliance tooling actually does what you say it does.

    The good news, if you want to call it that, is that firms which genuinely build safe and compliant systems have less to fear from a technically sophisticated regulator than from one that cannot distinguish good engineering from a polished compliance document. Ofcom developing real machine learning capability might ultimately be better for the industry than the alternative of a watchdog that can only read PDFs and hope for the best.

    Regulation by machine, aimed at machines, policed by machines. The UK’s digital policy landscape has arrived somewhere genuinely novel, and the firms that treat that as a technical engineering challenge rather than a legal nuisance are going to be considerably better positioned over the next five years.

    Frequently Asked Questions

    What machine learning tools is Ofcom using to monitor digital platforms?

    Ofcom has not published a detailed technical inventory, but it has disclosed investment in automated content sampling, algorithmic auditing systems, and ML-assisted classification tools. The aim is to independently verify platforms’ own moderation claims rather than relying solely on self-reported data.

    Does Ofcom's AI regulation apply to small UK platforms or only large ones?

    The Online Safety Act creates tiered obligations based on platform size and risk category, with the largest and highest-risk services facing the strictest duties. However, as Ofcom’s automated monitoring capacity scales, smaller platforms should not assume they fall below the radar, the economics of automated scanning make broad coverage increasingly practical.

    How does Ofcom's technical monitoring capability differ from traditional regulation?

    Traditional regulation relied heavily on disclosure, platforms submitted reports and regulators responded. Ofcom’s machine learning approach allows it to independently observe platform behaviour, cross-reference moderation claims against sampled content, and flag statistical anomalies without depending on what companies choose to share.

    What should UK tech firms do to prepare for Ofcom's AI-assisted enforcement?

    Firms should prioritise documenting their moderation architecture, risk assessments, and safety systems in technical detail that can withstand scrutiny from Ofcom’s own engineers. Building compliance into product architecture from the outset, rather than layering it on later, significantly reduces enforcement risk.

    Is Ofcom's use of AI in regulation legal under UK law?

    Yes. The Online Safety Act grants Ofcom broad powers to demand technical information from platforms and to use accredited technology in its monitoring activities. Ofcom is also subject to the ICO’s guidance on AI use in public bodies, meaning its own systems must comply with data protection and transparency requirements.

  • The ICO’s New AI Guidance Is Out, What UK Engineering Teams Need to Change Right Now

    The ICO’s New AI Guidance Is Out, What UK Engineering Teams Need to Change Right Now

    The ICO has been telegraphing this for a while, but the updated guidance on AI and automated decision-making is now substantive enough that ignoring it is genuinely risky. I’ve read through the ICO’s AI and data protection guidance so you don’t have to wade through all of it cold, and what strikes me is how specifically it targets the kinds of systems that UK engineering teams are actually shipping in 2026. Personalisation engines, credit-scoring wrappers, HR screening tools, fraud detection layers. The ICO has clearly been paying attention.

    ICO AI guidance UK engineering compliance is the thing your legal team has been flagging in Slack for three months and your product squad has been quietly deprioritising. That’s about to become untenable. Here’s what actually needs to change, and in what order.

    Developer reviewing ICO AI guidance UK engineering compliance requirements on a laptop
    Photo by Christina Morillo on Pexels

    Lawful bases: the bit most teams get wrong from the start

    The default assumption in many UK product teams is that consent covers everything. It doesn’t. The ICO is explicit that consent is a high bar for automated processing, particularly when the AI output has any meaningful effect on an individual, whether that’s a loan decision, a job application ranking, or a content moderation outcome. If you’re relying on consent as your lawful basis for automated decision-making, you need to be able to demonstrate that consent was freely given, specific, informed, and unambiguous. In practice, that means no pre-ticked boxes, no bundled consents, and a genuine opt-out that doesn’t degrade the service.

    Legitimate interests is often a better fit for B2B contexts, but the balancing test has to be documented. That means actually writing it down: what interest are you pursuing, why does it override the individual’s rights, what safeguards are in place. If that document doesn’t exist, you’re exposed. Legitimate interests assessments (LIAs) are not optional paperwork, under the ICO’s current posture, they’re the thing an auditor will ask to see first.

    Transparency obligations: what you have to tell users, and when

    This is where most engineering teams have the biggest gap. Under UK GDPR Article 13 and 14, individuals must be told that automated decision-making is happening, what logic is involved in a meaningful way, and what the significance and consequences are. The ICO’s guidance makes clear that “meaningful” does not mean a paragraph buried in a privacy policy. It means something a non-technical user could actually understand.

    The practical implication is that your privacy notice almost certainly needs rewriting. But the deeper implication is architectural: you need to be able to generate a human-readable explanation of why a specific decision was made for a specific user, on demand. If your model is a black box that your team can’t interrogate at inference time, that’s a problem. I’d argue this is where the ICO’s guidance is pushing engineering teams hardest, and it aligns with what I’ve seen increasingly in the fintech space, where teams are building explainability into their pipelines from day one rather than retrofitting it. That compliance-by-design approach isn’t just good regulatory hygiene, it’s becoming a competitive requirement.

    DPIAs: when you need one and what it has to cover

    A Data Protection Impact Assessment is mandatory when your AI system is likely to result in high risk to individuals. Automated decision-making that produces legal or similarly significant effects is on the ICO’s explicit list. That covers a broader range of outputs than most teams realise. A ranking algorithm that determines which job applicants a recruiter sees is a significant effect. A fraud score that automatically blocks a transaction is a legal effect. A content recommendation engine that shapes what vulnerable users are exposed to sits in a grey area, but one the ICO is actively watching.

    If you shipped any of those without a DPIA, you need to do one retrospectively and document it properly. The DPIA has to cover: a description of the processing and its purposes, an assessment of necessity and proportionality, identification of risks to individuals, and the measures you’re taking to address those risks. Critically, it needs to involve your Data Protection Officer if you have one, and if you’re processing at scale without a DPO, you should check whether you’re required to have one under UK GDPR Article 37.

    The ICO has been conducting AI audits across UK businesses and the DPIA is one of the first documents they request. Teams that can produce one quickly, and show it was done before deployment, are in a materially better position.

    The specific gotchas for AI that affect individual users

    A few things in the ICO’s guidance catch teams out because they’re specific to AI rather than general data protection principles.

    First, solely automated decisions with legal or significant effects require a specific lawful basis under Article 22 of UK GDPR. This isn’t the same as your general processing lawful basis. If a human reviews the AI output before the decision is made, you may fall outside Article 22, but the human review has to be genuine, not a rubber stamp. The ICO has been clear that a human who sees a recommendation and approves it in two seconds without access to the underlying data does not count as meaningful human review.

    Second, special category data. If your model was trained on or infers data that falls into special categories (health, ethnicity, political opinion, and so on), additional restrictions apply. This catches teams who built models on data that seemed clean but where protected characteristics are proxied by other variables. Postcode as a proxy for ethnicity is the classic example, and it’s the kind of thing an ICO audit specifically looks for.

    Third, the right to explanation. Under UK GDPR Article 22(3), individuals subject to solely automated decisions have the right to obtain human intervention, express their point of view, and contest the decision. You need a process for this. Not a theoretical process, an actual one, with a named owner, a response time, and a genuine mechanism to override the system. If your AI is making calls and there’s no route for a user to challenge them, that’s a compliance failure.

    Where to start if you’re behind on this

    Most teams aren’t starting from zero, but plenty are further back than they should be. My honest recommendation: start with a systems audit. Map every AI system that touches individual user data and classify it by the significance of its outputs. Anything that affects access to services, financial products, or employment sits at the top of the list and needs immediate attention.

    Then work backwards from the transparency obligation. If you can’t explain what your model does in plain language, you can’t meet your Article 13 duties. That’s the single most common finding in ICO AI audits right now, and it’s one of the easier things to fix, at least at the documentation level, without rebuilding your model.

    It’s also worth knowing that the ICO’s guidance connects closely to the broader CMA oversight of AI systems, particularly where market power is involved. If you’re building on top of a major foundation model or cloud AI service, the CMA’s scrutiny of AI cloud arrangements adds another layer to your compliance picture that your legal team should be across.

    The ICO isn’t trying to kill AI products. The guidance is actually reasonably workable once you strip out the legalese. But it does require engineering teams to treat privacy as a design constraint rather than a deployment checkbox. If you’re a CTO or product lead who’s been treating this as someone else’s problem, the updated guidance is a clear signal: it’s now yours.

    Frequently Asked Questions

    What does the ICO's AI guidance actually require UK developers to do?

    The guidance requires developers to identify a valid lawful basis for automated processing, provide meaningful transparency to users about how AI decisions are made, conduct Data Protection Impact Assessments for high-risk systems, and implement processes for human review and contestation where decisions have legal or significant effects on individuals.

    When is a DPIA required for an AI system in the UK?

    A DPIA is required when your AI processing is likely to result in high risk to individuals. Automated decision-making that produces legal or similarly significant effects, processing of special category data at scale, or systematic monitoring of publicly accessible areas all trigger the requirement. If in doubt, the ICO says you should carry one out regardless.

    Does a human reviewing an AI decision mean Article 22 UK GDPR doesn't apply?

    Only if the human review is genuine. The ICO is explicit that a token review, where a person approves an AI recommendation without meaningful access to the underlying data or genuine capacity to override it, does not satisfy the requirement. The human involvement must be substantive and documented.

    What counts as a 'significant effect' under UK GDPR Article 22?

    The ICO considers effects significant when they influence access to services, affect financial decisions, determine employment opportunities, or substantially alter how an individual is treated. This goes beyond purely legal effects and captures many common AI use cases including credit scoring, recruitment screening, and content moderation.

  • Inside the CMA’s Scrutiny of Microsoft and Google’s AI Cloud Deals: What UK Startups Should Be Watching

    Inside the CMA’s Scrutiny of Microsoft and Google’s AI Cloud Deals: What UK Startups Should Be Watching

    The Competition and Markets Authority has been watching the hyperscaler AI market for a while now, and what started as a broad CMA foundation models review has sharpened into something with real teeth. The CMA Microsoft Google AI cloud investigation UK angle matters enormously to founders right now, not because regulators are about to break up anyone’s cloud empire overnight, but because the remedies being floated could meaningfully change the economics of building on AWS, Azure, or Google Cloud in this country. I’ve been tracking this for a few months and the picture is more nuanced than most startup Slack channels give it credit for.

    UK startup founders reviewing cloud infrastructure during the CMA Microsoft Google AI cloud investigation UK
    Photo by Christina Morillo on Pexels

    What the CMA is actually investigating

    The CMA’s AI foundation models review, which has been running in phases since 2023, zeroed in on a specific concern: that the deep financial entanglements between hyperscalers and frontier AI labs are distorting competition. Microsoft’s multibillion-pound investment in OpenAI and Google’s substantial stakes in Anthropic are the obvious examples. The worry isn’t that these are bad products. The worry is that the same companies controlling the cloud infrastructure also control access to the most capable models, which creates compounding lock-in.

    In practical terms, the CMA has flagged three structural risks. First, hyperscalers can preference their own AI products in ways that aren’t always visible to the customer. Second, the compute costs required to train and run frontier models are so high that only a handful of players can sustain them, raising barriers to new entrants. Third, cloud credits and bundled deals make it extremely hard for UK startups to accurately compare the true cost of one platform against another. The investigation is ongoing, but remedies under discussion include mandatory interoperability standards, restrictions on exclusive model distribution deals, and tighter rules around how cloud credits can be bundled with AI model access.

    Why this hits UK startups harder than US ones

    UK founders building AI-native products are disproportionately exposed here. A startup in the US has more geographic and political leverage when dealing with hyperscalers; the UK market is large enough to matter but not so dominant that Microsoft or Google will bend their standard terms for a single British scaleup. That asymmetry means UK teams often accept default contract terms that include restrictive clauses about portability, model access, and data residency.

    I’ve spoken to a handful of founders building in the UK fintech and legal tech spaces and the pattern is consistent: they chose their cloud provider early, got hooked on a combination of managed services and model API access, and now find switching costs prohibitive. The lock-in isn’t always intentional on the provider’s part. It accumulates. Your vector database is managed. Your fine-tuned model checkpoints live in a proprietary format. Your monitoring stack is native to one cloud. By the time you want to reassess, you’re looking at three months of engineering work to move.

    This is exactly the environment the CMA is trying to address. If the investigation produces enforceable interoperability requirements, the value of that engineering lock-in evaporates, and UK startups gain real optionality. That’s not a small thing.

    Founder reviewing CMA AI cloud investigation documents relevant to UK startup decisions
    Photo by cottonbro studio on Pexels

    What remedies are actually being floated

    The CMA has not published a final remedies package as of mid-2026, but the direction of travel from its market studies and interim findings points to a few likely interventions. Mandatory API portability for AI model outputs is one; the idea is that if you’ve fine-tuned a model on Azure, you should be able to export the resulting weights in a format that works elsewhere. Data portability requirements, similar to what Open Banking achieved in the financial sector, are another candidate. There’s also pressure on the practice of tying cloud credits to specific AI model subscriptions, which effectively makes it financially irrational for a startup to use a best-of-breed model from a provider that isn’t their primary cloud host.

    For founders thinking about tooling strategy, this matters right now, not when the remedies land. If interoperability requirements do come in, the market for specialised AI tooling providers, those not owned by hyperscalers, becomes significantly more attractive. Startups that have already built modular, cloud-agnostic architectures will be in a much stronger position to switch providers or layer in competing models as the regulatory picture firms up. Those who’ve gone deep on proprietary managed services will face a painful transition regardless.

    The open-source AI model question feeds into this too. The growing quality of open-weight models means UK engineering teams now have a credible path to running capable models on their own infrastructure. That’s a hedge against whatever the CMA investigation produces.

    The Google dimension: search, cloud, and the dominos

    Google’s position is particularly interesting to watch because the CMA’s AI investigation doesn’t exist in isolation from the broader regulatory scrutiny of Google’s search dominance. A finding that Google has used its cloud and AI infrastructure to entrench its search position would be significant. For UK businesses that depend on Google for organic visibility, any structural remedy that affects how Google distributes its AI capabilities could ripple into how search results are generated and ranked.

    Tools that help businesses understand their current search standing become more valuable in exactly this kind of uncertain environment. Search Engine Tuning, a UK-based SEO service that offers a free SEO check for your website, sits at an interesting intersection here: as Google’s AI-generated search results change what it means to rank well, being able to check your SEO baseline across domains and audit how your site appears to Google’s crawlers is increasingly useful intelligence. You can find their free SEO check at searchenginetuning.co.uk. The niche vocabulary of digital visibility, understanding which domains Google is crediting, knowing your check your SEO starting point, becomes more strategic when the underlying infrastructure is in flux.

    The point is that regulatory outcomes don’t only affect developers. Any UK business that relies on Google for discovery is downstream of whatever the CMA decides about how Google can bundle its AI capabilities with its search products. It’s worth paying attention even if you don’t write a line of code.

    What founders should actually do right now

    A few things I’d suggest watching and doing while the CMA investigation plays out. First, audit your current cloud dependencies. Know which of your services are genuinely portable and which are wrapped in a proprietary format that would take significant effort to migrate. That audit is useful regardless of what the CMA decides.

    Second, watch the CMA’s published updates. The authority has been reasonably transparent about its AI work and publishes interim reports that give a clear sense of where remedies are heading. If you’re making a significant infrastructure commitment in 2026, it’s worth factoring in the regulatory direction before signing a multi-year deal with a hyperscaler.

    Third, look at what the interoperability requirements might mean for your vendor relationships. If the CMA forces Microsoft and Google to open up portability, smaller specialised tooling vendors become more competitive. Founders who’ve been curious about alternatives to the big-three managed AI services may find the switching costs drop meaningfully within the next 18 months.

    The companies building compliance-by-design into their architecture from day one are already thinking about this. Modularity and regulatory readiness are increasingly the same thing. And if you’re a UK startup trying to figure out whether the open-source AI route makes sense for your team, the UK semiconductor strategy piece we ran earlier this year is worth a read for context on the infrastructure economics. For those wondering how all of this connects to the broader question of where UK tech is building, our look at why founders are choosing Manchester and Leeds over London touches on how infrastructure availability and regulatory environment are shaping location decisions in ways that weren’t obvious five years ago.

    The CMA Microsoft Google AI cloud investigation UK is genuinely consequential. Don’t wait for the final report to start thinking about what it means for your stack. By then, the decisions will already have been made.

    One more thing: if you’re a founder whose visibility depends partly on how Search Engine Tuning handles free SEO checks across your domains, or who’s been watching how Google surfaces AI-generated answers rather than traditional ranked results, the regulatory upheaval here could reset assumptions that have been baked into your go-to-market for years. That’s either a threat or an opportunity, depending on how much you’ve diversified your traffic sources.

    Frequently Asked Questions

    What is the CMA investigating about Microsoft and Google's AI cloud deals?

    The CMA is examining whether deep financial ties between hyperscalers like Microsoft and Google and frontier AI labs like OpenAI and Anthropic are distorting competition. Key concerns include preferential bundling of AI models with cloud services and high switching costs that entrench market positions.

    How could CMA remedies affect UK startup cloud costs?

    Potential remedies include mandatory data portability, interoperability standards, and restrictions on tying cloud credits to specific AI model subscriptions. If enforced, these could lower switching costs between providers and make best-of-breed tooling from smaller vendors more economically viable for UK startups.

    Is the CMA's AI investigation finished?

    As of mid-2026, the investigation is ongoing. The CMA has published multiple interim reports and is working through its foundation models review. Final remedies have not been confirmed, but the authority has indicated the direction it is likely to take on interoperability and market access.

  • Why UK B2B Founders Are Choosing Manchester and Leeds Over London for Their Company HQ

    Why UK B2B Founders Are Choosing Manchester and Leeds Over London for Their Company HQ

    Something has been quietly shifting in where UK B2B tech companies choose to plant their flag. Not a dramatic overnight exodus, but a measurable, structural drift that shows up clearly when you pull Companies House registration data by geography and cross-reference it with the kinds of businesses being formed. Manchester and Leeds are no longer just regional also-rans in the UK startup conversation. For a growing cohort of B2B tech founders, they’re the first choice, not the fallback.

    Modern office buildings in central Manchester representing the UK tech startup HQ Manchester Leeds vs London trend
    Photo by Max W on Pexels

    I’ve spoken to founders who’ve made this call deliberately, and their reasoning is consistent enough to be worth mapping properly. This isn’t about London being bad. It’s about the specific maths of running a B2B software business, where your cost base, your talent pipeline, and your customer relationships all interact in ways that make the northern cities increasingly rational choices. The question worth asking is: what changed, and is it permanent?

    What the Companies House data actually shows

    According to ONS business demography figures, the proportion of new enterprise registrations occurring outside London has been rising steadily since 2020. More specifically, the Leeds City Region and Greater Manchester both recorded above-average growth in professional and technical services registrations between 2022 and 2024, the most recent full-year data available. That category includes the SaaS, data infrastructure, and B2B platform businesses that define the current generation of UK tech.

    Companies House records bear this out at a more granular level. Search for recently incorporated limited companies in the SIC codes associated with software development, data processing, and IT consultancy, and filter for registered offices in M1 to M4 or LS1 to LS11 postcodes, and the volume is striking. This isn’t just one-person consultancies registering a convenience address. Many of these are seed-funded businesses with real headcount, genuine revenue ambitions, and institutional backing.

    The office cost argument is real but it’s not the whole story

    The obvious starting point is cost. Grade A office space in central Manchester runs at roughly £35 to £40 per square foot per year. In the City of London or Shoreditch, comparable space sits at £65 to £85. For a 20-person B2B tech company that wants a proper office rather than hot-desks in a WeWork, that difference compounds fast. But I’d argue founders who’ve relocated or incorporated in the North aren’t primarily driven by rent savings. The rent saving is the bonus, not the thesis.

    The real driver is the talent market. Manchester and Leeds have both developed genuinely deep technical talent pools over the past decade, partly because local universities (Manchester, Leeds, Sheffield, York) have strong computer science and data science departments, and partly because enough companies have now set up there that engineers have career optionality without moving south. When engineers have optionality, they stop treating northern roles as stepping stones. That changes the hiring dynamic entirely.

    This connects to something I’ve watched play out with salary benchmarking in the AI era. London salaries for senior engineers have been inflated by Big Tech presence and a decade of VC-funded bidding wars. Manchester and Leeds haven’t seen the same inflation. A principal engineer in Manchester might be on £80,000 to £95,000 where the same role in London commands £110,000 to £130,000. For a B2B SaaS company that needs to keep burn low through to Series A, that differential is material.

    What B2B specifically means for this calculation

    Consumer tech companies benefit from being in London partly because the press, the influencer ecosystem, and the consumer attention are all concentrated there. B2B is different. Your customers are procurement leads, CTOs, and operations directors sitting in offices across the country. A Manchester or Leeds address is not a credibility handicap in a procurement conversation with a Yorkshire manufacturing firm, a Birmingham logistics company, or a Scottish NHS trust. If anything, it can be an advantage, a signal that you understand the real commercial landscape outside the M25.

    Several of the founders I’ve spoken to made the point that their actual sales process happens on video calls, at trade shows in Birmingham or Manchester itself, and through referrals. The geography of closing enterprise software deals in the UK is not London-centric in the way it was a decade ago. The pandemic accelerated that, and it hasn’t reversed.

    Investor presence has caught up, though the gap hasn’t fully closed

    The honest caveat is that investor geography still skews south. The majority of UK venture capital by value is deployed from London-based funds. But the picture is more nuanced than that headline suggests. Firms like Praetura Ventures in Manchester, Mercia Asset Management with its Northern coverage, and the British Business Bank’s regional funds have all become more active. The North West and Yorkshire combined attracted over £500 million in venture investment in 2023, according to Beauhurst’s regional data, a number that would have seemed implausible five years earlier.

    Founders raising seed or pre-seed rounds increasingly tell me that their lead investor didn’t care about HQ location at all, especially if the founding team had London-adjacent credentials or could demonstrate a remote-friendly culture. Series A and beyond gets more complicated, but by that stage a company operating profitably out of Leeds or Manchester has something more compelling than a postcode to put in front of a London fund.

    Quality of life as a legitimate business variable

    I’ll be direct about something that gets talked around in polite business coverage: quality of life affects founder retention and co-founder relationships in ways that show up in company outcomes. A first-time founder burning through savings whilst paying London rent, commuting on the Jubilee line, and trying to recruit engineers is under a specific kind of pressure that compounds every decision. The same person running a lean operation in a flat in Chorlton or Headingley, cycling to the office, and buying a round of pints for the team on a Friday without wincing, is making decisions from a different baseline.

    This is not a soft argument. Founder mental state is a hard variable in early-stage company survival. The data on startup failure rates in the first three years is grim enough without adding avoidable financial pressure to the stack.

    The structural shift is also happening in adjacent professional services. The rise of UK legal tech has produced specialist startup law firms with genuine Northern presence, making incorporation and early-stage legal work easier to handle locally. The ecosystem services that used to require a trip to EC1 are increasingly available without it.

    This trend is about more than geography

    The question I keep returning to is whether this is a cyclical blip tied to post-pandemic remote working sentiment, or a structural change in where UK tech builds its foundations. My reading of the data is that it’s structural, driven by compounding effects: talent pools that are now self-sustaining, investor networks that have genuinely developed, and a generation of founders who grew up outside London and don’t carry the assumption that the capital is the only valid place to build something serious.

    For founders still weighing the decision, the honest answer is that neither Manchester nor Leeds is right for every B2B business. If your customers are exclusively London financial services firms and your entire leadership network is in Soho, the calculus changes. But if you’re building infrastructure, logistics software, HR tech, procurement tooling, or any of the other categories where your customers are distributed across the UK, the argument for incorporating in the North is now genuinely strong, and the friction of doing so has largely disappeared.

    The UK tech startup HQ Manchester Leeds vs London debate used to be about aspiration versus pragmatism. Increasingly, for B2B founders who’ve run the numbers, it’s just the rational call. And there’s something worth noting in the fact that the founders making it aren’t doing so reluctantly.

    Frequently Asked Questions

    Is it harder to raise VC funding if my startup is based in Manchester or Leeds rather than London?

    It can be slightly harder at Series A and beyond, where most large UK funds are London-based, but the gap has narrowed significantly. Seed-stage funding is now genuinely accessible from Northern-focused investors like Praetura Ventures and Mercia, and many London funds will back strong teams regardless of postcode.

    How do I find technical talent for a B2B tech startup in Manchester or Leeds?

    Both cities have deep pipelines from universities including Manchester, Leeds, and Sheffield, as well as established tech communities built around companies like AutoTrader, Sky Betting and Gaming, and Moneysupermarket. Hiring at senior level is competitive but salaries are materially lower than London equivalents, which helps extend runway.

    What are the actual cost differences between running a tech company in Manchester versus London?

    Grade A office space in central Manchester costs roughly £35 to £40 per square foot annually, compared to £65 to £85 in central London. Senior engineering salaries in Manchester typically run £25,000 to £35,000 lower per head than London equivalents, which compounds significantly across a team of 20 or more.

The Latest