GEO supplier AI disclosure

What should a GEO supplier disclose about its use of AI and tools?

Use an eight-field disclosure register to assess where a GEO supplier uses AI, what data enters each tool, who verifies outputs, how changes are controlled and what the buyer can retrieve at exit.

Published by SALIENS · Published

Ask about the real workflow, not an AI label

A GEO supplier may use AI for research, clustering, drafting, translation, coding, testing, monitoring or summarising evidence. A yes-or-no question does not tell a buyer which task is affected, what information enters a tool, whether a person checks the result, or whether the buyer can reproduce the evidence later.

Disclosure should support proportionate due diligence rather than operate as a blanket ban. GOV.UK PPN 02/24 distinguishes AI used to prepare a tender from AI used in the products or services being delivered. Make the same distinction in a GEO procurement: a polished proposal is not evidence that the proposed delivery workflow, capacity or controls are sound.

Complete one eight-field AI and tool register

Require one row for each material tool or automated step in the proposed service. The register should describe the current workflow, not merely the supplier's general policy or a list of familiar product logos.

GEO supplier AI and tool disclosure register
FieldEvidence to recordBuyer acceptance question
1. Task and decisionThe GEO task, intended output, users and any decision the output informs; state where AI is not used.Can the buyer see exactly what changes when the tool is present?
2. Tool and supply routeProvider, product or API, model or material version where available, account owner and any intermediary service.Is the real delivery dependency identifiable rather than hidden behind a generic label?
3. Inputs and classificationPrompts, documents, website data, analytics, personal data, confidential material and the approved source of each input.Is every input permitted, necessary and correctly classified?
4. Retention, training and locationRetention period, reuse or model-training position, deletion route, geographic processing and relevant supplier terms.Could buyer information be retained or reused beyond the agreed purpose?
5. Output and limitationsOutput type, intended use, known failure modes, prohibited uses and the facts or claims requiring verification.Does the workflow treat plausible output as a draft or observation rather than proof?
6. Human control and approvalNamed reviewer, review method, escalation, buyer approval gate and actions the tool cannot take autonomously.Is meaningful human control placed before publication or consequential action?
7. Evidence and change controlPrompts or configuration where appropriate, source links, test samples, logs, version record, error history, change notice and retest evidence.Can the supplier demonstrate what ran and what changed without exposing unrelated sensitive material?
8. Ownership, export and fallbackBuyer-owned outputs and source records, IP or licence limits, export format, manual fallback, replacement path, access revocation and deletion evidence.Can the buyer continue, audit or transfer the service if the tool or supplier changes?

Separate tender assistance from service delivery

For the tender, ask whether AI helped draft answers and whether each claim, reference and capacity statement was checked against evidence. PPN 02/24 notes that additional clarification or supporting documentation may be appropriate where AI creates uncertainty; the aim is to establish accuracy, robustness and credibility, not to reject a bidder because a tool was used.

For delivery, ask a different question: which AI or machine-learning technologies form part of the proposed products or services, and how are they integrated? Follow each declared use into the register. If the proposal promises original research, bilingual review, technical implementation or continuous monitoring, record which parts are performed by people, tools and external providers and how the accepted result is produced.

Set data boundaries before any material is uploaded

Classify the information before choosing the tool. Public webpages, approved brand facts, unpublished strategy, analytics exports, enquiry records, personal data and credentials require different handling. Do not assume that a consumer interface, enterprise account and API have the same retention, training, location or administrator controls; record the terms and configuration that apply to the actual service route.

PPN 02/24 recommends proportionate controls so confidential authority information is not used as AI training data and gives an example in which service data should not be used for training unless the client has specifically agreed and approved it in writing. Apply that principle to the stated purpose, then route personal-data, security and international-transfer questions through the buyer's separate assessments rather than treating this register as a substitute for them.

Require evidence of human review and reproducible decisions

An output is not accepted merely because it reads fluently. The AI Playbook calls for meaningful human control at the right stages and lifecycle management; PPN 02/24 warns that statistically plausible language can still contain false statements. For GEO work, the reviewer should trace factual claims to approved sources, distinguish observations from conclusions, check both language versions, test technical changes and obtain buyer approval before publication where the scope requires it.

Preserve enough evidence to understand the decision: the question or task, relevant source material, system and material version, output or change, reviewer, checks, exceptions and final approval. Exact prompts are not always necessary or safe to disclose, but the supplier should be able to show how a result was produced and verified. Define an evidence-preservation period that matches the service and contract.

Control model, provider and workflow changes

AI services change even when the buyer has not changed the brief. Agree which events require notice and retesting: a new model or provider, altered retention or training terms, a different hosting region, new data source, changed prompt or automation, expanded autonomous action, loss of a feature, material quality drift or a newly discovered failure mode.

The NCSC secure-development guidance recommends documenting supply-chain dependencies and treating models and data as assets; its operation guidance covers logging, monitoring, updates and incident processes. Translate those principles into procurement evidence: identify the affected deliverables, test a representative sample, record approval or rejection, update the register and keep a fallback for critical work.

Run one disclosure-to-delivery acceptance test

Choose one real deliverable, such as correcting an English and Chinese service fact. Ask the supplier to trace it from approved source through every person and tool to the release evidence. Verify the declared inputs, data route, generated or transformed output, human checks, approval, published result, monitoring record and the files the buyer receives.

The test passes when the delivered workflow matches the register, factual claims are supported, prohibited data was not used, approvals are visible and the buyer can retrieve usable evidence. Record each mismatch as a correction, control change or scope exception. A declaration without a tested workflow is only an assertion; a test without a maintained register becomes stale as tools change.

How SALIENS supports controlled GEO delivery

SALIENS provides GEO audits, AI visibility monitoring, content and technical improvements, and ongoing GEO delivery. An agreed scope can include an AI and tool register, approved data boundaries, source-linked factual review, bilingual approval gates, version and change records, release evidence and an exit handover. These controls improve accountability; they do not guarantee crawling, indexation, AI mentions, citations, rankings, traffic or enquiries.

Email info@oxfordintelligence.co.uk with your website, markets and languages, intended deliverables, information classifications, required systems, approval owners and assurance constraints. SALIENS is operated by Oxford Intelligence Limited. This guide is a procurement framework, not legal, data-protection, cyber-security or AI-assurance advice; buyers should assess specialist obligations for their own circumstances.

Sources

  1. GOV.UK: PPN 02/24 Improving Transparency of AI use in Procurement (published 25 March 2024; checked 18 October 2026)
  2. GOV.UK: Artificial Intelligence Playbook for the UK Government (published 10 February 2025; checked 18 October 2026)
  3. UK National Cyber Security Centre: Guidelines for secure AI system development — Secure development (checked 18 October 2026)
  4. UK National Cyber Security Centre: Guidelines for secure AI system development — Secure operation and maintenance (checked 18 October 2026)
  5. SALIENS: Who actually delivers your GEO work? Map the supplier dependency chain

Prepared with AI assistance using the linked sources and SALIENS service information.

Discuss your GEO project

info@oxfordintelligence.co.uk

SALIENS is a brand operated by Oxford Intelligence Limited.