What an AI chatbot actually collects about your prospects
An AI recruitment chatbot on an Australian university or private higher education provider website begins collecting personal information at the very first interaction โ well before a prospect types their name. IP address, session timestamp, typed messages, course consulted: each of these is personal information under the Privacy Act 1988 (Cth) and the 13 Australian Privacy Principles (APPs).
72% of questions submitted to education chatbots are automatable FAQ inquiries, 21% require institution-specific context, and 7% require a human. (Source: automated classification of 12,000 Skolbot conversations, 2025.) Each of those 12,000 conversations is a processing activity subject to the Privacy Act. The chatbot holds a decisive advantage over other channels: average response time of 3 seconds, 24/7, versus 47 hours by email and 72 hours by web form (Source: Skolbot mystery-shopping audit, 2025, 80 institutions). Capturing that advantage requires a privacy-compliant data collection infrastructure.
Typical categories of personal information collected by a chatbot at an Australian higher education institution:
- Conversational data โ message text, timestamps, session language, session duration
- Voluntarily provided identifiers โ first name, last name, email address, phone number (when the prospect provides these to receive follow-up)
- Interest data โ course(s) browsed, target credential level, study mode sought (on-campus, online, combined)
- Voluntarily provided demographics โ citizenship status, state or country of residence, ATAR or WAM range (if relevant to admission)
- Technical data โ IP address, device type, browser, session identifier
The Office of the Australian Information Commissioner (OAIC) requires that each processing activity carried out via a chatbot rest on a lawful basis, and that individuals be notified of that collection at or before the time of collection (APP 5). Registered higher education providers are also subject to oversight by TEQSA (Tertiary Education Quality and Standards Agency), which can factor privacy compliance into registration decisions. For a complete overview of your institution's personal information processing, see our complete Privacy Act and student data guide.
The legal bases applicable to each data category
The Privacy Act 1988 does not use a "legal basis" framework identical to the GDPR, but APP 3 (Collection of solicited personal information) requires that collection must be reasonably necessary for one or more of the entity's functions or activities. Four grounds cover the vast majority of chatbot processing at an Australian institution:
Consent (APP 3.3 / APP 7) โ The individual has provided voluntary, informed, and current consent. This is the appropriate basis for subsequent direct marketing communications (follow-up emails, course information, open day invitations) triggered by chatbot interactions. Consent must be obtained through an active mechanism (unchecked checkbox), and individuals must be able to opt out of direct marketing at any time (APP 7.3). Electronic commercial messages also require consent under the Spam Act 2003.
Directly related to primary purpose (APP 6.1) โ Use or disclosure is for the primary purpose for which information was collected. A prospect requesting fee information or entry requirements: processing their email to send the requested documentation is directly related to the collection purpose.
Reasonably necessary secondary purpose (APP 6.2(a)) โ The individual would reasonably expect use or disclosure for a related secondary purpose. Aggregating anonymised conversation data to improve the chatbot's response quality generally satisfies this standard. Note: a documented assessment is best practice, particularly before any system upgrade or new use of existing data.
Legal obligation โ Required or authorised by Australian law. Relevant where data must be retained to satisfy ESOS Act obligations for international students or TEQSA registration requirements.
For sensitive information โ see the following section โ APP 3.3 imposes a higher standard: consent is generally mandatory, and the consent must be explicit.
The minimisation principle: collect only what is necessary
The "reasonably necessary" standard in APP 3 functions similarly to the GDPR minimisation principle: collect only what is adequate, relevant, and limited to what is necessary for the identified function. This is the most frequently breached principle in Australian higher education chatbot deployments.
Practical implications for your institution's chatbot:
- The chatbot must not require an email address to answer a question about courses. An email is only necessary if the prospect wants to be followed up or receive documentation.
- Citizenship status should not be collected systematically. It becomes relevant only when a prospect asks about domestic vs. international fee structures, Commonwealth Supported Places (CSP), HECS-HELP eligibility, or student visa requirements under Department of Home Affairs rules.
- Precise date of birth is unnecessary if the chatbot only needs to determine whether the prospect has an ATAR or is applying as a mature-age student. A study-level indicator is sufficient.
- Full conversation logs must not be retained indefinitely. The purpose of retention (service improvement, CRM transfer) must be defined before go-live, not after.
The OAIC's guidance on privacy by design and the Privacy Act Review 2022 emphasise that organisations should embed privacy-protective practices into system design from the outset โ minimisation must be architectural, not a post-deployment correction.
Sensitive information: citizenship, health, disability
Some information collectible via an Australian higher education chatbot constitutes sensitive information under Section 6 of the Privacy Act, attracting the higher APP 3.3 consent standard.
Racial or ethnic origin: citizenship is not inherently sensitive information, but where collection could reveal or be used to infer a person's racial or ethnic origin, APP 3.3 applies. A chatbot segmenting prospects by citizenship for targeted marketing must assess whether this constitutes indirect collection of racial or ethnic information.
Health and disability: prospects seeking information about accessibility services, special consideration for exams, or disability support services may disclose health information within the chatbot. The system should be configured to not record such disclosures in unprotected free-text fields. Where collection is genuinely necessary (routing to a disability support coordinator), it must rest on express consent under APP 3.3 with full prior notification.
Financial situation: questions about Youth Allowance, Austudy, FEE-HELP eligibility, or fee waivers may reveal financial circumstances. While not strictly "sensitive information" under the Act, such data requires a robust collection basis and appropriate security safeguards under APP 11.
Practical rule: configure your chatbot to detect sensitive topic keywords and redirect to a human agent or secure form, rather than capturing this information in the standard conversational interface.
Data categories, legal bases, and retention periods
| Data type | Legal basis (APP) | Retention period | Notes |
|---|---|---|---|
| Conversation messages (anonymised) | APP 3 โ reasonably necessary | <12 months | For service improvement โ anonymisation required |
| Email + name (qualified prospect) | Consent or primary purpose | 3 years after last active contact | Automated purging required |
| Phone number | Consent (Spam Act 2003 for electronic messages) | 3 years after last active contact | Separate opt-in required for direct marketing |
| Course(s) of interest | Reasonably necessary (APP 3) | Linked to prospect profile | Document in privacy management register |
| Citizenship / residency status | Consent or reasonably necessary | Linked to prospect profile | Assess risk of racial/ethnic origin inference |
| Age / study level | Reasonably necessary (APP 3) | Linked to prospect profile | Necessary to direct prospect to correct course |
| IP address (non-anonymised) | Reasonably necessary (APP 3) | <13 months | OAIC recommends prompt anonymisation |
| Health or disability information | Express consent (APP 3.3) | Strictly necessary | Do not collect in standard chatbot interface |
| Technical session logs | Reasonably necessary (APP 3) | <3 months | Security and debugging only |
Privacy Impact Assessment: when does your chatbot require one?
The Privacy Act does not mandate PIAs in all cases, but the OAIC strongly recommends a Privacy Impact Assessment for any project involving new or substantially changed information-handling practices. For Australian higher education chatbot deployments, a PIA is effectively required where any of the following apply:
- Large-scale collection: a chatbot processing thousands of conversations monthly at a university or TAFe/private provider readily qualifies as large-scale processing
- Profiling: if the chatbot scores or classifies the prospect (warm/cold, course recommendation, enrolment probability) from their interaction data, this is automated profiling that warrants a PIA
- Sensitive information: any collection of health, disability, racial, or financial information
- Overseas disclosure: if your chatbot provider stores data or uses language models on servers outside Australia, APP 8 (cross-border disclosure) applies โ and a PIA should assess whether the overseas recipient meets APP-equivalent standards
The PIA documents: purpose and data flows, risks and likelihood, and mitigation measures. Where residual risks remain high, the OAIC recommends consulting before proceeding.
For the full technical and organisational checklist, see our Privacy Act audit checklist for Australian schools.
Implementing compliant data collection: the chatbot interface
Privacy Act compliance for a chatbot operates at three levels: collection notice, consent mechanism, and individual rights.
Collection notice (APP 5)
Before the first exchange, the chatbot must display a notification including:
- The identity of the collecting organisation (the institution)
- The purposes of collection (answering questions, qualifying the prospect)
- Whether disclosure to overseas recipients is likely, and if so, which countries
- How individuals can access or correct their personal information and make complaints
- The disclosure that the interlocutor is an artificial intelligence system (aligned with emerging obligations under Australia's AI Safety Standards and the OAIC's guidance on automated decision-making)
Compliant example: "I'm [Chatbot Name], [Institution]'s AI assistant. We collect your information to answer your enquiries. See our [privacy policy] or contact privacy@[institution].edu.au to access or correct your information."
Integrated consent mechanism
Where the chatbot collects email or phone number, an active consent mechanism must precede that collection:
- Unchecked checkbox for marketing communications
- Separate disclosure for each purpose (re-engagement, course newsletter, open day invitation)
- Timestamp and retention of consent evidence
Individual rights: access, correction, deletion
Under the Privacy Act, individuals have the right to access personal information (APP 12) and request correction (APP 13). Requests must be responded to within 30 days. A deletion or de-identification request should cover all systems: chatbot logs, CRM, email platform, analytics, and backups.
Test Skolbot on your institution in 30 seconds
FAQ
Does the Privacy Act require a PIA for a chatbot that only answers FAQs without collecting emails?
A mandatory PIA is not prescribed for all chatbot deployments under the current Privacy Act, but the OAIC strongly recommends one for any new or substantially changed information-handling system โ including a chatbot that processes IP addresses and session logs, even without email collection. Following the Privacy Act Review 2022, the Australian Government has indicated it will strengthen PIA requirements. Best practice: conduct a PIA before go-live regardless of scale. This positions your institution well under both current law and anticipated reforms.
What are the retention periods for chatbot conversation data in Australia?
The Privacy Act (APP 11.2) requires that personal information is destroyed or de-identified when it is no longer needed for any purpose for which it may be used or disclosed. The OAIC recommends defining clear retention schedules before deployment. Practical guidance: anonymised service-improvement logs โ up to 12 months; qualified prospect data (email provided) โ up to 3 years after last active contact; technical session logs โ no more than 3 months. These periods must appear in your privacy management register and be enforced through automated purging.
Can the chatbot transfer prospect data to the CRM without additional consent?
This depends on whether CRM use falls within the primary or a related secondary purpose for which the information was originally collected. Transfer for admissions follow-up is generally within scope. Use for broader promotional campaigns (advertising retargeting, unsolicited marketing emails) requires consent obtained before the transfer โ and express consent under the Spam Act 2003 for electronic messages. Critically, if the CRM involves disclosure to an overseas recipient (e.g., a US-hosted Salesforce instance), APP 8 requires either reasonable steps to ensure equivalent privacy protection or the individual's informed consent to that cross-border disclosure.
How must an Australian institution disclose that a prospect is interacting with an AI?
There is currently no standalone AI disclosure statute in Australian law equivalent to the EU AI Act, but the OAIC's Guidance on Privacy and AI and the Australian Government's AI Ethics Principles both support clear, upfront disclosure. Best practice: a chatbot name that signals AI (e.g., "Skolbot, AI Assistant"), a welcome message explicitly identifying the system as AI, and a visible indicator in the interface. The OAIC has signalled that AI disclosure obligations will be strengthened as part of the Privacy Act reform process, making early adoption prudent.
What if a prospect spontaneously discloses a disability or health condition in the chat?
Configure your chatbot to detect sensitive topic keywords (disability, health, chronic illness, mental health) and respond with a redirect: "For personalised support, our Student Accessibility Services team can help. Would you like us to connect you?" Do not store the sensitive disclosure in standard conversation logs. If full session logging is technically unavoidable, sensitive fields must be masked or deleted before archiving. The risk: health or disability information flowing into a marketing CRM without the express consent required under APP 3.3 โ a direct Privacy Act breach.



