Inputs, outputs, retrieved context, tool arguments, traces, and feedback can all contain personal information. Assess purpose, disclosure, accuracy, security, retention, deletion, human review, and breach response, not prompts alone. For Australian analysis, use the Privacy Act term personal information; treat PII as security shorthand, not the legal test.
Enterprise operating guide · Australia
Deploy production AI with evidence, authority, and a way back.
A step-by-step path from use-case approval to a monitored production system, with Australian legal checks, Microsoft Foundry and Amazon Bedrock implementation paths, and a governed Finance and ERP example.
Vendor-neutral control model · Current to 17 July 2026 · General information, not legal advice. Confirm obligations, cloud terms, model availability, and feature status for the specific organisation and workload.
Australian applicability
Separate four questions that are often collapsed into one.
Privacy, residency, sovereignty, and critical-infrastructure status are related, but they are not synonyms. Record each requirement, its source, the accountable decision, and the control that satisfies it.
Record where each component processes and stores data, including inference, abuse monitoring, indexes, logs, backups, support access, and subprocessors. A regional resource name is not the complete data flow.
Consider jurisdiction, keys, identity, administration, support access, provider dependency, auditability, lawful access, operational continuity, and the ability to move or stop the system.
Identify the defined critical infrastructure asset, the responsible entity or direct interest holder, the applicable obligation, and whether the AI or cloud service handles business-critical data. Sector proximity alone does not complete the analysis.
No blanket localisation claim
The Privacy Act framework is not, by itself, a rule that all organisational data must remain in Australia. APP 8 instead addresses cross-border disclosure and accountability, while APP 11 requires reasonable security and lifecycle measures. Contract, procurement, sector, customer, or SOCI requirements may still set a stricter boundary. Start with the official APP 8 guidance, APP 11 guidance, and CISC applicability guidance.
The deployment path
Eleven gates from business intent to production operation.
Complete the gates in order for the first workload. Later systems can reuse the platform, patterns, and evidence, but each use case still needs its own authority, data, evaluation, and operating decision.
Authorise a bounded use case
A named business owner, a clear purpose, and a line the system is not permitted to cross.
- Write the decision or task the system assists, the people affected, and the business outcome it must improve.
- Name the accountable executive, product owner, technical owner, data owner, security owner, and human approver.
- List prohibited outcomes and irreversible actions. For finance, autonomous posting, payment, vendor-master changes, and bank-detail changes should begin outside the AI authority boundary.
- Define a manual fallback before any technical build starts.
Classify the data and legal context
A data-flow map that distinguishes policy preference from an actual legal, contractual, or sector requirement.
- Inventory every input, retrieved document, prompt, output, trace, cache, index, tool argument, and write-back field.
- Mark personal information, sensitive information, financial data, credentials, commercially sensitive data, and business-critical operational data.
- Assess Privacy Act use and disclosure, APP 8 cross-border handling, APP 11 security and deletion, and Notifiable Data Breach response.
- Determine whether the organisation is a responsible entity or direct interest holder for a defined critical infrastructure asset before assigning SOCI obligations.
- Record data residency, sovereignty, support-access, subcontractor, retention, deletion, and lawful-access requirements separately.
Write the system contract
Testable requirements for quality, safety, latency, cost, evidence, and human control.
- Define accepted inputs and schemas, required source evidence, response schema, confidence rules, and refusal behaviour.
- Set quality thresholds against a representative, versioned evaluation set rather than a demonstration prompt.
- Specify which actions are read-only, which create a draft, which require approval, and which are prohibited.
- Set service objectives for latency, availability, recovery, token or inference cost, and maximum tolerated error.
Build the governed landing zone
Separated environments with identity, network, policy, key, budget, and asset controls in place before model access.
- Separate development, test, and production accounts, subscriptions, projects, data, credentials, and logging destinations.
- Use infrastructure as code and policy as code so a production environment can be recreated and reviewed.
- Restrict regions, services, model deployment types, public endpoints, and unapproved marketplace models centrally.
- Attach owners, data class, environment, cost centre, recovery tier, and system ID to every resource.
Make identity the control plane
Every person, workload, model call, retrieval, and tool action has attributable, least-privilege identity.
- Federate workforce access through the enterprise identity provider with MFA, conditional access, and lifecycle management.
- Use workload identities and short-lived credentials; keep long-lived model API keys out of production applications.
- Route model, storage, search, database, secrets, telemetry, and ERP traffic through approved private paths where required.
- Create separate read and write roles. Give the AI runtime no direct payment or privileged ERP authority.
Prepare governed data and grounding
The system receives only the minimum current context needed, with source identity and access rules preserved.
- Minimise or de-identify personal information before it reaches the model where the task permits.
- Apply source-system permissions to retrieval, not one broad service account shared by every user.
- Version and hash policies, procedures, master data, and reference documents used for grounding.
- Define freshness, deletion, re-indexing, and source-revocation behaviour for every knowledge store.
Layer validation around the model
Probabilistic generation is contained by deterministic checks, policy tests, and evidence requirements.
- Use provider guardrails as one layer for harmful content, prompt attacks, and sensitive-data handling, not as proof of business correctness.
- Validate schemas, totals, dates, vendor identifiers, tax fields, delegated authority, and ledger rules with deterministic code.
- Require citations to approved source records and reject unsupported material claims.
- Test prompt injection, data exfiltration, tool misuse, ambiguous documents, stale policy, model refusal, and degraded provider behaviour.
Put gates in front of business actions
The system can recommend or draft without silently converting an uncertain output into an authoritative ERP event.
- Present the proposed action, source evidence, changed fields, confidence, policy result, and exceptions to the approver.
- Require step-up approval for sensitive, high-value, unusual, or irreversible actions.
- Use idempotency keys, transaction limits, duplicate detection, and two-person control where the business process requires it.
- Keep a tested kill switch for tool access and a queue that returns work to the manual process.
Capture an evidence-grade trace
Operations can reconstruct what happened without turning the telemetry store into a second uncontrolled data lake.
- Assign a correlation ID across user request, retrieval, model call, validator, approval, tool call, and ERP record.
- Record identity, model and deployment, prompt template version, source IDs and hashes, policy result, output hash, approval, latency, cost, and final state.
- Redact secrets and minimise personal information before telemetry leaves the application. Treat traces as production data with their own access and retention controls.
- Send security events to the SIEM and quality, cost, latency, failure, override, and drift metrics to the operating dashboard.
Release through evidence gates
A versioned deployment that can be promoted, compared, rolled back, and stopped.
- Version model deployment, prompt, policy, guardrails, validators, retrieval configuration, tools, and evaluation set together.
- Block promotion when quality, safety, security, latency, cost, or rollback tests fail.
- Start in shadow mode, then a limited cohort, then a capped production release with explicit stop conditions.
- Keep the prior known-good configuration and manual process ready throughout rollout.
Operate, respond, and re-authorise
The system remains safe as data, models, vendors, laws, threats, and business processes change.
- Review overrides, near misses, complaints, drift, data leakage, provider changes, cost anomalies, and tool-permission changes on a fixed cadence.
- Exercise incident triage, model or connector isolation, evidence preservation, breach assessment, stakeholder communication, and manual fallback.
- Re-run the applicability assessment and evaluation suite after material changes to model, purpose, data, integrations, authority, or affected people.
- Retire systems that no longer clear their value, control, or supportability threshold.
Reference architecture
Keep generation away from authority.
The model proposes. Deterministic services validate. Policy constrains. A named person approves high-impact work. A narrow integration identity performs the permitted action. The evidence trace crosses every boundary.
Request-to-action pathOne correlation ID · every boundary
01Approved channel
Authenticated user, service, or event
02Policy boundary
Purpose, data class, consent, and authority
03Grounding
Permission-aware retrieval from governed sources
04Model gateway
Approved model, region, limits, and guardrails
05Validation
Schema, evidence, arithmetic, policy, and risk
06Human gate
Review the proposal, sources, and changed fields
07Narrow action
Idempotent tool call with least privilege
Evidence plane
Identity · purpose · data class · model and region · prompt and policy version · source hashes · validator results · approval · tool call · target record · cost · latency · outcome
Two implementation paths
The control model stays stable. The cloud mechanics change.
Confirm current regional support, deployment type, generally available status, data handling, and feature limitations before build approval. Both platforms evolve quickly; pin the reviewed service configuration in the release evidence.
Microsoft Foundry
Start with Australia East where the required generally available capabilities and model are supported. Select the processing and deployment type deliberately; do not assume a global or data-zone option satisfies an Australia-only requirement.
- Create separate production and non-production Foundry resources or projects through Bicep or Terraform, with Azure Policy restricting locations, public access, resource types, and unapproved models.
- Use Microsoft Entra ID, managed identities, project-scoped RBAC, Privileged Identity Management, and access reviews. Prefer identity-based authentication over production API keys.
- Use Private Link for inbound access and private endpoints for Storage, Key Vault, AI Search, databases, and Application Insights where the architecture requires isolation. Restrict agent outbound traffic to approved destinations.
- Connect governed Storage, Search, SQL, or ERP integration services through workload identity. Preserve source permissions and separate read roles from write roles.
- Deploy an approved model and configure platform guardrails. Add application-level schema, arithmetic, policy, evidence, and action validators.
- Connect Application Insights and OpenTelemetry tracing. Redact before export, restrict Log Analytics access, set retention, alert in Azure Monitor, and forward security events to the enterprise SIEM.
- Promote a version manifest through evaluation, security, cost, latency, approval, canary, and rollback gates. Avoid preview-only dependencies unless risk acceptance covers their lack of production SLA.
Control stack
- Entra ID + managed identities + Azure RBAC
- Azure Policy + private networking + Key Vault
- Foundry guardrails + application validators
- Application Insights + Azure Monitor + SIEM
- Bicep/Terraform + CI/CD evaluation gates
Amazon Bedrock
Start in Asia Pacific (Sydney), ap-southeast-2, with an in-region model when processing must remain in Australia. APAC geographic inference can process in other APAC Regions; global inference can process worldwide.
- Use separate development, test, and production accounts in AWS Organizations. Apply service control policies for approved Regions, Bedrock actions, models, marketplaces, and cross-region inference profiles.
- Federate people through IAM Identity Center and use temporary IAM roles for workloads. Grant model, data, guardrail, logging, and ERP permissions independently.
- Use Bedrock Runtime interface VPC endpoints through AWS PrivateLink, private subnets, endpoint policies, KMS keys, Secrets Manager, and restricted egress.
- Keep governed source data in encrypted S3 and approved data services. Preserve source entitlements and use narrow, auditable connectors for the ERP boundary.
- Select an approved Bedrock model and attach Guardrails for prompt attacks, denied topics, sensitive information, and grounding where appropriate. Add deterministic business validators outside the model.
- Enable CloudTrail for API activity and CloudWatch metrics. Model invocation logging is off by default and can capture full inputs and outputs, so decide content logging only after privacy, access, encryption, and retention review.
- Promote CloudFormation or Terraform releases through the same evaluation, security, cost, latency, approval, canary, and rollback gates used by the vendor-neutral system contract.
Control stack
- IAM Identity Center + workload roles + SCPs
- PrivateLink + endpoint policies + KMS
- Bedrock Guardrails + application validators
- CloudTrail + CloudWatch + central security account
- CloudFormation/Terraform + CI/CD evaluation gates
Region-routing warning
Microsoft documents that processing geography changes with Global and DataZone deployment types, and AWS documents that APAC geographic inference can route across APAC destination Regions. If the approved boundary is Australia, choose an eligible in-region path and block unapproved routing, not merely a resource labelled Australia. Verify the current Microsoft data-handling description and AWS cross-region description.
Product selection
A product name is not a production architecture.
Public chatbots, enterprise workspaces, managed cloud model services, and direct APIs can have materially different identity, administration, data handling, evidence, networking, support, and contract controls. Approve the exact service, tier, configuration, deployment type, and use case, never the brand in the abstract.
The OAIC recommends due diligence, ongoing review, human oversight, and a cautious approach to personal information in commercially available AI products. It recommends not entering personal or sensitive information into publicly available generative AI tools as a matter of best practice. Read the OAIC guidance.
Contract
Who is the processor, which terms apply, and can the service reuse customer content?
Identity
Does the approved tier support SSO, lifecycle management, conditional access, and attributable use?
Administration
Can administrators restrict models, tools, connectors, sharing, retention, and spend?
Data flow
Where are prompts, files, outputs, indexes, traces, and support copies processed and stored?
Evidence
Are API activity, model calls, tool actions, approvals, policy results, and changes exportable?
Isolation
Can production traffic use private paths, workload identity, scoped projects, and separate environments?
Assurance
Are limitations, model changes, subprocessors, incidents, deletion, and independent assurance visible?
Exit
Can data, prompts, evaluations, logs, workflows, and business continuity survive a provider change?
Worked example · Finance and ERP
Accounts-payable invoice exception assistant.
A useful first production pattern because it combines document processing, finance policy, ERP data, deterministic reconciliation, an explainable AI contribution, a human decision, and measurable operational value without granting payment authority.
The system prepares a reviewable exception case.
It may extract, reconcile, classify, explain, draft, and create an approved ERP exception record. The finance team still owns vendor changes, ledger policy, delegated authority, posting, payment release, fraud decisions, and exception approval.
No autonomous payment · No bank-detail change · No vendor-master write · No silent journal posting · Manual queue always available
Receive an invoice through the controlled accounts-payable channel and assign a case ID. Reject unsupported formats and quarantine malware before extraction.
Extract only fields needed for matching. Mask bank, tax, contact, and employee data from model context unless the approved exception path requires it.
Use deterministic services to perform purchase-order, receipt, duplicate, tax, currency, vendor-master, and delegated-authority checks.
Let the model classify the exception and draft a recommendation grounded in current finance policy, with source links and structured confidence.
Reject outputs that fail schema, arithmetic, policy, evidence, or permitted-action rules. Route low-confidence or conflicting cases to manual review.
Show the finance approver the source documents, proposed field changes, rule results, model explanation, and exceptions. The approver can edit, reject, or accept.
A narrow integration role creates or updates the approved ERP exception record using an idempotency key. It cannot release payment or change bank details.
Store the correlated decision record, validation results, approval, ERP identifiers, version manifest, latency, cost, and final status under the retention policy.
Exception-classification precision and recall
Unsupported recommendation rate
Human override and material-edit rate
Duplicate or policy-breach escape rate
Average exception cycle time
Manual fallback volume and queue age
Sensitive-data and prompt-attack detections
Cost per completed, approved case
Logging is a data decision
Microsoft traces can contain prompts, model inputs and outputs, retrieval, and tool calls. Bedrock model invocation logging can capture full request and response content and is disabled by default. Redact or minimise before export, restrict access, set retention, and decide whether content logging is necessary. Always keep a structured application audit event even when full prompt logging is inappropriate. See the Microsoft tracing guidance and Bedrock invocation logging guidance.
Official source register
Verify the boundary before you rely on it.
Reviewed 17 July 2026. These primary sources support the guide, but service features, regional availability, legal obligations, contracts, and regulatory guidance can change. Record the exact source and review date in each production decision.
Australia
Cyber and Infrastructure Security CentreSOCI Act regulatory obligations
Role- and asset-specific obligations, data-service-provider notification, incident reporting, and risk management programs.
Office of the Australian Information CommissionerGuidance on privacy and commercially available AI products
AI product due diligence, personal information, transparency, human oversight, monitoring, and public chatbot caution.
Office of the Australian Information CommissionerAPP 8: Cross-border disclosure of personal information
Reasonable steps and accountability for overseas recipients, including cloud-provider control considerations.
Office of the Australian Information CommissionerAPP 11: Security of personal information
Technical and organisational security measures, lifecycle protection, destruction, and de-identification.
Office of the Australian Information CommissionerNotifiable Data Breaches scheme
Assessment, serious-harm threshold, remediation, and notification for eligible data breaches.
Australian Signals DirectorateEssential Eight maturity model
A baseline cyber mitigation maturity model for internet-connected IT networks.
National AI CentreGuidance for AI Adoption: implementation practices
Australia's current voluntary implementation guidance for safe and responsible AI adoption.
Microsoft
Microsoft LearnWhat is Microsoft Foundry?
Current platform, governance, project, model, agent, tool, and operations overview.
Microsoft LearnData, privacy, and security for Azure Direct Models
Processing geography, storage, training use, stateful features, content filtering, and abuse monitoring.
Microsoft LearnNetwork isolation for Microsoft Foundry
Private endpoints, inbound and outbound boundaries, DNS, permissions, and limitations.
Microsoft LearnRole-based access control for Microsoft Foundry
Foundry resource and project scopes, built-in roles, managed identity, and enterprise access patterns.
Microsoft LearnSet up tracing in Microsoft Foundry
Application Insights, OpenTelemetry, production trace content, access, retention, and preview limitations.
AWS
AWS DocumentationData protection in Amazon Bedrock
Shared responsibility, identity, encryption, logging, model-provider separation, and abuse-detection considerations.
Amazon Web ServicesAmazon Bedrock security, privacy, and responsible AI
Customer inputs and outputs, model training, encryption, private connectivity, and guardrail capabilities.
AWS DocumentationUse interface VPC endpoints for Amazon Bedrock
PrivateLink endpoints, private DNS, supported APIs, and endpoint policies.
AWS DocumentationMonitor model invocation using CloudWatch Logs and S3
Invocation logging defaults, captured request and response content, destinations, and limitations.
AWS DocumentationMonitor Amazon Bedrock API calls using CloudTrail
Control and runtime API activity, identity, source, time, and ongoing trail delivery.
AWS DocumentationCreate an Amazon Bedrock Guardrail
Content, prompt attack, sensitive information, grounding, denied-topic, and reasoning controls.
AWS DocumentationGeographic cross-Region inference
Processing boundaries, destination Regions, storage considerations, IAM, and service control policies.
From one system to enterprise change
Put this deployment path inside a five-year operating roadmap.
The companion roadmap sequences governance, cyber, data, platform, delivery, workforce, and value management from the first 90 days to selective AI-native operations.
- Five annual mandates with measurable exit gates
- Six workstreams that run through every year
- A practical first 90 days
- Quarterly funding and assurance cadence