How Australian SMEs can use Azure OpenAI safely

We are asked at least once a week whether a small business can use ChatGPT-style tools without exposing customer data. The short answer is yes, but not by signing up to the consumer product and pasting your customer list into a chat window.

The problem with the consumer product

Most consumer chat tools are designed for individual productivity. They are not designed to be a system of record for a business. When an employee pastes a customer contract, a pricing sheet or a patient note into a public chat window, that information leaves your control. You have no audit trail, no retention control, and no way to prove to a regulator or a client that you did not make that data available to a third party.

For an Australian small business operating under the Privacy Act 1988, that is a problem. You are accountable for personal information about your customers, even if an employee did it on their personal account at home.

What Azure OpenAI actually changes

Azure OpenAI Service runs the same underlying models inside Microsoft's cloud. The difference for a business is that the deployment sits in your Azure tenant. Your prompts and your completions do not train the base model. Data is processed in the region you choose. For an Australian business, that means a deployment in Australia East or Australia Southeast.

You are not building a model. You are not training a model. You are connecting a model you already use to documents you already own, inside a tenant you already administer.

The pattern we recommend

For most small and medium businesses, the useful starting point is retrieval-augmented generation. That is a technical phrase for a practical idea: index your own documents, and let the model answer questions grounded in those documents. When a staff member asks "what is the warranty on this product?", the system searches your internal PDF library, pulls the relevant page, and asks the model to summarise it. The answer comes back with a citation to the original document.

Key properties:

• The model cannot invent a policy that does not exist in your documents.
• Every answer is traceable to a source file.
• You control who can ask, what they can ask, and what is logged.

What to put in front of the model

Start with documents that are already internal: product specifications, standard operating procedures, warranty terms, onboarding checklists. Do not start with customer databases or financial records. Those introduce governance questions that are better answered after you have measured the value of the tool.

We do not deploy foundation models. We integrate the tools you already use with the documents you already own. That is the difference between an AI project and an AI experiment.

The governance minimum

You do not need a 50-page AI policy on day one. But you do need four things before an AI tool touches customer-facing work:

• A list of who is allowed to use the tool.
• A log of what is asked and what comes back.
• A rule about what kinds of data are never pasted into a prompt.
• A human in the loop before anything the tool drafts goes to a customer.

Where we see SMEs going wrong

The most common failure is not technical. It is that a business buys a tool, lets employees use it freely for six weeks, and then realises they cannot answer the question "what have we put into this?". The fix is not to ban the tool. It is to put it inside your tenant, with the log, the access control and the human review from week one.