Follow the information.
A request can pass through source systems, retrieval services, model providers and logs. Backups, support access and administrative accounts add further questions.
To describe an Australian operating boundary, trace those steps. Specify where processing happens, who controls access, what providers retain and which contractual arrangements apply.
Make control something the organisation can use.
Permissions need to work across the connected system. Someone must own identity, keys, monitoring and recovery. The team also needs to understand how dependencies can be changed or removed.
These are engineering and operating decisions. They belong in the architecture and agreement for the specific engagement.
Retain control over model changes.
On controlled compute, open-weight models let us retain the weights, tokenizer, runtime and generation configuration alongside the application. We can test replacements before changing a working system. Managed endpoints need provider-specific checks on versioning and routing.
Model licence, infrastructure, support and operating cost remain part of the decision. The capabilities overview explains how we assess those choices.
Plan for the day after delivery.
The system will need maintenance, updates and a way to recover when something fails. Document those responsibilities while building it, so the organisation knows what it is taking on.
The reference operating model shows the areas we work through. Actual hosting, provider and access arrangements are established for each project.