AI is already part of clinical documentation, patient communication, rostering and business administration. Without clear rules, staff can expose health information, rely on an unsupported output or adopt a tool nobody has assessed. The practical answer is one policy that names approved uses, owners and controls. This template is written for Australian general practices, allied health clinics and specialist services, with a register and rollout plan for daily care.

What an Australian healthcare AI policy needs to do

The Australian Government's AI policy template covers responsible-use principles, expected behaviours and internal rules, roles and responsibilities, governance and approval points, monitoring and review, and reporting issues or misuse. Healthcare needs more specific controls because patient information is sensitive, clinical outputs can affect care and registered practitioners remain accountable for their decisions and records.

Five rules shape those controls:

1. Privacy applies to inputs and outputs. The Office of the Australian Information Commissioner (OAIC) states that privacy obligations apply to personal information entered into an AI system and personal information generated by it. It recommends a privacy impact assessment and advises organisations against entering personal, especially sensitive, information into publicly available generative AI tools. The OAIC's AI guidance also calls for AI policies, procedures and transparent notices.
2. The practitioner stays responsible. The Australian Health Practitioner Regulation Agency (AHPRA) requires practitioners to apply human judgement to AI output, understand a tool's intended use and limitations, and make sure AI-generated clinical records are accurate and relevant. Its professional obligations guidance applies whether or not a tool is regulated by the Therapeutic Goods Administration (TGA).
3. Digital scribes require an informed patient choice. The TGA and AHPRA support obtaining informed consent before a digital scribe captures a consult. The TGA says clinicians are responsible for obtaining informed consent and checking information entered in the health record. AHPRA says practitioners should ideally note the patient's response in the record, which makes documentation a recommended governance control rather than a universal statutory step. See the TGA's digital scribe guidance, AHPRA's AI guidance and our patient consent guide.
4. Intended purpose determines TGA status. A tool intended only to transcribe or translate a clinical conversation into a written record, without analysis or interpretation, is not a medical device. A digital scribe that generates a diagnosis, differential diagnosis or treatment recommendation that the practitioner did not state is a medical device and must meet the relevant requirements, including inclusion in the Australian Register of Therapeutic Goods before supply. The TGA explains this distinction in its digital scribe guidance.
5. A policy needs an operating system. An approved-tool list, AI register, risk screen, training, incident process and review schedule turn principles into repeatable decisions. The Australian Commission on Safety and Quality in Health Care similarly structures clinical AI use around what happens before, during and after use in its AI Clinical Use Guide.

At Lyrebird, Clinical Notes turns ambient capture, dictation or typed input into a structured draft note ready for clinician review. Under our current Privacy Policy, application databases, transcripts, authentication and user data, speech processing and encrypted backups remain in Australia. Payment metadata, pseudonymised logs or non-health analytics may be processed in the United States, while de-identified health information may be processed in the European Union. Notes and transcripts are not used to train external AI models under our data controls. These product controls still need an accountable clinical workflow around them.

Copy-and-adapt AI policy template

Before you adopt this template: This is a starting point, not legal advice or a universal statement of Australian duties. Tailor it for your state or territory, the professions in your team, service model, surveillance and recording laws, health-record retention, employment arrangements, indemnity cover and contracts. Retention periods vary by jurisdiction, profession and record type. A product's default retention period must not be copied into the practice's legal record schedule. Seek privacy, clinical governance or legal advice where appropriate.

Replace all square-bracketed text, remove drafting instructions and approve the finished policy through your usual governance process. Small practices can assign several responsibilities to the same person, but each responsibility still needs a named owner.

Document control

1. Purpose

At [Organisation], we use artificial intelligence where it has a defined benefit for patients, clinicians or operations and where its risks can be managed. This policy sets our rules for selecting, approving, using, monitoring and retiring AI systems.

The objectives are to:

• protect patient safety, privacy, dignity and choice
• keep clinical judgement and accountability with qualified people
• use only approved systems for approved purposes
• identify and manage bias, inaccuracy, omission, unsupported content and security risk
• maintain records that show what was approved, why and by whom
• respond promptly to clinical, privacy, security and service incidents.

2. Scope

This policy applies to employees, contractors, students, volunteers and third parties who procure, configure or use AI for [Organisation]. It covers free and paid products, embedded AI features, pilots, application programming interfaces, vendor systems and internally developed tools.

It applies to clinical and non-clinical uses, including:

• ambient AI scribes, dictation and clinical documentation
• patient messages, letters, summaries and educational material
• diagnostic, prognostic, treatment, triage or decision support
• coding, billing and referral workflows
• recruitment, rostering, finance, analytics, marketing and administration.

For this policy, an AI system is technology that infers, predicts, recommends or generates an output from data. An AI output includes text, audio, images, classifications, scores, recommendations and actions. An AI system owner is the person accountable for one approved system throughout its use at [Organisation].

3. Responsible-use principles

We will:

• use AI for a defined and documented purpose
• apply controls in proportion to likely patient, privacy and organisational harm
• minimise the personal information collected and used
• maintain meaningful human oversight and a workable non-AI alternative
• tell affected people about AI use where it is relevant to their care, information or rights
• assess performance across the people and clinical contexts in which the system will be used
• enable correction, complaints and escalation
• stop or restrict a system when its risks are no longer acceptable.

4. Use categories and approval

Every use case must be entered in the AI register and assigned a category before use.

The following are prohibited unless a later version of this policy expressly authorises them with stronger controls:

• entering patient, staff or confidential business information into a public generative AI service or a personal AI account
• allowing AI to make or sign off a diagnosis, treatment, prescription, referral, triage outcome or clinical record without an appropriately qualified person
• using AI as the sole basis for a decision that materially affects a person's care, employment, payment or rights
• representing AI-generated material as a clinician's considered view before review
• creating misleading patient communications, fabricated evidence, impersonation or discriminatory content
• connecting an AI system to the clinical record, email, messaging or other production system outside the approved configuration.

5. New tool and use-case assessment

The proposed system owner must submit the intended purpose, users, affected people, data, outputs, integrations, known limitations, human review step and fallback process to [policy owner]. A new use of an already approved tool needs a new assessment when the purpose, data or potential impact changes.

The assessment must cover:

• whether AI is necessary and suitable for the problem
• evidence that the product performs its intended task in the proposed Australian clinical context
• likely omissions, unsupported content, contradictions, bias and automation reliance
• whether the intended purpose makes the product a medical device and, if so, its regulatory status
• the vendor's collection, processing, storage, retention, deletion and data-location arrangements
• subprocessors, overseas disclosures, secondary uses and any model training using customer data
• contractual ownership of inputs and outputs, confidentiality, breach notification and exit arrangements
• encryption, access control, multifactor authentication, audit logs, backups and service continuity
• the patient information, consent or other authority required
• validation, monitoring, complaint and incident procedures
• professional indemnity, contractual and jurisdiction-specific requirements.

Approval expires when the system materially changes, the vendor changes its data terms, a new high-severity risk emerges or the review date passes.

6. Privacy, patient information and consent

Identifiable audio, transcripts, prompts, generated content and metadata must be handled as health information while they identify or can reasonably identify a person. Staff may use this information only in the system, account and workflow approved for that purpose.

We will:

• collect only the information needed for the approved use
• document where information is processed and stored, who can access it, how long it is retained and how it is deleted
• store the reviewed final clinical record in the approved patient record system
• manage temporary audio, transcripts and drafts under a documented retention schedule and applicable recordkeeping law
• update our privacy policy, collection notices and patient information when AI changes how personal information is handled
• manage access and correction requests through existing privacy and health-record procedures
• assess suspected privacy incidents to determine whether an eligible data breach has occurred under the Notifiable Data Breaches scheme, then notify the OAIC, affected people and other bodies when required. The OAIC explains the threshold and notification process in its NDB scheme guidance.

Before an ambient AI scribe captures a consult, the clinician must explain the tool's role, what information it captures, material data-handling arrangements and the patient's right to decline. The clinician must obtain any informed consent or other authority required for that workflow before capture. The patient's response will be documented where required by law or the approved practice process. A patient who declines or withdraws consent will receive the same care using the documented alternative.

The patient process must account for applicable state or territory surveillance and recording law. It must also address substitute decision-makers, minors, interpreters and other people present where relevant. Highly sensitive consults may require a more detailed discussion or a decision to use the fallback process.

7. Clinical use and human review

Generative documentation is a draft until an appropriately qualified clinician reviews, edits and signs it. The clinician remains responsible for the care decision and the accuracy and relevance of the patient record.

Review must compare the draft with the consult and other available clinical context. It must address, where relevant:

• patient identity, clinician identity and dates
• allergies, medicines, doses, routes and frequencies
• symptoms, history, examination findings, results and diagnoses
• negation, uncertainty, chronology and attribution to the correct speaker
• clinical reasoning, plan, safety-netting, referrals and follow-up
• omissions, unsupported statements, contradictions and irrelevant detail.

AI must not invent absent findings or turn possibilities into confirmed facts. Approved write-back may place a draft in the clinical system, but it must remain clearly available for clinician review and sign-off.

8. Transparency, fairness and patient choice

We will provide plain-language information about material AI use. AI must not be presented as a human. Patients and staff must have a clear route to ask a question, raise a concern, request correction or use an available non-AI process.

System assessment and monitoring must consider performance for the people who will use or be affected by it, including differences in language, accent, disability, age, sex, gender, cultural background and clinical complexity. A lower-performing group or context requires a control, restricted use or an alternative process.

The Australian Privacy Principles (APPs) are the privacy standards in Schedule 1 of the Privacy Act 1988. An APP entity is an Australian Government agency or organisation covered by the Privacy Act.

From 10 December 2026, an APP entity must add specified information to its separate APP Privacy Policy if it has arranged for a computer program to make a decision, or do something substantially and directly related to making a decision, using personal information, where the decision could reasonably be expected to significantly affect an individual's rights or interests. The APP Privacy Policy must disclose:

• the kinds of personal information used in the program
• the kinds of decisions made solely by the program
• the kinds of decisions for which the program does the substantially and directly related thing.

Adding a clause to this internal AI policy does not update the separate APP Privacy Policy. The OAIC's APP 1 guidance sets out the new threshold and disclosures.

9. Security and access

Access is limited to authorised users with unique accounts and the minimum permissions required for their role. Multifactor authentication is mandatory where supported. Staff must not share accounts, credentials, patient information through support channels, or approved-system content through unapproved applications.

The system owner and privacy and security contact will manage onboarding, role changes and prompt removal of access. Integrations, exports, browser extensions, mobile applications and automated actions must use the approved configuration.

10. Training and day-to-day responsibilities

Before first use, each user must complete training on:

• the approved purpose and prohibited uses
• privacy, consent and patient communication
• system limitations and common output errors
• required human review and record sign-off
• security and incident reporting
• the manual fallback process.

Training is repeated after a material system or policy change and at least annually. A person who is unsure whether a tool or use is approved must pause that use and refer it to the policy owner.

11. Monitoring and change control

The system owner will monitor the measures set in the approval record. These may include adoption, patient decline, corrections, clinically relevant omissions, unsupported statements, complaints, incidents, service availability and performance across intended user groups.

Clinical documentation systems must undergo periodic sample review using defined error categories. Our clinical note evaluation framework separates hallucinations, accuracy errors, omissions, irrelevant inclusions and formatting so that one average score does not hide a clinically meaningful problem.

The system owner must assess material software updates before broad deployment. New features, changed intended purpose, new integrations, changed data handling, unexplained performance change, serious complaint or incident trigger reapproval.

12. Incident response

Anyone who identifies a possible patient-safety, privacy, security, bias, record-quality or regulatory incident must immediately notify [incident channel or role]. Where continued use could cause harm, the system owner or clinical safety lead will suspend the affected function and activate the fallback process.

The response will:

1. protect the patient and correct the clinical record where required
2. contain the issue and preserve relevant logs, outputs, versions and decisions
3. assess clinical, privacy, security, regulatory and contractual impact, including whether a suspected privacy incident is an eligible data breach under the Notifiable Data Breaches scheme
4. notify the OAIC, affected people, the vendor, insurer, regulator or another body when required
5. document cause, corrective action, owner and completion date
6. approve safe restoration or retire the use case.

Incidents and near misses will inform training, risk controls and the next policy review.

13. Roles and accountability

14. Non-compliance and review

Suspected breaches will be managed under [workplace, clinical governance, privacy, security or contractor process]. Patient safety and fair process take priority. A breach may lead to retraining, restricted access, corrective action or disciplinary action under the applicable agreement.

The policy owner will review this policy at least annually and after a material incident, legal or regulatory change, major vendor change or introduction of a new high-impact use. Substantive changes require the same approval as the original policy.

AI register template

The register should capture systems already used by staff, including free accounts and AI features embedded in existing software. It serves as a control record rather than a product catalogue.

Put the policy into practice

A signed policy will not change behaviour on its own. A practical rollout is:

1. Inventory actual use. Include licensed systems, free tools, personal accounts, pilots and embedded AI features.
2. Stop prohibited handling. Remove patient and confidential data from unapproved workflows and preserve incident evidence where needed.
3. Classify each use case. Separate generic administrative help from sensitive support and high-impact decisions.
4. Assess and approve. Complete vendor, privacy, security, clinical and regulatory assessment in proportion to risk.
5. Create the register and owners. Record one accountable person and one review date for every approved use.
6. Prepare patient and staff processes. Update notices, consent processes, complaint routes, training and fallback procedures.
7. Configure the controls. Use managed accounts, access limits, multifactor authentication, approved integrations and documented retention.
8. Pilot and review. Audit real outputs, collect patient and clinician feedback, resolve incidents and approve broader use only when controls work in practice.

For an AI scribe pilot, Lyrebird Clinical Notes creates a structured draft note for clinician review, while our patient consent guide provides practical patient-facing wording. The practice remains responsible for its approved workflow, record sign-off and jurisdiction-specific duties.

Frequently asked questions

Is an AI policy legally required in Australia?

Australia does not impose one blanket requirement for every healthcare organisation to maintain a document named an AI policy. The Australian Government treats a policy as a responsible-governance practice in its current AI policy guidance.

Existing duties can still apply to the use behind the policy. Depending on the organisation and workflow, these include the Australian Privacy Principles, AHPRA professional obligations and TGA medical-device requirements. An APP entity must also maintain practices, procedures and systems that support APP compliance under APP 1. A written AI policy gives staff a practical way to apply those requirements, but it does not replace them.

Is an AI policy the same as a privacy policy?

No. An AI policy is mainly an internal governance document that tells workers which systems and uses are approved, how risk is assessed and who is accountable. A privacy policy is a public explanation of how an organisation manages personal information. AI use may require updates to both the privacy policy and collection notices. From 10 December 2026, the automated-decision disclosures described above belong in the separate APP Privacy Policy when the threshold is met.

Can staff use a public AI chatbot if they remove the patient's name?

Removing a name may not de-identify clinical information. A person can remain reasonably identifiable from a combination of details, and the content may still be confidential. The OAIC says information is de-identified only where re-identification risk is very low in the relevant release context; its de-identification guidance explains why context matters. Public AI tools must not receive patient or confidential information under this template. An approved healthcare workflow requires documented data handling, contractual, access, review and incident controls.

How often should an AI policy be reviewed?

Review it at least annually and sooner after a material incident, significant legal change, major vendor or model update, changed data terms, new integration or new high-impact use. System approvals also need their own review dates so an unchanged policy does not leave stale tools running indefinitely.

Who should own the policy in a small practice?

The practice owner or senior manager can own the policy, while a clinical lead owns patient-safety decisions and the privacy or IT lead owns information controls. One person may hold several roles, but every decision and escalation path should still have a name.

Good AI governance should make the safer action the easiest action during a busy consult. To implement clinical AI with a defined consent, privacy and review workflow, Contact us.