Just Sustainability Design for AI Product Teams

Just Sustainability Design for AI Product Teams

AI product teams are trained to solve problems. Define the requirement, build the model, deploy the system, measure performance, iterate. Christoph Becker’s Insolvent, based on its title, table of contents, and introductory excerpt, challenges the assumptions behind this familiar workflow. What if the problem is not objectively given? What if the technology is not neutral? What if optimization creates debts that others must pay?

The book argues that computing in its current form is “insolvent”: unable to pay back the environmental and social debts it produces. The introductory bitcoin example is useful for product teams because it shows how a design decision can create systemic externalities. Energy use and e-waste are not random side effects; they are consequences of architecture.

AI systems create similar issues. Model size affects energy consumption. Data collection affects privacy and consent. Automation affects work. Ranking systems affect visibility and opportunity. Decision models affect access to services. Product teams cannot responsibly separate technical design from social impact.

Becker identifies myths that are deeply embedded in computing: technology as neutral, problems as objective, designers as rational agents, and design as straightforward problem-solving. In AI productization, these myths appear in phrases such as “we are just building the tool,” “the data speaks for itself,” or “the business gave us the requirements.” Each phrase hides design responsibility.

A just sustainability design approach would change the AI delivery process. Requirements would not only capture functional needs. They would also capture affected stakeholders, environmental constraints, justice concerns, uncertainty, and long-term consequences. Discovery would include indirect users and impacted groups. Architecture reviews would include sustainability and governance. Evaluation would include failure modes, bias, energy use, and social impact.

This is not anti-technology. It is better technology practice. Products that ignore hidden debts often become expensive later: regulatory remediation, reputational damage, user mistrust, technical rework, or organizational resistance. Products that account for these issues early are more resilient.

For consulting teams, Becker’s argument supports a stronger product framework. Start with problem framing. Who defined the problem? Which alternatives were excluded? Which values are implied? Then move to impact mapping. Who benefits directly? Who may be harmed indirectly? Which effects appear only over time? Then connect these insights to product requirements, governance controls, and measurable acceptance criteria.

In practical AI projects, this might mean limiting data retention by design, choosing smaller models where sufficient, adding human appeal mechanisms, measuring energy footprint, documenting training data boundaries, or refusing automation where the organizational problem is actually social rather than computational.

At Ozycore, the principle would be: responsible AI is not a compliance add-on; it is systems design. Sustainability and justice must enter the backlog, architecture, interface, monitoring, and operating model.

The next generation of AI products will be judged not only by accuracy and speed, but by the debts they avoid creating.