Privacy & GDPR by Design at the Edge

Most AI projects fail not on model quality but on one question. Where do the data go? A sensor reading, a machine log, an occupancy pattern in a building. The moment those data travel to a cloud for analysis, a long chain begins. Data processing agreements, third-country transfers, purpose limitation. Privacy then becomes downstream contract work. With an Edge Agent it is the other way around. Data sovereignty is not a policy layered on top, it is a property of the architecture. The AI runs where the data are created.

Data Sovereignty as an Architecture Property

An agent on the machine processes its inputs locally. The graph describing the agent runs as a single binary on the device, from a single-board computer to an industrial PC. The intelligence sits in one node of that graph, and that node can be a small language model running locally next to the engine, via a local, OpenAI-compatible inference server. For most industrial tasks, an on-device model with one to three billion parameters is enough.

The decisive point is that if processing happens locally, there is no transfer to a third-country cloud that would even need legal cover. Data that never leave the device create no processing contract with a US provider. That is the difference between “we have handled privacy” and “there is nothing to handle, because nothing leaves the device”.

GDPR Principles Become Technically Achievable

The GDPR demands data minimization and purpose limitation. On paper these are principles. In a cloud pipeline they are hard to enforce, because raw data land centrally and become available there for anything. Local on-device AI inverts that.

• Data minimization. The agent evaluates the raw value on site and passes on only the result, for example a classification or a parameter. The raw signal stays on the device.
• Purpose limitation. The workflow graph is the program. It is finite, inspectable, and describes deterministically which node touches which data. What the agent does is not hidden in a black box but traceable as a graph.
• Durable memory lives as a local file on the device. A knowledge base with semantic search runs at the edge, instead of sending every context to an external service.

The honest caveat matters. “Local” answers where the data are processed, not automatically every security question. The moment a cloud LLM, a web search, or an external retriever enters the graph, outbound connections appear. An Edge Agent runs fully sealed off only with a local model. That choice is made deliberately per node, not implicitly.

Open-Source Core Instead of a Black Box

Privacy you cannot inspect is a promise, not proof. The core (engine, LLM proxy, and the visual builder) is open source and fully usable without an account. You can read the code, self-host the system, and trace what actually happens. There is no vendor lock-in chaining operation to a foreign cloud. The backend is a convenience and management layer for fleets, not mandatory. Whoever wants maximum control runs the engine standalone and offline-by-default.

Security Architecture That Matches the Data Handling

Local processing is the foundation, but it does not stand alone. An Edge Agent’s security architecture rests on three real properties, namely local execution, container isolation, and signed image distribution. Updates arrive as signed images, and the deploy lifecycle covers the bootstrap bundle, preflight, heartbeat, and status. The bounded graph itself is a security feature. Because it is finite and auditable, there is no open agent loop firing actions uncontrolled.

This is where CRA readiness belongs, soberly stated. This architecture is designed for the EU Cyber Resilience Act through local execution, container isolation, signed distribution, and planned SBOM and signing steps. CRA readiness here is an architecture property, not a certificate. We deliberately do not say “CRA-compliant” or “CRA-certified”, nor “audited”. What we do say is that the foundation is built so the CRA’s requirements become achievable, instead of bolted on afterwards.

A Scenario in a Building With Sensitive Areas

This is how an Edge Agent could solve a problem. In a residential or care-adjacent building, the building services should react to occupancy. Ventilation, heating, and lighting should adapt to actual use, without occupants’ movement and presence data going to an external service. Those very data deserve strong protection.

An agent on the machine evaluates the sensor signals locally. An occupancy signal arrives via an MQTT trigger, the agent classifies the pattern with an on-device model, and writes only the result, for example “area active”, into the controller. The raw value never leaves the device. No cloud call exports an occupancy profile, so there is no third-country transfer.

How It Works at the Edge

Technically, the agent sits next to the control loop, never inside it. The pattern is “agent-as-a-tool”. The deterministic controller keeps running uninterrupted, the agent only writes parameters, buffered. Concretely, in the scenario.

• Trigger. An mqtt-message trigger reacts to an incoming occupancy topic, and a threshold trigger with deadband can damp noise.
• Processing. The graph feeds the raw value to a node with a local SLM (one to three billion parameters) via the local inference server. If a rule suffices, the intelligence cascade catches it earlier, that is rules before classical ML before on-device SLM. Frontier cloud is the exception, not the default.
• Action. The result goes via an MQTT publish or GPIO node to the building controller. Real Linux drivers, a buffered parameter, no intervention in the real-time loop.
• Distribution. The same binary runs on the target hardware without a rewrite, and updates arrive as a signed image.

Data needed for a decision are processed where they are created, and only the result moves on. An honest limitation remains. Even a fully local device needs a physical interface to the plant. “Local” solves the data-handling question, not the physical-integration one.

Key Takeaways

• For an Edge Agent, data sovereignty is an architecture property. The AI runs where the data are created, instead of shipping them to a cloud.
• Local processing makes GDPR data minimization and purpose limitation technically achievable and avoids third-country transfers, because nothing leaves the device.
• The open-source core is usable without an account and self-hostable, inspectable instead of a black box, with no vendor lock-in.
• The security architecture (local execution, container isolation, signed images, bounded graph) is designed for the EU Cyber Resilience Act, with CRA readiness as an architecture property, not a certificate.
• “Local” answers the where of data processing. An Edge Agent runs fully sealed off only with a local model, and physical integration remains a separate question.