No Offline Mode

Your bank closes its branches. Your GP moves to an app. Your government puts everything behind a login. Your identity lives in a database. Every analog fallback, quietly removed.

Nobody asked whether this was a good idea. They just did it because digital is cheaper.

Good systems design has one rule that predates computers: never have a single point of failure. We are breaking that rule at civilisational scale.

The Redundancy Principle

Every engineer learns this. Redundancy is not waste. It is resilience. RAID arrays store data across multiple disks so that losing one does not lose the data. Backup generators keep hospitals running when the grid fails. Fire escapes exist alongside elevators. Paper maps sit in the cockpit next to the GPS.

The principle is simple: if one path fails, another exists. Not because failure is likely on any given day, but because failure is certain over time.

Digital systems are not exempt from this principle. They are more subject to it. Software has bugs. Servers go down. Networks get partitioned. Credentials get compromised. Cloud providers have outages. Power grids fail. Ransomware encrypts everything it touches.

When any of these things happen, the question is: what still works?

Increasingly, the answer is nothing.

We used to have fallbacks without thinking about them. Cash worked when the card machine was down. Paper records existed alongside digital ones. You could walk into a building and talk to a person. These were not old-fashioned holdovers. They were the redundancy layer. They were the backup that kept the whole system resilient.

We are removing them because they are expensive to maintain. That is true. Redundancy is always expensive. That is not an argument against it. That is the point. Resilience costs money. The alternative costs more.

What We Are Removing

Banking. Branches are closing across every developed country. Some banks are app-only from launch. Cashless businesses refuse notes and coins. When the payment system goes down, and it does go down, you cannot buy food. You cannot pay for transport. You cannot access your own money. In 2024, multiple major banks had outages lasting hours. People with cash were fine. People without cash had nothing.

Healthcare. Medical records are digital-only in most systems. Telehealth is replacing in-person consultations for routine care. Prescriptions are electronic. When the system goes down, your doctor cannot see your medical history. They do not know your allergies. They do not know what medication you are on. The paper chart in the filing cabinet does not exist any more.

Government services. Applying for benefits, renewing a licence, filing taxes, registering a business. In most jurisdictions, these are online-only. Automated phone systems loop you through menus with no human option. If the website is down, or you do not have internet access, or the system rejects your digital identity, there is no counter to walk up to. There is no form to fill in by hand. There is no fallback.

Education. Coursework lives in learning management systems. Textbooks are digital licences that expire. Research papers sit behind institutional logins. When the platform goes down, students cannot access their own work. When the licence expires, the textbook disappears.

Personal data. Photos in the cloud. Documents in Google Drive. Passwords in a password manager. Notes in an app. When the service shuts down, or the account gets locked, or the company gets acquired and changes the terms, everything is gone. Not because it was deleted. Because you never had a copy.

The pattern is the same in every case. The old system was presented as outdated. The new system was presented as an upgrade. Faster. Cheaper. More convenient. Nobody mentioned that the old system was not just slower. It was the backup.

Things That Should Never Be Online

Some data should not be entered into networked systems at all. Not because the encryption is weak today, but because the risk of centralisation is structural.

Private medical details you have not shared with a doctor. Your self-assessment, your symptoms diary, your mental health notes. These are yours. Putting them in an app means they exist on someone else’s server, subject to someone else’s terms of service.
Personal journals, notes, unfinished thinking. The things you write to process your own thoughts. These are not data. They are cognition. They do not belong in a system that can be subpoenaed, scraped, or sold.
Biometric data that cannot be changed if compromised. You can change a password. You cannot change your fingerprints, your iris pattern, or your face. Once biometric data is breached, it is breached permanently.
Information about people who have not consented to being in your system. Photos of your children. Contact details of your friends. Medical information about family members. Entering someone else’s data into a system they did not agree to is a consent violation, regardless of what the privacy policy says.
Anything where the consequence of breach is irreversible. If the worst case of a data breach is inconvenience, maybe the risk is acceptable. If the worst case is identity theft, blackmail, discrimination, or physical danger, the data should not be in a networked system.

“But it is encrypted” is not a complete answer. Encryption protects data in transit and at rest. It does not protect against the system being subpoenaed. It does not protect against the company being acquired and the new owner changing the privacy policy. It does not protect against the terms of service being updated to allow uses you never agreed to. It does not protect against the encryption being broken in ten years by hardware that does not exist yet.

Some things are safer on paper in a drawer. Local-first is not a lifestyle choice. It is a security architecture.

The AI Acceleration

AI is accelerating this centralisation at a pace that makes the previous decade look cautious.

Every AI product wants your data in their system. Every “personalised” experience requires your information to leave your device. Every agent that acts on your behalf needs access to your accounts, your history, your preferences, your contacts. The more data it has, the better it works. That is the pitch.

The pitch is always the same: give us everything, and we will make it better. The question nobody asks: what happens when this system fails? What happens when it gets hacked? What happens when the company gets acquired? What happens when the terms of service change? What happens when the AI provider decides your use case is no longer profitable?

We are building AI systems that depend on having all your data, all the time, in one place. That is not intelligence. That is a single point of failure with a language model attached.

The constraint-mandatory approach says: the system should work without needing all your data. If your AI agent requires total access to function, the architecture is wrong. If removing the AI layer breaks everything, you have not built a tool. You have built a dependency. If the agent cannot operate with minimal, scoped, time-limited access, the permissions model is a single point of failure.

The same redundancy principle applies. What works when the AI is down? What works when the API is unreachable? What works when the model provider changes their pricing and you can no longer afford the service? If the answer to any of these is “nothing,” you do not have a product. You have a subscription to someone else’s infrastructure with no fallback.

Replacing the People Who Know How

The same single point of failure problem applies to people. If you replace every human who knows how to do a job with an AI system that does it instead, you have not automated the work. You have created a dependency on a system that nobody around you understands well enough to replace when it fails.

When a company replaces its customer support team with a chatbot, and the chatbot goes down, there is nobody left who knows how to handle a customer complaint. When a hospital replaces its diagnostic radiologists with an AI reader, and the AI service has an outage, there is nobody left who can read the scan. When an organisation replaces its entire content team with generative AI, and the output starts producing errors, there is nobody left who knows the subject matter well enough to catch them.

The knowledge does not sit in a manual somewhere waiting to be picked up. Expertise is built through years of practice, pattern recognition, edge case experience, and institutional memory. When you remove the people, you remove the knowledge. And unlike a backup drive, you cannot just plug it back in.

This is not an argument against using AI in the workplace. AI that assists experienced people makes the work better. AI that replaces experienced people makes the organisation brittle. The difference is whether the human knowledge still exists somewhere in the system.

The goal should be upskilling, not offloading. Train humans to be better at their work with AI as a tool, not to hand the work to AI and hope nobody notices the humans are gone. A radiologist who uses AI to catch things they might miss is more capable than before. An AI system that replaced the radiologist is a single point of failure that nobody in the building can compensate for when it fails.

But there is a second problem with replacement that nobody talks about: scope creep. When you remove roles and hand their responsibilities to AI, the remaining humans absorb whatever the AI cannot do. Their job descriptions expand. Their scope spirals. They become increasingly powerful and increasingly stressed, making decisions that used to be distributed across a team, with no additional training, no additional oversight, and no agreed terms for the expanded authority they now hold.

This is how you end up with unelected individuals guiding organisations, departments, or systems without any democratic mandate or accountability framework. Not because they seized power, but because the structure around them was hollowed out and they were the ones left standing. Nobody voted for them to have that authority. Nobody defined the boundaries. The AI took the tasks, but the responsibility landed on whoever was still in the room.

Good systems design does not just ask “can the AI do this task.” It asks “what happens to the humans in the system when we change the structure.” If the answer is “fewer people doing more work with less oversight,” you have not improved the system. You have made it more fragile and less accountable at the same time.

The test is the same as every other redundancy question: what happens when the AI is unavailable? If the answer is “we cannot do this work at all,” you have a single point of failure and it is the AI. If the answer is “we can still do it, just slower,” you have a resilient system.

Good engineering says: keep the humans who know the work, give them better tools, define their roles clearly, and make sure the system degrades gracefully when any component fails. That includes the AI component. Especially the AI component, because it is the one you have the least control over.

What Redundancy Looks Like Now

This is not an argument against digital systems. Digital is fine. Digital-only is the problem.

For individuals:

Keep paper copies of critical documents. Passport, birth certificate, insurance, medical records, property deeds. Not because you distrust the digital versions, but because you are designing for the scenario where they are unavailable.
Use local-first software where the data lives on your device and syncs to the cloud as a backup, not the other way around.
Maintain cash. Not as ideology. As infrastructure. Enough to cover a few days of essentials if the payment system is down.
Store important files in at least two physical locations. A hard drive at home and one somewhere else.
If a service has no offline mode, that is a design flaw, not a feature. Choose alternatives that work without connectivity when they exist.
If a system requires you to be online to access your own data, you do not own that data.

For builders:

Design systems that degrade gracefully. If the server goes down, the client should still function for core tasks. If the network is unavailable, the user should still have access to their information. If the AI service is unreachable, the core functionality should survive.
Test with the network cable unplugged. If your product becomes a blank screen, that is a single point of failure in your architecture.
Give users the option to export their data in a standard format, always. Not as a compliance checkbox. As a design principle.
Never make the AI layer load-bearing for basic functionality. The AI should enhance. The application should work without it.

For policymakers:

Before removing an analog service, answer this: what happens when the digital replacement fails? If the answer is “nothing works,” you have not replaced the service. You have created a dependency.
Essential services should always have an offline pathway. Banking, healthcare, government, emergency services. If any of these are accessible only through a working internet connection and a charged device, the system is fragile by design.
Digital identity should supplement, not replace, physical identity. A system that only works when the database is up is not more secure. It is more brittle.

What You Can Do

If you are building software:

Run your product through the Safety Evaluation. Ask specifically about graceful degradation, data residency, and what happens when external dependencies are unavailable. If your product cannot answer those questions, it has a single point of failure that you have not addressed.

If you are evaluating AI products:

Ask the vendor: what works when your service is down? If the answer is “our uptime is 99.9%,” that is not an answer. 99.9% uptime means almost nine hours of downtime per year. What happens during those hours? If you are planning to open source a framework, consider whether it creates new single points of failure or reduces existing ones.

If you are a person:

You are the systems architect of your own life. Apply the same principle every engineer learns on day one: never have a single point of failure. Paper copies. Local copies. Cash. A phone number for your bank that reaches a human. A plan for what you do when the app is down and the website is unreachable.

The goal is not to reject technology. The goal is to make sure that when one part of your system fails, the rest still works. That is not paranoia. That is engineering.

The AI Safety Evaluation Tool, Release Decision Framework, Cross-Jurisdiction Compliance, and AI Psychosis are open tools. Use them on anything.

This post is licensed CC BY-SA 4.0. Share it, adapt it, use it. Just cite us.