By the mid-2010s, you could attach a sensor to almost anything and get data back to a dashboard within minutes. Temperature. Humidity. Pressure. Vibration. Location. Fill levels. Energy consumption. Brake conditions. Door status. Water leakage. Machine anomalies. The hardware was cheap. Connectivity was available. Cloud storage cost almost nothing.
The pitch was clean: replace a dumb device with a smart one, detect problems before they become expensive, automate the response, show the ROI on a slide. Customers nodded. Pilots launched. The proofs-of-concept worked.
And then almost nothing scaled.
Not because the sensors failed. Because the industry had mistaken the technical problem for the actual one.
When Sensors Start Measuring People
The easy cases in IoT are easy for a specific reason.
A flood sensor does not care who watches it. A transformer does not worry about how its vibration data will be used next year. A parking space does not suspect the city is building a behavioral profile. When the sensor measures a physical condition with no human attached to the consequence, adoption is straightforward. The benefit is immediate. The perceived risk is low.
The friction arrives the moment data stops describing a condition and starts describing a person.
A GPS device in a delivery vehicle can be sold as route optimization. It is experienced as behavioral scoring. A connected health monitor can be framed as prevention and become the foundation for a future insurance pricing model. A workplace safety sensor can reduce accidents and simultaneously shift what management knows about productivity, presence, and accountability. The technology is identical across all of these cases. The meaning is not.
Privacy researcher Helen Nissenbaum gave this distinction a precise name. Her theory of contextual integrity holds that privacy is not violated by data collection itself, but by the movement of data outside the context in which it was originally shared (Nissenbaum, 2004). A worker’s location, shared with a dispatcher for a specific delivery route, is functional information. The same location data flowing into a centralized fleet management system used for performance evaluation is something different. The context has changed. The norms governing appropriate data flow have been violated, even if no law was broken and no consent clause was missed.
Most IoT architectures do this by design. They extract data from local contexts and route it into centralized systems where new parties, new purposes, and new interpretations become possible. The architecture is the problem, not the application built on top of it.
Consent Is Not Trust
People are not good at evaluating this kind of risk at the point of adoption. That is not a character flaw.
Acquisti, Brandimarte and Loewenstein, writing in Science in 2015, showed that privacy decision-making is systematically distorted by uncertainty (Acquisti, Brandimarte & Loewenstein, 2015). People cannot reliably anticipate future uses of data they share today. They respond more strongly to immediate and visible benefits than to abstract future risks. When consequences are delayed, uncertain, or invisible, rational calculation breaks down in predictable ways. Asking a customer to consent to an IoT deployment is asking them to evaluate a risk they have no useful prior experience of. The resulting consent is structurally weak, regardless of how much legal language accompanies it.
The privacy calculus framework in information systems research formalizes the underlying mechanism: adoption intent is a function of perceived benefits minus perceived risks, and when risk perception rises, usefulness becomes insufficient as a driver on its own (Dinev & Hart, 2006). The privacy paradox literature complicates this further. Kokolakis’s systematic review of 49 studies found that the gap between stated privacy preferences and actual behavior narrows sharply when the perceived risk is concrete rather than abstract (Kokolakis, 2017). IoT risks are almost never concrete at the point of adoption. They are abstract, future-oriented, and conditional on decisions a third party has not yet made. Customers who appear to accept the risk may simply be unable to evaluate it.
Weber’s legal analysis of IoT privacy challenges identified the structural dimension: ubiquitous data collection, cloud storage, and third-party access create risks qualitatively different from those in conventional software systems, and existing consent frameworks were not designed to handle them (Weber, 2010). A customer who signs an IoT agreement is consenting to something the consent mechanism was not built to cover.
The Workforce Makes the Consequences Legible
The adoption problem is sharpest in workforce contexts, because the consequences there are most measurable.
Research on electronic performance monitoring shows that employees perceive monitoring as procedurally unjust when they have no input into its implementation and no transparency about how results are used (Alge, 2001). Alge’s controlled studies found that perceived invasion of privacy from monitoring reduces organizational citizenship behavior and increases counterproductive work behavior. The sensor that was supposed to improve operational efficiency produces a workforce that trusts management less and cooperates less freely. Neither effect appears on the ROI spreadsheet at procurement.
Stanton’s framework for understanding monitoring reactions identified a second mechanism: the degree of invasiveness perceived by employees is not determined by what data is collected, but by whether the employee believes the monitoring system is used fairly (Stanton, 2000). This means that even technically benign IoT deployments, collecting only what is strictly necessary for operational purposes, can undermine adoption if governance is unclear. The technical scope of the data and the perceived scope of control are different things. Vendors consistently conflate them.
Zuboff’s work on surveillance capitalism formalized the structural version of this dynamic: the same data that serves users today can be used to predict, price, and score them in ways that serve other interests tomorrow (Zuboff, 2019). A car insurer offering a driving sensor is not only offering feedback. It is building a new pricing mechanism. An employer using sensor data in field operations is not only optimizing logistics. It is shifting the power relationship between management and the people it manages. The same data that reduces your risk can increase mine. That asymmetry is not incidental to the business model. It often is the business model.
Pilot Purgatory Is a Trust Calculation
Empirical research on smart home adoption illustrates how these dynamics play out at the product level.
Zeng, Mare and Roesner studied end-user security and privacy concerns with smart home devices across a diverse user sample and found that technical failures were not the primary concern (Zeng, Mare & Roesner, 2017). Users worried about who else might access their data, how manufacturers or third parties might use it, and whether they had meaningful control over collection. Critically, users frequently did not use available privacy settings, not because they did not care, but because they did not trust that the settings were technically effective, or that the company would honor them under future ownership, future policy changes, or future business pressures.
Gefen, Karahanna and Straub, in one of the most-replicated studies on trust and technology adoption, found that trust was a necessary antecedent of behavioral intent to use a system, independent of perceived usefulness (Gefen, Karahanna & Straub, 2003). Usefulness matters. It does not substitute for trust when the perceived risk is personal. Roman, Zhou and Lopez extended this to distributed IoT systems specifically, finding that multi-party, multi-device architecture introduces trust dependencies that do not exist in conventional IT and cannot be resolved through technical standards alone (Roman, Zhou & Lopez, 2013). Each additional node in the data chain is a new trust question the customer must answer, usually without enough information to do so well.
McKinsey and Cisco have each reported that a majority of IoT deployments fail to scale beyond the pilot stage, with estimates ranging from 60 to 75 percent (McKinsey, 2020; Cisco, 2017). These are industry figures, not controlled studies. But they are directionally consistent with what the adoption literature predicts. When contextual integrity is violated by architecture, when the privacy calculus is negative, and when trust has not been established before data is collected, the rational organizational response is to contain the deployment. What the industry calls pilot purgatory is the observable outcome of a trust calculation the customer organization cannot always articulate, but is running anyway.
Start Local
The better entry point is smaller than the industry preferred.
Start with local task automation. Solve a problem where the benefit is immediate, the data stays close to the source, and the user controls what happens next. Detect the leak before the damage. Warn the technician before the failure. Give the driver useful information before the fleet manager receives a score. Help the patient understand a pattern before the insurer sees a risk classification.
Make the first promise local, concrete, and reversible. Then earn the right to aggregate, transmit, and automate.
This sequence matters because trust is not created by a privacy policy. It is created when a user can verify that a system serves a legitimate purpose, limits its own reach, and does not quietly convert help into control. Cavoukian’s privacy-by-design framework and Langheinrich’s foundational work on privacy in ubiquitous computing systems both establish data minimization and user control as structural adoption requirements, not compliance add-ons (Langheinrich, 2001; Cavoukian, 2009). Systems that collect only what is necessary for a local purpose, with transparency about who sees what and when, reduce the perceived risk at the point of decision. Not because the risk disappears, but because the user can actually evaluate it.
Task Automation or System Change?
Before any serious IoT strategy goes to market, one question needs a direct answer.
Are you automating a task, or are you asking the customer to accept a new system?
If it is task automation, narrow is right. Keep the data local. Let the user feel the benefit where the problem happens. A simple product with a visible constraint builds more trust than a sophisticated platform with a detailed privacy notice.
If it is system automation, you have a harder job. You need to solve the trust problem before you solve the data problem. Governance, transparency, data minimization, reversibility, and explicit constraints on who can access what and when are not features to add after the pilot. They are the product. Not because regulation demands it, but because the adoption evidence consistently shows that customers do not extend trust before they have reason to.
Most IoT vendors assumed the second while pricing and selling the first. That is not a messaging problem. It is a business model problem. And it is one the adoption record has been documenting for over a decade.
The internet and the thing were never the hard part
The hard part was always the question no dashboard answers: once this device is connected, who becomes stronger, who becomes more exposed, and who has to trust whom for any of it to work?
When that question has no credible answer built into the product, the pilot succeeds and the project stalls. Not because the technology failed. Because the negotiation never closed.
Sources
Acquisti, A., Brandimarte, L., & Loewenstein, G. (2015). Privacy and human behavior in the age of information. Science, 347(6221), 509–514.
Acquisti, A., & Grossklags, J. (2005). Privacy and rationality in individual decision making. IEEE Security & Privacy, 3(1), 26–33.
Alge, B. J. (2001). Effects of computer surveillance on perceptions of privacy and procedural justice. Journal of Applied Psychology, 86(4), 797–804.
Cavoukian, A. (2009). Privacy by design: The 7 foundational principles. Information and Privacy Commissioner of Ontario.
Davis, F. D. (1989). Perceived usefulness, perceived ease of use, and user acceptance of information technology. MIS Quarterly, 13(3), 319–340.
Dinev, T., & Hart, P. (2006). An extended privacy calculus model for e-commerce transactions. Information Systems Research, 17(1), 61–80.
Gefen, D., Karahanna, E., & Straub, D. W. (2003). Trust and TAM in online shopping: An integrated model. MIS Quarterly, 27(1), 51–90.
Kokolakis, S. (2017). Privacy attitudes and privacy behaviour: A review of current research on the privacy paradox phenomenon. Computers & Security, 64, 122–134.
Langheinrich, M. (2001). Privacy by design: Principles of privacy-aware ubiquitous systems. In G. Abowd, B. Brumitt, & S. Shafer (Eds.), Ubicomp 2001: Ubiquitous computing (Lecture Notes in Computer Science, vol. 2201, pp. 273–291). Springer.
Roman, R., Zhou, J., & Lopez, J. (2013). On the features and challenges of security and privacy in distributed internet of things. Computer Networks, 57(10), 2266–2279.
Stanton, J. M. (2000). Reactions to employee performance monitoring: Framework, review, and research directions. Human Performance, 13(1), 85–113.
Weber, R. H. (2010). Internet of things: New security and privacy challenges. Computer Law & Security Review, 26(1), 23–30.