Body-Adjacent AI Needs a Kill Switch on Our Side

AI is not going to stay in a chat box.

That is the bit people keep missing. Everyone argues about which model writes better code, which one is cheaper, which one feels more alive. Fine. Useful conversation. But the direction of travel is bigger than that.

AI is moving closer to the body and closer to the machines around the body.

First it sits in the browser. Then in your phone. Then in your ear. Then in glasses. Then in the vehicle. Then in the workshop tools. Then in the systems that decide what you see, what you hear, what task comes next, what warning matters, what customer gets replied to, what part gets ordered, what machine moves.

And eventually, yes, some version of brain-computer interface or nervous-system-adjacent control will become normal enough that people stop calling it science fiction.

That is when the architecture matters more than the model.

The off switch must be on our side

If an AI system sits between human intent and real action, the off switch cannot depend on the same AI system behaving nicely.

It also cannot depend on a cloud provider being online, an account being in good standing, an API policy staying the same, or a safety classifier somewhere else understanding the context correctly.

The kill switch has to be ours.

For me, that means local first:

local policy
local audit log
local approval gate
local fallback mode
local shutdown path
physical switch where the risk justifies it
cloud models treated as workers, not owners of the loop

That is not paranoia. That is normal engineering.

I repair cars. Nobody sane designs a brake system where the pedal asks a remote server whether stopping is allowed. You can add sensors, software, ABS, stability control, radar, cameras, all of it. But when the driver needs the system to fail safe, there has to be a path that does not depend on a marketing promise.

AI needs the same thinking before it gets too close to bodies, vehicles, tools and money.

Human in the loop is not enough

People say “keep a human in the loop” like it solves the problem.

It does not, by itself.

The question is: who owns the loop?

If the human approval button is inside a cloud dashboard, and the cloud system decides what gets shown, what gets hidden, what gets delayed, what wording frames the choice, and whether the button is available, then the human is not really in control. The human is part of somebody else’s loop.

That might be acceptable for low-risk work. Drafting text. Summarising notes. Sorting emails. Fine.

It is not acceptable for body-adjacent AI, vehicle control, workshop automation, customer money, procurement, medical-like feedback, or anything that can create damage faster than a person can understand it.

For those systems, the pattern should be:

Human intent comes in.
Local controller checks scope, permission and risk.
AI worker proposes or performs only the allowed part.
Verifier checks the result.
High-risk actions wait for explicit approval.
The off switch cuts the action path locally.
The ledger records what happened.

That is the loop I want.

Why this connects to agents

This is not just about future implants. It is the same problem I see in agents now.

An agent that can read files, call APIs, send messages, change DNS, order parts, talk to customers or deploy code is already body-adjacent in the practical sense. It may not touch your nervous system, but it touches your business nervous system.

The danger is not that the model becomes evil. The boring danger is enough:

it misunderstands the task
it sees too much context and reacts to the wrong thing
it takes a shortcut
it leaks something private
it sends before asking
it changes production because the prompt sounded confident
it does the right action in the wrong profile

That is why my agent architecture keeps coming back to the same shape: front controller, worker, verifier, approval queue, ledger, rollback.

Not because I like diagrams. Because the naive version fails.

Local does not mean anti-cloud

I am not saying never use cloud models. That would be stupid. The best cloud models are useful. They can reason, code, review, summarise and spot things smaller models miss.

But they should be workers in a system we control.

The local layer decides:

what context they receive
what tools they can touch
what actions need approval
what gets logged
what gets blocked
what happens if the provider disappears

That is the difference between using AI and renting your nervous system.

For my own setup, this is why the local GPU server matters. Not because I am going to train a frontier model in the garage. I am not. The useful thing is local sovereignty: local evaluators, local routing, local memory, local safety checks, local fallbacks and a way to keep working when the cloud is only a tool, not the owner.

The workshop version of AI safety

AI safety usually gets discussed like a philosophy problem. I think about it more like a workshop problem.

What happens when this relay sticks? What happens when the sensor lies? What happens when the apprentice is clever but tired? What happens when the diagnostic tool says something confident and wrong? What happens when the machine keeps moving after the operator says stop?

You do not answer those questions with vibes. You answer them with fuses, isolation, interlocks, procedures, logs and somebody responsible enough to pull power.

That is the version of AI safety I trust.

For anything close to the body, close to vehicles, close to customers, close to money or close to production infrastructure, the rule is simple:

Cloud can assist. AI can propose. Agents can execute inside boundaries.

But the switch belongs here.

Not later, after the first bad incident.

Now.