Trust is an architectural property⁠.

Trust is not built in an onboarding screen. I once helped build a system in which people record their dream memories — content as close to a person's inner life as hardly anything else. One conviction stayed with me from that work: people do not trust a product's promises. They trust the architecture behind it.

Trust shows up in the data flow

The decisive question is not how a system feels but where the data goes. What is stored? Who can read it? On which machine does the model that processes the content run? These questions cannot be answered with phrasing, only with decisions: minimal storage, clear deletion, processing paths that can be explained in a single paragraph.

A system that people entrust with something personal has to have those answers ready without fine print. Trust is more fragile than any feature: one discovered detail that does not fit the story causes more damage than ten good features can repair.

Local first

For intimate data my position is therefore clear: it belongs in the user's own environment by default. Local processing with locally operated models is not an optimisation here — it is the foundation. Cloud inference is the justified exception for individual, clearly named steps, not the default.

That does not mean everything must run locally. But the sensitivity of the data determines the architecture — not the convenience of the stack. That is where I see the real value of local models: they make an architecture possible that does not merely promise trust but produces it.

Clarity instead of control

Part of that is transparency you do not have to hunt for. What is stored where? What happens to it? How can everything be exported or deleted? A system that depends on trust has to stay understandable without anyone studying terms of service or asking support.

Trust cannot be retrofitted. It is part of the design from the very beginning — or it is missing.