MEASURE-2.12: Environmental impact and sustainability of AI model training and management activities – as identified in the map function – are assessed and documented.

MEASURE-2.12 requires you to assess and document the environmental impact and sustainability of your AI model training and ongoing model management activities that you already identified during the MAP function. Operationalize it by defining scope (which models and activities), selecting measurable indicators, collecting data from infrastructure and third parties, recording decisions, and refreshing the assessment on a set cadence. ¹

Key takeaways:

• Scope the assessment to training and model lifecycle operations already captured in your MAP inventory, not “AI in general.” ¹
• Put numbers and sources in writing: what you measured, how you estimated, and who approved tradeoffs. ¹
• Build a repeatable control: named owner, procedure, evidence set, and recurring refresh tied to material model changes. ¹

If you can’t show how you assessed the environmental impact of training and operating your models, you will struggle to defend AI governance claims to internal audit, customers, and regulators that increasingly ask for ESG-aligned accountability. MEASURE-2.12 is a “measure and document” requirement: you are expected to evaluate the environmental impact and sustainability considerations of AI model training and management activities, and keep a durable record of what you found and what you decided. The scoping phrase “as identified in the map function” matters because it anchors the work to your existing AI system inventory and lifecycle understanding rather than an open-ended sustainability program. ¹

For a CCO, GRC lead, or model risk owner, the fastest path is to treat MEASURE-2.12 like a control with a clear boundary: define which models and lifecycle activities are in scope, define the indicators you will track (even if you must estimate), document assumptions, and establish a refresh trigger (for example, major retrains, architecture changes, cloud region changes, or material usage increases). This page gives requirement-level guidance you can execute without waiting on a full ESG transformation. ¹

Regulatory text

Requirement excerpt: “Environmental impact and sustainability of AI model training and management activities – as identified in the map function – are assessed and documented.” ¹

What the operator must do:

1. Identify the AI training and model management activities already captured in your MAP function inventory, 2) perform an assessment of environmental impact and sustainability for those activities, and 3) document the assessment in a way that is reviewable and repeatable (including assumptions, data sources, and decisions). ¹

Plain-English interpretation

You need a defensible write-up that answers: “For this model, what is the environmental footprint of training and operating it, what sustainability risks exist in the way we run it, and what actions or tradeoffs did we approve?” The requirement is not asking you to hit a specific emissions target. It is asking you to measure and document the impact, based on the AI activities you already mapped. ¹

Who it applies to (entity and operational context)

This applies to organizations developing or deploying AI systems, especially where you:

• Train models (foundation, fine-tuned, classical ML) on owned or third-party infrastructure.
• Retrain regularly (drift management, continuous learning, periodic refresh).
• Run inference at scale (customer-facing services, decision engines, batch scoring).
• Use third parties for compute, MLOps platforms, data labeling, or model hosting, where your footprint is partially dependent on their infrastructure choices. ¹

Common accountable owners:

• Model owner / product owner (scope and business rationale)
• ML engineering / MLOps (training and inference telemetry)
• Cloud / infrastructure (energy/carbon reporting inputs)
• GRC / compliance (control design, evidence, audit readiness)
• Procurement / third-party risk (supplier data, contract terms)

What you actually need to do (step-by-step)

Treat this as a lightweight assessment workflow that you can run per material model, then maintain.

Step 1: Lock scope to the MAP inventory

Create a list of in-scope items directly from your AI system inventory produced in MAP:

• Model name/version and intended use
• Training type (from-scratch, fine-tune, retrain cadence)
• Runtime pattern (batch, real-time, hybrid)
• Environments (dev/test/prod), regions, and compute types
• Key third parties involved (cloud, platform, labeling, monitoring) ¹

Output: “MEASURE-2.12 scope register” tied to your model inventory.

Step 2: Define assessment boundaries and methodology (document first)

Decide and record:

• Boundary: training only, inference only, or full lifecycle (recommended: both training and material ongoing management activities, since the requirement names both). ¹
• Method: direct measurement (metered usage) vs. estimation (provider calculators, internal conversion factors).
• Allocation: how you allocate shared compute (multi-tenant clusters, shared GPUs).
• Materiality triggers: what changes force reassessment (new base model, more frequent retraining, new region, new hardware class). ¹

Operator tip: auditors do not need perfection; they need consistency and traceability. Document how you measure and where the numbers come from.

Step 3: Collect the minimum viable dataset

Build a repeatable data pull that covers:

• Training runs: job metadata, duration, instance/GPU type, region, number of runs, failed runs (waste factor).
• Inference: average and peak resource use, autoscaling behavior, batch windows, caching.
• Storage and data movement: large dataset storage tiers, cross-region transfer, retention policies.
• Third-party attestations/inputs: cloud sustainability reporting artifacts you can obtain under contract, plus any platform-specific usage exports. ¹

If you cannot get primary energy/carbon data from a third party, record the request, the response, and the fallback estimation method you used. That paper trail matters.

Step 4: Assess environmental impact and sustainability risks

Your assessment should include both quantitative indicators (where available) and qualitative sustainability risks. Examples to include:

Quantitative (choose what you can support with data):

• Compute consumption proxy (GPU-hours/CPU-hours)
• Total training workload volume (number of runs, retrains)
• Inference workload volume (requests/jobs) and resource intensity
• Region-based considerations (where the workload runs)
  Record the calculation approach and data source for each measure. ¹

Qualitative sustainability risk review (always feasible):

• Efficiency controls (early stopping, right-sizing, scheduling off-peak where appropriate)
• Waste reduction (failed run reduction, experiment tracking discipline)
• Lifecycle management (model decommissioning, archiving policies)
• Supplier dependency (limited visibility into a third party’s footprint; contract gaps)
• Governance: who can approve very large training jobs and what review occurs ¹

Deliverable: a “MEASURE-2.12 assessment memo” per model (or per model family) with an executive summary and an appendix of data sources.

Step 5: Decide and document actions, tradeoffs, and approvals

The requirement is “assessed and documented,” but operationally you need to show that the assessment feeds governance. Document:

• Optimization actions you will take (right-size instances, reduce retrain frequency where acceptable, improve experiment controls)
• Accepted tradeoffs (higher footprint justified by risk reduction, safety improvements, or required performance)
• Approvals (control owner, model owner, and any required committee sign-off) ¹

Step 6: Implement recurring evidence collection

Convert this into a control with:

• A named control owner
• A procedure (data pull, assessment template, review steps)
• A recurring schedule aligned to model changes and operating rhythm
• A repository path and retention expectations ¹

If you use Daydream, treat this as a mapped control with automated evidence requests to engineering and procurement, and a standard assessment template stored alongside model risk documentation. ¹

Required evidence and artifacts to retain

Keep artifacts that prove scope, method, data provenance, and governance decisions:

Core artifacts (exam-ready):

• AI inventory extract showing the in-scope models/activities from MAP ¹
• MEASURE-2.12 methodology statement (boundary, estimation approach, allocation method) ¹
• Per-model (or per-family) environmental impact assessment memo with:
  • training + management activities covered
  • inputs and assumptions
  • results and limitations
  • decisions and approvals ¹
• Raw evidence: job logs/exports, cloud billing/usage exports, MLOps experiment tracking extracts, region/config snapshots
• Third-party evidence: sustainability/energy/carbon statements received, contract clauses, and correspondence showing requests and responses
• Change triggers: retrain tickets, model version release notes, architecture change records tied to reassessments

Common exam/audit questions and hangups

Expect reviewers to probe for control boundaries and repeatability:

1. “Show me which training and management activities you assessed, and how you know the list is complete.”
   Tie back to the MAP inventory and your MLOps pipelines. ¹

2. “Where did the numbers come from?”
   Have a data lineage note: logs, billing exports, third-party reports, and estimation formulas. ¹

3. “How do you reassess after changes?”
   Point to defined triggers and evidence that a change resulted in a refreshed memo. ¹

4. “Who approves high-impact training runs?”
   Show approvals, thresholds (if you set them), and an exception process.

5. “How do you handle third parties?”
   Show due diligence steps and contract hooks for reporting.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Better approach
Writing a generic ESG paragraph with no model-specific assessment	Doesn’t satisfy “assessed and documented” in a reviewable way	Use a per-model template with inputs, method, and results 1
Scoping only initial training and ignoring retraining/inference	“Training and management activities” includes ongoing operations	Include retraining cadence, monitoring, and inference footprint proxies 1
Relying on a third party’s marketing claims	Not auditable	Request primary artifacts or document fallback estimates and limitations
No refresh trigger	Memo becomes stale immediately	Tie reassessment to material model and infrastructure change events
No owner	Work becomes ad hoc	Assign a control owner and embed into MLOps change management 1

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the supplied sources. Practically, the risk shows up as: (a) inability to substantiate sustainability claims to customers or procurement questionnaires, (b) internal audit findings for incomplete AI governance controls, and (c) reputational and contracting risk when counterparties ask for footprint transparency and you cannot produce consistent documentation. Keep your language factual and evidence-based, and avoid making external sustainability claims that your internal assessment cannot support. ¹

Practical 30/60/90-day execution plan

First 30 days (stand up the control)

• Name an owner (GRC or model risk) and contributors (MLOps, infra, procurement).
• Pull your MAP inventory and identify in-scope models and lifecycle activities. ¹
• Publish a one-page methodology: boundaries, inputs, estimation rules, and reassessment triggers.
• Create an assessment template and an evidence checklist in your GRC system.

Days 31–60 (run assessments for priority models)

• Select priority models (highest compute, highest business criticality, most frequent retrains).
• Collect training/inference logs and billing/usage exports; request third-party sustainability artifacts.
• Complete assessment memos and hold review meetings with model owners; record decisions and action items. ¹

Days 61–90 (operationalize and scale)

• Integrate evidence collection into MLOps workflows (release checklist, retrain approval, change tickets).
• Add procurement requirements for third-party reporting where gaps exist.
• Establish recurring reporting to your AI governance forum (status, exceptions, improvements).
• Configure Daydream (or your GRC tool) to issue recurring evidence requests and track completion against the MEASURE-2.12 control. ¹

Frequently Asked Questions

Do we have to calculate carbon emissions to meet MEASURE-2.12?

The requirement says “assessed and documented,” not “calculate emissions.” If you can estimate emissions credibly, include them, but a defensible assessment can start with compute and operational proxies plus clear limitations. ¹

What counts as “model management activities”?

Include the operational lifecycle work that keeps the model running: retraining, monitoring, inference hosting, scaling, storage/retention, and decommissioning. Tie the list back to what you identified during MAP. ¹

We use a third-party hosted model. Are we still in scope?

Yes, because you are deploying AI and operating it through a third party. Assess what you can (usage volume, regions, request patterns) and document what you requested from the third party and what you could not obtain. ¹

How granular should the assessment be: per model, per product, or per platform?

Start where your telemetry is strongest. Many teams do per-model-family assessments with a shared methodology, then add model-specific deltas for high-impact models. The key is that scope matches the MAP inventory and remains reviewable. ¹

How do we keep this from becoming a paperwork exercise for engineers?

Use existing artifacts first (job logs, billing exports, experiment tracking) and automate evidence pulls. Engineers should review the memo for accuracy, not manually compile sustainability narratives. ¹

What if our data is incomplete or estimates change later?

Document the limitation, the estimation method, and a plan to improve data quality. Auditors usually accept early-stage estimates if they are clearly labeled and consistently applied across models. ¹

Footnotes

1. NIST AI RMF Core