Compliance
Microsoft Foundry Agent Service in Australia
Structured issue-spotting for deploying Microsoft Foundry Agent Service in Australia, read against the rules for that jurisdiction.
- Source
- Rules engine over a generic brief — no anchored quote on this page
- Verified
- Evidence not verified
- Confidence
- Low
Structured issue-spotting to support your own review — not legal advice. Verify against the cited primary sources and your counsel.
01What this reading assumes
- Jurisdiction
- Australia
- Principal framework
- Privacy Act 1988, through the thirteen Australian Privacy Principles. They govern open handling, anonymity, collection, notification, use and disclosure, direct marketing, cross-border disclosure, government identifiers, quality, security, access and correction, and they apply to an AI pipeline the same way they apply to a filing cabinet. The Privacy and Other Legislation Amendment Act 2024 added a statutory tort for serious invasion of privacy, doxxing offences, a Children’s Online Privacy Code still in development, a mechanism to prescribe countries with substantially similar laws that has never been used, and an automated decision-making transparency duty that commences twenty-four months after Royal Assent — that is, in December 2026. The OAIC has published two AI-specific guidance documents, one for organisations buying commercially available AI products and one for developing and training generative AI models.
- Delivery assessed
- Enterprise SaaS
- Data leaves the network
- unknown — the deciding question for a hosted product
- Vendor home jurisdiction
- United States
- Verified vendor positions
- none — every vendor position below is a question, not an assurance
- Rules evaluated
- 38
- Rules fired
- 13
Assumptions about use
- An internal deployment used by employees, not a public-facing product.
- A person reads the output before acting on it — but that is not recorded, so the engine reports it as a gap rather than assuming it.
- No significant automated decision is taken about a person by the system alone.
02Issues to work through
Australia
There is no Australian whitelist — you stay accountable for the overseas recipient
The OAIC states that it does not have a list of countries with substantially similar laws or binding schemes. APP 8’s default is accountability rather than permission: an APP entity that discloses personal information overseas remains liable for the recipient’s acts and practices unless an APP 8.2 exception applies. Sending a prompt to a model provider outside Australia is that disclosure.
- Required checks
- Decide whether you are relying on APP 8.1 accountability or on a specific APP 8.2 exception, and write down which.
- Assess the receiving environment rather than the receiving country, because there is no country to look up.
- Extend the assessment to the vendor’s subprocessors — accountability follows the information, not the contract.
- Vendor questions
- Where is inference performed, and can it be pinned to an Australian region?
- Which subprocessors can access prompts or outputs, and how are we notified when that list changes?
- Will you accept contractual terms requiring you to handle the information consistently with the Australian Privacy Principles?
- Technical controls
- Pin the inference region where the vendor offers one, and alert when a request is served elsewhere.
Human review required — take this to your counsel
We do not know where this vendor processes the data
We could not verify where this vendor performs inference or stores prompts and outputs. Under APP 8 the answer changes what has to be documented, because a disclosure overseas keeps the discloser accountable for the recipient. This is a gap in our evidence rather than a finding against the vendor, and it is the first question to put in writing.
- Required checks
- Get the processing location in writing, including for logs and backups, before the assessment is signed off.
- Vendor questions
- In which countries is inference performed, and where are prompts, outputs and logs stored?
- Can processing be constrained to Australia, and at what cost?
Training on data you already hold is a new use, not a continuation of the old one
The OAIC’s guidance on developing and training generative AI models directs developers to Australian Privacy Principles 1, 3, 5, 6 and 10 in particular — open and transparent handling, collection, notification, use and disclosure, and quality. The practical consequence is that re-using records collected for one purpose to train a model is a use for a secondary purpose, and the notice given at collection almost never reaches it.
- Required checks
- Identify every dataset that would enter training or fine-tuning, and the purpose each was collected for.
- Decide the basis for the secondary use before any data is copied into a training pipeline.
- Check data quality against APP 10 — a model trained on inaccurate personal information reproduces it at scale.
- Vendor questions
- Is customer content used to train or improve your models by default, and can that be switched off in the contract?
- Technical controls
- Keep training corpora in a separate store with recorded provenance per source, so the basis for each is auditable.
Human review required — take this to your counsel
The OAIC expects due diligence on a bought AI product, before it is bought
The OAIC’s guidance on commercially available AI products says an organisation should conduct due diligence to ensure the product is suitable to its intended uses, considering whether it has been tested for those uses, how human oversight is embedded, the privacy and security risks, and who will have access to the personal information going in and coming out. That is a procurement gate, not a post-launch review.
- Required checks
- Write down the intended uses before evaluating the product, because suitability is judged against them.
- Establish who at the vendor can see prompts and outputs, and under what circumstances.
- Record the due diligence — the guidance is what an OAIC enquiry would measure the record against.
- Vendor questions
- What testing has this product had for uses like ours, and can you share the results?
- Who at your organisation can access customer prompts or outputs, and is that access logged?
- Technical controls
- Keep the human oversight step in the product, not in the runbook, so it cannot be skipped under load.
Human review required — take this to your counsel
Australia decided not to introduce mandatory AI guardrails — there is no risk tier to fill in
The mandatory guardrails for high-risk AI consulted on in 2024 were not proceeded with; the feedback fed a national AI plan instead. There is therefore no Australian risk classification to complete and no conformity assessment to pass. That is not the same as no obligations: the Privacy Act, the sectoral regulators and the online safety codes all reach an AI deployment, and they are where the work is.
- Required checks
- Do not spend effort on an Australian high-risk classification — it does not exist.
- Do read the Voluntary AI Safety Standard if a customer or a tender asks how you govern AI, because it is the vocabulary they will use.
Cross Cutting
Confidentiality duties bind independently of data protection law
Material can be entirely free of personal data and still be the material a contract stops you disclosing. Client retainers, non-disclosure agreements, supplier contracts and common-law duties are the usual sources, and several of them require consent before a third party processes the material at all — which a model API call is.
- Required checks
- Review the confidentiality clauses in the contracts covering the material going into the system.
- Identify any contract requiring notice or consent before a subcontractor processes the material.
- Decide whether the deployment needs a confidentiality carve-out negotiated into new contracts.
- Vendor questions
- Will the vendor accept a confidentiality undertaking beyond its standard terms?
- Which staff at the vendor can access customer content, under what controls?
- Technical controls
- Segregate the most sensitive corpora into an index that the general assistant cannot reach.
Human review required — take this to your counsel
What ends up in a prompt, and where it goes next
Every prompt is a transfer of whatever it contains. Staff paste more than they intend, retrieved context travels with the prompt, and system prompts can often be extracted from the output. Assume anything reaching the model has left your control unless the contract and the architecture say otherwise.
- Required checks
- Write down which categories of information may be entered into a prompt, and tell people.
- Establish what the system prompt contains and whether disclosing it would matter.
- Establish which shadow tools staff are already using; the policy has to name the permitted ones.
- Vendor questions
- Are prompts and completions retained, for how long, and can retention be set to zero?
- Are prompts used for abuse monitoring, and if so who can read them and for how long?
- Technical controls
- Redact or block high-risk patterns before the prompt leaves the application.
- Keep prompt and completion logs out of general-purpose observability tools.
- Set an explicit retention period on prompt logs and enforce it.
The acceptable-use policy may exclude your use case
Acceptable-use policies commonly carve out unsupervised legal, medical and financial advice, decisions about people without human review, and some surveillance and biometric uses. They are incorporated into the contract by reference and change without a signature, so the version that matters is the one live on the day you rely on it.
- Required checks
- Read the acceptable-use policy against your actual use case, not against a summary of it.
- Where a carve-out applies, decide whether human review brings the use back inside the policy.
- Set a reminder to re-read the policy — it changes without notice to you.
- Vendor questions
- Does your acceptable-use policy permit this use case, and will you confirm that in writing?
- How are we notified when the acceptable-use policy changes?
Human review required — take this to your counsel
Being able to reconstruct a decision months later
The question that arrives after a complaint is what the system was shown and what it produced on a particular day. Models change, prompts change, and indexes are rebuilt, so the answer has to be recorded at the time. Without it, the only available response is that the output cannot be reproduced.
- Required checks
- Decide what is recorded per interaction: model and version, prompt template version, retrieved document ids, output, reviewer and outcome.
- Set how long those records are kept, balanced against the retention duties that also apply to them.
- Vendor questions
- Does the vendor pin model versions, and how much notice is given before a model is retired or changed?
- Technical controls
- Version prompt templates in source control and log the version used.
- Log the model identifier and version returned by the provider, not the one you requested.
Vendor documentation has not been verified
We could not verify a data processing agreement, a subprocessor list, a position on training on customer data and a stated processing region for this vendor from a retrieved document. That is a gap in our evidence, not a finding against the vendor: until a document has been fetched and read, nothing here should be treated as settled either way.
- Required checks
- Obtain the current versions of the processing agreement, subprocessor list, security page and any regional-processing commitment.
- Check that what the sales conversation promised also appears in the contract.
- Vendor questions
- Where is your data processing agreement published, and which version applies to us?
- Where is your subprocessor list, and how much notice do we get before it changes?
- Do you train on customer content by default, and where is that stated contractually?
- In which country or region is inference performed, and where are logs retained?
We were not told whether a person reviews the output
Where output influences a decision about a person, the reviewer has to be able to disagree with it. That needs three things a rubber-stamp review lacks: enough information to judge, enough time to judge, and an override that is used often enough to be real. Design it before the volume makes it impossible.
- Required checks
- Name the role that reviews the output and what they see when they do.
- Decide what evidence is retained about each review, so the practice can be shown to exist.
- Set a threshold below which the system must not act without review.
- Vendor questions
- Does the product expose the retrieved context and the confidence behind a suggestion, or only the answer?
- Technical controls
- Show the reviewer the retrieved sources next to the suggestion, not the suggestion alone.
- Record the reviewer’s decision, including overrides, as part of the audit trail.
Human review required — take this to your counsel
An AI deployment creates new copies of the data
Vector indexes, prompt logs, completion caches, evaluation datasets, fine-tuning checkpoints and backups are all copies of the source material in places the existing retention schedule does not mention. Deletion requests are the moment this is discovered, because deleting the source document does not delete its embedding.
- Required checks
- List every store the deployment creates and add each to the retention schedule.
- Establish how a deletion request propagates to the index, the caches and the logs.
- Establish how long backups keep material that has been deleted from the live system.
- Vendor questions
- What does the vendor retain, where, and for how long after we delete our copy?
- Technical controls
- Store the source document id with every embedding so deletion can cascade.
- Set time-to-live on prompt and completion logs rather than relying on manual cleanup.
The vendor’s terms may not permit the deployment you are planning
Provider terms routinely restrict things architectures assume: sharing seats, building a competing service, benchmarking and publishing results, reselling capacity, and processing certain data categories. A consumer or self-serve plan often carries different terms from the enterprise agreement, and the enterprise agreement is the one worth reading.
- Required checks
- Identify which contract actually governs — self-serve terms, an order form, or a negotiated agreement.
- Check restrictions on seat sharing and on service accounts, which a shared internal assistant can breach without anyone noticing.
- Check whether the terms allow the categories of data you intend to send.
- Vendor questions
- Which agreement governs our use, and can we have the current version in writing?
- Are there restrictions on the data categories or the industries we may use the service for?
Structured issue-spotting to support your own review — not legal advice. Verify against the cited primary sources and your counsel.
03What this reading does not know
- Whether any of the data falls into a special or sensitive category.
- Whether any material is covered by legal professional privilege.
- Whether prompts or documents leave the company network.
- Whether a person reviews the output before it is acted on.
04Instruments these issues point at
- statuteAPP 8APP 8 sets what an APP entity must do before disclosing personal information overseas. The accountability approach is the default: the discloser remains liable for what the overseas recipient does, unless an APP 8.2 exception applies. There is no list of acceptable destinations.
- guidanceOAIC GenAI training guidanceThe OAIC’s guidance for organisations that develop or fine-tune generative AI. It directs developers to Australian Privacy Principles 1, 3, 5, 6 and 10 in particular, covering open handling, collection, notification, use and disclosure, and the quality of the personal information used.
- guidanceOAIC AI products guidanceThe OAIC’s guidance for organisations buying rather than building AI. It expects due diligence on whether the product suits the intended use, how human oversight is embedded, what the privacy and security risks are, and who can reach the personal information going in and coming out.
- statutePrivacy ActAustralia’s general privacy statute. The thirteen Australian Privacy Principles govern collection, use, disclosure, quality, security, access and correction for APP entities, and they apply to an AI pipeline the same way they apply to any other handling of personal information.
05Vendor documents being watched
- Data residencyhttps://learn.microsoft.com/en-us/privacy/eudb/eu-data-boundary-learnnot yet fetched
- Data residencyhttps://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/deployment-typesnot yet fetched
- Data processing agreementhttps://www.microsoft.com/licensing/docs/view/Microsoft-Products-and-Services-Data-Protection-Addendum-DPAnot yet fetched
- Model documentationhttps://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/models-from-partnersnot yet fetched
- Model documentationhttps://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/models-sold-directly-by-azurenot yet fetched
- Pricinghttps://www.microsoft.com/en-us/microsoft-365/enterprise/microsoft365-plans-and-pricingnot yet fetched
- Pricinghttps://azure.microsoft.com/en-us/pricing/details/machine-learning/not yet fetched
- Pricinghttps://azure.microsoft.com/en-us/pricing/details/cognitive-services/openai-service/not yet fetched
- Privacy policyhttps://privacy.microsoft.com/en-us/privacystatementnot yet fetched
- Security pagehttps://learn.microsoft.com/en-us/azure/foundry/responsible-ai/openai/data-privacynot yet fetched
- Security pagehttps://www.microsoft.com/en-us/trust-centernot yet fetched
- Security pagehttps://learn.microsoft.com/en-us/azure/ai-foundry/responsible-ai/openai/data-privacynot yet fetched
- Security pagehttps://learn.microsoft.com/en-us/copilot/microsoft-365/microsoft-365-copilot-privacynot yet fetched
- Security pagehttps://learn.microsoft.com/en-us/azure/foundry/how-to/configure-private-linknot yet fetched
- Subprocessor listhttps://www.microsoft.com/en-us/trust-center/privacy/data-accessnot yet fetched
- Supported countrieshttps://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure-region-availabilitynot yet fetched
- Supported countrieshttps://azure.microsoft.com/en-us/explore/global-infrastructure/data-residency/not yet fetched
06Ask about your own deployment
This page reads the rules against a generic organisation. Your size, industry, data and existing contracts change which of these issues matter and which fall away.