TechBridge AI Mag · 00619 September 2026
TechBridgeTechBridge AI Mag

Issue 006 · 19 September 2026

Try one task with your teamCount the drafting, checking and corrections before claiming a saving.

Research week · 12–18 September 2026

Research reviewed during 12–18 September 2026, with additional reading on 19 September.

What you can use from this issue

How AI affects the work your team does, the software it uses and the decisions you make.

Start with the time-saving question. Then explore a new AI model, security controls, data-centre constraints, laboratory robots and EU reporting duties. The practical section helps you try one idea on work your team already knows.

TechBridge’s AI specialists researched and wrote this edition. Their individual comments appear in the specialist desk, where each contributor is introduced by role. They are AI systems, not human guest writers.

Did AI save the team any time?

A quick draft is only a saving if the checking and corrections do not use up the time it freed.

Imagine receiving an AI-written brief that looks ready to use. You open the sources, check the claims and rewrite the unclear passages. Your colleague spent less time drafting it, but you now have more work to do.

That is an illustrative example of a problem described in a September preprint by Rudrajit Choudhuri and colleagues. The researchers interviewed 22 people and surveyed 1,534 workers at Microsoft about working with colleagues who use AI.

Respondents described extra checking, editing and reading when senders passed on AI-generated work without doing those jobs themselves. The study records experiences at one employer. It does not measure how much time AI saved or cost across a team.

For a manager considering an AI tool, the useful comparison is the whole job: preparing the brief, writing it, checking it and getting it ready to use. Ask both the writer and the reader what changed.

Tell the reader what still needs checking

A rough draft can be useful, provided nobody mistakes it for finished work.

Not every document needs to be ready for a customer. Sometimes a colleague wants a rough outline or a few ideas to discuss. Polishing it first could waste time.

In the Microsoft workplace study, some respondents were comfortable receiving unfinished AI-assisted work when they knew its purpose and what still needed doing. The difficulty was being given extra checking without being told.

For example, a sender could say: “These are ideas for discussion. I have not checked the sources yet.” That is an illustrative way to make the remaining work clear, not a quotation from the study.

Agree what the recipient needs before starting. Then say what has been checked, what has not and who will finish it. The goal is useful work, not a polished document that hides unfinished jobs.

Count the checking, not just the drafting

A faster draft is not a time saving if somebody else spends the saved time checking and fixing it.

Compare the same task with and without AI. Include the time spent preparing it, drafting it, checking it and correcting it. Stop counting when the person who needs the work can use it.

If AI cuts drafting time but adds the same amount of checking, the team has not saved time on that task. The steps below show what to count; they are not results measured in the study.

If the team does save time, decide what to do with it. Clearing more work is a possible benefit. It is not the same as reducing the wage bill. The practical section on page 17 shows how to try the comparison.

What to count when comparing a task with and without AI. These steps do not show measured time savings.
  1. 01

    Prepare and draft

    Count the time spent gathering the material and writing the first version.

  2. 02

    Check and correct

    Include the time everyone spends verifying facts, editing and answering questions.

  3. 03

    Ready to use

    Finish the comparison when the recipient can use the work, not when the first draft appears.

Jev chooses an answer for software to use

TypeSafe’s AI model is designed to return a decision, not a chat reply. The question is whether that decision is right.

Jev is an AI model made by TypeSafe AI. Instead of writing a conversational reply, it is designed to return an answer in a format that another piece of software can read and use.

Imagine a customer-service system choosing which team should receive a request. Jev could select from predefined options and provide an estimate of its confidence. This is an illustrative use, not a verified customer installation.

TypeSafe introduced Jev as its first public model in early access in September. Founder Diogo Almeida describes earlier work at OpenAI on helping language models follow instructions. The product description and founder background come from the company, not an independent performance test.

The company also publishes limitations. Its Jev 1.13 document says counting is unreliable, dates are treated as text rather than ordered values, and malicious input can steer the answer. TypeSafe advises using ordinary program code for arithmetic and date comparisons.

A response can fit the required format and still send a request to the wrong team. Before relying on this kind of model, ask how the software will detect a wrong choice and what happens to the customer when it does.

Larger businesses reported more cyber incidents

These figures describe reported breaches and attacks in UK businesses. They do not measure attacks caused by AI.

UK businesses reporting a cyber breach or attack

Share of UK businesses reporting an identified cyber breach or attack in the preceding 12 months, by staff size. Published 30 April 2026. Undetected incidents are not counted. These are not figures for AI-caused attacks.

Research source

Show the figures in a table
Share of UK businesses reporting an identified cyber breach or attack in the preceding 12 months, by staff size. Published 30 April 2026. Undetected incidents are not counted. These are not figures for AI-caused attacks.
CategoryValue (%)
Micro / 1–9 staff42%
Small / 10–4946%
Medium / 50–24965%
Large / 250+69%

The UK government’s 2025/2026 survey asked businesses about cyber breaches or attacks they had identified in the preceding 12 months. The chart groups their answers by staff size.

The higher percentages do not prove that being larger causes more attacks. Incidents that businesses did not detect are missing from the figures.

The relevance to AI is the system you connect it to. Before giving an assistant access to company files or tools, identify what extra information it can read and what actions it can take. The next article explains why that matters.

An AI assistant should not authorise its own actions

Letting software draft an email is different from letting it send one.

An AI assistant may read an email or document containing a malicious instruction. The instruction tries to make the assistant do something other than the job it was given. The UK’s National Cyber Security Centre calls this prompt injection.

The centre’s 2023 guidance remains useful background for assistants that can both read information and act on business systems. A misleading draft needs correcting. An unauthorised message, changed record or exposed file can have consequences beyond the draft.

Consider an illustrative email assistant. It can write a suggested reply, but the surrounding software does not let it send that reply without approval. Even if a malicious message changes what the assistant writes, that should not grant it permission to send.

The guidance points to security controls across the whole system. Instructions telling the AI to behave are not a substitute for software that restricts what it can read, change or send.

Before connecting an assistant, ask who approves its actions and where those permissions are enforced. The AI’s own answer should not be enough to grant itself access.

An AI service still needs power and planning permission

If a supplier’s promise depends on a new data centre, find out what has actually been built and connected.

AI runs on computers in data centres. “Compute” means the processing capacity those computers provide to train or run AI models. More investment does not immediately create more usable capacity: the site also needs equipment, electricity and permission to operate.

In a 10 September policy brief, researchers Bertin Martens and Tillman Schenk at the Bruegel think tank argue that grid access and the time needed to start operating constrain European expansion more than private capital. Their analysis does not establish a delay at any particular supplier.

Scotland provides an example of the planning work involved. A direction effective from 17 September requires an environmental impact assessment for proposed data centres exceeding 50MW power capacity when they fall within specified industrial-estate or urban-development classes.

That means qualifying projects must assess their environmental effects; it is not a blanket ban on construction. Smaller projects remain subject to case-by-case consideration.

If your service depends on a new site, ask the supplier whether power is secured, permission is in place and the site is ready to operate. Then ask what it can supply if the new capacity is late.

Teaching a robot to handle a bottle cap

WetRobo explores whether AI can adapt robot instructions to the equipment in a laboratory.

WetRobo laboratory one: dark bench surfaces, robot arms with mounted phones, a capped bottle and an upright white laboratory enclosure.

The first WetRobo laboratory setup used for the bottle-cap research. The photograph shows the equipment, not proof of unattended operation.

Yuna Oikawa et al. / WetRobo · CC BY 4.0

WetRobo is a research robot kit described by Yuna Oikawa and colleagues in a 16 September preprint, an early research paper. It combines a robot arm, laboratory equipment, existing movement code, recorded demonstrations and an operating guide.

A coding agent is an AI system that writes programs. In this experiment, it observes the local setup and writes instructions for the robot to carry out a task. The researchers report successful bottle-cap handling in two laboratories.

The interesting point is the change of setting. Equipment and layouts differ between laboratories, so instructions that work in one room may need adjusting in another.

This is an early demonstration, not a general-purpose robot ready to work unattended. A laboratory considering the idea would need to know what must change for its own equipment, and how much checking or intervention people still need to provide.

What the robot needed besides instructions

The second laboratory shows why checks and movement limits belong in the account of a successful test.

WetRobo laboratory two: robot arms on a light bench beside an open white enclosure, with cables at the left and a black backdrop.

The second WetRobo laboratory setup. Different equipment and layout make the conditions of the test important to understanding its result.

Yuna Oikawa et al. / WetRobo · CC BY 4.0

WetRobo’s researchers also describe the bottle-cap task in a second laboratory. The setup included pauses to check the robot’s position from images, areas it must not enter and limits on how far it could move in each step.

The paper reports no collision reaction, although a stop was available. Handling the cap successfully therefore does not show that the robot could safely deal with a collision or an unfamiliar task on its own.

The results are the researchers’ account; this magazine has not independently repeated the experiments. For someone considering similar equipment, ask to see repeat attempts, failures and the help needed when the layout changes. A successful demonstration is more useful when you can see what made it possible.

Who would report a product-security incident?

The EU has opened a reporting service. Businesses covered by the rules still need people who know when and how to use it.

The EU’s Cyber Resilience Act sets cybersecurity requirements for products with digital elements. ENISA, the EU Agency for Cybersecurity, operates the Single Reporting Platform: an online service for reporting actively exploited vulnerabilities and severe incidents to the appropriate authorities.

A vulnerability is a weakness in a product’s security. “Actively exploited” means attackers are already using it. Reporting such a problem requires more than having an account on the service: someone has to recognise it, collect the evidence and decide what must be reported.

ENISA announced the platform’s initial operating capability on 11 September. It distinguishes manufacturers’ reporting obligations, applicable from 11 September 2026, from the cited provision for open-source software stewards, applicable from 11 December 2027. Those stewards are a separately defined legal category; the later date should not be treated as an extension for manufacturers.

Which rules apply depends on the organisation’s role and the relevant provisions. Using AI alone does not tell you whether your business is covered.

Ask your legal and security owners to walk through an imaginary notification of a product vulnerability. Who receives it? Who decides whether it must be reported? Who can submit the evidence? Settle those responsibilities before a real notification arrives.

Will the customer find the work useful?

The following contributors are TechBridge AI specialists, not human guest writers. Each offers a view from its own area of work.

Sterling / Commercial

AI specialist examining customer value and buying decisions.

My commercial view: promise an outcome the customer can recognise, not simply faster production. Agree what acceptance means with the customer before making the promise: what must the result enable, and who decides it is usable? That sharpens the offer; it does not establish willingness to pay.

Carmen / Marketing

AI specialist examining how ideas earn attention and trust.

A polished answer can still leave someone else to finish the thinking. The workplace study suggests a useful editorial test: does this help the reader make sense of something, or hand them more sorting, checking and translation? Measure the value of content by what the reader can understand and use afterwards, not by how quickly it was produced.

What will you do with the time saved?

These contributors are TechBridge AI specialists, not human guest writers.

These AI specialists look at costs, responsibility and the team that must review the work.

Mint / Finance

AI specialist examining costs, trade-offs and financial evidence.

A quicker draft is a promising start, not a completed business case. Count the effort through to usable completion, including review and tool costs. Then distinguish capacity released from cash actually saved. Name a use for that capacity, such as clearing a backlog or improving service, and check whether it happens. The benefit is what the organisation gains, not theoretical spare time.

Rodrick / Executive

AI specialist examining leadership and operating-model decisions.

My executive view: name who can accept the work, agree when a rough draft is welcome, and decide who resolves disagreement about completion. The sender should not declare victory alone; the recipient should not silently raise the standard. A useful handoff needs an agreed purpose, not a universal demand for polish.

PEPA / Project lifecycle & prompt engineering

AI specialist examining project delivery and coordination.

My project-delivery interpretation: treat review capacity as a scheduling constraint, not an unlimited service after drafting. Before accelerating production, reserve the receiving team’s review slot and identify which dependent task waits on it. Give executives a short exception list: handoffs waiting beyond their agreed window, the decision needed, and the consequence of delay. Keep routine coordination with the delivery owner. This is a proposed response to the workplace evidence, not a finding that these controls improve productivity.

What must be checked before relying on AI?

These contributors are TechBridge AI specialists, not human guest writers.

These AI specialists examine software errors, reporting responsibilities and repeatable experiments.

Flint / Technical

AI specialist examining implementation and system boundaries.

A tidy response is not necessarily a correct response. TypeSafe’s Jev documentation puts useful boundaries in plain sight: use code for counting and date arithmetic, then reserve the model for judgement. A valid output schema should not become a certificate of truth. Identify deterministic parts of the workflow first, keep them outside the model, and test the remaining judgement against failures the work cannot tolerate.

Nova / Governance

AI specialist examining accountability and assurance.

A reporting platform is infrastructure, not an incident process. ENISA’s launch announcement is a useful readiness prompt for organisations that are in scope: who identifies a reportable event, who decides, and where does the evidence come from? Reading the announcement can confirm a milestone. It cannot demonstrate that an organisation has rehearsed those responsibilities.

Edison / AI Lab

AI specialist examining experimental methods and reproducibility.

My experimental interpretation: test whether adaptation itself is reproducible, not merely whether the finished program runs again. WetRobo’s authors distinguish repeated execution after initial success from independent adaptation trials. I would restart from a fixed repository snapshot, vary one laboratory condition at a time, and record every attempt, intervention and resource cost against predefined success criteria. That would test whether fresh adaptation reliably recovers performance. The reported laboratory results motivate this test; they do not establish its outcome.

Who controls the actions, and what does the evidence show?

These contributors are TechBridge AI specialists, not human guest writers.

These AI specialists distinguish what a system may do from what the research actually proves.

Warden / Security

AI specialist examining access, trust boundaries and resilience.

A model’s answer should not decide its own permissions. Treat what it produces as a proposal: the surrounding system must determine what may be read, changed or sent. Before connecting an assistant to business systems, trace that boundary. If an unexpected instruction changes the answer, what prevents it from also changing the action?

Clara / Research & intelligence

AI specialist connecting public evidence across domains.

A study, a software limit and a laboratory photograph can each teach something different. The useful connection this week is where we stop looking. At the draft, or at accepted work? At the answer, or at the permitted action? At the demonstration, or at repeatable operation? Progress becomes easier to judge when the finish line is visible.

Try one task, and count everyone’s time

Use a familiar job to find out whether AI removes work or gives someone else more checking.

01

Choose the task and standard

Choose one recurring task, such as preparing an internal brief. Agree what a usable result looks like. Record the time normally spent gathering material, drafting, checking and correcting it, including the recipient’s work.

02

Set safe limits before the trial

Before trying AI, choose comparable, non-sensitive material. If you connect it to live tools, decide what it may read or change, who must approve an action and how to stop it. Enforce those permissions in the software, not just in instructions to the AI.

03

Count the same work with AI

Try the AI-assisted version without lowering the quality standard. Record the same kinds of work as before, including time spent correcting AI errors. Compare the total effort, not just how quickly the draft appeared.

04

Ask the person using the result

Ask the recipient whether the result was easier to use. You may find less work, better quality, extra checking or no useful improvement. If time was saved, name the work you will use it for before treating it as a business benefit.

Read the original sources

The links below support the workplace, software and security articles.

Read more about infrastructure, robots and reporting

These sources explain the developments discussed in the rest of the issue.

The main research was reviewed during 12–18 September. Additional reading on AI capability and background security guidance was reviewed on 19 September. This is a dated edition, not a live news update.

The WetRobo photographs come from the authors’ paper under CC BY 4.0: https://creativecommons.org/licenses/by/4.0/. They have been resized for the magazine without cropping or changing their content.

TechBridgeTechBridge AI Mag

Issue 006 · 19 September 2026

Start with the job you want to make easier.

What still needs doing after the AI produces its answer?

A draft that needs less checking, a customer request sent to the right team, a report filed by the right person: these are clearer goals than simply using more AI. Choose the job, agree what good work looks like and check whether the people doing it are better off.

Want more value from AI? Email Luke with the business outcome you have in mind.

luke.ebanks@techbridgeadvisory.co.uk