On this page
Bridging the Digital Divide with AI
Growing up in Nepal, I didn't have reliable internet until I was a teenager. Here's what I've actually seen AI do (and not do) for communities like the one I grew up in.
There was a cyber café near my school in Kathmandu where I used to go after classes. Twenty rupees an hour. The computers were old, the keyboards had the letters worn off half the keys, and the café ran a generator through the scheduled power cuts, but you still learned to save constantly or you lost your work. Most days the connection was slow enough that images would load one strip at a time, top to bottom, like a curtain being raised. I didn't think of it as a bad experience. It was just access. And access was something you scheduled.
That experience is the first thing I think about when someone proposes an AI tool for a community with limited connectivity. Before asking what the model can do, I want to know whether someone can use it when the power or connection drops.
The assumption problem
Every design decision has a user assumption baked in. What device they're on. How fast their connection is. Whether they can read Latin script. Whether they have a street address. Whether they're likely to use an app every day or once a year. These assumptions don't usually show up as explicit choices. They show up as defaults, as the shape of an interface, as what gets optimized and what gets treated as an edge case.
This usually isn't malicious; it comes from the structure of who builds these systems. The people building most AI systems have reliable broadband, modern phones, and live in places with consistent electricity. They build for their own context first because that's the context they understand. The result is that the communities that most need these tools are the ones the tools assume least about. Those defaults need attention in both the product design and the technology.
What AI actually gets right
One example worth looking at is diabetic-retinopathy screening at Aravind Eye Hospital and Sankara Nethralaya in India. A prospective study of 3,049 patients evaluated a deep-learning system against manual grading. That is evidence for a specific screening task in those settings, not a general claim that AI can replace clinicians or that deployment works equally well everywhere.
Language translation is another genuine win. When I was in school, almost everything online was in English. That's still largely true, but the quality of translation tools has improved to the point where a student reading a textbook written for a Western curriculum has a materially better experience than I did. For a lot of learners, that's not a small thing.
Both of those are real. But they come with a caveat I don't want to bury: the wins are real in specific, well-resourced deployments. The Aravind program works partly because Aravind is an exceptional institution that's been building operational capacity for decades. A government ministry deploying the same AI tool without that infrastructure won't get the same results. Technology on its own is not sufficient.
What it doesn't fix
Connectivity is still the actual problem. AI tools that run in the cloud don't help anyone 40 kilometers from a tower. A diagnostic model that requires uploading a high-resolution retinal image is not accessible to a clinic with a 2G connection that drops when it rains. There are attempts to address this with edge computing and offline-capable models, and some of them are promising. But in their current state, most AI applications assume connectivity that a significant part of the world doesn't have.
There's also a failure mode that gets less attention: systems built without community involvement. The failures I mean are often technically sound systems, designed by smart people with good intentions who flew in, assessed needs, built something thoughtful and deployed it, then watched it go unused because the workflow didn't match how people at the clinic actually worked. Sometimes the person who was supposed to use it didn't have a phone with enough storage, or the training happened once and the staff who attended have since moved on. You can make something technically correct and still have it fail completely because the design didn't account for the actual humans in the loop.
This is one of the core lessons from participatory design research, and it keeps being relearned. Imposing a solution, even a good solution, without involving the people it's meant to serve tends not to work. The involvement isn't just consultation. It means building with feedback cycles long enough to actually catch the places where your assumptions broke.
Data and who owns it
This one doesn't have a clean answer, but it deserves to be named. Communities with less infrastructure often, though not always, have weaker data protection law in practice. When a company collects patient data, I want to know which rules apply and who can enforce them. The company is not local. The servers are not local. And the people whose data is being collected frequently have no visibility into what's being stored or what it's used for.
Data collected for a service may also be proposed for model training. Whether that happens, and under what terms, needs to be explicit rather than assumed. I don't think it means AI shouldn't be deployed in those contexts. But I do think it means the people building these systems need to take data governance seriously in places where the law doesn't require them to.
How this shapes the work I actually do
The Revenue Platform I built during a summer internship at SimplySoft was an internal testing clone of the tax portal the company runs for FCGO, and the district-office staff who use the real portal have variable digital literacy. Some were comfortable with computers, while for others this portal was the main thing they used a computer for. Connectivity varied by region, so there was no assumption of consistent, fast internet.
That context shaped specific design choices. Free-text inputs were replaced with cascading dropdowns wherever possible because free text creates error states that are hard to recover from at low familiarity. Every state change had a visual confirmation so users could tell something had happened, even on a slow connection. Error messages were written to be specific and actionable, not technical. The mental model for every feature was the most uncertain user, not the most capable one.
That last point is the one I'd generalize: design for the hardest user, not the easiest. In most commercial software, the hardest user is treated as an outlier. For this portal, less experienced users belonged in the core design brief. I should be clear about the limits, though. My design decisions came from the feedback of the senior developers on my team rather than from watching district staff use anything I built, so I never got the long feedback loop with real users that this essay argues for.
Who we assume the user is
AI can help in specific, well-designed applications. The screening study shows one concrete possibility. Translation tools offer another, provided the output is useful in the learner's language and context. But the question I keep coming back to is whether we're honest about who we're assuming as a user when we build.
The cyber café where I learned to use a computer didn't have reliable power from the grid. It had keyboards with no letters on them. The people using it were resourceful and adaptive, not in spite of those constraints, but because of them. The tools that actually serve communities like that one are built by people who take those constraints seriously from the start, not as edge cases to address later. That's the design problem. Everything else follows from whether we decide to solve it.
One practical example of this work: the Revenue Platform, a centralized tax portal built for a government agency in Nepal, built to serve people who needed it most.