The Provenance Paragraph: Documenting AI Inputs in a UK Media Funding Bid

The question has changed

For much of the past three years, artificial intelligence appeared in UK media funding applications as a footnote: a line in the production notes, a passing reference to "AI-assisted workflows", occasionally a speculative budget saving. That era is closing. By late 2026, assessors at lottery distributors, screen agencies and private media funds are routinely asking applicants to identify where generative tools touch development, production and post. The question is no longer whether AI is present. It is whether the applicant can describe its presence with enough precision for a funder to price the risk.

The difficulty is calibration. Too little detail reads as evasion. Too much detail — a sprawling technical annex covering every prompt and plugin — buries the assessor and invites follow-up questions that the applicant never intended to answer. The practical solution is a short, structured disclosure schedule: a document that sits alongside the budget and the chain-of-title file, states what the machine does, and stops.

What the funder is actually asking

A funder is not usually trying to establish whether AI is artistically legitimate. It is trying to answer four administrative questions. First, does the applicant control the rights in what the tool produces? Second, has the cost been properly budgeted rather than absorbed invisibly? Third, does the use of the tool conflict with the funder's own policies on credit, labour or intellectual property? Fourth, if the project is audited after delivery, will there be a record that explains how an asset was made?

Those questions are answerable in two pages. The disclosure schedule should be written for a assessor who understands production finance but may not understand machine learning. Plain description beats technical vocabulary. "A synthetic voice tool was used to generate a temporary guide track for an animatic" is more useful than a list of model versions.

A four-column disclosure schedule

The most defensible format is a table with four columns: stage, tool or technique, output, and rights basis. The first column identifies whether the use sits in development, principal photography, post-production or delivery. The second names the category of tool — for example, AI-assisted script analysis, generative image tool, synthetic voice, de-aging or clean-up, automated translation, or music generation. The third describes the specific deliverable affected: a scene, a voice track, a subtitle file, a marketing asset. The fourth column states the contractual or licensing basis on which the production holds the output.

A single row might read: "Post-production | Synthetic voice (licensed voice model) | Temporary narration for internal rough cut, not delivered | Vendor licence permits commercial use; voice artist consent on file." That row does more work than a paragraph of preamble. It tells the funder where the use sits, what it touches, and why the production can rely on it.

Applicants should resist the temptation to list every experimental tool tried during development. The schedule should record uses that affect the funded deliverables, the budget, or the chain of title. A tool tested and discarded before the application need not appear unless it generated material that remains in the project.

Where the cost belongs in the budget

AI costs are frequently misclassified. A generative image subscription may appear under office expenses; a synthetic voice licence may be buried in post-production contingency; a de-aging pass may be quoted as a visual effects line without identifying the AI component. Assessors are increasingly alert to this, because misclassified costs distort the true cost of the production and can make a budget look cheaper than it is.

The safer approach is to place AI costs where the work happens. If a tool is used in development to analyse a script or generate mood boards, the cost belongs in development. If it is used in post to create or modify delivered images, it belongs in post-production, with a note identifying the AI component. If a licence is purchased for the life of the production rather than on a monthly basis, the budget should distinguish the licence fee from the processing or rendering cost. Contingency should not be used to absorb AI costs silently; if the use is planned, the cost should be planned.

Where a funder caps specific cost categories, the applicant should confirm whether AI licences are treated as software, as third-party services, or as a form of subcontracting. The answer varies between schemes and should be confirmed in writing before the budget is locked.

Chain of title and training-data provenance

The most common weakness in AI disclosure is the assumption that a commercial licence solves every rights question. It does not. A funder will want to know whether the output incorporates third-party material, whether the tool's terms permit the intended use, and whether the production can warrant that the delivered work does not infringe. For synthetic voice, the file should include the voice artist's consent and the scope of the licence. For de-aging or face replacement, it should record the performer's agreement. For generative images, it should identify whether the output is treated as original or as derived, and on what basis.

Training-data provenance is harder. Most applicants cannot audit a model's training corpus, and funders do not expect them to. What they can expect is a statement of reliance: the applicant has reviewed the vendor's published terms, has sought warranties where available, and has a protocol for replacing an asset if a rights issue emerges. That protocol is worth describing in one sentence. It signals that the production has thought about the problem rather than deferred it.

Answering the assessor's follow-up

Three follow-up questions recur. The first is "which delivered assets contain AI-generated material?" The answer should be a list, not a general assurance. The second is "who owns the output?" The answer should distinguish between the production company, the vendor and any third party whose likeness or voice is represented. The third is "what happens if the tool is withdrawn or the licence changes?" The answer should identify whether the asset can be recreated, replaced or licensed under a fallback arrangement.

Applicants who answer these questions in the schedule itself reduce the risk of a compliance query later. A query is not a refusal, but it consumes time and can delay a first payment. A schedule that anticipates the question is cheaper than a clarification round.

Clauses worth negotiating in 2026 award letters

Three clauses deserve attention. The first concerns deliverables. If an award letter defines delivery as "all production files", the applicant should clarify whether that includes AI-generated intermediates or only final assets. Handing over model prompts, working files or vendor licences may exceed what the funder needs and may conflict with third-party terms.

The second concerns credit. Some funders now ask for a statement on AI use in the production credits or in the delivered metadata. Applicants should agree the wording before signature, particularly where the creative team regards the disclosure as misleading or disproportionate.

The third concerns audit. A funder may seek audit rights over AI-generated assets, including the right to inspect licences and consent records. That is reasonable, but the clause should be limited to records the production actually holds and should include a confidentiality provision covering vendor terms. An unlimited audit right over a third-party model is not a right the applicant can grant.

Keep the record live

AI use changes during production. A tool used only in development may migrate into post; a synthetic voice tested for an animatic may end up in a delivered trailer. The disclosure schedule should be treated as a living document, updated at each major milestone and filed with the cost report. Funders do not expect perfection at application stage. They expect a record that can be explained later. That record is the difference between a disclosure that reassures and one that raises a query.