How to write a practical AI-use policy for your event team

Someone on your event team has found an AI tool that can turn a rough brief into an email in seconds. Someone else has uploaded a supplier proposal to get a summary. Your freelancer uses an assistant inside their design software. You haven't agreed what any of them may share, check or send, but the work is already happening.

Your event team AI policy should make those decisions clear. Allow specific tasks in approved tools, define the information each task may use, and name the person responsible for checking the result. Give separate approval for anything that can contact buyers, change records or spend money. Staff should be able to read the policy and know whether they can continue with the job in front of them.

I'd begin with a narrow permission that your team can actually use. Drafting a programme announcement from public event information is a reasonable starting point. Uploading your entire buyer database because the tool might find something interesting needs a different conversation. The policy should explain how to get that conversation resolved, including what to do while approval is pending.

This guide walks through those decisions, develops a worked example for a paid event business, and includes policy wording you can adapt. The sample is an operating starting point. The person responsible for your contracts, privacy and employment arrangements should check the relevant requirements before you adopt it.

Start with the jobs your team already does

Ask staff where AI appears in their work today. Include tools they've chosen themselves and features inside software you've already purchased. A meeting recorder, an automatic summary button and an image generator can all handle event information, even if nobody thinks of them as a separate AI project.

Make that first conversation practical. Ask someone to describe their last use, the information they supplied, what came back, and where the result went. You may discover that the main issue is an agency automatically recording supplier calls, rather than staff using a chatbot to suggest subject lines. A policy written without those examples can miss the work it needs to govern.

Cover permanent staff, temporary workers and contractors who handle your information or represent the event. Explain the requirements to agencies before they start. Your internal document doesn't automatically change their contract, and their own software policies may allow uses you wouldn't approve. Agree the terms of the assignment rather than assuming everybody follows the same rules.

For this guide, consider a fictional business called Rowan Events. It runs paid professional conferences and practical workshops. Leila manages operations, Dev handles marketing, and a freelance designer prepares campaign assets. Mara owns the business and approves campaign releases. They want AI assistance with routine preparation while retaining control of buyer communications and event decisions. Every Rowan example below is invented to show how the policy works.

Their initial inventory finds announcement drafts, summaries of supplier documents, proposed survey themes and automatically generated meeting notes. Those uses have different consequences. Rowan can approve one while holding another for review. It doesn't need to settle every future application before giving Dev a safe way to prepare his next campaign.

If you're still deciding which applications deserve a trial, our guide to AI trends in events compares the main options. The policy has a different job. It defines how your team may use an application after you've decided it's worth considering.

Approve a task, its information and its permissions together

An approved software name is too broad to guide someone through an actual decision. The same account might produce a harmless draft from a public programme or analyse private messages from ticket buyers. Record the permitted task alongside the tool, account, allowed information and required review.

For Rowan, the first approval is specific. Dev may use the business's approved writing account to draft programme announcements using public event descriptions and approved factual notes. Leila checks event facts and promises before the copy is used. The assistant receives no buyer list and has no permission to publish or send anything.

That permission doesn't extend to another account with a similar name. It also doesn't cover a browser extension that can read the whole ticketing dashboard. Staff need to know the actual account and feature they may use, including whether access is through the business or a personal subscription. Put a direct reference to the approved setup in a shared list of approved uses. This register is where staff check the current permission and its conditions.

Record limitations in ordinary words. For example, the tool may suggest alternative wording but may not invent ticket inclusions, quote customer results or change the refund policy. If the source doesn't answer a question, the draft should identify the missing information for a person to resolve. Making the output look complete isn't an acceptable reason to fill a gap with a guess.

NIST's voluntary AI Risk Management Framework core calls for documented responsibilities, oversight and continuing review. It isn't an event policy or a legal certificate. For a small operator, a useful application is to give each approved use an owner who can explain its limits and stop it when the conditions change.

Keep the register short enough to maintain. Staff need to recognise which approval covers their work without documenting every harmless change to a sentence. Add a new entry when the task, information or ability to act changes materially. A spelling suggestion and an assistant connected to your sales account should never inherit the same permission simply because both use AI.

Tell staff which information they may use

Start with material you can confidently allow for the task. Public event descriptions, published opening times and fictional practice records are useful inputs for many writing and training exercises. Public availability still doesn't establish permission to reproduce somebody else's work, so keep source rights separate from whether the information is confidential.

Next, identify information that requires a specific decision. A supplier's unpublished proposal may contain commercially sensitive prices and contract terms. A buyer message may contain personal details, a complaint or an access request. An internal budget may reveal negotiating limits. Staff shouldn't have to guess whether a general approval for document summaries includes those records.

I would keep personal information, confidential contracts and sensitive operational documents out of general writing tools by default. That is a proposed business rule, not a claim that every such use is unlawful everywhere. If a genuine task needs them, the owner should assess the particular information, supplier arrangement and controls before allowing it.

Describe prohibited inputs with examples staff recognise. Payment credentials, account passwords, identity documents and private incident reports don't belong in a routine announcement-writing conversation. Include attachments, screenshots and copied email threads. Someone can avoid typing a customer's name while uploading an image that displays their address, booking reference and full message. Check the whole file before sharing it.

Removing names alone doesn't make a file anonymous. A comment about a distinctive role, event and incident can still identify someone. Small groups can also reveal individuals when combined with what staff already know. Use genuinely invented material for practice whenever it will answer the question, and ask the person responsible for privacy before treating altered customer records as safe.

The UK's ICO discusses the need to assess security and use only necessary personal information in its AI security and data minimisation guidance. That guidance concerns UK data protection and is under review following legislative changes. Check the requirements applying to your own business and proposed processing; a staff policy doesn't supply legal permission to share data.

For Rowan's survey-summary proposal, Leila asks what the team actually needs to learn. They want to organise recurring programme suggestions, not identify unhappy customers. She holds the real-comment upload while the supplier and data review happen. Dev can practise the categorisation method with fictional comments, but he must label the exercise so nobody reports its themes as attendee findings.

Check the supplier arrangement behind the account

A paid subscription doesn't answer how your information will be handled. Before approval, establish what happens to prompts, uploaded files and generated results. Ask about storage, access, retention, deletion and use for model training. Find the applicable terms for the account you intend to use and record anything you still cannot confirm.

Look beyond the most reassuring setting on the screen. A statement that content isn't used for training doesn't by itself answer how long it remains stored, whether support staff can access it, or what happens when you close the account. Your approval needs to match the full arrangement and actual settings, rather than relying on a label such as business or private.

Check who controls the account. The business needs an agreed way to remove a departing worker's access and retain whatever records it legitimately needs. Shared passwords make that harder. Where the tool supports individual accounts and access controls, use them in a way that matches each person's work. A freelancer shouldn't need broad access to your internal documents to produce an approved campaign graphic.

Inspect connected services separately. An assistant that searches a chosen public webpage has a narrower information supply than one connected to all your files and messages. Ask which folders or accounts it can read, whether it keeps copies, and how access is withdrawn. Approving the original writing task should not silently approve every connection the supplier later offers.

If the person assessing the service cannot get a clear answer, reduce the proposed use or hold it. You can often continue using public or invented information while a more demanding use remains unapproved. Don't ask staff to infer a supplier's promises from a successful demonstration. A tool can complete the task while handling information in a way your business cannot accept.

Keep the approval evidence somewhere the next reviewer can find it. Record the relevant terms, settings, account owner and date checked. When terms or features change, you need to know what the original decision depended on. This can be a simple shared record; the important part is that someone owns the follow-up.

Define what a human review must check

Saying that a human must review every output sounds clear until you ask what the reviewer actually does. Reading a draft for tone won't catch an invented accessible entrance. Comparing it with the current event brief might. Define the check around the consequence of an error and give the reviewer the source material they need.

For announcement copy, check the event, date, venue, time zone where relevant, ticket inclusions, booking requirements and links. Compare claims with current approved information. If a sentence implies that a workshop is included in admission, the reviewer needs the actual ticket offer, not their memory of last year's programme. Check the meaning of the promise as well as the individual facts.

For a supplier summary, someone should compare important obligations and exclusions with the original document before making a commitment. A summary that omits overtime, access restrictions or cancellation terms can make the cheaper quote look much better than it is. The supplier's document remains the source; the generated summary is an aid to reading it.

The ICO's guidance on AI accuracy distinguishes correct personal information from a model's statistical performance. In its UK context, it also explains why predictions should not be presented as established facts. For your event workflow, that supports a practical distinction between a recorded buyer request and a tool's interpretation of what that person might want.

Require a competent reviewer. Someone who doesn't know the programme can't validate a technical session description simply by finding it readable. Someone unable to read the target language cannot approve a translation of safety instructions. Arrange the relevant expertise or restrict the task to work your team can check properly.

Let the reviewer reject the output and use the ordinary process. A person who has no time, authority or source access to challenge the assistant isn't providing much protection. If review repeatedly takes longer than doing the work directly, narrow the task or stop using the tool for it. Your policy should allow that decision without treating it as a failure to embrace technology.

Keep consequential decisions with named people

Some jobs involve more than producing a correct sentence. Deciding whether to refuse a refund, exclude a visitor, respond to harassment or change an access arrangement requires authority and context. Your policy should say who makes those decisions, even if AI helps prepare notes or draft wording after the decision is made.

For Rowan, a tool may help shorten an already approved explanation of the refund procedure using fictional details. It may not decide whether a real buyer qualifies, promise an exception or initiate a refund. The staff member with the appropriate authority checks the actual booking and policy through the existing support process. This keeps the decision understandable to the buyer and the business.

Apply the same care to predictions about people. A generated description of someone as a likely troublemaker, high spender or unsuitable speaker can influence staff even when no automatic action follows. Don't let casual labels become customer facts. Require a defined, reviewed purpose before using AI to rank or categorise individuals, and hold uses the business cannot justify or check.

Safety decisions need the responsible operational team. An assistant may help organise an approved checklist, but it shouldn't independently decide that a room can take more people or that an evacuation instruction can be shortened. Route proposed changes to the competent person responsible for that plan. Your policy should direct staff to the person already responsible for those instructions.

Make the boundaries equally clear when a tool can act through connected software. Reading an account, preparing a proposed change and applying that change are different permissions. Name which actions are allowed, what approval they need and what remains outside the assignment. Your own controls should enforce important limits wherever possible, so an instruction in a chat isn't the only thing preventing an unwanted action.

Our guide to what AI won't replace in events develops the role of human judgment. For the staff policy, convert that principle into names and actions. At Rowan, Leila handles operational exceptions and Mara approves campaign releases and payment commitments. People need a real escalation contact when a tool suggests something outside those limits.

Limit what connected tools can do

A document can contain instructions you never intended your assistant to follow. Someone might place a request inside a supplier file telling the assistant to share other documents or contact an external address. When software treats material it is reading as an instruction to act, your ordinary summarising task can become something very different.

This is commonly called prompt injection. The UK's NCSC explains in its analysis of prompt injection risks that systems need controls limiting the consequences, including restrictions outside the model itself. It cautions against assuming a product can eliminate the problem. For an event operator, the practical issue is what the assistant could access or change if it follows a misleading instruction.

Don't give a supplier-summary assistant broad authority over your inbox or ticketing account merely because a connection is available. Start with the smallest access the approved task requires. Have the person responsible for technology verify the actual restrictions and approval controls. A message telling the assistant to be careful is not the same as removing its permission to send.

Test the boundaries using safe material before real work begins. Can the assistant create a draft without sending it? Does it show the exact recipients and content before approval? Can you withdraw its connection? What happens if a supplied file asks it to ignore your rules? Check these conditions in the actual setup using fictional records.

Approval should identify the action being authorised. Staff shouldn't approve a vague continue message without knowing whether it means preparing text or publishing it. If the tool cannot make that distinction clear enough for your team to supervise, keep it out of that workflow until you have a reliable control.

Also decide who can stop the connection during a problem. A manager should not discover during an event that only a freelancer on another time zone can remove the assistant's access. Keep the account owner and interruption process in the approved-use record, and check that your named backup can use them.

Use your existing event platform for work it already handles

A writing assistant doesn't need your audience list just to draft an announcement. Give it the permitted event facts, review the wording, and use the system where your campaign and audience already belong. Exporting buyer data into another service adds a new handling decision without necessarily improving the writing.

For example, Loopyah's attendee email tools let your team build a campaign, send a test and schedule it. A policy can therefore permit a separate assistant to prepare wording from public information while a person reviews and uses that wording in Loopyah. Check the audience, final rendered message and schedule in the sending workflow.

Keep approval for a writing tool separate from any automation already authorised in your event software. If a configured email sequence sends messages under agreed rules, that doesn't grant a different assistant permission to create campaigns or change the sequence. Document the particular system's job and the person responsible for its configuration.

This also makes the work easier to review. Rowan keeps the approved email in its campaign system and the factual source in its event brief. The AI conversation isn't the only record of what buyers were told. If a buyer queries a promise later, the team can inspect the actual message and the approval behind it.

Set rules for creative work and public claims

Your designer may use generative tools without touching buyer data. The result still needs review. A generated venue image can imply facilities that don't exist. A synthetic crowd can suggest an atmosphere or turnout you haven't achieved. A fictional quotation can look like a real attendee endorsement when placed beside a ticket button.

Make the expectation concrete. Public claims need evidence, and invented examples need labels that survive the way people encounter them. Don't allow generated customer reviews, fabricated results or realistic depictions presented as documentation of an actual event. Require specific approval for imitating an identifiable person's face or voice, with permissions and disclosure assessed before use.

Input rights and ownership of output are separate questions. The US Copyright Office's report announcement on AI and copyrightability explains that US protection depends on sufficient human authorship and that prompts alone don't establish it. That doesn't decide whether your input materials were licensed, whether an output infringes someone's rights or what rules apply elsewhere. Check the intended commercial use rather than assuming an account's download button settles those issues.

For Rowan's designer, the permitted trial uses original rough concepts and an approved public programme description. The designer must identify generated elements internally and obtain approval before any public release. A realistic image suggesting that a particular speaker attended a previous event would fall outside that permission, even if the file contained no confidential information.

Keep useful creative assistance available. You can permit idea exploration, alternative layouts and wording suggestions while requiring actual venue information and approved photography in claims about the experience. The rule should protect what buyers reasonably understand from the finished work. Staff need to assess that meaning, not simply whether the file has an AI label.

A practical AI-use policy you can adapt

The following sample assumes a small paid-event business starting with narrowly approved uses. Replace the role names with your actual owners and complete the supporting approved-use register before issuing it. Have the appropriate adviser check any legal, contractual or employment implications for your business. The wording below is an original example, not a regulator's template.

Purpose and scope

We use AI where it helps our team complete useful event work under controls we can explain and maintain. This policy applies to staff and to contractors where agreed in their assignments. It covers standalone AI services and AI features inside other software whenever they handle our information or contribute to work produced for our events.

Generative AI produces material such as text, images, audio, video or code in response to instructions. An assistant may also be connected to systems that let it read information or perform actions. Permission to use one feature does not automatically include another. The approved-use register defines the account, task, allowed information, review and action permissions for each authorised use.

What you may do

You may perform a task already listed in the approved-use register using the specified account and permitted information. Follow the recorded checks before using the output. You do not need fresh approval for every routine attempt that stays within those conditions. If the task or required information changes, ask the use owner before continuing.

You may practise an approved method with genuinely fictional information where the register permits it. Label practice records and generated examples so they cannot be mistaken for real customers, event findings or supplier commitments. Do not copy real records into a practice exercise simply because you intend to delete them afterwards.

Information and access

Only supply the information permitted for that task. Payment credentials and passwords must not be supplied to general writing tools. Buyer records, confidential agreements, private staff or incident information and identity documents are also excluded by default. Any proposed use of those records requires a documented assessment and approval from the relevant information owner before use. The owner must also establish the applicable legal and contractual basis where required.

Check attachments, screenshots and quoted message threads as well as the words you type. Removing names does not automatically make information anonymous. Use the approved business account, protect access and do not add file, inbox or event-account connections without approval. Do not use a personal account as a workaround when a business use has been held or refused.

Checking and responsibility

The person using the output remains responsible for following the required review. Compare factual claims, numbers, dates, links and promises with current approved sources. Do not treat an AI-generated citation as verified evidence. The named reviewer must understand the subject, have access to the sources and be able to reject the result or request specialist help.

AI may prepare options or drafts within an approved task. It may not independently decide refunds, visitor exclusions, safety changes, access arrangements, employment decisions or supplier commitments under this policy. The authorised person makes those decisions through our existing process. Any proposal to automate a consequential decision requires a separate assessment and explicit approval before deployment.

Actions and publication

Do not allow an assistant to publish, send messages, change records, alter access or spend money unless that exact action is authorised in the register and the required controls have been tested. Approval to draft or read does not include approval to act. Check the proposed action and affected records or recipients before giving any required confirmation.

Keep the final approved work in the normal business system. Record the use and approval evidence required for that task without unnecessarily duplicating personal information. Generated material must not fabricate customer evidence, results, permissions or actual event scenes. Follow our agreed permissions and disclosure requirements for synthetic images, audio and other creative material.

Problems, exceptions and review

Stop the affected task and contact the operations lead immediately if information goes to an unapproved tool, the assistant takes an unexpected action or an incorrect result is used. Preserve the minimum evidence needed in an approved restricted location. Do not circulate the information more widely or attempt to conceal the problem. The responsible lead coordinates containment, correction and any required assessment or notification.

Exceptions must state the task, information, account, limits, reviewer and expiry or review condition. Until approved, continue through the ordinary process or use permitted fictional material for practice. The operations lead maintains the policy, reviews it when tools, terms or uses change, and names a backup contact. Urgency does not extend permission beyond the agreed task.

Give staff an approval record they can fill in

The policy supplies the standing rules. A short approval record applies them to a particular use. Keep it where people already find event procedures, and make the current status obvious. Someone should not have to search through old chat messages to discover whether a proposed survey upload was approved or merely discussed.

Use fields such as these, adapting them to the task:

• The job to be done and why AI assistance is being proposed.

• Tool, feature, business account and available version or configuration details.

• Allowed source information, with explicit exclusions.

• What the assistant can read and which actions it can perform.

• Person doing the work, reviewer, use owner and backup contact.

• Checks required before the output is used, including specialist review where needed.

• Supplier terms and settings checked, unresolved questions and relevant approval evidence.

• Where the final work and necessary records are kept, and how access or use can be stopped.

• Approval status, date, conditions and the change that requires another review.

Here's Rowan's completed example. The job is to prepare alternative wording for a public conference programme announcement. Dev uses the approved business writing account. Inputs are the published programme and a factual brief Leila has cleared. Buyer records, draft contracts and internal incident material are excluded. The assistant can produce text only and has no connection to the event account or sending system.

Dev compares the chosen draft with the factual brief, then Leila checks programme promises and timings. Dev builds the approved message in the campaign system and sends a test through the ordinary process. Mara checks that final version and audience before release. The saved campaign is the record of the communication; the use record stores the review reference without copying buyer information.

Leila owns the permission and Mara is the backup who can suspend it. Enter the exact service, account identifier and checked terms reference in your own record. New data inputs, an account change, a proposed connection, changed supplier terms or a material failure trigger review. Survey analysis remains pending under its own request. This completed record gives the team a usable answer while leaving unrelated applications undecided.

Rehearse the awkward cases before the next launch

Read the policy with the people who will use it, then give them realistic situations. Ask them to show what they would do and where they would find the answer. Having everyone acknowledge the document doesn't tell you whether a temporary marketing assistant can apply it during a busy launch afternoon.

Start with a straightforward case. Dev wants alternative subject lines using the public programme description in the approved writing account. That fits the recorded permission. He can proceed without asking Leila to approve the same method again. The output still goes through the normal campaign review before use.

Then change one condition. He wants to paste a buyer's complaint into that conversation so it can draft a personal response. The information and task have changed. Under Rowan's policy, he uses the existing support process and asks for a separate assessment if there is a worthwhile recurring use. A clean subject-line trial hasn't approved complaint handling.

Try a supplier case. The designer receives a confidential proposal and wants an AI summary. The policy directs them to the information owner before upload. They can ask a human to identify the relevant section or work with a permitted summary prepared internally. The fact that the deadline is close doesn't change the proposal's status.

For an action case, a tool offers to connect to the event account and publish the announcement automatically. The drafting approval doesn't cover it. Staff should identify the missing action permission and stop before connecting. If your rehearsal exposes uncertainty over who can approve that connection, name the owner before launch.

Finally, test a wrong output. The approved source says doors open at 18:00 and the programme begins at 18:30, but the generated email reverses them. The reviewer should catch the mismatch against the brief. Ask what happens if they don't. You need a correction route as well as a rule requiring checks, because even a sensible process can fail.

Fit these exercises into your existing event operations process. The same people who own announcements, buyer support and live changes should recognise their responsibilities here. AI use shouldn't create a second unofficial approval chain that nobody follows when the event gets busy.

Make mistakes easy to report and contain

An honest report gives you a chance to limit the problem. If staff expect punishment for admitting that they pasted the wrong attachment, they may keep experimenting with deletion settings or wait until somebody notices. Tell them whom to contact and what immediate actions are safe for their role. Investigate conduct through your normal employment or contract process rather than hiding it inside an unclear technical rule.

The first response depends on what happened. An inaccurate draft that never left the team may need correction and a review of the source. Buyer information uploaded to an unapproved service needs an assessment of the information, the service and possible exposure. A connected assistant that sent messages needs its further actions contained as well as the communication corrected.

Preserve enough evidence to establish the event and affected material. Store it with restricted access rather than forwarding the whole conversation to everyone. The responsible lead should coordinate any account restriction, supplier contact or deletion request, and confirm what can actually be done. Removing a local file doesn't establish that a supplier no longer holds a copy.

Assess notification obligations promptly with the person responsible for privacy or legal advice. Requirements depend on the incident and applicable rules. Don't let a general instruction to investigate become an excuse to miss a relevant deadline. Equally, don't ask an employee to improvise a public statement or legal conclusion alone while trying to contain the problem.

If Rowan's incorrect opening times reached buyers, Leila would confirm the actual times with the event owner, stop further incorrect communications where possible, and agree the correction. The team would inspect where the wording had been reused, including scheduled posts and staff notes. Correcting one email draft is insufficient if the same error remains in messages waiting to go out.

Keep the policy current without reopening every task

Review the policy when something relevant changes. That might be a supplier's terms, a new account feature, access to another system, a different type of information or a failure in the existing method. Give each approved use a review owner and a planned review point as well, so permissions don't survive indefinitely because nobody remembers to revisit them.

Pay attention to changes in the event business itself. A conference that begins collecting accommodation requests or introduces private buyer meetings may handle information its old writing trial never encountered. A new agency may use automatic meeting notes. Recording and transcribing calls needs its own review of permissions, participant information and handling arrangements before anyone switches the feature on. Updating your attendee information and reviewing your event privacy notice may be part of the resulting work; the internal AI policy doesn't replace either task.

Ask staff whether the permission still helps. If the approved process is too awkward, find out which step causes the delay and whether the tool is worth keeping. Simplify a repeated approval when the conditions are stable, or remove a use that demands more supervision than the business can provide. Don't quietly weaken the checks just because a subscription has already been paid.

Record what you change and tell the affected people before their next use. A freelancer needs to hear that a feature is no longer permitted, not discover it in a document edited after delivery. Remove account access when assignments end and check that the remaining owner can still manage the approved setup.

Before your next launch, choose a real task and ask the person doing it to show you the approved account, permitted information and required reviewer. Then have them explain what would make them stop and contact somebody. If those answers are clear, you have a policy your team can use. Resolve any missing permission before that task reaches buyer data or a live send.