How to capture useful evidence from a live AI demo without recording attendees

Record the tool, tier, input, output and stated limits from a London AI demo while keeping attendees, private screens and unauthorised material out of your notes.

Direct answer: Write down the demonstrated task, product, account tier, date, input conditions, output, stated limitation and official source link. Capture slides or audio only when the organiser and relevant speaker permit it, and frame out attendees, badges, conversations and private screens. If the rules are unclear, use written notes and ask for the published materials afterwards.

A polished video of a London stage is often worse evidence than a short structured note. It may show the result while hiding the account configuration, prepared input, unsuccessful attempts and speaker qualification that determine whether you can reproduce it.

Your objective is not to archive the room. It is to preserve enough context to test one claim later without collecting information about people who did not agree to become part of your record.

Applies to: public and private technology events in London. Recording, privacy and reuse requirements depend on the event rules, the material, the people captured, intended publication, contracts and jurisdiction; obtain qualified UK advice when a proposed use has legal consequences.

Use the demonstration evidence ledger

The demonstration evidence ledger is a note format with one row per technical claim. It records what was shown, the conditions around it and what remains unverified. It is an editorial method, not a recognised assurance standard.

Create these fields before the event:

• claim in the speaker's own meaning, paraphrased cautiously;
• product or application and named feature;
• model or service version if stated;
• account tier, region and connected tools if stated;
• input type and relevant constraints;
• visible output and time taken;
• limitation or failed case mentioned;
• official documentation or slide reference;
• question to test later; and
• evidence status: observed, speaker claim, documented or reproduced.

This is a narrow version of the source-preserving approach in A Useful AI Workflow for Focused Knowledge Work. It keeps observation separate from interpretation and later testing.

Check the event rules before opening the camera

Read the ticket page, venue notice and opening slide. Some London events permit photographs of presentation slides but not video. Others mark particular sessions or demonstrations as off the record. A speaker's willingness to answer a question does not automatically grant permission to record everyone nearby or publish their words.

If the rule is not visible, ask the organiser one precise question: “May I photograph this slide for personal reference, without attendees in frame?” Do not ask a broad question and interpret a casual nod as permission for filming, transcription and publication.

Copyright and permission are separate from whether a photograph contains personal information. UK government guidance says copyright material generally needs permission, a licence or a relevant exception for the intended use. Exceptions are specific and fact-dependent. Attendance or ticket purchase does not transfer ownership of a speaker's slides. GOV.UK guidance on using copyright material.

Where recording is allowed, keep the frame tight. Avoid name badges, laptop displays, audience questions and informal conversations. Disable automatic cloud photo sharing if it would send the image somewhere the event or your organisation has not approved.

Record conditions, not just the impressive output

Start with the task. “Produced a good summary” is not testable. “Produced five action points from a prepared two-page fictional meeting note” gives you a bounded claim.

Record whether the input was typed live, selected from a prepared file or retrieved through a connected system. Note any visible instruction, examples, retries or manual corrections. If the presenter switches tools or edits the output, preserve that fact rather than treating the final screen as a single automatic result.

Ask about the account tier and region only when they affect availability. Do not infer the model from the application's brand or visual design. The same model can behave differently across applications because the surrounding instructions, available tools, safety controls and account features differ.

If a detail is not stated, write “not stated”. A blank field is evidence of missing information. Filling it from memory later turns your assumption into something that looks observed.

Distinguish four evidence statuses

Do not promote an observation to a general product capability. One successful run does not establish reliability, and a prepared stage example may be selected because it works well. Equally, one failed venue run may reflect connectivity rather than the underlying system.

The UK government's AI Playbook recommends testing outputs against existing knowledge and documenting the system and source. Its mandatory language addresses government organisations, so use it here as a useful evidence principle rather than a private-event rule. AI Playbook for the UK Government.

Work through a 35-minute demonstration

Suppose a London meetup allocates 35 minutes to a live product demonstration with six headline claims. You have no permission to record audio or video. The following timings are illustrative assumptions, not measured standards.

Recording a complete ledger row takes about three focused minutes. Capturing the event title, speaker role and official documentation link takes another five minutes. Reserving six minutes for watching without typing leaves:

35 − 5 − 6 = 24 minutes.

At three minutes per row, the theoretical capacity is:

24 ÷ 3 = 8 rows.

Six claims fit, but interruptions and questions may reduce that capacity. You decide to prioritise the four claims connected to your work. Four rows require 4 × 3 = 12 minutes, leaving 24 − 12 = 12 minutes for corrections and context.

Each row has eight technical evidence fields, excluding status and follow-up. Across four rows that is 4 × 8 = 32 fields. After the demo, 25 are filled, four say “not stated” and three are blank because you missed them. The recorded-field rate is 25 ÷ 32 × 100 = 78.1%.

That percentage is not an accuracy score for the product or your notes. It reveals that seven conditions need clarification before you can present the claims as documented or reproducible. The correct next action is to seek the slides or official documentation, not to invent the missing tier, model or input.

Keep attendee information outside the ledger

Do not write names merely because they appear on badges. If an audience member asks a technically useful question, record the question without identifying them unless attribution is necessary and agreed. Separate the speaker's answer from the audience premise so later readers do not attribute both to the presenter.

Avoid descriptions of appearance, employer or personal circumstances that do not serve the verification task. If a contact asks you to follow up, store only the professional details and agreed action in the appropriate system, subject to its notice and retention rules. Do not turn an event conversation into an unrelated marketing record.

The ICO's data-minimisation guidance asks organisations to assess whether information is adequate, relevant and limited to the purpose. Its detailed AI material is under review, but the practical question remains useful: would your evidence still work if this attendee detail were absent? ICO data-minimisation guidance.

Convert the ledger into a reproducible next step

Within 24 hours, mark each row observed, claimed, documented or reproduced. Add links to official documentation beside the relevant claim, including the date, plan and region checked. Do not attach a generic provider homepage to a detailed limitation.

Select one material claim and build the smallest safe test that could disprove it. Use synthetic or public inputs unless you have authority for anything else. Record the input, settings, output, review criteria and exceptions.

Share the result with colleagues only after the evidence status is explicit. A concise note saying “observed at the event, not yet reproduced” is more useful than a confident recap that hides the remaining work.

Complete the evidence pass the next morning

1. Spend ten minutes cleaning the ledger without adding facts from memory.
2. Spend twenty minutes opening the official sources captured at the event and marking which exact claims they support.
3. Choose one claim for a bounded reproduction test and assign its reviewer.
4. Stop sharing the claim as a recommendation if the relevant tier, input or success condition remains unknown.

Delete incidental photographs that contain attendees or private screens and are not needed for an authorised purpose. Keep permitted evidence only for as long as its purpose and your applicable record rules require.

Related guides

• How to choose an AI workshop when you cannot upload work data
• How to judge an AI startup pitch at a London demo night

Frequently asked questions

Can I photograph every slide if the organiser says photography is allowed?

Not automatically. Confirm whether the permission covers all sessions, the particular speaker and your intended use. A photography-friendly event may still mark individual slides as confidential or prohibit commercial republication. Frame out attendees and private screens, and stop if the speaker changes the rule. For personal notes, capture only slides that preserve a material setting, limitation or source. If you plan to publish the image, check copyright, attribution, privacy and contractual requirements separately. UK exceptions are specific, so obtain qualified advice when your proposed use is consequential or unclear.

Is an audio note safer than filming the room?

It can collect less visual information, but it still records voices, audience questions and potentially private conversations. Check the event and speaker rules before recording. If permission is absent or ambiguous, type or write a structured note instead. A short voice memo made afterwards in a private place can preserve your own recollection without capturing the session, provided you label uncertain details and verify them later. Do not dictate names, badge details or confidential material unnecessarily. Store any permitted audio according to its purpose rather than leaving it in an automatically synchronised personal library indefinitely.

What if a speaker tells me directly that I may record them?

Clarify the scope: audio or video, which part of the session, personal reference or publication, editing, attribution and retention. Their permission may not cover other speakers, audience members, slides owned by another organisation or venue rules. Capture the agreement in an appropriate record, then frame and edit within it. Do not interpret consent to one interview as permission to record the surrounding room. Rights vary by material, contract and jurisdiction. If the recording will be commercial, widely distributed or used in a disputed context, seek qualified advice before relying on an informal exchange.

Should I copy the presenter's prompt word for word?

Only if the event permits it and the prompt itself contains no private or protected material. A prompt can help reproduce the demonstrated conditions, but it does not guarantee the same output. Record surrounding facts such as model or application, account tier, connected sources, settings and whether the presenter retried. If exact copying is prohibited, describe the instruction's structure in your own words and ask whether an authorised example will be published. Never copy visible system instructions, credentials or attendee inputs from a screen simply because they appeared during a live session.

How do I note a failed demonstration fairly?

Record what happened, the stated conditions and what the presenter did next without diagnosing a cause you cannot establish. A venue connection failure, account problem, incorrect input and system limitation can look similar from the audience. Write “the request did not complete during the observed run” rather than “the product never works”. If the presenter explains the cause, label that as their explanation until supported. Preserve any successful retry as a separate run. A fair note makes both the failure and uncertainty visible, allowing later testing to investigate rather than amplify an embarrassing moment.

May I share my notes publicly if they contain no attendee names?

Possibly, but removing names does not resolve every issue. Your notes may reproduce protected slides, reveal an off-record claim, misattribute an audience question or expose a confidential demonstration. Review the ticket and session rules, distinguish quotations from paraphrases, link evidence and ask permission where needed. Correct the speaker's meaning rather than publishing a rushed interpretation. Data protection, confidentiality, copyright and defamation considerations depend on the facts and jurisdiction. For a consequential public account, use your organisation's editorial or legal review rather than assuming nameless notes are automatically safe to publish.

Sources and verification

• GOV.UK: using somebody else's intellectual property, checked 6 October 2026 for the distinction between permission, licensing and specific copyright exceptions.
• AI Playbook for the UK Government, checked 6 October 2026 for documenting sources, testing outputs and using objective evidence. Its government scope is stated in the article.
• ICO: AI data minimisation, checked 6 October 2026 for limiting information to the purpose and the notice that the guidance is under review.
• The assigned parent guide was read from the supplied website source. Its exact internal URL is retained as instructed.