Hardware-native AI: the alarm that sees

This is a position paper rather than a reading of somebody else's work. It is an argument we have been making internally for a long time, written down properly for the first time.

The next operating system layer gets built into hardware, not shipped as an application on top of it.

Home security is the clearest worked example, so the argument runs through it. An alarm today is a deterrent. It detects motion, it makes a noise, and it is right about what caused the motion roughly as often as a cat is a burglar. Everything it knows, it knows through a passive sensor, and everything it does, it does the same way every time.

A camera that understands what it is looking at is not a better alarm. It is a different category of device, because for the first time the thing at the edge can form a description, weigh it and choose a response.

The rest of this note is about the part that is actually hard, which is not the vision model. It is deciding how far up the response ladder a device is allowed to go without a person, and that is a design question with legal edges.

1. Latency is what forces this into the hardware

Start with the constraint that settles the architecture, because it is the one people argue about last and should argue about first.

Somebody walks up a drive. The useful window in which a response still means anything is a handful of seconds. Not because of a benchmark, but because that is how long it takes to reach a door.

A round trip to a large remote model does not reliably fit inside that window, and it is not only the model's thinking time. It is the upload of frames over a domestic connection that is having a bad evening, a service that is briefly rate limiting, a reconnect after the router did something. A correct answer that arrives after the event is worth nothing, and unlike a chat application there is no option to wait politely.

This is the latency axis from AI implementation is an architecture decision applied to a physical product. Somebody is waiting, so the model has to be fast and narrow, and code has to own the loop around it.

So the split is not cloud or local. It is fast loop local, slow loop remote:

• Local, in milliseconds: is anything happening, is it a person, what are they doing, does this warrant interrupting somebody.
• Remote, whenever: summarising the week, learning that the postman comes at eleven, improving the model, keeping the long archive.

Nobody is waiting on the second list, so it can go anywhere. Everything on the first list has to be on the box. That is the whole case for hardware-native, and it is a stronger one than privacy, which tends to be the argument these products lead with.

2. The response ladder

Here is the framing we would put at the centre of this. A device that perceives something has a ladder of possible responses, and they are not equivalent.

The first three are cheap when wrong. The last two are not, and the difference is not one of degree.

That table is the actual product decision. Almost everything being sold as an intelligent camera today operates at rung one and calls it rung four in the marketing. The engineering question worth answering is where the unattended ceiling sits, and our position is that it sits at three.

This is the same structure we found reading OpenAI's dots, where an agent left running while nobody is watching is restricted to reading, and every action that changes something needs a grant. A camera unattended at three in the morning is exactly that situation with a physical world attached.

3. Why the ceiling is not rung four

The arithmetic here is unforgiving and it is why we would not automate summoning.

Take a household with fifty perception events a day. Deliveries, the family, neighbours, foxes, a cyclist turning in the drive. Suppose the classifier is right 99 percent of the time, which would be a genuinely excellent system.

That is one wrong answer every two days. Say the wrong answer is a false alarm in one in ten cases. You are calling the police on an innocent person roughly twice a month.

The person who pays for that is not the homeowner. It is a courier, a neighbour's teenager cutting through, a relative arriving unannounced. Getting the police called on you is a real harm, and it is distributed to people who never agreed to the system.

Raise the accuracy to 99.9 percent and you still have an incident every few months, in a category where a handful of incidents is a news story and a regulator's letter.

So the design answer is not a better model. It is a human in the loop at rung four, every time, with the device doing the work that makes the human fast: a precise description, a clip cued to the moment, and a one-tap escalation. The device should make a person confident in four seconds. It should not replace them.

That is the same conclusion, arrived at from a different direction, as the approval lanes in governed autonomy and the reserved set of never delegable actions in the GPT-6 Astra system card.

4. Where we would push back on our own idea

The version of this idea we have argued for in the past included the device triggering defensive measures inside the house. We no longer think that should be built, and it is worth being explicit about why rather than quietly dropping it.

A use-of-force decision cannot be delegated to a classifier. In the United Kingdom, and in most comparable jurisdictions, force against a person has to be reasonable in the circumstances as the person using it believed them to be. That test assumes a person doing the believing. An automated measure that acts on somebody has no defensible answer to the question of who decided, and "the model was 97 percent confident" is not one.

There is a narrow and boring exception that is genuinely fine: acting on your own property in ways that were already yours to do. Locking a door that locks anyway. Turning on lights. Closing a gate that closes on a timer. The distinction is whether the action operates on the building or on a person. Locking a door is the former even though a person is affected by it; anything designed to deter, obstruct or harm somebody is the latter.

So the honest form of the original idea keeps the perception, keeps the speaking, keeps the instant notification, and stops before the part that was the most exciting to imagine.

5. The part that is genuinely new and under-built

Rung three deserves more attention than it gets, because it is the rung nobody has really built and it is entirely safe.

A device that can say something appropriate, out loud, in the moment. Not a recorded "you are being recorded" klaxon, but a system that can tell a courier where to leave a parcel because it recognised the uniform and knows the household's standing instruction. That can tell somebody at the door at eleven at night that nobody is available and the occupants have been notified. That can answer a question.

And the inward-facing version, which we think is the strongest idea in the original argument: the device tells the person inside what it has seen. Not an alert. A sentence. Somebody is at the side gate, they have been there ninety seconds, they are carrying a bag, here is the view.

That is a genuinely new capability, it is reversible, it makes the human better at the decision rather than replacing them, and no regulator has a problem with it.

6. What it costs you to build this properly

Four requirements that follow from the above, none of them optional.

1. On-device inference for the fast loop. If the perception decision needs the internet, the product does not work on the evening it matters.
2. A reserved set the configuration cannot reach. Summoning and any physical response sit outside what any rule, setting or future update can automate. Build that as a property of the system, not a default.
3. An evidence trail by construction. Every decision keeps what it saw, what it concluded, what it did and what threshold applied. You will need it for a complaint, an insurance claim or a regulator, and you cannot reconstruct it afterwards. This is the same argument as when the verifier moves inside the model: an internalised check leaves no record, so the record has to be produced around it.
4. Regulatory design up front. A camera that identifies individuals engages data protection duties immediately, and the EU AI Act treats some biometric identification as prohibited or high risk. We set out the shape of those obligations in engineering for the EU AI Act. A device that both identifies a person and acts on that identification is in the most scrutinised category there is.

7. Why this generalises beyond alarms

The alarm is a worked example, not the point. The pattern repeats wherever a device perceives something and could respond:

• A till that understands what is in the basket rather than what was scanned.
• A vehicle that describes what it is about to do and why.
• A machine on a line that explains the fault instead of flashing a code.
• A door entry system that holds a conversation.

In each case the same three questions decide the architecture. What is the latency budget, which settles where the model runs. Which rung of the ladder is reachable unattended, which settles the safety design. What evidence survives the event, which settles whether you can defend the decision later.

We think that is what the next decade of this looks like: not a general assistant living in a cloud and reaching into devices, but capable narrow intelligence at the edge, with code owning the loop and a person holding the irreversible actions. Which is, unsurprisingly, the same architecture we argue for in software in TypeSafe's System One.

8. What would change our mind

If on-device models get good enough that rung four accuracy genuinely reaches the level of a trained human observer, the argument for a human gate becomes an argument about liability rather than capability, and liability arguments move.

If a jurisdiction builds a legal framework for automated summoning, with an accountable party and a defined standard, the ceiling could move to four in that jurisdiction. Nobody has.

If the false positive maths turns out to be wrong in practice, because real household event rates are far lower than our estimate or because ambiguous cases cluster in ways that are easy to abstain on, the arithmetic in section three gets better. We would want to see that measured on real installations rather than assumed.

We have not built the device described here. This is an architectural argument, and the numbers in section three are illustrative estimates from plausible event rates rather than measurements. If you are building something at this intersection and the arithmetic looks different in the field, we would genuinely like to know.

If you are putting perception and action into a product and want the ladder and the gate designed before the capability, talk to us, or see how we build systems for businesses.

9. Sources

This is a position paper: the argument is ours and should be argued with. These are the primary sources behind the parts of it that are not opinion, which is mostly the claim that the models small enough to sit on the device now exist.

1. Howard et al, MobileNets, 2017, the line of work that made vision on a constrained device practical at all.
2. Google, Gemma 3n, a current example of a multimodal model built to run on a phone-class device rather than in a data centre.
3. NVIDIA, the Jetson modules, the accelerator class the fourth rung of the response ladder assumes.
4. Hu et al, LoRA: Low-Rank Adaptation of Large Language Models, 2021, on why tuning a model for one narrow job stopped being expensive.
5. Our own governed autonomy, which is where the approval lanes in section 2 come from, and our own a chain of events beats one big model, the companion position paper.

This note sits in our Engineering track, alongside the agentic, governance and system design threads. The full library is at Research.