Our Melbourne deployments follow a structured methodology designed for Australian regulatory and infrastructure realities. Phase 1 — Data classification and compliance mapping (weeks 1-2): we start with a data classification exercise aligned to the Australian Privacy Principles (APPs). We map which datasets constitute "personal information" under the Privacy Act and which fall under sector-specific regulations — APRA CPS 234 for financial services, My Health Records Act for healthcare data, TGA requirements for clinical AI, and institutional data governance policies for universities. For each dataset, we determine: can this data leave Australian infrastructure? Can it be processed by a US-headquartered cloud provider (CLOUD Act risk)? Does it require air-gapped deployment? This classification drives the infrastructure selection. Phase 2 — Infrastructure selection (weeks 2-3): Melbourne has strong infrastructure options. Cloud GPU: AWS Sydney region (ap-southeast-2) offers NVIDIA A100 (p4d instances) and H100 (p5 instances) with the lowest latency from Melbourne (~10ms). Azure Australia East provides A100 availability with Azure Private Link for network isolation. Google Cloud Sydney offers TPU and GPU options. For non-regulated workloads, cloud GPU provides the fastest time to production. On-premise: for organizations requiring physical control over infrastructure, we work with NextDC M1 (Port Melbourne, 7MW capacity) and M2 (Tullamarine, 40MW capacity — one of Australia's largest facilities) for colocation. We specify rack configurations for GPU workloads: 20-40kW per rack power density, liquid cooling options for H100 clusters, and redundant power feeds. Equinix ME1 provides carrier-neutral colocation with direct connectivity to Melbourne's enterprise networks. Edge deployment: for agricultural and manufacturing clients, we deploy inference on edge hardware (NVIDIA Jetson, Intel NUCs with GPU) at the point of data generation — essential for farm applications with poor connectivity and factory floor systems requiring sub-10ms inference latency. Phase 3 — Model selection and Australian fine-tuning (weeks 3-5): we benchmark open-weight models against the client's actual tasks, not generic leaderboards. For Australian enterprises, model selection typically involves: Llama 3 8B and 70B (strongest general-purpose, excellent for enterprise document processing and customer interaction), Mistral 7B and Mixtral 8×7B (best inference economics — Mixtral's MoE architecture processes requests at 40% lower cost than equivalent-quality dense models), Command R+ (optimal for RAG workloads — built-in citation and grounding, important for compliance-sensitive applications where source attribution matters), and domain-specific models (BioMistral for healthcare, CodeLlama for software development, fine-tuned models for Australian legal and financial text). Australian English fine-tuning: Australian English has distinct vocabulary ("superannuation" not "401k," "ute" not "pickup truck"), spelling conventions (colour, organisation, licence), regulatory terminology (APRA, ASIC, AUSTRAC, ACCC), and cultural references that US-trained models handle inconsistently. For customer-facing applications, we fine-tune on Australian corpora to ensure natural, locally appropriate language. Phase 4 — Production deployment and MLOps (weeks 5-8): we deploy the production inference stack with vLLM (continuous batching, PagedAttention for memory-efficient long-context serving), model optimization (GPTQ/AWQ quantization, KV cache management, speculative decoding for latency reduction), monitoring (Grafana dashboards tracking latency P50/P95/P99, GPU utilization, token throughput, and model quality metrics), and security controls (TLS encryption, RBAC, audit logging for every inference request). Phase 5 — Handoff and ongoing operations (weeks 8-10): comprehensive knowledge transfer to the client's team, including runbooks for model updates, GPU failure recovery, capacity planning, and escalation procedures.