AI Model Version Disclosure: What Your Board Needs to Know

When a board approves an AI-generated analysis, the model version that produced it becomes part of the decision's evidence base. This guide sets out a one-line disclosure standard, a materiality test for when a platform's model upgrade requires telling the board, and the vendor questions that make version-level accountability enforceable.

Three things the board needs to understand and one thing it does not: it needs to know that the version is frozen, logged and retrievable; it needs a materiality test for when to pay attention to an upgrade; and it needs the right questions to ask of vendors. It does not need to understand how the model works.

AI-generated analysis has quietly become a routine input into board packs. Formal oversight has not kept pace. When ISS-Corporate examined S&P 500 proxy statements, it found only about 15% of companies provided any disclosure about board oversight of AI, and just 1.6% disclosed explicit full-board or committee-level oversight.^[1]

• Only about 15% of S&P 500 companies disclose some level of board oversight of AI in proxy statements.
• Just 1.6% disclose explicit full-board or committee-level oversight responsibility.
• EU AI Act Article 50 transparency obligations apply from 2 August 2026, requiring disclosure that content is AI-generated and machine-readable marking of generative outputs.^[2]

The sharper, largely unaddressed question is: which model version produced the analysis, and what happens to accountability when the platform quietly upgrades that model after the board has signed off? Boards that cannot answer this question cannot reconstruct what they approved, even in principle.

The model is a load-bearing input into the analysis itself: it shapes how problems are structured, which framings are surfaced, how evidence is weighed and what language the conclusions are written in. A re-run of the same brief on a different model version can produce a materially different document.

Research on regression testing for generative AI systems built a benchmark of 80 test cases per language across eight task categories and found that newer models generally improve correctness on average, but improvements can be modest and uneven, and a newer version might improve overall yet unexpectedly degrade on specific inputs or tasks.^[3]

Three properties that depend on knowing the version:

• Reproducibility: if the version is not recorded, nobody can later reconstruct which system produced the approved output.
• Accountability: the person presenting the analysis, not the vendor, answers for its contents. That accountability rests on a specific system state.
• Drift detection: model behaviour changes across versions. IBM's guidance on model drift identifies drift detection as a core component of strong AI governance, and it starts with knowing the version baseline.^[4]

Three elements on a single cover-page line are enough to make an AI-assisted analysis reconstructable. The exact format matters less than the discipline: every AI-assisted document that reaches the board carries the line.

1. The platform or tool name, so the artefact is attributable to a specific system.
2. The model version or version range, so the exact system state is identifiable.
3. The date of generation, tied to the vendor's release history.

A workable line: "Analysis generated on [Platform], model version [X], on [date]." This gives the board, the audit function and any future examiner the three co-ordinates needed to locate the analysis in the vendor's version history.

The same discipline should extend to any significant update. If an analysis is refreshed at a later date, the cover page carries the refreshed version's disclosure line – and if the model version changed between the original and the refresh, that change is noted.

If the platform upgrades its underlying model after the board approved the analysis, the approved artefact is unaffected as long as the version it was generated on is frozen, logged and retrievable. Sign-off attaches to the artefact, not to the vendor's current release.

The change becomes material when the analysis will be re-run, refreshed or relied on for a live decision. Providers frequently deprecate older versions on their own schedule, and updates to underlying models can silently change behaviour.^[5]

Three questions to run when a vendor announces a model change:

• Will this analysis be re-run or refreshed on the new version? If yes, outputs may differ and the committee should see both versions side by side.
• Will a live decision still draw on it? Live reliance means the current model state is doing the work, not the frozen artefact.
• Did the vendor give adequate notice? Notice determines whether the team had time to test the new version before relying on it.

Rule of thumb: inform the board when a re-run on the new version would plausibly change a material conclusion. Do not inform the board every time a version number changes.

Three questions convert model-version concern into enforceable commitments at the point of contract, rather than after the analysis is already in a board pack.

1. Is the model version logged in the audit trail for every generated output, and can it be exported as part of a reproducibility pack together with sources and prompts?
2. What does the service agreement say about model changes, deprecations and notice periods?
3. Can an enterprise order form strengthen notice and version-pinning terms at signing?

Vendor notice periods vary considerably. Analysis of live vendor terms indicates OpenAI commits to 14 days' notice for model changes, Anthropic and Google to 30 days, and some vendors commit to no notice period at all.^[6] These default clauses are often floors rather than ceilings; notice windows and version-pinning commitments are genuinely negotiable at signing for enterprise customers.

The board needs almost no technical detail. Three properties a non-technical director can verify are all that matters:

1. Is the model version recorded for every AI-assisted analysis that reaches us?
2. Is that record retained in a form we could retrieve in a year, if a decision is challenged?
3. Is the version behind a given document frozen, so a re-run today would be run on a known, named system state?

Technical detail – transformer architecture, parameter count, benchmark scores – belongs one level down, with the company secretary or audit function. Boards already rely on valuation models, actuarial assumptions and statistical sampling methods whose internals most directors cannot reconstruct. The model version is the same kind of input: a named, dated system state that can be referenced later, not a mechanism the board needs to understand.

The company secretary or audit function's job is to confirm, once a year, that the version-logging discipline is being applied and that at least one significant analysis from the past year can be reproduced on the version it was generated on.

This example is illustrative. An investment committee at a private equity firm approves an AI-assisted deal analysis in Q1. The cover page carries the disclosure line: platform name, model version and generation date. A reproducibility pack is archived with the deal file.

In Q2 the platform upgrades its underlying model. The governance review runs three checks:

1. Is the approved Q1 analysis still reproducible on the frozen version? If the vendor has already deprecated it, the reproducibility pack becomes the only record of what was approved.
2. Does any Q2 re-run on the new model change a material conclusion? If yes, the item is flagged for re-approval with old and new outputs side by side.
3. Did the vendor's notice terms give the team enough time to test the new version before any reliance on it? If not, the contract terms should be reviewed at renewal.

The outcome is one of two short notes to the committee: either the approved analysis is unaffected and the Q1 artefact is on file, or the item is flagged for re-approval. Neither requires the committee to understand the technical details of the model change.

Platforms built for board-level strategy work, such as Decisity, treat source traceability and auditability as core design requirements, so the version attachment and reproducibility pack are produced as part of the standard workflow rather than a retrospective documentation task.

Related reading:

• Who Is Accountable When an AI-Drafted Strategy Goes Wrong?
• Confidentiality Terms to Require From an AI Platform Vendor
• Confidential Documents and AI Strategy Tools: What to Verify
• Presenting AI-Assisted Strategy Analysis to a Skeptical Board

• ISS-Corporate via Harvard Law School Forum on Corporate Governance: AI Governance Appears on Corporate Radar (April 2024)
• EU Artificial Intelligence Act: Article 50, Transparency obligations
• GPR-bench: Regression testing for generative AI systems
• IBM: What is model drift?
• The Neural Base: How model updates change AI behaviour
• Digital Applied: AI price schedules and soft commitments in procurement