CT-GenAI: Energy Use of GenAI and AI Regulations, Standards and Frameworks

GenAI consumes energy because training and running large language models needs intensive use of many specialized computing resources, and every prompt a tester sends is processed on that hardware. The CT-GenAI syllabus (section 3.3) notes that LLMs are offered as web-based services, so their use increases the load on devices, networks and data centres, which leads to higher energy consumption.

This matters for testers because most GenAI use in testing is inference: drafting test cases, generating test data, summarizing defect reports, rewriting scripts. The device a tester types on does only a small part of the work. The model itself runs on the provider's accelerators, and each request and response crosses networks on the way. What each answer costs is the computation needed to produce it, repeated for every request.

Two things follow. First, the environmental impact of GenAI in testing is real even when the work is invisible to the person using it. Second, the people who run the hardware are not the only ones who influence the total: the test team decides how often, how heavily and with which model GenAI is used.

The energy of a single GenAI task is driven by the complexity of the task and the computational resources it requires. These are the two factors the syllabus names, and both describe the model's own work: what it is asked to produce and how much computing that takes.

The syllabus illustrates the difference with a widely cited comparison (Heikkilä 2023):

So, per request, image generation is far more energy-intensive than text generation. Producing a mock-up picture of a login page for a training deck costs much more than drafting an SQL query that seeds test data, writing acceptance criteria or explaining a stack trace. The figures are orders of magnitude to reason with, not exact measurements: the per-request cost also depends on the model's size and how much output it produces.

Energy consumption rises sharply as usage increases, so the total impact of GenAI in testing is set by how often models are called, not just by what one call costs. The syllabus accepts that a single search or text-generation task may seem negligible, but states that the cumulative effect across millions of users results in substantial environmental strain.

The same arithmetic applies inside one organization. Total energy is roughly unit cost × frequency, summed over every task:

• A chat assistant built into the test management tool, which every tester queries dozens of times a day, can outweigh a handful of heavy but occasional tasks.
• An expensive task attached to an automatic, frequent trigger quickly dominates the total.
• A cheap task run occasionally contributes little, whichever model it uses.

Training a model also consumes a great deal of energy, but it is largely a one-off cost. Inference is repeated for every request by every user, which is why usage patterns are where a test team has the most influence. Uncertainty about exact figures (next section) does not change this: volume still multiplies whatever the true unit cost is.

Accurate data on the environmental impact of GenAI is hard to obtain, yet it is clear that these energy-intensive operations collectively contribute to significant CO₂ emissions. The syllabus cites research for both halves of that statement (Luccioni 2024b on the difficulty of getting data, Berthelot 2024 on the emissions).

Few providers publish per-prompt energy or CO₂ figures. Those that do (since 2025, some have released median per-prompt estimates for their own services) use their own methods and boundaries, which are not standardized or independently audited, and the figures do not transfer to other models or workloads. Test teams therefore still work with estimates. The syllabus hands-on objective HO-3.3.1 asks learners to use a simulator to calculate the energy and CO₂ emissions of given GenAI test tasks and to observe how task characteristics and model usage change the result. The point of the exercise is to understand the drivers (task type, model size, number of interactions), not to produce a precise number.

Uncertainty about the exact figure does not make the impact small, and it is not a reason to stop using GenAI until exact figures exist. It is a reason to reason in relative terms: which tasks, models and usage patterns cost the most, and which of them are unnecessary.

Test teams reduce GenAI energy use mainly by limiting unnecessary model interactions and by selecting right-sized models for each test task. The syllabus calls adopting best practices such as limiting unnecessary interactions critical to mitigating environmental risk, and section 5.2.1 lists the environmental considerations testers need: optimizing model selection and usage patterns to reduce computational overhead, selecting right-sized models for test tasks, and balancing the benefits of GenAI automation against cost and energy consumption.

Right-sized models

A right-sized model is the smallest model that does the task to the required quality. Narrow, repetitive work, such as extracting field names and types from an API specification into a test-data template, often suits a small language model (SLM). Open-ended reasoning, such as reviewing a risk-based test plan for missing risks, can justify a large model. A smaller model saves energy only where it still meets the quality the task needs, so the choice is made per task rather than once for the whole team. Settings and prompt content that change the style or variety of output do not change which size of model a task needs.

Limiting unnecessary interactions

An interaction is unnecessary when it repeats work whose result is already available or adds nothing to quality. Typical patterns:

• Keep and reuse approved results: once generated material has been reviewed and accepted, store it and use it again rather than asking the model for it each time.
• Trigger generation by change: for example, regenerate API tests when the interface specification changes, rather than on a fixed timer.
• Retire generation that no longer pays off: periodically check whether each automated GenAI job still produces useful, changing output.
• Match verification effort to risk: extra checks that themselves call models (such as comparing outputs across models, a mitigation from section 3.1) multiply interactions, so they belong where an error would matter most.
• Avoid blind retries: asking the same model again and again does not, by itself, make an answer correct.

Some techniques add interactions on purpose and are still the right choice for difficult or critical work. The goal is not the fewest calls at any cost, but no calls that do not earn their place.

Where the biggest saving is

Because total energy is unit cost × frequency, rank candidate changes by how much of that product they remove. The biggest saving usually comes from eliminating frequent repetitions of the most expensive task, not from small efficiencies on tasks that were already cheap or rare.

GenAI use in testing should be justified by balancing the benefits of GenAI automation against its cost and energy consumption. These are the two factors the syllabus names for the cost side of the balance.

In practice the balance is struck task by task. Where GenAI output keeps delivering value, its cost and energy are earned; where it repeats identical work or never yields anything useful, they are spent for nothing. A business case for adopting GenAI in testing therefore estimates both sides, chooses models and usage patterns accordingly, and revisits the choice as tasks change. The same thinking appears in the GenAI strategy and LLM/SLM selection criteria covered in chapter 5.

The syllabus (section 3.4) names four key guidelines relevant to GenAI in software testing: two ISO/IEC standards, one regulation and one framework. Addressing GenAI risks such as reasoning errors, data privacy, vulnerabilities and environmental impact should take general AI regulations, standards and best practice frameworks into account.

A quick way to keep them apart is one keyword each: 42001 = organization-wide AI management; 23053 = ML lifecycle and data quality; EU AI Act = law, risk classes; NIST AI RMF = fairness and risk guidance.

Of the four guidelines, only the EU AI Act is legally binding, because it is a regulation; the two ISO/IEC standards and the NIST AI RMF are voluntary for organizations to adopt. The verbs in the syllabus table reflect this: the EU AI Act mandates compliance, while the others promote, provide or support.

Watch the names. ISO/IEC 23053's title begins "Framework for AI Systems Using Machine Learning", yet the syllabus types it as a standard, because it is an ISO/IEC standard. Likewise, the EU AI Act "establishes a legal framework" but is a regulation. The type comes from what the document is, not from the word "framework" in its description.

Two other real ISO/IEC standards are easy to confuse with the AI guidelines, but neither is one of the four the syllabus lists for GenAI in testing.

The shared words ("management system", "framework") are not enough to match a guideline: check the subject. Data-privacy regulations such as the GDPR belong to the data privacy and security risks covered in section 3.2 rather than to this list.

Test organizations must stay updated on the development of regulations, standards, national laws and best practice frameworks, because AI technologies and their regulatory landscapes continue to evolve. The syllabus presents its four guidelines as examples ("such as those in this table"), not a complete list.

In practice this means:

• Law depends on where and how AI is used. Which regulations and national laws apply can change whenever the context changes, for example a product launched in a new market or a new kind of AI use. Voluntary standards and frameworks an organization follows sit alongside binding law; they do not replace it.
• Adopted guidelines change too. Standards and frameworks are revised, and new companion guidance appears (for example, NIST has published a Generative AI Profile to accompany the AI RMF). Alignment checked once can go out of date.
• Compliance stays with the organization. Supplier documentation is a useful input, but the organization using GenAI in its testing remains responsible for meeting the obligations that apply to that use.

The EU AI Act itself applies in phases, with different obligations taking effect at different dates, which is one more reason the regulatory picture has to be watched rather than checked once.