Digital Ethics: Beyond Compliance

A GDPR-compliant consent dialog can be designed in two hours. A consent dialog that genuinely respects user autonomy takes much longer, because it requires actually thinking about whether users understand what they are consenting to and whether the choice architecture makes opting out as easy as opting in. Most organizations design the first kind and call it their ethics work. This is the compliance-ethics gap, and it is the thing I find most underappreciated in how organizations approach digital systems.

Compliance asks whether something is permitted. Ethics asks whether something is right. These are different questions. They often have different answers. Something can be legal, technically compliant with every applicable regulation, and still wrong. A consent interface that is technically GDPR-compliant but uses dark patterns, small text for the opt-out link, pre-checked boxes for data sharing, a confusing double-negative for the privacy option, is designed to maximize acceptance rates, not to facilitate informed consent. The opt-out button exists. Compliance is satisfied. The underlying practice, collecting behavioral data from people who would have opted out if the design made that easy, continues unchanged.

The ACM Code of Ethics, revised in 2018, is a real public document that articulates what the computing profession says it values. It includes principles about contributing to society and human well-being, avoiding harm, being honest and trustworthy, acting fairly, and respecting privacy. These are aspirational statements of professional obligation, not legal requirements. The IEEE Ethically Aligned Design framework makes similar commitments with more specificity about AI systems in particular. Both documents are careful and thoughtful. Both documents are also, to put it bluntly, aspirational in a way that most organizational decision-making is not.

The distance between a professional ethics document and an actual organizational decision is an empirical question, and it is one that IS researchers are starting to take more seriously. An engineer at a social media company who reads the ACM Code of Ethics and then goes to work on an engagement-maximizing ranking algorithm is not necessarily a hypocrite. They are operating inside an organizational context with its own incentive structures, reporting relationships, product roadmaps, and definitions of success. The ethics code describes what the individual should value. The organization describes what the individual will be rewarded for. When those two things conflict, the organization usually wins.

This is not a cynical observation. It is a structural one. Organizations are not collections of autonomous ethical agents making independent judgment calls. They are systems with rules, hierarchies, and incentives that shape behavior in predictable ways. If the organizational incentive system rewards engagement metrics and punishes shipping delays, an engineer who raises an ethics concern about an engagement-maximizing feature is swimming against the current. They might win sometimes. The current is still running.

The question of who is affected by a system but was not consulted in its design is one that comes up repeatedly in IS ethics literature, and it is one that organizational practice almost never answers well. The people who design enterprise systems are usually not the people who use them at the operational level. The people who design consumer platforms are usually not the people most affected by algorithmic bias or by misinformation amplification. Participatory design approaches try to address this by involving affected communities in the design process. These approaches exist, are studied, and are occasionally practiced. They are not common in enterprise IS development, where the design process is usually driven by requirements from managers and executives, not from the workers and end users who will live with the system.

The "responsible AI" label has become particularly revealing in the last few years. Organizations that have faced public criticism over AI-related harms have responded in part by creating ethics offices, publishing principles, and releasing responsible AI frameworks. Some of this work is genuine. Some of it is governance theater, the isomorphic response I have written about in the context of AI policy and institutional isomorphism: organizations adopt the visible form of ethical governance to satisfy external legitimacy demands without making the substantive changes that would actually alter their practices. The ethics office exists. The product decisions are still made by the product team, governed by the same metrics.

One thing I find useful is the distinction between ethics as a floor and ethics as a ceiling. Compliance defines the floor: you must not violate these rules. The floor is set by law and regulation. But ethics, properly understood, does not stop at the floor. It asks what you should do given that you have the capability to do better. A platform that could design consent interfaces that genuinely facilitate informed choice but instead designs them to maximize acceptance is choosing to stay at the floor. That is not illegal. It is not ethical either.

This connects to the accountability question I wrote about in the algorithmic bias post. When an algorithm produces disparate outcomes, the compliance response is to check whether those outcomes violate any applicable regulation. The ethics response is to ask whether those outcomes are acceptable regardless of their legal status. In many cases, the compliance answer and the ethics answer are different. The false positive rate that differs by race may not violate a law. It may still be wrong.

My read is that digital ethics in practice requires three things that most organizations are not doing. First, asking the ethics question explicitly, separate from and before the compliance question. Second, giving the people who raise ethics concerns enough organizational protection and authority to have those concerns actually shape decisions, not just be noted and set aside. Third, including the people most affected by a system in the design process, not as a post-hoc validation step but as an input into what the system is supposed to do and for whom. None of these are technically difficult. They are organizationally and politically difficult, because they slow things down, complicate the product roadmap, and occasionally require the organization to decide not to build something it could build and monetize.

The compliance infrastructure that most organizations have built is real and in some cases effective at keeping them below the legal floor. It is not ethics. It is the minimum required to stay out of legal trouble. Calling it ethics is a category error that makes it harder to have the actual conversation about what should be built and why.