In projects meant to include everyone, why does 'should we even build this AI?' never make it onto the list of choices?

This explores why people invited to help shape an AI project almost never get to answer the most basic question: should this be an AI system at all? The short answer from the corpus is that the outcome is mostly decided before anyone is invited in. An analysis of 80 participatory-AI papers found that stakeholders shaped the user interface in every project but influenced core model decisions in only about 10% of them Does participatory AI actually give stakeholders real power?. Project leads usually chose who took part, and they used preference-elicitation methods: 'which of these options do you like better?' That format leaves the designers in charge. When the menu only lists versions of the AI system, 'none of the above' isn't one of the choices.

The word 'participatory' also covers very different practices. The corpus identifies eight traditions behind participatory AI work, including user-centered design, co-design, participatory design and value-sensitive design, and each assumes a different balance of power What participatory traditions shape AI design practice?. User-centered design treats people as sources of requirements for a product that is already going to be built. Participatory design began as a political movement to give workers a say over the technologies being brought into their workplaces, and in that tradition rejecting the technology is a legitimate result. So the real question is which tradition a project is borrowing from. Many projects use the vocabulary of the more democratic traditions while following the methods of the more product-driven ones.

The broader corpus suggests that shutting out refusal works against the projects themselves. A historical analysis running from GPS to today's AI agents finds that capable systems often stall because ecosystem conditions are missing, and social acceptability is one of five named conditions Why do capable AI agents still fail in real deployments?. A stakeholder saying 'we don't want this' is early evidence that a condition is missing. Evans makes a related point from the enterprise side: making tools easier to build doesn't fix the fact that workers often don't see their own tasks as automatable, or that adoption depends on organizational decisions that cut across departments Does easier tool-building actually solve enterprise adoption problems?. Whether AI is the right answer is a question about the organization, and it can't be settled by tuning the interface.

Another point the corpus raises is that use is not the same as consent. Stack Overflow's 2025 survey found that about 80% of developers use AI tools, while their trust in the tools' accuracy fell from 40% to 29% Why do developers keep using AI tools they don't trust?. People keep using technology they doubt because the surrounding environment expects it. In participatory projects, the same effect can make stakeholders look like they've accepted AI when they just weren't given a realistic way to decline. That's why a design process that only measures preferences between options can't detect rejection.

One caveat: the corpus has strong material on how participation gets narrowed, but little that directly studies projects where stakeholders refused AI, or the methods that would make refusal possible. The material points to three likely ways in: frame 'no system' as a valid outcome, let stakeholders shape the problem and not just the interface, and draw on traditions that treat participation as power-sharing and not as gathering feedback.