AI Policy Template for Australian Practices: AI Acceptable Use Policy for RACGP 6th Edition F11

What's in this template?

This is an AI policy template for Australian general practices and allied health practices: the internal policy that decides which AI tools your team may use, in what configuration, with what patient information, what patients are told, and how the practice checks itself afterwards. It is built from the OAIC's Guidance on privacy and the use of commercially available AI products, the Privacy Act 1988 (APP 1, 3, 6, 8, 10 and 11), and the RACGP Standards for general practices (6th edition): criteria F11.A and F11.B on artificial intelligence, the F4 guidance on training for AI systems, the CG7 guidance on AI-related incidents, the F9.A privacy policy content, and F10.A on digital health technologies.

The OAIC's expectation is direct: organisations using AI should "establish policies and procedures for the use of AI systems to facilitate transparency and ensure good privacy governance." The RACGP's AI scribes guidance (last updated October 2025) tells practice owners to "Develop a policy on using AI scribes in the practice." The RACGP does not publish an AI policy template: its policy and procedure templates page (last updated 19 May 2025) lists none, and MDA National's AI governance template (21 September 2026) is for its members only. This template is that document, built to the criteria and mapping every F11 indicator to the section that answers it.

The template has 12 numbered sections and four appendices:

1. Purpose: why a decision about AI has to be recorded rather than left to whoever found the tool first
2. Scope: all staff including contractors and locums, every AI tool that touches practice information, and AI features a vendor switches on inside software you already use
3. How this relates to your other documents: the boundary table (security policy, privacy policy, the AI scribe consent form, the digital health technology governance policy, the AI scribe governance pack)
4. Approved AI tools and configurations: only what is on the AI register at Appendix A, in the plan it was approved in
5. Prohibited uses: what must never be entered into an unapproved tool (names, dates of birth, Medicare and IHI numbers, clinical details, referral content, consultation notes), plus AI output used as clinical advice without clinician review
6. Patient disclosure and consent: what the privacy policy must say (including the F9.A overseas-disclosure and document-automation lines and the 10 December 2026 automated decision-making duty), consent where AI is involved in care, 6.3 withdrawal of consent and the alternative care pathway (the four F11 steps), AI scribes (note review as soon as possible and before saving, sending or billing; MBS item suggestions verified), patient-facing tools identified as AI, and 6.6 the labelling decision for AI-involved records
7. Assessing a new AI tool before adoption: the 13-step procedure (data processing agreement and indemnity clauses, model-training opt-out, data residency, sub-processors, breach notification, exit and historical data, security certifications, human oversight, privacy impact assessment, the ARTG question with a recheck after every update, team discussion, the register entry)
8. De-identification and identified patient data: why removing a name is not de-identification, and 8.3 the three conditions under which identified patient data may be used by an AI tool (F11.A: clinically necessary, explicitly authorised, documented governance and consent)
9. Monitoring, review and incidents: 9.1 the register review, now including every vendor update; 9.2 the annual AI review, a nine-measure checklist built from the RACGP's F11 monitoring examples; 9.3 AI-related incidents, the CG7 category with its five sub-types and proactive detection that does not rely on complaints
10. Roles and responsibilities: the practice owner, a named AI governance lead, the privacy officer, clinicians, all staff, the IT provider; 10.1 training for AI systems (the three F4 topics and a refresh interval)
11. Related documents
12. Approval and review: with a signature block and the review triggers (the 6th edition transition announcement, the OAIC's automated decision-making guidance, a vendor update that adds a feature that suggests or decides)

Appendix A: AI register, in two landscape tables. Table A1 (approval): ID, tool and vendor including features inside existing software, plan approved, permitted and prohibited uses, whether identified patient data is authorised, the alternative pathway if a patient declines or the tool is offline, named owner, approval and review dates. Table A2 (regulatory and data): features that suggest or decide, ARTG entry or the exemption basis the vendor relies on, where data is stored and processed, the model-training setting and the clause it rests on, retention, the DPA reviewed, and the last vendor update checked. The same columns as the register in the AI Scribe Governance Pack, so a practice keeps one register.

Appendix B: Staff acknowledgement and training log: who has read the policy, which tool they were trained on, which of the three F4 topics were covered, and when the refresh is due.

Appendix C: RACGP 6th edition F11 criterion map: all nine F11.A and F11.B indicators, quoted from the Standards, against the section that answers each and the evidence the practice keeps, plus the related criteria a surveyor may look at (F4.B, CG7.B, F9.A, F8.B, F10.A, PP4.B).

Appendix D: Staff AI rules card: one page for reception and non-clinical staff.

Editable placeholder fields

The template uses yellow-highlighted {{placeholder}} fields:

• {{ }}Practice name{{practice_name}}, {{ }}ABN{{abn}}, {{ }}Practice address{{practice_address}}
• {{ }}AI governance lead{{ai_governance_lead}}: the person who holds the AI register, checks every vendor update, runs the annual review, receives AI-related incident reports and keeps training current (often the privacy officer or the person with primary responsibility for digital governance under F8.B)
• {{ }}Privacy officer{{privacy_officer}}: the privacy policy and breach assessment
• {{ }}Approved by{{approved_by}}: who signs off the policy, every tool added to the register, and any authorisation of identified patient data
• {{ }}Labelled or not labelled{{labelled_or_not_labelled}}, {{ }}AI label text{{ai_label_text}}, {{ }}Labelling decision date{{labelling_decision_date}}: the labelling decision (Section 6.6)
• {{ }}AI training refresh interval{{ai_training_refresh_interval}}: the training refresh (Section 10.1; at least every 12 months is our suggestion)
• {{ }}Withdrawal flag location{{withdrawal_flag_location}}: where a patient's withdrawal of consent is flagged in the clinical software
• {{ }}Effective date{{effective_date}}, {{ }}Next review date{{next_review_date}}, and the sign-off dates

Grey italic notes mark the places that need your judgement rather than a find-and-replace, including the one most practices need to hear: an empty register alongside this policy is a compliant position for a practice that uses no AI, and it is better evidence than a register listing tools nobody has assessed.

Six documents, six different questions

Practices often have one of these documents and assume it covers the others. It does not.

This policy feeds the privacy policy and relies on the security policy. It does not replace either. The security policy sets the baseline controls any software sits on top of. It does not answer whether a clinician may run an AI scribe in a consultation, or whether reception may paste a referral into a chatbot to tidy up the wording. The privacy policy is where patients are told AI is in use, but a public document cannot tell your staff which tier of which product they are allowed to open. The gap between those two is exactly the space this template fills.

A worked example. A practice has a strong security policy: MFA everywhere, tested backups, patched endpoints. A GP starts using an AI scribe on a personal trial account. Nothing in the security policy is breached, because the laptop is patched and the account has MFA. What has happened is that consultation audio is now going to an overseas vendor whose terms permit training on inputs, no patient has been told, and the privacy policy says nothing about it. That is an APP 6, APP 8 and APP 1 problem, and only the AI acceptable use policy would have caught it before it started.

What the OAIC and the Privacy Act actually require

The Privacy Act applies to every use of AI that involves personal information, and the obligations bite now, with no transition period.

Privacy obligations cover outputs as well as inputs. The OAIC is explicit that privacy obligations apply to any personal information put into an AI system and to the output the AI generates where that output contains personal information. Information an AI system generates or infers about an identified or reasonably identifiable individual, including something the model has invented, is personal information the practice must handle under the APPs. If your AI tool generates or infers personal information, that is a collection under APP 3, and it has to be reasonably necessary for your functions and done by lawful and fair means.

APP 6 limits what you can put in. Health information is collected for the purpose of providing healthcare. Under APP 6 you can only use or disclose it for that primary purpose, unless the patient has consented or the secondary use is one they would reasonably expect and is directly related to the primary purpose. Vendor model training on your consultation content is a secondary purpose, and the OAIC notes that given the privacy risks AI presents, it may be difficult to establish that a secondary AI-related use was within a patient's reasonable expectations at all. Where you cannot clearly establish that, seek consent or offer a meaningful opt-out.

Due diligence before adoption, and it is not set and forget. The OAIC expects organisations to check that a product is suitable for the use they intend: whether it has been tested for that use, how human oversight is built into the process, the privacy and security risks, and who gets access to the information going in and coming out. It also expects regular review of the product's performance, staff training and monitoring across the whole lifecycle of the tool. Section 7 of the template is that due-diligence procedure; Section 9 is the review loop. For an AI scribe, our guide to assessing an AI scribe for privacy compliance walks Section 7 step by step.

Transparency, in the privacy policy and at the point of use. Update your privacy policy and collection notices with clear information about the practice's use of AI, and make sure any public-facing AI tool such as a chatbot identifies itself as AI to the people using it.

Accuracy under APP 10. Generative AI is probabilistic and produces false results. APP 10 requires reasonable steps to keep personal information accurate, and the OAIC's position is that those steps scale with the higher risk of an AI context. In a practice, that means a clinician reads and corrects the note before it is saved.

Public generative AI tools. The OAIC recommends, as a matter of best practice, that organisations do not enter personal information, and particularly sensitive information, into publicly available generative AI tools. Health information is sensitive information. That recommendation is why Section 5 of the template is a hard prohibition rather than a caution.

What the RACGP 6th edition requires

The RACGP published the Standards for general practices (6th edition) on 26 August 2026. Criterion F11 is the first accreditation criterion in Australian general practice to name artificial intelligence. The RACGP's mapping guide classes F11.A and F11.B as new, with no 5th edition equivalent. F11 applies only to practices that use AI, and the RACGP's consultation FAQ made clear that it covers administrative AI as well as clinical AI.

The template maps every F11 indicator to the section that answers it. Appendix C carries the full quotes; the short form:

Three other 6th edition criteria reach an AI tool, and the template now answers them too:

• F4 (training). The guidance on training for AI systems says training needs to cover the safe and effective use of these systems, the purpose, limitations and appropriate use of AI tools, and the importance of clinical oversight and judgement over AI-generated outputs, and that practices "need to update their training regularly to reflect new capabilities, risks, and regulatory requirements." Section 10.1 sets the three topics and a refresh interval; Appendix B records them.
• CG7 (clinical incidents). The guidance on AI-related incidents says the incident process "needs to include steps for identifying, documenting, and responding to AI-related issues" and that "Identifying AI-related issues must not rely solely on feedback or complaints." It gives five examples: incorrect or misleading outputs; system failures or outages; breaches of privacy or data handling protocols; clinician or patient concerns about safety or appropriateness; unexpected changes in AI behaviour after updates to the software. Section 9.3 makes that a category with proactive detection.
• F9.A (privacy policy). The privacy policy states "whether health information is likely to be disclosed overseas and, if so, where and how" and "how the practice uses document automation technologies, particularly so that only the relevant medical information is included in referral letters." Section 6.1 carries both.

Withdrawal of consent. F11 says patients have the right to withdraw consent for the use of AI tools in their care at any time, and that when they do the practice documents the withdrawal in the health record, stops using AI tools in that patient's care unless clinically necessary and re-authorised, provides alternative care pathways where feasible, and communicates any limitations of opting out respectfully. Section 6.3 turns those four steps into the practice's process. The Australian Commission on Safety and Quality in Health Care's ambient scribe scenario (August 2025) adds a fifth: stop the recording and delete any data and outputs.

Labelling. The bodies disagree, and the Standards are silent. The Commission's AI Clinical Use Guide (August 2025) says to label records indicating that AI was involved in their creation. ACRRM's scribing checklist (June 2025) offers a label "if desired". The RACGP 6th edition says nothing. Section 6.6 records the practice's decision rather than imposing one.

Status, stated plainly. Practices are still accredited against the 5th edition. The Australian Commission on Safety and Quality in Health Care says accreditation under the National General Practice Accreditation Scheme "currently uses the 5th edition of the Standards" and that "Information about arrangements for the 6th edition of the Standards will be provided in due course" (page last updated 26 August 2026). F11 is not assessable today. Two other dates do bite: from 1 November 2026 the TGA's clinical decision support exemption is amended, so any tool listed in Appendix A as suggesting a diagnosis or treatment needs the vendor's written regulatory basis (our post on the TGA change explains the new test); and from 10 December 2026 the privacy policy must describe automated decision-making that could significantly affect a patient.

That gap is the reason to do this now rather than later. The register, the vendor assessments, the consent process and the review loop are the same evidence F11.A and F11.B will ask a surveyor to see. Completing this policy answers the Privacy Act duty that applies today and puts the accreditation evidence on the shelf before the transition is announced. Our RACGP 6th edition migration guide covers what else changes.

How to customise this template

1. Download the Word document and open it in Microsoft Word or Google Docs
2. Replace each {{ }}Placeholder{{placeholder}} with your practice details
3. Name the {{ }}AI governance lead{{ai_governance_lead}}. In most practices this is the existing privacy officer or the person responsible for digital governance, not a new appointment; one person may hold all three roles in a small practice
4. Fill in the AI register (Appendix A, both tables) before you circulate the policy. Section 4 has no meaning until the register lists the tools your practice actually uses, with the plan named, the features that suggest or decide, and where the data goes. Walk the practice and ask: what is the clinical team using, what has reception signed up to, and what AI features have appeared in the clinical software or the office suite since the last review
5. Run Section 7 over the tools already in use, not only the next one. Most practices adopt an AI scribe first and assess it afterwards. Record the assessment on the date you actually did it; for a scribe, use the assessment guide
6. Record the labelling decision (Section 6.6) and set the training refresh interval (Section 10.1), and name where a withdrawal of consent is flagged in your clinical software (Section 6.3)
7. Decide your prohibited-use additions in Section 5. Common ones: a scribe approved for consultations but not for medico-legal reports, or a general-purpose tool approved for administrative drafting but never for clinical content
8. Update your privacy policy at the same time. Section 6 sets what staff must do; the privacy policy is where patients are told
9. Adopt the AI scribe consent form if you use a scribe, so consent is captured and documented before anything is recorded
10. Have your practice owner and AI governance lead sign the approval block, then circulate, collect the Appendix B acknowledgements, and set the review date: at least annually, and sooner whenever a vendor changes its terms or a new AI feature turns up in existing software

Related templates and tools

• AI Scribe Patient Information and Consent Form: once a scribe is approved here, this kit tells patients about it and asks for, records and honours their consent
• AI Scribe Governance Pack: the scribe-specific policy, the assessment record, the vendor questionnaire, the register log, the annual review, the note audit, the AI incident log and the F11 evidence map, built on top of this policy
• How to assess an AI scribe for privacy compliance: the eight-step assessment to run before a scribe goes on the register; Section 7 is the general procedure, the guide is the scribe-specific one
• AI scribe and automated decision-making: the two definitions this policy relies on
• TGA clinical decision support changes from 1 November 2026: why Appendix A, Table A2, records the features that suggest or decide and the vendor's regulatory basis
• Computer and Information Security Policy: the baseline controls this policy assumes are in place
• Privacy Policy: the patient-facing APP 1 document that must disclose the practice's use of AI. Update it whenever a tool is added to or removed from Appendix A
• Data Breach Response Plan: where the privacy sub-type of an AI-related incident goes
• Clinical Risk Management Policy: the clinical incident register that Section 9.3 feeds
• Privacy Impact Assessment: step 10 of the Section 7 assessment for any AI tool that will handle health information
• Digital Health Technology Governance Policy: the wider F10.A document; AI tools are assessed under both
• AI privacy compliance for healthcare practices: the full explanation of the APP obligations behind this policy
• RACGP 6th edition migration guide: what the 6th edition changes beyond F11, and what to do while the 5th edition still applies

Frequently asked questions

Is there an official RACGP AI policy template?

No. The RACGP's policy and procedure templates page (last updated 19 May 2025) lists no AI template, and its AI scribes guidance tells practice owners to "Develop a policy on using AI scribes in the practice" without supplying one. MDA National publishes an AI governance template for its members only. This template is built to F11.A and F11.B and maps every indicator to the section that answers it; F11 itself is not assessable until the 6th edition accreditation arrangements are announced.

Does my practice need an AI acceptable use policy?

If anyone at your practice uses an AI tool with practice information, yes. The OAIC expects organisations deploying AI to establish policies and procedures for its use, and that expectation sits under the Privacy Act, which applies now. The harder question is whether you know what is in use. AI features arrive inside software you already pay for, and individual clinicians adopt scribes without a practice-level decision. If you cannot list your AI tools and the plan each one is on, filling in Appendix A forces the audit.

Does this policy ban AI?

No. It is a permission structure, not a prohibition. The template says which tools are approved, in which configuration, for which tasks. The OAIC's guidance is not that AI is off limits in healthcare; it is that a practice has to assess what it uses, understand how the tool handles health data, and document that assessment. A practice with three approved tools and a completed register is in a stronger position than a practice that has banned AI on paper while a scribe runs in room 4.

What about ChatGPT on a free account?

Prohibited for anything involving patient information, and the template says so explicitly. Consumer and free tiers generally permit inputs to be used to improve the vendor's models, which makes any patient information entered a secondary use under APP 6 and, for an overseas vendor, a cross-border disclosure under APP 8. The OAIC recommends as best practice that organisations do not enter personal information, and particularly sensitive information, into publicly available generative AI tools. The business or enterprise tier of the same product is a different question, which is why the template approves tools by plan rather than by product name.

Do patients have to be told the practice uses AI?

Yes, in two places. Your privacy policy has to carry clear information about the practice's use of AI under APP 1, and a public-facing tool such as a chatbot has to identify itself as AI. Where an aspect of care will be delivered using AI, F11.A expects informed consent to be obtained and documented, and F11 says a patient may withdraw it at any time: the practice then documents the withdrawal, stops using AI in that patient's care unless clinically necessary and re-authorised, offers an alternative pathway where feasible, and explains any limitations respectfully. Ahpra's guidance says to obtain informed consent and "ideally note the patient's response in the health record."

What is RACGP criterion F11, and does it apply now?

F11 is the artificial intelligence criterion set in the Standards for general practices (6th edition), published 26 August 2026. F11.A: "Where the practice uses artificial intelligence, it does so safely and securely and consistent with existing standards." F11.B: "The practice assesses and evaluates its use of artificial intelligence." It applies only to practices that use AI, including administrative AI, and it is not assessable today: accreditation still uses the 5th edition and the Australian Commission on Safety and Quality in Health Care has not announced the arrangements for the 6th. The Privacy Act obligations in this template apply regardless.

What goes in the AI register?

Two tables, one row per tool in each, including AI features inside software you already use. Table A1 records the approval: the tool and plan, permitted and prohibited uses, whether identified patient data is authorised, the alternative pathway, the owner and the dates. Table A2 records the regulatory and data position: features that suggest or decide, the ARTG entry or exemption basis, where data is stored and processed, the training setting, retention, the DPA reviewed, and the last vendor update checked. The National AI Centre's guidance calls this maintaining an AI register that captures AI features embedded in common software. If your practice uses no AI, write "No AI tools in use" in the first row and date it.

How does this relate to our computer and information security policy?

They cover different ground. The security policy is about how practice systems are protected: user accounts, passwords and MFA, backups, malware protection, patching, mobile devices, and general email and internet acceptable use. This policy is about which AI tools are allowed on top of that baseline, what information may go into them, what patients are told, and how the practice reviews the tools afterwards. A practice can be fully compliant with its security policy and still have a live privacy problem, because a patched laptop running an unassessed AI scribe is a secure device sending consultation audio somewhere nobody has checked.