Using AI in education

Worked example: turn a vague request into a usable session plan

This fictional workplace-email activity shows how to draft, check and revise a lesson. It is a teaching exercise, not an assessment tool or evidence of competence. You can adapt it without an RTOAiVoX account.

1. 1Start with the learning outcome: by the end of 30 minutes, adult learners will rewrite a fictional email so its purpose, requested action and deadline are clear. A request such as ‘make a communication lesson’ leaves all three decisions to the model.
2. 2Try this prompt: ‘Draft a 30-minute lesson for eight adult learners practising workplace emails. Use fictional names and no real customer information. Include a five-minute introduction, a five-minute demonstration, ten minutes of paired rewriting, five minutes of peer feedback and a five-minute exit activity. Supply an unclear email and a revised version. Explain each change. Do not assign a qualification or unit code.’
3. 3Use this starting email: ‘Hi Alex, about the booking we discussed, can you sort the thing out soon? Thanks, Sam.’ Ask learners what Alex would need to know before acting. The missing details are the booking reference, the action and the deadline.
4. 4A possible revision is: ‘Hi Alex, please confirm whether meeting room B is available on Thursday from 10 am to 11 am. Please reply by 3 pm on Tuesday so I can send the invitation. Thanks, Sam.’ This is one possible answer. Learners can choose other wording if the same information is clear.
5. 5Check the generated plan before use: do its activities total 30 minutes, can pairs finish the task in ten minutes, and does the exit activity check the stated outcome? Remove invented workplace rules. Adjust reading demands and delivery methods for your actual learners.
6. 6Finish with a new fictional email for learners to revise individually. Record which details were still missing and use that information to plan the next lesson. Completing this activity alone does not establish competence in a training-package unit.

Worked example: find a confident but unsupported AI claim

A fluent paragraph can hide an unsupported conclusion. This deliberately flawed sample gives trainers a repeatable way to review an answer before sharing it.

1. 1Sample output to challenge: ‘This ten-question quiz proves that every learner is competent and makes your assessment fully compliant.’ There are two claims to investigate: that this quiz proves competence, and that it establishes compliance. Neither follows from the information supplied.
2. 2Separate the draft from the evidence. Ask: what learning outcome does each question address, what does the learner actually demonstrate, and what requirements have not been considered? For nationally recognised training, consult the current unit and assessment requirements on training.gov.au rather than asking the model to invent them.
3. 3Use this review prompt with material you are permitted to share: ‘Review the following fictional quiz description. List each factual claim, the evidence needed to support it, and any uncertainty. Do not invent sources, codes or compliance conclusions. Keep suggested edits separate from the original text.’
4. 4A more accurate description is: ‘This quiz provides a check of the topics covered in this session. The trainer reviews the responses and identifies where more teaching or evidence is needed.’ Use that description only if it matches the actual purpose of your quiz.
5. 5Keep a simple review record: original claim; source or evidence checked; decision to keep, revise or remove; reason; reviewer; date. For this sample, the decision is to remove both guarantees because the quiz description does not establish either claim.
6. 6Try it yourself: take one paragraph of your own non-confidential draft and highlight every number, guarantee and reference. Check each against its source. If you cannot establish a claim, remove it or state the uncertainty before learners rely on it.

Worked example: choose a small AI workflow and measure it

Start with a task you can inspect and reverse. This example uses a fictional workshop reminder, with no learner records or automated sending.

1. 1Define the task narrowly: draft a reminder from an approved workshop outline. Keep enrolment lists, email addresses, attendance and personal support information out of the prompt. A person still checks and sends the final reminder using the organisation’s normal process.
2. 2Example prompt: ‘Write a reminder of no more than 100 words using only these fictional details: workshop on Tuesday, 10 am to 11 am, room B; bring a notebook; practise writing clear workplace emails. Use plain Australian English. If a detail is missing, flag it separately rather than inventing it.’
3. 3A reviewable draft is: ‘Your workplace-email workshop is on Tuesday from 10 am to 11 am in room B. Please bring a notebook. We will practise writing clear workplace emails.’ Before sending, check the actual calendar date, location, recipient group and any approved accessibility information. The prompt has not supplied all of these.
4. 4Measure the whole task, including checking. Fictional timing example: a manual draft takes 12 minutes; prompting takes three minutes, checking five minutes and corrections two minutes. The reviewed AI workflow takes ten minutes, a saving of two minutes for this example, not a promised saving for other tasks.
5. 5Decide whether to continue based on several reviewed attempts. Record total time, factual corrections and whether the message helped recipients. Stop or redesign the workflow if checking takes longer than drafting, confidential information is required or errors are difficult to detect.

Where our tools fit, and where they do not

Every document our tools produce is a first draft. That is not modesty, it is the design: the tool has your unit code and your form inputs, and it does not have your learners, your delivery context, your industry consultation or your validation history.

• A generated assessment tool is a starting structure. Whether it actually assesses the unit against its own requirements is a judgement only you can make.
• A generated session plan does not know your cohort, your facilities or how much of the last session ran over.
• Validation output works clause by clause against the Standards for RTOs 2025. It tells you what to look at. It does not decide whether you comply, and no software can.
• Nothing we produce is an audit outcome, a legal opinion or a compliance determination.

What to check before you use AI output

Use this review sequence before sharing a draft. It is a practical checklist, not a ranking based on measured error rates.

1. 1Unit and qualification codes, against training.gov.au. A model will produce a plausible code as readily as a real one.
2. 2Every performance criterion and knowledge-evidence item you rely on, against the actual unit. Paraphrasing a criterion changes what you are assessing.
3. 3Numbers, dates and durations. These are where confident-sounding output is most often wrong.
4. 4Anything presented as a quotation from a standard, a regulator or a training package.
5. 5Whether the material suits the learners in front of you, including reading level and prior knowledge.
6. 6Whether an adjustment you have on record for a learner survived into the adapted material.

What to disclose, and to whom

There is no single Australian rule on this yet, so the practical test is: who would be surprised to learn AI was involved, and would they have a fair reason to be?

• Your own organisation's policy comes first. If it says nothing about AI, that is worth raising rather than treating as permission.
• In assessment validation records, note where a draft was AI-generated and who validated it. A validation record that hides the drafting method is less useful to the next reader, not more.
• To students, when AI shaped material they are assessed against, and when you expect them to disclose their own use. Asking for a disclosure you do not give is hard to defend.
• In an audit, if asked. A drafted-then-validated document with a named validator is an ordinary quality process, and describing it plainly is stronger than being found to have obscured it.
• Not every use needs announcing. Using AI to reword a paragraph of your own writing is not a disclosure event.

What not to put in a prompt

Requests go to third-party providers over HTTPS under those providers' API terms, and may be processed outside Australia. We do not add training rights, and the providers behind our document tools and chat state that API submissions are not used to train their models. That still leaves things that should not be sent.

• Named learner information. A learner's name, contact details, student identifier, disability, health information or assessment results. Describe the situation without identifying the person.
• Staff records, performance matters or anything about a named colleague.
• Anything covered by the Privacy Act 1988 that you would not send to an external contractor, because functionally that is what you are doing.
• Third-party copyright material you do not hold rights to, including whole published assessment tools and purchased resources.
• Commercially sensitive material about your organisation or another one, including tender documents and pricing.
• Credentials of any kind. No passwords, no API keys, no student-management-system logins.

If you are writing your own AI policy

We deliberately do not offer an AI policy template. A template invites being adopted unread, and an unread AI policy is the exact problem it appears to solve. What follows is what a workable one settles.

• Which tasks staff may use AI for, named specifically rather than by category.
• What must be checked before output is used, and who signs off.
• What may never be entered into a prompt, in your own words and your own examples.
• How AI involvement is recorded, in validation records and in student-facing material.
• What you expect of students, and what you will do when you suspect undisclosed use.
• Who to ask when the policy does not cover the situation, because it will not cover every situation.