A VA uses an AI writing assistant inside an approved office suite. A manager tries a different chatbot on a personal account. A sales tool introduces an automatic meeting summary. All three may believe they are following the same rule: “AI is fine if you check it.”
That rule leaves important questions unanswered. Which account is approved? What information can it receive? Who may connect a customer system? What happens when an output makes a promise nobody authorised?
A useful AI policy gives your Australian and Philippines-based team the same clear operating boundaries. It should be short enough to find an answer during work and specific enough to resolve a real situation.
Start with the work your team already does
Ask people to list the AI tools and embedded features they use, the tasks involved and the information supplied. Include browser extensions, meeting assistants and AI features within existing subscriptions. Buying the parent software does not settle whether every new feature is suitable for every task.
Choose a policy owner and a person who can approve each proposed use. In a small business, one person may hold both roles, but the responsibilities still need to be explicit. Involve the staff who will follow the rules, including remote workers and relevant service providers.
The National AI Centre recommends tailoring an AI policy to the organisation and testing it with the people who use or oversee it. Its current guide covers permitted use, data, approvals, oversight, issue reporting and review. See the National AI Centre's policy guide.
The examples below are original starter wording for discussion, not a complete policy or a substitute for checking your actual obligations.
Approve a specific use, account and information scope
Maintain a short approved-use list alongside the policy. Record the tool, business account, owner, permitted task, permitted information and review conditions. “Tool approved” is less useful than “this business account may shorten approved public service descriptions, with the final text checked before use”.
An approval to draft wording should not silently become approval to read the whole customer drive, send emails or update a CRM. Treat new connections and actions as separate proposals for review.
Suggested policy wording: Use AI only through the approved account, for the listed task and with the permitted information. Ask the named owner before changing any of those conditions.
Give people a workable request route. Ask what they want to achieve, the data involved, whether the tool can take actions and who will check the result. Record the decision and its limits so another team member does not have to guess next time.
Explain the boundary with everyday examples
Use situations your team recognises. The following table illustrates how one business might apply its policy; these are proposed internal rules, not universal legal classifications.
| Situation | Suggested policy response |
|---|---|
| Rewrite an already published service paragraph | Use the approved writing tool; check that the meaning and claims remain accurate. |
| Summarise a customer file in a personal chatbot | Do not upload it; ask the owner for an approved process. |
| Enable an assistant that reads a shared mailbox | Obtain a separate access and information-handling review before connecting it. |
| Draft an installation update | Use permitted source material; a human checks the actual milestone and authority to send. |
| Let a tool select job applicants or promise a refund | Stop and seek a specific assessment and decision from the responsible owner. |
The OAIC recommends, as best practice, keeping personal information—especially sensitive information—out of publicly available generative AI tools. Its guidance also calls for assessing product suitability, oversight and information access. Read the OAIC's commercial AI guidance.
A paid subscription does not by itself establish that a use is suitable. Check the actual service, settings, terms and information flow. Removing a name alone may leave enough context to identify someone. Give staff an approved alternative when they cannot use a tool for a particular record.
Name the reviewer and the release decision
State who checks the result, what they check and who may release it. A person comparing dates against a job record may have different authority from the person approving a price change or technical statement.
Suggested policy wording: AI output remains a draft until the required checks are complete. The person authorised for the underlying business decision retains that responsibility.
For customer-facing text, checks might include source accuracy, current versions, omitted conditions, attachments and the recipient. For a technical solar document, the relevant qualified professional retains their substantive review and sign-off responsibilities. Our AI fact-checking workflow provides a practical claim register.
Also define how the business explains AI use. The National AI Centre's foundations guidance recommends transparency about AI interactions and decisions affecting people. Set context-appropriate disclosure rules; staff should not present an automated assistant as a human specialist. Read the AI adoption foundations.
Make it easy to report a mistake or unexpected result
Provide a named contact, backup and reporting channel. Explain what staff should do if they entered information into an unapproved tool, noticed an incorrect customer answer or saw the system act beyond its permission.
Suggested policy wording: Stop the affected activity when safe to do so and report the issue promptly. Preserve relevant references in the approved location and follow the responsible owner's instructions.
Do not ask staff to copy an entire customer file into a broadly visible incident message. A short initial report can identify the tool, time, task, affected record reference and whether anything was sent or changed. The owner can then assess containment, correction and any applicable reporting duties.
A reporting route only works if people can use it without hiding uncertainty. Thank staff for raising a concern, establish the facts and improve the process. Give the team a route to pause questionable work while waiting for an answer.
Practise the policy and keep its decisions current
Before release, walk through three short scenarios with both local and offshore colleagues: an allowed draft, a request outside the approved scope and a mistake that needs reporting. Ask each person where they would find the rule and who they would contact.
Record the policy version, owner, approval date and review trigger. Revisit it when the tool, connected data, task or degree of automation changes, and when incidents reveal a gap. Update the approved-use list and tell affected staff what changed.
Use the internal knowledge-base guide to make the current policy easy to find. Talk to Nexus about practical team workflows that turn policy decisions into clear daily instructions.
