Decide which AI conversation you need
“AI” can mean a strategic discussion for a board, a practical introduction for employees or a specialist technical session. A virtual AI keynote needs a brief that identifies the audience’s starting knowledge and the decisions or questions it should help them address.
This is a topic-selection guide. It does not imply that every speaker featured elsewhere on this site offers specialist AI keynotes. Verify the expertise needed for your particular session.
Three different briefs
| Audience | Possible direction | Evidence to request |
|---|---|---|
| Senior leaders | Opportunities, organisational implications and questions for investment. | Relevant work, clear assumptions and dated sources. |
| Wider workforce | An accessible introduction and examples related to everyday work. | Understandable explanations and realistic demonstrations. |
| Specialists | A narrowly defined technical or sector question. | Specific expertise and material matched to the audience’s level. |
Keep predictions separate from established facts. Ask when the speaker last updated the material and how they will handle uncertainty or conflicting evidence.
Plan demonstrations for remote viewing
If demonstrations are included, check that text and interface details remain legible on a laptop screen. Ask for a backup recording or screenshots in case the live service or connection fails, and label prerecorded material clearly.
Use demonstration data that is suitable for public display. Agree the tools, account requirements and any audience participation in advance. A keynote should not unexpectedly require attendees to register for a third-party service.
Questions for the shortlist
- Which part of AI is your expertise in, and how does it relate to our audience?
- Which examples are your own work, and which are third-party cases?
- How do you distinguish a current capability from a forecast?
- What can you deliver if a live demonstration is unavailable?
- Will our recording rights cover the demonstration content?
Keep the virtual format central
A well-briefed session gives remote participants a route to ask questions at their own level. Collect questions beforehand, group them by theme and have a moderator distinguish questions suited to the keynote from those requiring a specialist follow-up.
A useful brief names one desired outcome: for example, “Help our leaders ask better questions about proposed AI projects.” That is more actionable than “Tell us everything about AI.”
A demonstration checklist
- Ask what participants should learn from the demonstration, not just which product it shows.
- Agree a clearly labelled fallback recording or screenshots if the service is unavailable.
- Check the source and date of any capability claim and identify limitations.
- Use non-confidential demonstration data and avoid surprise account-registration requirements.
- Explain whether the recording may include third-party interface material.
Capture these items in the technical rehearsal checklist. For a multinational audience, also consider whether all locations can access any optional follow-up tools.
Choose an AI question, not a tour of tools
| Audience | A useful keynote angle | What would make it too shallow |
|---|---|---|
| All employees | Where human judgement belongs in everyday AI-assisted work. | A rapid list of product names with no worked task. |
| Business leaders | How to choose a use case and evaluate its results. | Predictions without assumptions or trade-offs. |
| Technical teams | What changes between a demo and a dependable service. | Introductory metaphors in place of implementation experience. |
| Customer-facing teams | How to explain AI-supported service and handle failure. | Treating every automated answer as reliable. |
Ask the speaker which claims are durable principles and which depend on a product version. A virtual keynote can show an example live, but the audience also needs to understand why the example matters.
A worked virtual brief: useful AI with visible limits
Illustrative brief. A non-technical workforce is beginning to use approved AI tools. The keynote asks: “How can we decide when an AI-generated answer needs checking?” Use a fictional, non-sensitive task such as summarising an invented customer request.
The speaker shows the original task, a plausible output and a deliberate ambiguity. Participants privately identify the part that needs confirmation before the speaker discusses it. The point is to practise judgement, not to make a particular tool look infallible.
Agree whether the example is live or recorded and label it accurately. If it is live, prepare an approved fallback that illustrates the same question. Do not use real customer records, confidential documents or audience submissions for an improvised demonstration.
Questions to distinguish expertise from enthusiasm
- Which AI deployment have you worked on, and what did you learn when it failed or underperformed?
- How do you distinguish an illustrative demo from evidence of improved performance?
- Which assumptions in this keynote might change within a year?
- Can you explain the same example to our audience without relying on product jargon?
A speaker can offer an excellent strategic perspective without being an engineer. The important point is to match the claimed expertise to the brief. Ask a strategic commentator for clear framing; ask a technical practitioner for technical evidence. Do not silently substitute one for the other.
Design the screen for the viewer
A demonstration that is clear on the speaker’s large monitor may be unreadable on an attendee’s laptop. Show only the relevant part of the task, narrate changes and provide a text summary. Build enough pause for the audience to understand an output before switching views.
Invite questions about limitations, evidence and consequences, not only possibilities. A useful follow-up is one proposed use case with an owner and an evaluation question. The keynote should not become an instruction to adopt a tool without the organisation’s normal review.