When systems fail, someone always carries the burden.
With all of this talk about AI innovation, efficiency, and scale, I have one question that keeps flagging in my mind:
Who absorbs the risk?
I’m not talking about theory, mission statements, or the refined language organizations use when they want a process to sound more thoughtful than it is.
I am talking about what happens in practice.
For example, when a system is confusing, who has to work around it? When communication is weak, who is left guessing?
Or for the C-suite or upper-level management, when leadership moves too fast, who is responsible?
To the InfoSec folks, when privacy is treated like a checkbox, who becomes more exposed?
For the website builders, when access is poorly designed, who gets left behind? Accessibility is not just a checklist issue; it is about meeting people’s needs in the real world.
For all of us, when rights are under pressure, who is expected to “just deal with it” (while others stay comfortable)? That is also why I do not think people need a brand-new identity to contribute. They need a clearer way to act from where they already are. When rights are under pressure, privacy and device security stop being abstract; they become practical ways to reduce exposure and protect people in real time.
Those questions matter because infrastructure is never neutral.
I do not just mean technical infrastructure, either. Sometimes infrastructure looks like a workflow. Other times it can look like a communication plan. It could also be a data governance approach or it looks like how decisions get made within an organization. For example, who gets consulted, what gets documented (or what doesn’t), and what can be ignored. That becomes even harder to challenge later if what gets tracked is never clear.
And when that infrastructure is weak, someone always pays for it. Usually, it is not the people with the most power in the room, because deflection and “being in the know” only protects specific paychecks, and it is designed that way on purpose, but its not always intentional. I’ll cover that later in the post.
So who truly pays for it?
For example, is it a patient trying to access care through a confusing process, or is it a staff member taking on more work because leadership never clarified the workflow?
Is it the community member who was left out because accessibility was treated like an afterthought?
Is it the person whose privacy becomes more fragile because the system was built for convenience rather than protection, or the (unemployed) volunteer doing unpaid work while their colleagues have the option to treat the effort more casually because they’re employed?
That is part of why I keep coming back to infrastructure.
Many people notice systems only when they fail loudly, which is one reason I keep coming back to the infrastructure underlying visible action.
They notice when a platform breaks or when trust collapses. They also notice when a rollout goes badly or when a public-facing error creates backlash.
But a lot of harm happens long before that, and sometimes it happens quietly.
That is why I do not think ethical infrastructure starts with branding, nor with compliance language alone. And it definitely does not begin with the C-suite, leadership, or middle management “moving fast and breaking things.”
It starts with a more practical question.
What does this system (or structure) ask people to carry?
And then: Is that burden fair? Is it necessary? Did anyone actually think through who would bear the consequences if something goes wrong?
This is where ethics becomes operational. It’s also why it requires more than just the usual putting-out-fires urgency and blanket vanity metrics; it requires a way to identify harms, assign responsibility, and determine how risk is distributed.
That is also why I think some people misunderstand what “ethical work” looks like.
They assume ethics reside solely in statements, policies, public commitments, and above all else, their paychecks.
Those things matter.
Ethics live in many places.
But ethics also lives in implementation, and whether people can understand what they are being asked to do.
It also depends on whether a process is actually usable and whether accessibility was built in or bolted on. That is also why I keep coming back to accessibility as a core part of design. It lives in whether privacy is protected or quietly traded (or sold) away, and it lives in whether the structure reduces harm or redistributes it downward. I wrote more about the difference between cybersecurity and data privacy in an earlier post.
That last part matters, because systems get built in ways that quietly offload risk onto the people with the least room to absorb it. That becomes even more likely when systems are designed without sociotechnical evaluation, stakeholder engagement, and feedback loops with impacted communities. Now, whether that is intentional or not can be debated. But if we can efficiently map and automate entire business processes with AI to fire 25% of a company’s employees, we can surely improve how we map decision-making to hold the people making those business decisions at the highest echelons accountable. That is also where who gets a say in those decisions starts to matter.
It also happens in healthcare, nonprofits, education, and movement spaces.
And the more normalized it becomes, the easier it is for people to call it “just how things work.” That is exactly why what gets normalized matters.
I have seen it with my own two eyes.
I have seen how much depends on the structures around a single process (and multiple processes, programs, and projects). For example, like in my telehealth projects. In those, access depended not only on compliance but also on whether workflows were understandable, multilingual, usable, scalable, and clear enough for real people (patients, employees, and management) to navigate and sustain.
I have seen it in communication systems, where message quality directly affected whether people knew what to do next.
In my rights-based work and movement-building, the difference between clarity and confusion shapes how safely someone navigates a moment of pressure, and it is important to note that structure, coordination, and plain language matter most in these types of projects.
Think about it. You have probably seen it in organizations where employees are expected to bear the unnecessary burden of tasks resulting from poor planning, weak governance, and/or vague leadership. AI cannot fix that alone, despite the hyperbole over the last couple of years.
Friction is not neutral.
Instead, unaddressed friction manifests in various ways, including stress, delay, confusion, and avoidable harm.
That is why I think ethical infrastructure should be judged less by how it sounds and instead by what it prevents, protects, and makes possible.
There are better questions to ask than whether something merely looks innovative or just generates revenue.
At the end of the day
Ethical infrastructure is not about flawlessness. It is about whether people are paying attention to the burden, risk, and consequences before those costs become someone else’s problem.
And if we are serious about building better systems, that is where we have to start.
Not just with what a system does.
With what it asks people to carry.