When Infrastructure Thinks for Us: Dependence on Networks, Clouds and Automated Systems
Networks, cloud services and automation save enormous amounts of work while hiding dependencies. How can we understand single points of failure, vendor lock-in, automation bias and technological resilience without pursuing technological autarky?
When a phone chooses a route, when a work login depends on a remote service, when a document exists only in the cloud, and when software decides which case deserves attention, we are no longer relying on one device. We are relying on chains of networks, identity providers, data centers, APIs, and automated decisions. Most of this infrastructure works so smoothly that we notice it only when it fails.
That is a major advantage of modern technology. Cloud computing provides rapid scaling, pooled resources, remote access, and services that many organizations could not economically build alone. Automation can reduce routine work, detect anomalies faster, and coordinate systems too complex for continuous manual control. Yet the same abstraction that simplifies use can also hide dependency.
When one identity service unlocks ten other systems, one provider hosts data for thousands of organizations, one API connects payments or logistics, and one algorithm routes human attention, resilience matters more than whether the technology works on an ordinary day. We have to ask what happens during an outage, a misconfiguration, a cyberattack, a change of commercial terms, or simply a wrong automated recommendation.
The goal is therefore neither technological autarky nor a return to a pre-network world. A more mature question is how much dependency we understand, how many alternatives we have, and whether an important function can continue when the normal path fails. Technological resilience is not life without infrastructure. It is the ability to keep infrastructure as a tool rather than an invisible point without which we can no longer act.
The cloud is not nowhere — it is someone else's computers inside a very large system
NIST defines cloud computing as a model that provides on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released. Its essential characteristics include on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. This is a technical model, not a metaphor for data floating outside the physical world.
For users, the physical layer is deliberately hidden. A document synchronizes, an application starts, a server receives more memory, and a service remains available without the user knowing which disk or data center is currently doing the work. That abstraction is a source of enormous usefulness. It lets an organization focus on its mission rather than every cable, disk, and fan.
But abstraction does not remove physical infrastructure or contractual relationships. Beneath it remain electricity, fiber, routers, data centers, identity systems, software libraries, and providers. When dependency becomes invisible, it becomes easier to mistake it for a permanent property of the world.
A digital service is a chain, not one server
A modern application may look like one service while actually depending on many layers. The user first needs connectivity and name resolution, then identity and authentication; the application may rely on external databases, maps, payment systems, analytics, communications APIs, and other third-party services. Each layer may belong to a different company.
A distributed system is therefore not automatically a system without a single point of failure. It may have many application servers and several data centers while all of them still depend on the same identity provider, DNS, library, or control plane. If a shared dependency fails, seemingly independent parts can fail together. In engineering this is a common-mode failure: redundancy does not help when backup components share the same cause of failure.
The most critical dependencies are not always the ones consuming the most money or compute. They are often small services sitting at a system crossroads: login, certificates, configuration, time synchronization, DNS, or an API without which the rest of the application does not know how to proceed.
.jpg)
Concentration brings efficiency — and systemic exposure
Large providers can build infrastructure that is economically or technically out of reach for an individual organization. Distributed data centers, specialized security teams, automatic scaling, and global networks are real advantages. Concentration therefore reflects not only market power but also economies of scale and the difficulty of operating complex systems.
The same concentration means many organizations share the same external dependencies. The European Banking Authority's 2025 and 2026 risk assessments specifically highlighted growing dependence on third-party ICT providers, especially cloud and payment services, and the possible systemic consequences when important functions rely on a small number of large providers.
This does not show that a large provider is less reliable than a local server. Often the opposite is true. It shows the difference between the probability of an individual failure and the consequence of a common failure. A highly reliable component can still represent substantial systemic risk if an enormous number of other systems depend on it at the same time.
Vendor lock-in is not only a contract; it is architecture
Dependence on a provider often becomes visible only when an organization tries to leave. Data may be exportable while applications are not; an application may be movable while it relies on proprietary databases, identity features, queues, or analytics that have no direct substitute elsewhere. Migration can require months of engineering even when a contract says that the customer owns the data.
NIST identified interoperability and portability early as key requirements of a mature cloud environment. Portability means that data and applications can move between systems at acceptable cost; interoperability means that different services can work together through common specifications. These are architectural properties, not merely legal rights.
The European Data Act addresses the same problem directly: it requires data-processing providers to reduce switching barriers, support export and open interfaces, and phase out switching and data-egress charges. The need for such rules is itself evidence that exit is not an automatic property of digital markets.
When automation does not merely perform a task but directs judgment
Infrastructure 'thinks for us' in a functional, not conscious, sense. A system ranks alerts, chooses a route, recommends a diagnosis, filters content, approves a transaction, or decides which case deserves human attention. It does not become a person, but it takes over part of the selection process that humans previously performed.
This can be useful because attention is limited. The problem begins when a recommendation effectively becomes the decision. Research on automation bias shows that people can over-rely on automated advice and miss errors, especially when verification is difficult, workload is high, or the system is correct most of the time. A highly reliable system can paradoxically reduce practice for the moment when it is wrong.
That is why 'human in the loop' is insufficient when the human is present only formally. If the person lacks time, data, authority, or skill to verify the output, the click may be merely a ritual of approval. Human oversight is meaningful only when the person can understandably check the recommendation and reject it when necessary.
An outage is not the only way to lose control
Technology dependence is often imagined as a dramatic data-center outage, but loss of access has many paths. A configuration error can stop a service without hardware failure; a stolen account can lock out its legitimate owner; an API change can break an integration; a contract dispute or account suspension can stop a business process; lost keys can make encrypted data unreachable.
Security architecture can also create dependencies. Modern approaches such as zero trust correctly remove implicit trust and require explicit verification of identity and access. Identity infrastructure therefore becomes critical to operation. Security design has to consider availability as well as who is allowed to enter.
NIST's cyber-resilience framework consequently focuses on the ability to anticipate, withstand, recover from, and adapt to adverse conditions. That is broader than preventing attacks. A system is resilient when its important function survives even when part of the infrastructure is no longer trustworthy or reachable.
A backup we cannot use is not real redundancy
Redundancy is a basic resilience tool, but the statement 'we have two' tells us little by itself. Two copies of data in the same account, region, or provider may disappear in the same incident. Two network links following the same physical route can fail together. A fallback system that has never been tested may exist only in documentation.
NIST contingency-planning guidance therefore includes alternate equipment, alternate processing locations, data recovery, and even temporary manual procedures. The important word is testing. A backup becomes part of resilience only when we know it can actually be restored within a time that still matters to the function.
Degraded modes also matter. A fallback does not have to reproduce every feature. A hospital, logistics center, or small business may mainly need to view essential records, make basic decisions, and record events for later synchronization. Resilience is not always a perfect copy of a normal day; often it is the ability to operate safely until full service returns.
A local alternative does not mean technological autarky
Criticism of dependency can easily swing to the opposite extreme: host everything yourself, keep every dataset local, and avoid external services. For most people and organizations this would be more expensive, harder to maintain, and often less secure. A large provider may offer expertise, redundancy, and response capabilities that a small team simply does not have.
A more useful goal is selective local capability. Critical data can have a verified local or independent backup; an essential function can have an offline mode; identity can include secure emergency procedures; applications can use open formats; some workloads can remain local while others use the cloud. Hybrid architecture can be a practical compromise rather than an ideological middle ground.
The same applies to multi-cloud. Two providers help only when the second is genuinely an independent path. If both depend on the same identity service, DNS, or external API, 'multiple clouds' can still hide one point of failure. Architectural diversity matters more than the number of logos on a diagram.
The ability to exit is a security and power property
A system that can be left only at enormous cost constrains practical choice. That applies to a company unable to move its data and to an individual unable to export information or perform an essential task without one account. Exit is therefore more than a competition-policy issue; it is part of resilience and the distribution of power.
A well-designed exit has several layers: data are available in documented, usable formats; dependencies are inventoried; critical configurations and keys are accessible; alternatives have been exercised at least occasionally; contracts specify termination procedures; and people know how to continue when automation is unavailable. This does not make migration easy. It makes it possible rather than practically impossible.
Both the European Data Act and NIST cloud standards emphasize interoperability and portability because markets do not automatically provide them. Technological freedom is not the absence of dependency. It is the ability to change, limit, or end a dependency without losing everything invested in the system.
When infrastructure becomes invisible, the plan for its absence must remain visible
Modern society cannot realistically operate without networks, clouds, software, and automation. Nor is there a reason to abandon them merely because they create dependencies. But high usefulness is not the same as infinite reliability, and convenience is not the same as control.
A mature architecture therefore asks more than whether a service works today. It asks what the service depends on, what happens when it fails, how long we can wait, which data must exist elsewhere, who can override an automated decision, and how we will leave if the provider or technology no longer fits our needs.
When infrastructure 'thinks for us', its greatest risk is often that it disappears from awareness. Resilience makes it visible again—not so that every person becomes a systems administrator, but so that essential functions, decisions, and data are not hostage to one invisible path. A good system saves us work. A resilient system also leaves us able to continue when the normal system cannot.
Sources and further reading
- THY-REALITY — Kibernetika: od povratne zanke do človeka v sistemu / Cybernetics: From Feedback Loops to the Human in the System (LOCKED): feedback, regulation, human-system loops and distributed control.
- THY-REALITY — Roboti in avtomatizacija: kdo dela, kdo odloča in kdo ima koristi? / Robots and Automation: Who Works, Who Decides and Who Benefits? (LOCKED): automation, algorithmic management and human authority.
- THY-REALITY — Opazovalec in model: koliko naš opis oblikuje to, kar vidimo? / Observer and Model: How Much Does Our Description Shape What We See? (LOCKED): models, measurement and epistemic limits.
- Mell, P.; Grance, T. — The NIST Definition of Cloud Computing. NIST SP 800-145, 2011.
- Sokol, A.; Hogan, M. — NIST Cloud Computing Standards Roadmap. NIST SP 500-291r2, 2013: interoperability and portability requirements.
- Badger, L. et al. — US Government Cloud Computing Technology Roadmap. NIST SP 500-293, 2014: secure, interoperable, reliable cloud services and provider switching.
- Ross, R. et al. — Developing Cyber-Resilient Systems: A Systems Security Engineering Approach. NIST SP 800-160 Vol. 2 Rev. 1, 2021.
- Swanson, M. et al. — Contingency Planning Guide for Federal Information Systems. NIST SP 800-34 Rev. 1: alternate processing, recovery and manual fallback.
- Rose, S.; Borchert, O.; Mitchell, S.; Connelly, S. — Zero Trust Architecture. NIST SP 800-207, 2020.
- NIST NCCoE — Implementing a Zero Trust Architecture. NIST SP 1800-35, 2025: distributed resources across on-premises and multiple clouds.
- European Commission — Data Act Explained, Chapter VI: switching between data processing services, portability, open interfaces and removal of switching barriers.
- European Commission — Results of the Study on Interoperability of Data Processing Services, 2026.
- European Banking Authority — Risk Assessment Report, June 2026: dependency on third-party ICT/cloud providers and operational-resilience concentration risks.
- European Banking Authority — Risk Assessment Report, December 2025: outsourcing and concentration dependencies in cloud and payment systems.
- Parasuraman, R.; Manzey, D. H. — Complacency and Bias in Human Use of Automation: An Attentional Integration. Human Factors 52(3), 2010, 381–410.
- Goddard, K.; Roudsari, A.; Wyatt, J. C. — Automation Bias: A Systematic Review of Frequency, Effect Mediators, and Mitigators. Journal of the American Medical Informatics Association 19(1), 2012, 121–127.
- Lyell, D.; Coiera, E. — Automation Bias and Verification Complexity: A Systematic Review. Journal of the American Medical Informatics Association 24(2), 2017, 423–431.
- Tabassi, E. — Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1, 2023.
- Chandramouli, R.; Butcher, Z. — A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments. NIST SP 800-207A, 2023.