How AI is used in Position Green's Carbon Management

An overview for customers, auditors, and partners

1. Summary

Next-gen is Position Green's new generation of Carbon Management. This document describes where artificial intelligence is used inside it, what each AI component does and does not do, and how any AI-assisted value can be traced back to its source.

The governing design rule is: AI proposes, deterministic code decides, a human approves. It is enforced by architecture, not by policy:

AI never returns free text where a number is needed. Every agent is bound to a JSON schema at the API call, so its output is a typed record - a classification, a candidate concept, a conversion factor - not prose a downstream parser has to interpret.

AI never performs arithmetic that reaches a reported figure. Where an agent produces a quantity-shaped value it returns the inputs, and platform code multiplies. The calculation engine, aggregation engine, unit conversion and factor ranking are deterministic code with unit tests.

AI never picks the final emission factor. At most an agent picks an archetype concept ("parquet flooring"). The concrete factor is then chosen by a pure ranking function on region proximity → specificity tier → vintage year → stable tie-break.

Everything AI touched is attributed. Records carry a source field distinguishing registry data, predictive models, AI agents, and user-set values. Supplier and library records are temporal, so the previous value and how it was set remain readable after a change.

The benefit AI delivers is throughput on the messy parts: reading a PDF invoice, deciding that "TRANSPORTKOSTNAD" is a freight fee rather than a purchased good, recognising that "Eik parkett 14mm" is oak parquet. Those are language problems. The carbon accounting stays arithmetic.

Four principles follow from that rule.

Human-in-the-loop by design. No AI output enters a reported figure without passing through a state where it can be accepted, edited, or rejected. Matches below the trusted confidence band collect in review queues showing the proposal, its certainty, and the source text; every field of a generated decarbonization action is an editable form field. Regeneration is granular and preserves user edits made at earlier steps.

Explicit invocation. Every customer-facing AI run is triggered by a user action. No background process autonomously re-classifies or re-values a customer's existing approved data.

Methodology lives in code, not in prompts. GHG Protocol scope and category placement, the specificity ladder, EN 15804 lifecycle handling, and double-counting guards are deterministic library logic. Prompts are versioned database records, and exactly one version per agent can hold PUBLISHED status - enforced by a unique database index.

Accuracy over coverage. Agents are permitted, and prompted, to return "no match". Archetype assignment returns a null archetype rather than a forced fit; the research agent reports finding nothing rather than inventing a factor. An empty answer routes to a human; a fabricated answer would not.

2. Where AI is used

2.1 Document ingestion and extraction

The largest AI surface is invoice and document processing. Upload a PDF to run a pipeline of narrow, separately-versioned agents rather than one large "read this invoice" prompt. Each stage has one job and a strict output schema.

Two behaviours matter for assurance. Non-goods lines are routed away from activity data - fee, tax, and financial-flow lines are flagged to skip factor assignment, so a bank charge does not become a purchased good. And estimated mass is quarantined: a mass inferred from a product description lands in a separate field with basis: mass_estimate and is treated downstream as a flagged estimate, never as a measured quantity.

Spreadsheet and ERP column mapping is not AI. It is rule-based code, as are currency normalization, incoterm handling, unit conversion, and organisation-number cleanup.

2.2 Classification

Supplier classification resolves through a cascade in which AI is a fallback, not the first resort: official registry by organisation number → predictive (non-generative) sector classifiers → third-party directories → AI classification → AI with web research. The winning source is recorded on the row, so "how do we know this supplier is in sector X" always has an answer.

Supplier name validation is a privacy control implemented with AI. Before a name becomes a supplier, an agent classifies it as a real supplier, sensitive data, anonymized, or other bad data - so employee names and private individuals in a purchase ledger are quarantined rather than silently entering a carbon inventory.

Archetype assignment. Rather than asking a model to choose among thousands of near-duplicate factors, the platform offers a bounded set of archetype cards - concepts with a name, description, available denominator units, and variant count - and the agent picks one, or none, with a confidence and a written reason.

GHG scope and category placement is not an AI decision. It resolves from the library's declared category envelopes, the customer's emission boundary, and explicit anti-pattern rules that forbid combinations which look plausible but are wrong (wood pellets under mobile combustion, for example). An AI suggestion cannot bypass an anti-pattern rule.

2.3 Emission factor matching

This is the most important distinction in the document.

What AI does: narrows the search space. It reads "Eik parkett 14mm, 2,3 m²" and proposes the concept parquet flooring. A second agent then independently validates the resulting product ↔ factor pair - a cheap check against the most common failure mode, a confident-but-wrong match.

What AI does not do: choose the number. Once the concept is fixed, the factor is selected by a pure ranking function applied within each lifecycle stage: region proximity (parent-walk distance, so exact match beats country beats bloc beats global) → specificity tier (§4) → vintage year (the most recent not after the reporting year) → a deterministic tie-break. A lifecycle-stage overlap guard then removes variants that would double-count a higher-priority stage, recording each removal.

This function is ordinary, unit-tested, side-effect-free code: same inputs, same factor, every time. No language model participates in it. Weak matches are surfaced rather than silently accepted - a null archetype, a low confidence, or a failed validation routes the line to review.

2.4 Gap handling and factor discovery

Gap handling in the inventory is deterministic: when no specific factor exists, the selector falls back down the specificity ladder to a spend proxy and tags the figure with the tier it used. AI does not invent activity data - it never fabricates a consumption figure, a spend amount, or a supplier's reported emissions. Where source data is missing, the output is an explicitly-labelled proxy or an explicit gap.

The long tail of purchased goods is where spend-based sector factors are least precise and where the library has no specific factor. From a spend-based line, ask the platform to discover a product-specific physical factor. Discovery runs asynchronously and returns a notification showing the proposed factor, its source, and its certainty, to accept or deny - sent even when discovery finds nothing, so a silent non-result cannot be mistaken for a pending one. Where nothing clears the threshold, the existing spend factor stays in place.

Certainty here is measured, not asserted. The score is composed from independently-checkable signals: whether the unit fits the product class; whether the cited URL resolves and its domain is on the allowlist of recognised factor databases; whether the figure is actually stated on the page when fetched; the authority tier of the source; and whether geography and year match the reporting context. The model's own confidence is weighted at zero, and retrieval is constrained to the allowlist rather than the open web. Accepting applies the factor as a company-scoped override, not a write into the shared library; promotion into the canonical library is a separate, reviewed step performed by Position Green, so one customer's accepted result never silently changes another's emissions.

2.5 Decarbonization planning

The second major AI surface. Agents propose scored decarbonization levers with written justifications, expand them into candidate actions, and - on request - turn a one-line idea into a modelled action through roughly a dozen cooperating agents covering description, requirements, component quantities with persisted reasoning steps, affected emission sources, residual consumption, parameter sourcing, and cost estimation. Each run is a record with mode, status, requesting user, exact inputs, timestamps, and locking against concurrent generation.

Parameter sourcing is ordered deliberately: an existing-parameter-match agent first tries to reuse the customer's own historical parameters or a library parameter, and only if none fits does a research agent run - whose output must carry a source URL and store the search results it consulted. Scenario modelling itself is deterministic: once parameters exist, the trajectory, action impact, and roll-ups are computed by the calculation engine. AI populates the model; it does not run it. Elsewhere, AI summarizes uploaded documents on ingest and generates risk narratives in ESG due diligence.

3. What AI deliberately does not do

The last row is a deliberate boundary rather than a gap. Disclosure text carries legal and assurance weight, and automating a first draft does not outweigh the risk of an unsupported claim entering a published report. What the platform provides instead is the material for the narrative: specificity tier distribution, factor sources and vintages, the share of spend-based versus activity-based emissions, and the count of unverified classifications. The reporting team writes the words and owns them.

Arithmetic is withheld from models for the same reason: a model's arithmetic is neither reproducible nor auditable, and there is no reason to accept either weakness for an operation a computer already does perfectly.

4. Methodology and calculation integrity

4.1 The specificity ladder

Every applied emission factor carries a specificity tier, which is both the ranking key in factor selection and the data-quality signal in reporting:

The threshold at rank 5 is the activity-versus-spend cut used by every spend-based totals query, which makes "how much of our inventory is spend-based?" answerable at any level of aggregation. Tracking the share of emissions at each tier, period over period, is a defensible data quality narrative that comes straight out of the platform.

AI's contribution to moving up this ladder is indirect but material. Spend-based estimation exists largely because reading an invoice line by line is expensive. AI-assisted invoice processing converts a spend line ("NOK 42,000 to a building supplier") into an activity line ("2.3 m² of oak parquet") - the move from rank 8 to rank 3–4, at a cost per document manual processing cannot match. Factor discovery does the same for the long tail. But AI does not upgrade a tier by assertion: the tier follows from the factor actually applied, and if only spend data exists it stays a spend proxy regardless of how confident any agent is.

4.2 Emission factor governance

The library is curated by Position Green, not generated by AI. It is a classification hierarchy whose leaves are archetype concepts, each anchoring variants that carry figures with units, region, vintage year, lifecycle stage, and specificity tier.

Every curation operation is recorded in an append-only log and can be reverted, with each row's live status derived from the log rather than overwritten. Library and supplier records are temporal: a change writes a new version and closes the previous one's validity window, so historical calculations remain reconstructable against the factor version current at the time.

AI's role in the library is limited and internal. An agent enriches rows with search-friendly generic names to improve matching. It does not create, alter, or approve emission factor values, and AI-proposed archetype bindings during import are suggestions for a curator to confirm, never auto-applied.

4.3 Audit trail

For any AI-assisted value, stored records yield: the source data (the uploaded document with its upload record, or the source transaction); which AI ran, by agent and agent version, and the model that version specifies; what it was given, as an input snapshot plus the versioned prompt template; what it proposed, with confidence, reasoning, and cited sources; what the user decided, via the verified flag, the AI-set versus user-set source, and the prior version with its validity window; which factor was applied and why, with identity, version, region, vintage, tier, and the ranking that selected it; and when and at what cost. If an agent's prompt changes, outputs produced before and after remain distinguishable by the version recorded on them.

5. Reviewing AI output

5.1 Three distinct signals

Uncertainty level - how much the platform trusts a supplier match or classification:

Model-reported confidence - a score the model assigns to its own output. It is a self-assessment, and it is not calibrated. A 0.9 does not mean 90% of such matches are correct. Use it to rank what to review first, not as evidence that a match is right.

Composed certainty - the score attached to a discovered factor (§2.4), built from independent checks against the world with the model's own confidence weighted at zero. This is a measurement rather than an opinion, and it can be argued with on its components.

The two signals worth more than any model-reported score are structural: whether an invoice's extracted lines reconcile to its printed totals, and whether the independent validation agent passed the product/factor pair.

5.2 Working the review

Accepting a suggestion sets a verified flag while the row's source remains the AI source, so acceptance stays distinguishable from origination. Editing writes a new version with a user-set source and the editing user. Regenerating creates a new run with its own input snapshot, preserving earlier user edits.

The queue is a work list, not a quarantine. An unverified Confident match still applies its factor to emissions - it is not blocked. Review is enforced by workflow design rather than by a blocking approval gate; implement segregated maker–checker sign-off as a process control on top of the queues if required, using the platform's record of who verified what and when. Prioritize by emissions exposure, not confidence score, and verify against a source rather than to clear a list.

The general rule for assurance: the platform records what the AI assumed; the user records why that assumption is acceptable. The first is automatic, the second is not, and only the pair is defensible.

6. Data governance and security

6.1 What data AI may process

What is not sent: user credentials, authentication tokens, platform access-control data, billing data, or the aggregate emissions results of other tenants. Prompts are constructed per request from that request's tenant-scoped data.

One caveat to understand: invoice processing sends the whole document. If a PDF contains information beyond what carbon accounting needs - personal names, bank details, contract terms in the footer - that content is part of what is sent. Where this matters, upload a structured extract rather than the full PDF, and pseudonymize person-name suppliers before export.

6.2 Providers and processing regions

Both providers are reached under Position Green's own cloud contracts, in European regions. No customer data goes to a consumer AI service or a shared public API endpoint. Web-grounded research runs on search-grounded Gemini, and its inputs are research questions about technologies and factors rather than customer transaction data. Provider selection is configuration, not code: each agent's prompt version names the model it uses, so the provider mix is auditable and changeable per agent without a deployment.

Chat and completion models use Azure Data Zone capacity, Azure's EU-scoped deployment type. Microsoft's terms state that for a Data Zone deployment in a resource located in an EU member nation, "prompts and responses may be processed in that or any other European Union Member Nation," and that data at rest remains in the customer-designated geography. The Foundry endpoint used for factor discovery sits in Norway East - within the EEA rather than the EU; where an EU-only processing boundary is a requirement, assess that endpoint on its own terms.

6.3 No training on customer data

This is a contractual commitment from both providers, not an inference.

Microsoft. Prompts, completions, and embeddings "are NOT available to OpenAI or other providers of Models sold by Azure," "are NOT used by providers of Models sold by Azure to improve their models or services," and "are NOT used to train any generative AI foundation models without your permission or instruction." The models are stateless - "no prompts or completions are stored in the model" - and run in Microsoft's own Azure environment, where they "do NOT interact with any services operated by providers of Models sold by Azure, for example, OpenAI (e.g. ChatGPT, or the OpenAI API)."

Google. The Google Cloud Service Specific Terms state: "Google will not use Customer Data to train or fine-tune any AI/ML models without Customer's prior permission or instruction." On retention, the same terms commit that "absent Customer's prior permission or instruction, Google will not store outside Customer's Account (i) Customer Data prompted to a Generative AI Service for longer than is reasonably necessary to create the Generated Output, or (ii) the Generated Output."

Provider-side abuse monitoring is the one place data may be retained. Azure classifies prompts and completions for harmful content and scores usage patterns. Content sampled for automated review "is not stored by the abuse monitoring system or used to train the AI model or other systems." Content flagged as harmful, or as part of a potentially abusive pattern, may be stored separately and in a subset of cases seen by authorized Microsoft employees through Secure Access Workstations with just-in-time approval; for EEA deployments, Microsoft states those reviewers are located in the EEA. Microsoft offers modified abuse monitoring, an application-gated option that removes the storage and human review step entirely for approved customers, verifiable directly on the Azure resource. Google's terms carry no equivalent retention carve-out.

6.4 Retention, credentials, and access

Stored inside the platform (customer database, EU-hosted, tenant-scoped, under the standard retention policy): AI outputs, execution metadata (agent version, tokens, cost, execution time, requesting user, timestamps, workflow input), and version history. Not stored by the platform: the raw prompt sent to the provider and the raw completion returned. What persists is the parsed, typed result plus that metadata; the prompt template is versioned, so a prompt can be reconstructed from its template and the recorded inputs.

Credentials and access. No API key exists in source code, environment files, or container images; keys live in Azure Key Vault and the backend's managed identity fetches them at runtime, and all model traffic is TLS. Every AI execution is bound to a company, and prompts are built from that company's data only. AI outputs are ordinary platform records inheriting tenant isolation and role-based permissions - a user who cannot see a supplier cannot see its AI classification. Agent and prompt administration is restricted to Position Green back-office roles; customers cannot author or modify prompts.

6.5 Customer control

AI capability is bundled with the module it serves, and modules are entitlements controlled per company and enforced server-side, not merely hidden in the UI. The more meaningful control is behavioural: every customer-facing AI run is user-initiated, so a customer who does not use AI-assisted invoice upload has no invoice data processed by a model. A contractual AI opt-out is handled as a per-customer configuration agreed with Position Green rather than a product setting.

Configuration also constrains what the deterministic layer accepts from AI. The emission boundary determines which GHG categories are admissible, so a suggestion outside it cannot be placed. Override a supplier's region, sector, GHG category, or material category to take precedence over the global classification. The reporting year drives factor vintage selection; the region drives proximity ranking.

7. A worked example

Input: a two-page PDF invoice from a Norwegian building supplier, 14 lines, one page scanned.

OCR and extraction - page 2 is detected as image-only and extracted as table-aware markdown. Supplier "Byggmakker AS", invoice 2024-4471, NOK, document total excl. VAT 41,880. Self-check: extracted line sum 41,880 matches the printed total. Document confidence 94; line 11, from the scanned page, scores 61.

Identity - line 3 "Eik parkett 14mm 2,3m²" → concept parquet flooring, material wood, kind product. Line 13 "Frakt" → fee and line 14 "Miljøgebyr" → tax, both skipped for factor assignment.

Quantity - effective unit m², per-item value 2.3, basis: explicit_unit. Platform code computes 1 × 2.3 = 2.3 m².

Assignment and validation - matched to the parquet card at confidence 0.88, reason: "explicit 'parkett' plus oak species; m² denominator matches the invoice unit, avoiding a mass estimate." An independent agent confirms the pair.

Factor selection - no AI. The Norwegian variant (region distance 0) beats the Nordic bloc (1) and the global average (3); activity-average tier beats the spend proxy; 2023 vintage is chosen for a 2024 reporting context. Selected: 17.9 kg CO₂e/m², modules A1–A3.

Calculation - no AI. 2.3 × 17.9 = 41.17 kg CO₂e, placed in GHG category 3.1 by envelope ∩ boundary, with no anti-pattern hit.

Review - line 11 surfaces at confidence 61. Open page 2, correct the quantity from 4 to 6, and save. The value is stored as user-set with the prior AI value retained in history.

What AI decided: that line 3 is parquet and line 13 is freight. What code decided: the quantity, the factor, and the emissions.

8. Limitations

AI can make incorrect suggestions, and will. The failure modes to expect: misread multi-column or scanned layouts, with lines merged or quantities taken from the wrong column; plausible-but-wrong archetype matches; unit and pack-size errors; confidently wrong sector classification for suppliers with generic names, which propagates into spend-based factor selection; and decimal separator confusion in mixed-locale documents ("0,207" versus "0.207") - a 1000× error class, and specifically why extraction reconciliation against document totals matters.

AI does not replace expert judgment. Organisational and operational boundary, consolidation approach, which categories are material, whether a proxy is acceptable, whether a reduction assumption is realistic, and what gets published all remain with the user. The platform records decisions; it does not make them.

AI does not create verified supplier data. An AI-researched or AI-discovered factor with a source URL is published information the model found, not supplier-reported data. It is not equivalent to a supplier-provided product carbon footprint, a verified EPD, or an assured GHG inventory - and a researched factor never occupies the batch-primary tier.

AI does not guarantee compliance. The platform supports GHG Protocol-aligned workflows and CSRD/ESRS reporting preparation. Neither the platform nor any AI feature certifies compliance, and responsibility for every published figure remains with the reporting organisation.

The largest residual risk is not technical. Structural controls catch a meaningful share of errors - extraction reconciliation, the independent validation agent, anti-pattern rules, source verification, allowlisted retrieval, and thresholds routing weak results to review. What no control prevents is an undocumented assumption or a rubber-stamped verification. The platform records who verified what and when; whether that verification actually happened is a matter of process, and worth spot-auditing.

9. Frequently asked questions

Does AI calculate my emissions automatically?

No. No emissions figure is computed by a language model. Calculation is deterministic, unit-tested code. AI prepares typed inputs - classifications, extracted line items, conversion factors - and the calculation engine does the arithmetic.

Can I review or override AI suggestions?

Yes, always. Low-confidence outputs collect in review queues and all generated records are editable. An override is stored as a new version with the editing user recorded, and the AI's original proposal remains in history.

Is customer data shared with external AI providers?

Data is processed by two providers - Microsoft Azure and Google Cloud - under Position Green's own infrastructure and contracts, in European regions. Both commit contractually that customer prompts and completions are not used to train their models, and Google additionally commits not to store prompts or outputs beyond what is needed to produce the response. The one place data may be retained provider-side is Azure's abuse monitoring path, described with the option that removes it in §6.3.

Can AI generate supplier-specific emission factors?

No. AI can find published information and record it with its source URL, but that is researched public data, not supplier-reported data, and it never occupies the primary-data tier. An accepted factor is also a company-scoped override - promotion into the shared library is a separate, reviewed step by Position Green, so one customer's accepted result never changes another's emissions.

How does AI support auditability?

Because AI outputs are structured records rather than free text, every AI-influenced value carries its provenance, confidence, reasoning, and version history. An AI-assisted classification is often more traceable than a manual one, because the manual one rarely records why the person chose it.

10. Appendix: AI surface at a glance

Every agent above records the version that produced its output, its token count, cost, and execution time, keyed to the customer's company.

Standards referenced by the platform's methodology: GHG Protocol Corporate Standard; GHG Protocol Corporate Value Chain (Scope 3) Standard and Technical Guidance; GHG Protocol Scope 2 Guidance; EN 15804 lifecycle module definitions; ESRS E1; PCAF Global GHG Accounting and Reporting Standard; ISO 14064-1.

Provider terms quoted in §6.3: Microsoft, Data, privacy, and security for Foundry Models sold by Azure, and Foundry Models sold by Azure abuse monitoring; Microsoft Products and Services Data Protection Addendum; Google Cloud Platform Service Specific Terms, §18 (Training Restriction) and §20 (Generative AI Services).

Further detail - emission factor library governance, specificity tier definitions, the supplier classification cascade, agent and prompt version control, data processing agreements, and a full worked audit trail for a single reported figure - is available from Position Green on request.

Position Green · Carbon Management (Next-gen) · August 2026