Even Realities Founder and CEO: AI Hardware Needs Privacy Built In From the Start
In a TechRadar article, Even Realities' founder and CEO argues that AI hardware makers must treat privacy as a design constraint from the beginning, especially as camera-equipped smart glasses create trust problems for wearers and bystanders.
The article describes a familiar cycle in consumer technology: companies race to expand what a product can do, packing devices with features, sensors, and capabilities to stand out. Privacy questions tend to become urgent only after products are in people's hands, when customers, industry observers, and the public begin to give feedback on how the technology feels to use and live around. The article says versions of this pattern appeared with social media, smartphones, and smart home devices, and is beginning to appear again as AI moves into devices that can see, hear, interpret, and respond to the world around them.
The Even Realities founder and CEO argues that sequence is backward. Privacy cannot simply be patched into a product after launch, the article says, because many decisions that shape a device's privacy implications are already made during development. Choices about hardware, architecture, data collection and processing, and even how much information a device needs to perform its job should be considered from the beginning, alongside fundamental decisions that determine how a product is built. Product teams already treat battery life, weight, cost, and performance as design constraints from the outset, the article says, and privacy should be treated the same way, particularly as AI lets consumer devices collect and interpret more information than before.
Smart glasses offer one of the clearest examples, according to the article, because much of the industry is building the category around cameras. The logic is understandable: more visual context can make AI more capable, allowing a system to understand what the wearer is seeing and respond accordingly. But cameras also introduce one of the category's hardest trust problems, because glasses are not used in isolation. They sit on someone's face through meetings, meals, commutes, and conversations, often in front of people who never chose to interact with the technology.
That creates a design consideration that is easy to overlook when evaluating a product only from the wearer's perspective. The person wearing a device may understand whether it is recording, what information is being processed, or why a sensor is active, while everyone around that person has far less context. Product teams also have to account for more than the experience they intend to create, the article says, because once a device can capture information about the people around it, that capability can be used in ways the designers never intended. A status light can indicate that a camera is active, and a privacy policy can explain how captured information is handled, but neither completely removes the uncertainty created by the sensor's presence. By that point, the article says, the most consequential privacy decision has already been made in hardware.
Not every privacy problem can be solved downstream with better policy or software, according to the article, particularly when a product depends on a specific sensor, continuously sends information to the cloud, or retains data by default. Privacy teams then inherit constraints established much earlier in the development process.
The article says a better starting question is not how much information a device can collect, but how much information it needs to collect to deliver its core value. Asking that question can lead product teams to make different decisions about what a device actually requires. Does an AI device need to identify everything in front of the user, or does it simply need enough context to deliver directions? Does information need to leave the device to be useful, or can some processing happen locally? Does the data need to be retained after a task is completed, or can it be deleted? Does a sensor need to remain active continuously or only when the user explicitly requests it?
These choices may limit certain capabilities in the short term, the article says, which is why privacy-by-design can be uncomfortable. Product development usually rewards adding capability, while restraint can look like choosing to do less. Consumer technology already requires product teams to make tradeoffs constantly, whether that means accepting smaller batteries to make devices lighter, constraining processing to manage heat, or removing features that make an interface too complicated. Privacy deserves the same discipline, according to the article, because the most capable version of a product is not necessarily the version people will feel comfortable bringing into their everyday lives.
Privacy discussions are often treated as legal or compliance conversations, the article says, but for consumer technology they are also questions of product experience. A device that technically complies with every requirement can still fall short as a product experience.