Standards for discussing the environmental impact of AI in social work
Why "AI" is the wrong unit of environmental analysis
I care about the environmental cost of AI. I have built an active research program around small, local, open-weight models precisely because I take the energy, water, and carbon footprint of this technology seriously. That commitment is also the reason I find much of the current environmental conversation in social work unsatisfying. The stakes are real, but the analysis is often too coarse to guide action. A field that cannot distinguish a frontier model running in a hyperscale data center from a model running offline on a desktop computer has little useful to say about the environmental cost of either.
This post proposes five standards that any environmental discussion of AI in social work should meet. I will state them up front and then walk through each one.
Specify which model is running, where, and for what task.
Distinguish inference costs from training costs, and acknowledge embodied hardware costs honestly.
Treat right-sizing as a core environmental practice.
Apply the environmental justice lens to the actual system in question.
Anchor quantitative claims to sources that describe the specific system, not to aggregate statistics applied indiscriminately.
None of this is a defense of frontier AI. It is the opposite. The environmental stakes warrant analysis rather than slogans.
Specify the model, the location, and the task
The word “AI” in most social work writing functions as if it referred to a single technology with a single environmental cost. It does not, and the problem runs deeper than most critics acknowledge.
Read the field’s recent writing on the environmental consequences of AI, and a pattern becomes clear. The concerns are almost always about large generative models accessed through hyperscale APIs. That narrow category is then quietly relabeled “AI,” and the conclusions are generalized to everything the term might cover. The relabeling is the move that does the damage, because everything the term covers is a much larger set.
Encoder-only models such as BERT and ModernBERT do classification and extraction work without generating a single token. Embedding models turn documents into vectors for retrieval and similarity search, and a typical embedding call is a fraction of the workload of a generative query. Classical methods, including logistic regression, random forests, and gradient-boosted trees, have been in routine use in social work research for decades and remain the right tool for many tasks a researcher might want to perform. All of these are AI by any reasonable definition. Their environmental profiles differ from those of frontier generative models in ways that a serious analysis cannot ignore. A researcher classifying case notes with a fine-tuned encoder on a laptop is not doing the same thing, environmentally or technically, as a practitioner running a long-context prompt through a frontier API, and a critique that cannot tell them apart is not yet describing the technology it claims to assess.
The second layer of specification sits inside generative AI itself. Consider where the field stood at the beginning of April 2026. Google released Gemma 4, a family of open-weight models that anyone can download and use for free. The smallest members of that family are designed to run on a phone. A social worker with a recent Android device or a current iPhone can install the Google AI Edge Gallery app, download a model, switch to airplane mode, and have a useful conversation with an assistant that never contacts a server. The model sits on the phone the way a podcast episode sits on the phone.
That is not the same technology as a frontier model accessed through ChatGPT, Claude, or Gemini. Frontier models live in hyperscale data centers and depend on warehouses full of specialized chips, dedicated power substations, and industrial cooling systems. A small open-weight model running on a device you already own relies on hardware already sitting on your desk or in your pocket. The two cases differ substantially in the energy they draw and the infrastructure they require. Treating them as the same thing when writing about environmental impact is a category error, and it is the second one the field routinely makes after collapsing all of AI into generative AI in the first place.
Any environmental argument should therefore be able to answer two questions rather than one. What kind of model is running, generative or otherwise? And if it is generative, where is it running and on what scale of infrastructure? A critique that cannot answer either has not yet reached the point where environmental analysis can begin.
Distinguish inference from training, and acknowledge embodied costs
The strongest version of the opposing view deserves a direct response. Small local models exist only because someone, somewhere, trained large ones first. The hardware that runs them carries embodied carbon from manufacturing, regardless of where inference happens. Both observations are correct, and neither is what I am contesting.
The claim I want to make is more specific. Training costs are real, but they are amortized across every subsequent use of a model, and open-weight releases distribute that amortization across a much larger and more diverse user base than a proprietary API does. A model trained once and downloaded by millions is a different environmental object than a model trained once and served exclusively through a metered endpoint.
Embodied hardware costs are also real, and this is where the argument needs care. A laptop already sitting on a practitioner’s desk carries no marginal embodied cost when it is used for local inference. A workstation or small GPU server purchased specifically for local inference does carry such a cost, but the relevant comparison is not local hardware against nothing. It is local hardware against the share of data center capacity that a comparable workload would consume over the same period. A single workstation, manufactured once and used for years across many workloads in an agency or a school, sits in a different category from hyperscale infrastructure that depends on continuous buildout, dedicated power substations, industrial cooling, and sustained water withdrawals. Treating the two as environmentally equivalent because both involve hardware is the same flattening move I am arguing against throughout this piece.
An honest environmental discussion should make these distinctions clear rather than collapsing them into a single, undifferentiated cost.
Right-sizing is an environmental practice
Some tasks genuinely require large generative models running on large infrastructure. Long-context reasoning across complex documents, high-quality code generation, and several multimodal tasks currently depend on frontier systems. Those uses carry real environmental costs and should be discussed accordingly.
Many tasks do not, and the right-sizing argument has two axes rather than one.
The first axis is whether the task needs a generative model at all. A great deal of the text work that fills a social work research pipeline or an agency workflow is classification, extraction, retrieval, or similarity search. Labeling case notes by service type, pulling structured fields from intake forms, finding the policy documents relevant to a question, or grouping records by topic are all tasks an encoder-only model or an embedding pipeline can perform at a fraction of the computational cost of a generative query. For many of them, a logistic regression or a gradient-boosted tree trained on a modest labeled sample will match or exceed the accuracy of a large language model while running on a laptop in seconds. Reaching for a frontier generative model to do work that a fine-tuned encoder or a classical classifier would handle is not a neutral choice. It is a more expensive choice, both financially and environmentally, and often less accurate.
The second axis sits inside generative AI. When a task does call for a generative model, the question becomes which one. Summarizing a short document, drafting a routine email, tidying up meeting notes, or rewriting a paragraph for clarity can be handled by small open-weight models running locally. When practitioners and educators reach for the largest available frontier model to do work that a small-parameter model on a laptop could adequately complete, the cost is not only financial. It is environmental and avoidable.
Right-sizing, which is the practice of matching the tool to the task across both axes, is therefore a core environmental position. An honest environmental argument in social work should name it as such. It should point readers toward classical methods where they remain appropriate, and toward Ollama, LM Studio, and the Google AI Edge Gallery for the cases where a small generative model is the right choice. The individual case matters, but the institutional case matters more. The environmental argument for right-sizing becomes substantial when a school of social work, a child welfare agency, or a legal aid organization adopts local and task-appropriate tools as the default rather than routing every problem to a frontier API. A critique that warns about the carbon cost of AI while ignoring the existence of tools that run on a laptop does not give readers the information they need to act.
Apply the environmental justice lens to the actual system
The environmental justice framing matters. Data center siting decisions, water withdrawals in drought-stressed regions, and the uneven distribution of environmental harms across communities are legitimate concerns that belong in this conversation. The lens, however, only works when applied to the specific system under discussion. Invoking environmental justice while failing to distinguish between a cloud-based frontier model queried through a hyperscale API and a small open-weight model running offline does not advance the cause of environmental justice. It borrows the moral authority of that framing without conducting the environmental analysis it requires.
A properly specified environmental justice analysis would name the data center, identify the community affected, describe the water and power draws of that specific facility, and connect those harms to the particular model families and workloads the facility supports. That is a harder piece of writing than a general invocation, and it is also the one the field actually needs.
Anchor the numbers
Quantitative claims about energy, water, and carbon should be tied to sources that describe the specific system in question. Aggregate statistics about “AI” as a category are not usable evidence for a claim about a particular workflow. If the claim is that a specific task on a specific model carries a specific cost, the citation should support that level of specificity. If the only available numbers are aggregate, the claim should be scaled back to what those numbers can actually support.
What this looks like in practice
A presentation, LinkedIn post, or paper that meets these five standards will look noticeably different from most of what is currently being discussed. It will name models. It will distinguish inference from training. It will treat local, open-weight alternatives as part of the environmental conversation rather than as a technical footnote. It will apply environmental justice framing to specific facilities and specific workloads. It will use numbers that actually describe the system under discussion.
That is a higher bar, and it should be. The communities whose water and air are affected by data center expansion deserve analysis at that level. So do the practitioners trying to decide what tools to adopt and what defaults to set for their organizations. Meeting the bar is the work. The standards above are where it starts.