How to write an AI-content policy for conference speakers

Your speaker's slides arrive on time. The presentation looks good, the examples fit the programme, and then you notice a customer quote that doesn't have a source. The speaker explains that an AI tool produced it to make the example more relatable. They weren't trying to mislead anyone. But the audience would have had no way of knowing it wasn't real.

That's the kind of decision your conference speaker AI policy needs to settle before someone walks on stage. Allow useful assistance, require disclosure when AI materially shapes what attendees see or hear, and keep a named speaker responsible for the evidence. Put separate approval around private information, realistic synthetic media and live demonstrations.

I'd start there rather than announcing a blanket ban. You can write a clear rule about invented customer results. You'll struggle to apply a vague promise that every sentence must be untouched by AI, especially when speakers use translation and accessibility tools. The useful question is what your audience might misunderstand, and what you need to check before selling or delivering the session.

This guide develops that approach into a policy you can adapt, a disclosure form, and a review process for a paid conference. The sample wording is an editorial starting point. Have the person responsible for your speaker agreements check how it fits your contracts, professional requirements and local law before adopting it.

Decide what your audience is paying to learn

Start with the promise of the session. An experienced practitioner explaining a real project owes the audience a clear account of what happened. A trainer demonstrating a generative tool owes them an honest explanation of the setup and limitations. A creative speaker showing imagined futures can use invented scenes, provided people understand what they're looking at.

Those sessions can share one basic policy while needing different reviews. If you judge all three by whether AI appeared anywhere in preparation, you'll spend time on harmless drafting and miss more consequential problems. An invented result presented as customer evidence matters even if a person wrote every word themselves.

Write down what you expect the speaker to contribute. That might be their own analysis, a practical method they can defend, or a clearly sourced explanation of other people's work. If you advertise firsthand experience, verify that the speaker actually has it. AI assistance doesn't turn a hypothetical example into professional experience.

Keep the same expectation for sponsored sessions. A commercial booking can justify an openly identified product demonstration. It doesn't justify fabricated evidence, hidden changes to a case study, or an endorsement from someone who never gave one. Your sponsorship team should see the policy before they make promises about editorial freedom.

Academic conferences may have obligations that go further than this guide. For example, ACM RESPECT's published AI policy addresses disclosure in papers and restrictions on reviewers' use of confidential submissions. That's a useful example of explicit rules for a particular conference, rather than a universal standard for every commercial presentation. Check any publication or accreditation requirements that govern your own programme.

Then choose your default. For a practical business conference, I'd permit assistance with preparation and clearly identified generated examples, while requiring human responsibility for claims and a separate decision on sensitive uses. A programme selling original research may reasonably impose tighter conditions. Explain the reason so speakers can apply the rule to something your form didn't anticipate.

Define the uses your policy covers

Generative AI means software that produces new material, such as text, images, audio, video or code, in response to instructions. Your policy should explain that in ordinary words. Speakers shouldn't need to identify the technology behind every feature in their slide editor to understand what you want from them.

Cover the whole contribution. A talk includes its title, description, biography, slides, handouts, demonstrations and any recording you distribute. An accurate slide deck doesn't fix a programme description that promises results the speaker never achieved. Ask the same questions when marketing turns a speaker's material into a promotional clip.

Separate assistance with expression from generation of substantive material. Correcting spelling in an existing paragraph is different from generating the argument, its supporting examples or the conclusion. Translation can also change technical meaning, so a language aid still needs someone competent to check the version the audience receives.

For your own event, you might say that routine spelling correction and formatting don't need an audience disclosure. Ask speakers to disclose substantive rewriting, generated explanations, synthetic images and media, code demonstrations, and generated datasets. If a professional body or publisher requires broader disclosure, follow that requirement instead of using your event's exemption.

Don't try to settle the boundary with a percentage of AI-written words. The most consequential part of a talk might be one chart or a short quotation. A word percentage tells you little about whether the audience could mistake a generated example for measured evidence. Describe the use and its effect on the session instead.

A practical scope note could read: this policy covers material generated or substantively changed by AI that contributes to the meaning, evidence, examples or delivery of your session. Routine corrections that preserve your meaning don't require a public label under our event policy. Tell the programme team if you're unsure, and explain the task the tool performed.

Make disclosure specific enough to help someone

A speaker saying they used AI tells you almost nothing. They might have shortened a paragraph, invented an example, or built the entire demonstration around a tool. Ask what it did, where the resulting material appears, and what the speaker checked. Those answers let you decide what attendees need to know.

Keep a private declaration for the programme team and a public disclosure for the audience. The private declaration can contain practical details such as the tool, the date of generation, affected slides, checks completed and outstanding permissions. The public statement should explain the relevant use without exposing confidential material or turning the introduction into a software inventory.

For a generated illustration, a caption saying that it is an AI-generated concept image may be enough under your editorial policy. If it resembles a real facility, make clear that it doesn't document an actual installation. The important information is the status of the image, not an impressive list of the tools used to make it.

For a hypothetical dataset, tell the audience that the figures were invented for the exercise. Explain that the dataset demonstrates a method and doesn't establish how real businesses perform. The speaker should still check the calculations. Fictional inputs can produce a useful example, but a mistake in the calculation remains a mistake.

A useful audience disclosure for a demo might explain that the presenter will run a live AI tool using prepared fictional information, and that the output can vary. If a successful run was recorded earlier, identify it as a recorded demonstration. Attendees shouldn't leave believing a prepared sequence was a fresh result produced in front of them.

Here is a fictional declaration for the hospitality session developed later in this guide. The presenter could write: I used a generative text tool to draft customer-comment examples for the exercise and suggest initial categories. The comments are fictional. I checked and edited the categories, and I will explain why individual examples may fit more than one. The slides identify the generated comments, and the demonstration uses the same fictional material. No customer records will enter the demo account.

The audience needs a shorter version. On the exercise slide, the speaker could write: These customer comments were generated for this exercise and do not describe real customers. The categories are suggestions for us to review together. In the private declaration, add the actual tool, available version information and date, plus the file reference. That gives your reviewer practical detail while keeping the public explanation focused on what attendees need to understand.

Put the disclosure where the misunderstanding could happen. A statement hidden on the final slide won't help someone who photographs a chart halfway through the presentation. Add the relevant label to the image, example, handout or clip itself. Check that it remains readable in the recording and any later extract.

Ask for enough detail to review the use, while avoiding an automatic demand for full prompt histories. Those histories can contain private information and may add little to your decision. Where a specific prompt matters to understanding a demonstration, ask for a safe version and its context. Your programme owner can request additional evidence when a real issue needs investigation.

Require sources for claims and an explanation of the work

Disclosure isn't a substitute for accuracy. A label saying AI-assisted doesn't make an invented reference acceptable or turn a sales claim into evidence. Your policy should say that speakers must verify factual claims against sources they have actually checked, and be able to explain how their examples and calculations work.

The US National Institute of Standards and Technology identifies confidently presented false content, including fabricated citations, as a risk in its Generative AI Profile. For your conference, the practical response is straightforward. Check the underlying source rather than trusting a plausible reference supplied by a tool.

Suppose a speaker says a new workflow reduced an organisation's processing time. Ask which organisation, what was measured, over what period, and what changed alongside the workflow. If they can't substantiate the result or get permission to describe it, remove the claim or replace it with an explicitly hypothetical example. Don't preserve an impressive number merely because it improves the session description.

For a chart, request the source and enough information to reproduce the main conclusion. That doesn't mean demanding a customer's raw confidential records. An approved summary, publication or appropriately reviewed explanation may be suitable. If the evidence can't be shared with your reviewer, the programme owner must decide whether a narrower claim is supportable.

Give consequential claims more attention. Advice about a legal obligation, medical treatment, financial decision or safety procedure needs the appropriate subject expertise and current sources. An organiser's visual check can't establish that the advice is sound. Ask a qualified reviewer to assess the relevant material, or change the session so it doesn't promise guidance you can't responsibly review.

A useful review question is whether the speaker can explain why the recommendation follows. Ask them to walk through one central example without reading the slides. You're checking understanding, assumptions and limits. Someone can use AI responsibly and still explain their work thoroughly; someone who cannot may need to revise the session regardless of how they prepared it.

For a long programme, concentrate detailed review on the claims that underpin the session's promise and the material most likely to cause harm if wrong. Tell speakers this is how you allocate review time. It doesn't relieve them of responsibility for the rest, and it doesn't justify describing your conference as independently fact-checked unless you can support that claim.

Separate permission to use material from ownership claims

A speaker may assume that generating a picture means they're free to use it in any way they choose. Your agreement needs a more careful question: do they have the permissions needed for the particular use you're planning? Showing a slide in a room, selling access to a recording and using an extract in advertising are different uses.

In the US, the Copyright Office's report on AI and copyrightability explains the continuing importance of human authorship and distinguishes human contributions from generated material. That addresses copyright protection. It doesn't provide a general clearance for every output or settle every question about third-party rights. Other countries' rules can differ.

Keep the permission request concrete. Ask whether the material includes third-party artwork, identifiable people, customer information, trademarks, music, footage or a recreation of someone's voice. Ask what the speaker is authorised to do with it and whether that authorisation covers your recording and distribution plans. Refer uncertain cases for appropriate advice instead of declaring that AI removes the problem.

I'd require specific written approval before a presentation uses a realistic synthetic voice or likeness of an identifiable person. Make that an event editorial rule, with the relevant permission evidence checked separately. A humorous intent doesn't tell you whether the audience will misunderstand the clip or whether you're authorised to publish it afterwards.

Avoid blanket claims that the speaker owns all AI outputs. Ask them to confirm the rights and permissions they can actually grant. Your speaker agreement should describe the recording, slide distribution and promotional uses you need, with any exclusions attached to the relevant material. Resolve those exclusions before production receives the deck.

Sometimes the sensible answer is to replace an asset. A clearly illustrated fictional character may explain the same point as an imitation of a real executive without creating the same confusion. If the likeness is central to the session, the programme owner needs to understand why, what approvals exist and which uses remain restricted.

Keep the evidence in a restricted record rather than adding private permission correspondence to the public deck. Production needs a clear instruction about what it can show and record. It rarely needs every email behind that instruction. Record who reviewed the permission and what they approved so a later editor doesn't expand the use by accident.

Keep private information out of unapproved tools

A speaker may want to demonstrate the tool using a real customer spreadsheet because it looks convincing. An organiser may want to upload everyone's draft presentations to get quick summaries. Both decisions involve information belonging to other people. Your policy should cover the organising team and reviewers as well as speakers.

The UK's National Cyber Security Centre advises against putting sensitive information into public language-model tools and says users need to understand provider terms in its guidance on large language model risks. Apply that to your conference by approving the tool and proposed use before anyone shares restricted material. Avoid assuming that every service handles information in the same way.

For live demonstrations, use a prepared fictional dataset wherever it will teach the same lesson. Build it for the exercise rather than copying real customer records and changing the names. Details in free-text notes, screenshots and unusual transactions may still reveal who a supposedly anonymous example concerns.

If the session genuinely requires real information, have the responsible privacy and security people assess the proposed use in advance. They need to consider the information, permissions, service terms, account settings, access and retention. A speaker ticking a box marked anonymised isn't enough to settle those questions.

For the organiser's review, share drafts only with the people and approved services needed for the task. Ask speakers to identify restricted sections through a private route. Don't request sensitive source documents in an ordinary upload folder merely to prove that a claim is real. Decide how you can review it without creating another disclosure problem.

Connect this policy with your rules for confidential conference discussions. A room rule about attribution doesn't automatically authorise someone to transcribe the conversation into an external AI service. Speakers, moderators and attendees need to understand the separate rules for recording and automated note-taking.

An attendee question can create the same issue during a demo. Ask people to describe the problem without identifying customers or disclosing private circumstances. If someone starts reading confidential information, the moderator should interrupt before it enters the tool. Agree that intervention during rehearsal so it feels like ordinary session management when it's needed.

Approve live demonstrations before the room fills

A live demonstration needs its own review because the output hasn't been approved in advance. You can approve the setup, inputs, purpose and boundaries. You can't honestly promise that an open-ended system will say exactly what it said during rehearsal. Make that uncertainty part of the session design.

Ask the speaker to explain what the audience will learn even if the output is disappointing. A session built around examining the tool's limitations can handle an unexpected answer. A session sold as proof that a system always reaches the right conclusion has a much bigger problem. Adjust the description before buyers make decisions based on it.

Use a dedicated demo account with only the access the demonstration needs. Remove unrelated documents, private messages and customer systems from the presentation environment. Have the production lead inspect what will be visible when the presenter switches windows. A clean opening screen doesn't prevent a notification from appearing later.

Agree which inputs are allowed and who controls them. Taking unrestricted prompts from the room can change the content and the information entering the service. You can accept questions through a moderator, choose one within the approved scope, and decline to enter personal or confidential details. Explain that arrangement before inviting participation.

Give the moderator permission to stop the demo. Define practical triggers, such as private information appearing, output that targets an identifiable person, or a result the presenter cannot explain safely in the time available. The moderator can ask the speaker to close the tool and continue with the prepared explanation. They shouldn't have to debate the policy on stage.

Prepare a fallback that still delivers the learning objective. It might be a clearly labelled recording, a static example or a discussion of the steps. Keep its disclosure and limitations intact. If the event promised hands-on live access and the fallback materially changes that offer, the programme owner also needs to consider attendee communications and the event's terms.

Rehearse the transition as well as a successful run. Ask the speaker to stop an unsuccessful run and continue without apologising through the rest of the slot. Test whether the fallback works on the presentation machine and whether the moderator knows which version it is. That short rehearsal is more useful than another sentence promising responsible use.

Send an adaptable policy with the speaker agreement

The policy below is original sample wording for a paid conference. Replace the placeholders with your event's decisions, and check it against your agreement before sending it. If you already have speakers booked, explain any proposed new obligations and obtain agreement where required. Don't assume a late email can rewrite an existing contract.

Sample conference speaker AI-content policy

Our conference permits responsible use of generative AI in preparing and delivering sessions, subject to the requirements below. The named speaker remains responsible for the presentation, its claims and the material they submit. Programme approval applies to the specific version and uses confirmed by the organiser.

• Tell the programme team when AI generates or substantively changes material that affects your session's meaning, evidence, examples or delivery. Identify the tool, the task, the affected material and the checks you completed. Contact the programme lead if you're unsure whether a use falls within this requirement.

• Under this event policy, routine spelling correction and formatting that preserve your meaning don't require a public disclosure. A publisher, professional body or other applicable requirement may impose stricter rules. Tell the programme team about any such requirement affecting your session.

• Verify factual claims, quotations, references, calculations and descriptions of real events. Provide sources for central claims when requested. Do not present invented people, results, research, customer experiences or testimonials as real. Identify fictional examples and synthetic datasets clearly wherever the audience encounters them.

• Make audience disclosures clear and specific. Label generated media or examples when their origin or status could affect interpretation. Place the relevant disclosure with the material, including handouts, recordings and extracts. The programme team will confirm any additional statement needed in your session introduction.

• Confirm the permissions required for the uses agreed with the organiser, including live presentation, recording, attendee distribution and promotion. Obtain specific written organiser approval before using a realistic synthetic likeness or voice of an identifiable person. Approval doesn't replace any underlying permission or legal requirement.

• Do not enter personal, confidential or otherwise restricted information into an AI service for this session without prior approval through the organiser's designated process. Use prepared fictional information for demonstrations unless a different use has been expressly approved. Apply the same restriction to audience questions entered into a tool.

• Request approval for live AI demonstrations in advance. Supply the proposed inputs, account setup, audience participation rules, known limitations, fallback and stop conditions. The moderator or production lead may stop a demonstration under the agreed session plan when those conditions arise.

• Submit the disclosure and materials by the confirmed review deadline. Identify substantive changes after approval, including new generated material, revised claims, new data inputs or changed demonstration tools. Do not replace the production copy until the organiser confirms the revision is approved.

• Raise errors or permission concerns promptly, including after the event. Cooperate with a proportionate review and correction of affected materials. The organiser will consider the evidence, the speaker's response, audience impact and the agreed terms before deciding on changes to presentation or distribution.

Send questions and declarations to [named programme contact] through [private submission route]. Our review deadlines are [draft deadline], [revision deadline] and [production approval deadline], each with a stated time zone. The person authorised to approve exceptions is [role and contact].

Explain the boundaries when you send it

A short covering note helps speakers understand the request. Explain that you want to preserve the value of their expertise while making the status of examples and evidence clear. Link the declaration form and say when someone will respond. An unsupported promise of instant review will create pressure to approve incomplete material.

Include the policy in the same process as your conference speaker management workflow. You don't need a separate system for every AI-related question. You need the declaration, evidence requests and final decision connected to the session record that your programme and production teams already use.

For panels, ask each contributor about their own submitted material and demonstrations. One chair's declaration can't cover work the chair hasn't seen. If someone plans to discuss a tool spontaneously, agree the boundaries beforehand, especially around displaying live outputs or entering audience information. A panel format doesn't remove the need for those decisions.

Use a short declaration and record the decision

The form should make review easier for both sides. Start with a direct question about whether generative AI affected substantive material, followed by space to describe the use. Let speakers explain uncertainty. A form that offers only yes or no encourages people to guess at your definition instead of asking a useful question.

Collect the information below privately. Adapt the amount of detail to the session rather than making every speaker complete a technical questionnaire. If there is no substantive AI use to declare under your policy, record that answer and the speaker's acknowledgement of the rules.

• Session reference, title, speaker and submitted version.

• Tool or service used, available version information and date of use.

• Task performed and the slides, handouts, media or demonstration affected.

• Whether each example is real, fictional, generated or a mixture, with the intended label.

• Sources and checks supporting central factual claims, calculations and quotations.

• Permissions needed for third-party material and the event's planned distribution.

• Whether restricted information entered a tool, and the approval reference if applicable.

• Proposed audience disclosure and any live-demo fallback or stop conditions.

• Unresolved questions, requested exceptions and the speaker's confirmation of responsibility.

Then add the organiser's decision. Record who reviewed the material, the version assessed, required changes, permitted uses and remaining restrictions. Give content approval and technical readiness separate answers when they differ. A safe demo setup doesn't establish that the commercial claims made during it are supported.

Use changes required when a correction is outstanding, and keep the session in that state until you have checked the revised version. Only then mark it approved for production. Otherwise, a technician may open the latest upload while the programme lead assumes the speaker is still changing it. Confirm the actual file and disclosure that may be shown.

For exceptions, record the reason and limit. Permission to use one prepared real-world example doesn't authorise the speaker to enter new customer information during questions. An approval for live presentation doesn't automatically extend to promotional clips. Send the restriction to whoever edits the recording as well as the person managing the stage.

Retain the record for your event's stated purpose and retention period, with access limited to the relevant team. Avoid keeping every draft and prompt forever because storage is easy. The useful record explains what was reviewed and decided; additional private material needs a reason to remain in your files.

Work through a submission that needs changes

Imagine a fictional paid conference for hospitality operators. A speaker proposes a session on using AI to analyse customer feedback. Their draft includes a supposed customer quotation, a chart labelled as a pilot result, and a live demonstration using a spreadsheet from their consultancy. These are invented circumstances for the example, rather than a report of a real event.

The declaration explains that the quotation was generated, the chart uses made-up data, and the spreadsheet contains actual customer comments. The speaker thinks the overall label AI-assisted covers all of it. Your programme reviewer now has several distinct decisions to make, and simply asking for a more prominent AI logo won't resolve them.

First, the quotation must stop looking like testimony from an actual customer. The speaker can replace it with an approved real quotation or label it as fictional text used in the exercise. If the wording is meant to sell a product, the issue becomes especially serious. In the US, the FTC's consumer reviews and testimonials rule guidance addresses fake and false testimonials, including AI-generated examples in its scope. That's a specific advertising rule, separate from your broader editorial standard for every talk.

Next, the chart needs a title that describes the figures as fictional exercise data. Remove language implying that the consultancy measured a real pilot. The speaker checks the arithmetic and explains what the exercise demonstrates. If the advertised session promised measured customer results, the programme lead must also change that promise or obtain real supporting evidence.

For the spreadsheet, ask the speaker to build a fictional replacement that teaches the same analytical method. The session doesn't need real customer comments to show how categories can be proposed and checked. If the speaker disagrees, they must explain the educational need and complete the event's separate approval process before any real information is used.

Finally, test the live demonstration with the replacement data. Agree that the speaker will describe the output as a proposed categorisation, review an example aloud and explain a limitation. Prepare a labelled recorded fallback. The moderator can then respond if the tool produces an unsuitable answer without improvising a new policy.

The decision record might say: revision required; replace the customer spreadsheet, relabel the quotation and chart, and submit the revised demo for testing. After reviewing the changes, the programme lead approves the new deck and labels. The production lead confirms the tested account and fallback. Recording permission covers the revised material only.

That outcome preserves a useful session. The speaker can still demonstrate AI, and attendees can still learn a practical method. Your intervention has changed the claims and information handling that would have misled or exposed people. It hasn't become a dispute about whether the speaker was allowed to use a writing aid.

Handle late changes and complaints with the same rules

After approval, a new AI-generated example is a content change. Ask what it replaces, why it's needed and whether it introduces new evidence, permissions or information. A correction to a mistake deserves attention. An impressive last-minute addition can usually wait if your team cannot review it properly before the session.

Have one named person make the decision and confirm it to production. Keep the approved version available until the replacement is accepted. If a speaker arrives with a different deck, the technician should know whom to contact and which file remains authorised. Production staff shouldn't have to decide whether a disputed claim is accurate while the audience is waiting.

Avoid deciding misconduct from a detector score or from how polished someone's writing sounds. Ask about the specific concern, the underlying source and the speaker's explanation. A fabricated reference is a concrete problem you can investigate. An accusation based only on a stylistic impression is a weak basis for removing someone from the programme.

If the issue emerges on stage, the moderator can clarify a fictional example, stop an unapproved demo or move the discussion away from private information. They should avoid making an unsupported accusation in front of the audience. Record what happened and refer the substantive decision to the programme owner once the immediate problem is controlled.

Afterwards, preserve the affected version and assess the complaint before distributing the recording. Ask the speaker to respond to the actual point. You may be able to correct a caption, remove a segment, replace a handout or add an explanation. A serious error that undermines the session's central claim needs a broader decision about distribution and what attendees should be told.

Keep remedies tied to your agreements and applicable obligations. Don't write automatic fines or blanket no-refund statements into an editorial policy and assume they apply. If the delivered programme materially differs from what buyers were promised, have the responsible person assess the event's terms and local consumer requirements. Record the decision separately from the correction to the slides.

For an attendee correction, say what was wrong, what the accurate position is and which material has changed. Reach the people who received the affected content through your established communication process. Loopyah's attendee email tools let organisers build messages and select attendee audiences, which can support that communication. Your programme team still needs to identify the affected session audience and write the correction; don't assume a ticket purchase proves attendance at a particular talk.

Set a review process your budget can support

Before sending the policy, test it against the programme you actually have. Who will review declarations? Who understands the technical claims? Which sessions need external expertise? A rule that requires detailed investigation of every slide is unlikely to survive a busy production week unless you've allocated people and time for it.

As a fictional budgeting example, suppose your conference has 20 sessions. You allow half an hour per session for the initial declaration review, making 10 staff hours. You reserve another six hours for questions and revisions, plus $600 for specialist review of selected material. At an assumed staff cost of $40 an hour, the allocated labour is $640 and the total planned resource cost is $1,240.

Those are illustrative USD assumptions, not a benchmark or a claim that this budget is enough for your programme. Existing salaried time may be an allocation rather than additional cash. The $600 specialist fee is additional spending in this example, and any purchase taxes are included. Other conference costs are unchanged. Estimate the actual work and cash requirements for your own event.

If the initial review takes an hour per session instead, you need 20 initial hours plus the same six revision hours. At the same rate, labour becomes $1,040 and total planned resource cost becomes $1,640. The $400 difference shows why a short declaration and clear evidence request matter. It doesn't prove that review will prevent a particular loss or generate extra ticket sales.

Set deadlines by working backwards from the people who need approved material. Leave time for clarification, specialist assessment where needed, revisions, accessibility preparation and technical rehearsal. Don't describe an arbitrary number of days as an industry requirement. A small practical programme and a conference publishing original research may need very different review arrangements.

Before you send the policy to every speaker, try it on one representative session with your programme lead and production lead. Read the declaration, make a decision, and check that the technician and recording editor can follow the resulting instructions. If someone still has to guess whether a generated example is real or which version they may publish, fix that instruction before expanding the process.