The Electrician Is Safe. The Work Around Him Is Not.

What AI labour-market data misses about construction, and why the next wave of automation starts in the back office.

The False Comfort

Electricians are safe.

That is the reassuring conclusion you could take from Anthropic’s latest labour-market research if you only read the chart once.

Near-zero observed AI exposure. Healthy projected employment growth. Physical work. Site judgement. Tools, materials, access, risk, experience. The person wiring the distribution board is not about to be replaced by a chatbot.

And that is true.

But construction work does not end at the distribution board.

That same board has to be designed, priced, installed, tested, certified, photographed, included in an O&M, reconciled against a drawing, claimed for in a payment application, and handed over to someone who may never meet the electrician who installed it.

The board is physical.

The work around it is mostly information.

That is the gap.

Not the trade itself. The work around the trade.

One Distribution Board

Take one distribution board on one commercial project.

Before anyone prices it properly, there is design intent. A consultant’s drawing. A specification. A load schedule. A riser diagram. A board reference. An earthing arrangement. A note that looks harmless until you understand what it means on site.

Someone has to design it, validate it, or turn that intent into something buildable. Cable sizes. Protective device selection. Zs values. Voltage drop. Discrimination. Load assumptions. RCD requirements. Surge protection. Fire-stopping interfaces. Space on the wall. Whether the consultant’s intent actually works when it meets site reality.

Then someone has to price that design. The estimator reads the drawings, checks the specification, works out the containment, cable, labour, prelims, margin, exclusions, and risk. They may do that from a tender pack that arrived as PDFs, schedules, emails, amendments, and consultant notes. If the design is incomplete, they price the gap, qualify the gap, or carry the risk.

Then someone installs it. That part is stubbornly physical. A person on site still has to handle the kit, route the cables, terminate correctly, test properly, make judgement calls, and deal with the mess that never appears on the drawing.

Then the paperwork begins.

The test results have to be captured. The certificate has to be completed. The schedule has to match the installation. Observations have to be coded properly. The remedial cost may have to be estimated. The O&M pack needs the board details, manufacturer data, schedules, as-fitted information, maintenance notes, and certification evidence.

Commercially, the QS needs to know whether that board is in the valuation. If it changed, they need the variation. If the device schedule changed, someone needs the evidence. If the consultant issued a late drawing, someone needs to know which revision was priced, which was installed, and which was certified.

The document controller needs to make sure the right drawing, right certificate, right O&M extract, right transmittal, and right revision end up in the main contractor’s CDE.

The project manager needs to report progress.

The client eventually needs handover.

One board. Dozens of information events.

The electrician is safe because the installation is physical, contextual, and skilled.

The back-office work around that installation is exposed because it is repeatable, structured, rules-led, and often duplicated across systems.

What Anthropic Measured

In March 2026, Anthropic published one of the more useful pieces of labour-market research on AI so far. The point of the research was not to make dramatic predictions about mass unemployment. It was more careful than that.

Anthropic introduced a measure called observed exposure. In plain English, that means they looked at two things at once:

1. What AI could theoretically help with.
2. What people are actually using AI for in work.

That distinction matters.

There is a large difference between “the model can technically do this task” and “businesses are actually using it to do this task in production.” Anyone who has worked in construction knows why. Capability is not adoption. Adoption requires trust, workflow, evidence, permissions, insurance, habit change, and someone willing to take responsibility when the output matters.

Anthropic’s research makes that gap visible.

Computer and mathematical occupations show high observed coverage because people are already using AI heavily for coding and adjacent tasks. By contrast, many physical and site-based occupations show low observed exposure. That is why electricians look safe on the chart.

But the chart measures occupations. Construction companies are not occupations. They are systems.

An electrical contractor is not just electricians.

It is estimating, design, project management, commercial management, document control, certification, procurement, finance, O&Ms, RAMS, site reporting, client communication, and handover.

The occupation-level view is useful. It is also too blunt.

What The Data Misses

The problem with looking at “electricians” as one category is that it hides the business around the electrician.

The person installing the cable and the person pricing the cable are not exposed in the same way.

The person testing a circuit and the person writing the certificate are not exposed in the same way.

The QS negotiating a final account and the QS assembling an interim valuation are not exposed in the same way.

The project manager holding a client relationship through a difficult job and the project manager writing a weekly progress report are not exposed in the same way.

Same industry. Same project. Sometimes even the same person.

Completely different automation profile.

That is why broad AI commentary often feels wrong when it hits construction. It either says the industry will be transformed overnight, which ignores the physical and relational nature of the work, or it says construction is protected, which ignores the huge amount of office work required to make construction happen.

Both are incomplete.

The truth sits in the split.

The tools are safer than the admin.

The relationship is safer than the spreadsheet.

The judgement is safer than the register.

The site decision is safer than the document assembly.

The Work Around The Work

Construction businesses run on a layer of work that rarely gets named properly.

It is not quite administration. That makes it sound too small.

It is not quite project management. That makes it sound too senior.

It is not quite compliance. That makes it sound too narrow.

It is the work around the work.

Pricing the job before it exists.

Turning drawings into quantities.

Turning quantities into estimates.

Turning estimates into procurement.

Turning installation into test results.

Turning test results into certificates.

Turning certificates into handover evidence.

Turning changes into variations.

Turning progress into payment.

Turning site reality into records the main contractor, consultant, client, insurer, and future maintainer can accept.

This is where the friction lives.

And it is where a large part of construction’s AI opportunity sits.

Not because every task is easy. It is not.

But because much of this work has a recognisable pattern:

• a document arrives
• information is extracted
• information is checked against rules
• information is moved into another format
• someone approves it
• it is issued, logged, chased, revised, archived, or claimed against

That is not a job title.

That is a workflow.

And workflows can be automated, augmented, measured, and improved.

Why This Matters To Electrical Contractors

Electrical contracting is a good place to start because the work is dense with structured information.

Circuits have numbers. Protective devices have ratings. Cable sizes have rules. Zs values have limits. RCD disconnection times can be checked. Observations can be coded. Certificates have fields. Distribution boards have schedules. O&M manuals have repeatable sections. Estimates have labour constants, material lines, prelims, margin, exclusions, and scope notes.

It is not simple. But it is structured.

That is the important distinction.

Structured does not mean easy. Structured means the work can be represented in a model.

Once the work can be represented in a model, it can start to feed other parts of the business.

The circuit in the design should become the circuit in the estimate.

The circuit in the estimate should still be recognisable when it becomes the circuit in the certificate.

The protective device selected at design stage should be checked against the Zs value at certification stage.

The board added to the estimate should appear in the O&M.

The installed item should be available to the QS when claiming.

The same object should not be typed five times by five different people.

That is the Prekon thesis in practical terms.

Add the object once. Let the system carry it forward.

Three Examples

Start with the electrician.

The physical installation stays human. The testing stays skilled. The judgement on site stays human. But the write-up around the work can change dramatically. Test results should populate certificates. Observations should connect to remedial cost. Device selections should validate against rules. The certificate should not be a dead form typed at the end of the job. It should be the visible output of the project data that already exists.

Now take the QS.

The final account conversation is human. The relationship with the main contractor’s QS is human. Knowing when to push and when to preserve goodwill is human. But assembling an interim valuation from measured work, variations, daywork sheets, materials, and progress evidence is a different kind of task. Much of it is structured. Much of it is repeated. Much of it is currently done in spreadsheets because the project data is not connected.

Then take the document controller.

The exception handling is human. Project protocol judgement is human. Knowing who to phone when something is stuck still matters. But filing, version control, drawing registers, transmittals, status trackers, document issue logs, and CDE uploads are mostly data movement. The main contractor chooses the platform. The subcontractor provides the human adapter.

That human adapter layer is where automation starts.

The Relationship Ceiling

This is where most AI arguments about construction go wrong.

They measure tasks and forget trust.

Construction does not run on tasks alone. It runs on relationships, memory, reputation, pressure, judgement, and the quiet knowledge of how people behave when a job gets difficult.

A QS who has worked with the same main contractor’s commercial team for ten years has context no model can scrape from a document folder.

A project manager who can keep a client calm through a bad week is doing something no dashboard can do.

A site manager who knows which subcontractor foreman will actually hit Friday’s promise is reading more than a programme.

That layer does not disappear because an agent can fill in a form.

If anything, it becomes more important.

The mistake is thinking automation reduces the value of people. In construction, the better argument is the opposite.

Automating the repeatable task load gives people more time for the part that cannot be automated.

The QS who is not spending Sunday night assembling valuation backup can spend more time on the final account strategy.

The PM who is not writing progress reports at 10pm can spend more time with the client.

The document controller who is not manually renaming, filing, and chasing revisions can handle exceptions, protocols, and communication.

The agent does the repeatable work.

The human keeps control.

How We Are Going To Measure It

The lazy version of this argument would be to say “AI will automate 80% of construction admin” and leave it there.

That is not good enough.

For this series, the method is going to be more concrete.

For each role, we will start with real UK construction job descriptions. We will extract the advertised responsibilities and group them into task types:

• data capture
• data movement
• document generation
• calculation
• classification
• compliance checking
• status tracking
• approval and chasing
• reporting
• judgement
• negotiation
• relationship management
• site and context interpretation

Then we will score those task groups against practical constraints:

• is the input structured?
• are the rules clear?
• is the output deterministic?
• is API or system access available?
• how often does the task hit exceptions?
• how much human judgement is required?
• how much relationship context is required?
• what is the compliance or liability risk?
• how much site context is needed?

Then we will weight the tasks by time burden.

That last bit matters. A task that happens once a month should not carry the same weight as a task that happens every morning.

The result will not be a universal truth. Every contractor is different. Every project has its own protocols. Every main contractor has its own way of making simple things complicated.

But it will give us a defensible working model:

• what can be automated now
• what can be automated with integration access
• what needs human approval
• what should remain human-led
• how much time and cost sits in each layer

And then we will build the workflows.

Not just write about them.

Build them.

From Essay To Proof

This is the part that matters.

The series is not going to stop at commentary.

Each role will become a lab.

We will take the work described in real job openings and build isolated workflows for it. Some will be simple automations. Some will be tool-using agents. Some will sit behind human approval checkpoints. The point is not to pretend one implementation route is magic. The point is to find the shape of the work.

For a document controller, that might mean:

• watch for a new drawing revision
• classify it
• extract the revision, title, date, discipline, and package
• update a register
• identify who needs to know
• draft the notification
• prepare a transmittal
• ask for human approval before issue
• log the outcome

For an estimator, it might mean:

• ingest a tender pack
• summarise scope
• flag missing information
• extract measurable items where possible
• map them to labour and material datasets
• produce a first-pass pricing structure
• keep margin judgement human

For certification, it might mean:

• take circuit data that already exists
• populate the certificate
• validate protective devices and Zs
• connect observations to remedial cost
• produce a handover-ready output

Some workflows will be easy. Some will fail. Some will need human approval at every step. Some will reveal that the real blocker is not AI capability but access to the right data.

That is useful too.

This is how construction automation should be discussed: task by task, role by role, with proof.

The Prekon Position

Prekon is not being built as a chatbot for construction.

It is being built as an operating layer for construction work.

The starting point is electrical contracting because that is the world I know. Thirty years in the trade. Thousands of certificates. Jobs won and lost on estimates. Design intent that works on paper and fails on site. Handover packs assembled after everyone is already exhausted. The same data typed again and again because the tools do not talk to each other.

That is the starting point.

But the pattern is bigger than electrical.

Document control crosses every trade.

O&Ms cross every trade.

RAMS cross every trade.

Payment applications, progress reporting, procurement tracking, submittals, RFIs, drawing revisions, compliance evidence, closeout packs - they are construction problems, not only electrical problems.

Electrical contracting gives Prekon the wedge.

Construction operations is the category.

What Comes Next

This article is the start of the series.

The first job is to name the gap: the difference between the physical work that remains human and the repeatable operational layer around it.

The next job is to measure it properly.

Then we build.

The first role lab will be the document controller, because it is the cleanest example of the human adapter problem. The main contractor chooses the CDE. The subcontractor pays someone to bridge the gap. Drawings, registers, revisions, transmittals, uploads, downloads, distribution, status tracking. All necessary. Much of it repeatable.

After that, we move through the estimator, the designer, the QS, the project manager, and the certificate workflow already being built inside Prekon.

For each one:

• what the job description says
• what the work really is
• what can be automated
• what should stay human
• what the workflow costs
• what the workflow saves
• what we built
• what failed
• what becomes Prekon-native

The electrician is safe.

The paperwork around him is not.

And that is where the work starts.

Richard is the founder of Prekon, building the operating layer for construction operations, starting with UK electrical contractors. Thirty years in the trade. Building in public at prekon.co.uk.