Guidance

Using AI in education

What to check before you use AI output, what to disclose and what not to put in a prompt. Written for Australian trainers, assessors, teachers and academics.

Practical guidance, not legal advice and not a compliance determination. Your own organisation’s policy and your regulator’s requirements come first.

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

Ordered by how often they catch something, not by how serious the problem would be.

  1. Unit and qualification codes, against training.gov.au. A model will produce a plausible code as readily as a real one.
  2. Every performance criterion and knowledge-evidence item you rely on, against the actual unit. Paraphrasing a criterion changes what you are assessing.
  3. Numbers, dates and durations. These are where confident-sounding output is most often wrong.
  4. Anything presented as a quotation from a standard, a regulator or a training package.
  5. Whether the material suits the learners in front of you, including reading level and prior knowledge.
  6. Whether 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 Google Gemini or, as a fallback, OpenAI, over HTTPS and under those providers' standard API terms. We do not add training rights and, under those terms, neither provider trains on API submissions. 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.

Where AI does not belong

These are not policy positions we invented. Each one is a place where the output would be used as a decision about a person.

  • Deciding whether a learner is competent. A judgement about a person's competence is the assessor's, and it has to be defensible by the assessor.
  • Deciding an appeal, a complaint or a disciplinary matter.
  • Deciding whether a learner has plagiarised or misused AI themselves. Detection tools are unreliable in both directions, and a false accusation is a serious harm.
  • Deciding a reasonable adjustment. A tool can help you plan and cost one; whether it is reasonable is a conversation with the learner.
  • Deciding a recruitment outcome.
  • Signing anything. A person signs, and that person is accountable for what they signed.

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.