Mining’s most valuable safety data is often its most sensitive.
Incident files can contain witness statements, medical information, photographs, personnel records, legal analysis, equipment vulnerabilities, control failures, and candid accounts of how work is actually performed. Safety management systems, audit findings, maintenance records, and operational telemetry can reveal weaknesses that would be damaging if exposed, altered, or taken out of context.
As mining companies introduce AI into investigations, document assurance, and critical-control management, this information enters a more complex data environment. It may pass through databases, document stores, retrieval indexes, AI models, application logs, backups, and support systems.
That makes hosting architecture a safety-governance decision, not merely an IT procurement detail.
Data residency is only the first question
A service can store its primary database in Australia and still expose information to other jurisdictions.
Backups may be replicated overseas. Support personnel may administer the service from another country. Prompts may be processed by an external AI provider. Diagnostic logs may retain fragments of customer content. Encryption keys may remain under provider control. Foreign laws may apply to the company operating the infrastructure.
The Australian Signals Directorate advises organisations to consider a cloud provider’s ownership, operational locations, support personnel, subcontractors, and exposure to foreign government directions. It also warns against relying on any single factor when judging whether a provider is suitable for sensitive data (ASD cloud assessment guidance).
The distinction is important:
- Data residency identifies where information is stored.
- Data sovereignty addresses which laws and authorities can reach it.
- Operational sovereignty determines who can administer, move, decrypt, recover, or delete it.
- Technological sovereignty considers whether the organisation can continue operating, migrate, or recover without unacceptable dependence on one provider.
The European Commission’s 2026 Cloud Sovereignty Framework similarly assesses sovereignty across legal, data and AI, operational, supply-chain, technological, and security dimensions. It specifically treats effective customer control of cryptographic access as a sovereignty criterion (European Commission framework).
A local database is useful. It is not, by itself, a sovereign architecture.
AI expands the data boundary
Traditional hosting reviews tend to focus on application databases and file storage. AI introduces additional components that leaders must understand:
- prompts and uploaded evidence
- generated responses and working drafts
- embeddings and retrieval indexes
- temporary processing and caching
- safety filters and model telemetry
- application and administrative logs
- model-provider retention
- product-improvement or model-training rights
- subprocessors used for hosting, monitoring, or support
This expanded data path matters because information can leave effective organisational control without an obvious “file transfer.”
The Office of the Australian Information Commissioner recommends that organisations avoid entering personal, particularly sensitive, information into publicly available generative-AI tools. It also advises organisations to establish who can access input and output data, whether information is used for training, and whether the intended use complies with privacy obligations (OAIC commercial AI guidance).
For cross-border disclosures, Australian organisations may remain accountable for how an overseas recipient handles personal information. Contracts, subcontractor obligations, security arrangements, retrieval rights, and permanent deletion are among the factors relevant to whether an organisation retains effective control (OAIC APP 8 guidance).
AI therefore requires organisations to map the complete information lifecycle, not just the location of the production database.
What a defensible sovereign-AI posture requires
A credible approach begins with classification. Not every dataset requires the same boundary, but the decision should reflect the sensitivity of individual records and the insight that aggregated data can reveal.
For sensitive safety and operational information, leaders should expect clear answers in five areas.
1. Location and jurisdiction
Document where data is stored, processed, backed up, logged, and accessed. Include disaster-recovery locations, model endpoints, support functions, and every material subprocessor.
2. Customer control
Establish who controls identities, privileged access, encryption keys, retention periods, export, and deletion. Access should be least-privileged, monitored, and attributable to an individual.
3. AI data use
Contracts should state whether customer content is retained, used to train models, reviewed by provider personnel, or shared with additional services. Model and provider changes should be governed rather than introduced silently.
4. Evidence and accountability
AI outputs used in safety work must remain traceable to their sources. Human review should be explicit, and the record should show what information was used, what the system produced, and who approved the outcome.
5. Resilience and exit
Sovereignty also means being able to retrieve records, restore operations, preserve audit history, and change providers without losing control of critical information.
ASD’s current shared-responsibility guidance is direct: cloud customers cannot outsource the risk to the confidentiality, integrity, or availability of their data. Encryption, access control, logging, backups, incident response, and supplier oversight remain shared or customer responsibilities (ASD executive guidance).
MineGuard AI’s Australian sovereign deployment
MineGuard AI makes sovereignty a distinct deployment choice rather than treating an Australian database region as sufficient.
For customers who require Australian data sovereignty, Incident AI can operate in a separate Australian environment where hosting, storage, backups, logging and AI inference all run in Australian regions. Tenants are routed to this environment through server-side configuration after sign-in, and the published architecture states that there is no data path from the sovereign environment to the standard deployment (Incident AI Subprocessor Register).
An Australian boundary across the workflow
The sovereign option keeps the principal Incident AI data path in Australia:
- Application runtime: The web application, API and media-processing worker run on Azure Container Apps in Australia East. Request and response payloads are processed in memory.
- Database, audit trail and backups: Supabase Postgres operates in Sydney, Australia (
ap-southeast-2). Cases, tool completions, transcriptions and audit records are held there. Result, prompt and content fields use field-level encryption, while encrypted managed backups support point-in-time recovery. - Evidence storage: Uploaded images, audio, video and generated documents are stored with Wasabi in Sydney, Australia.
- AI reasoning: Amazon Bedrock using Anthropic Claude runs in Sydney with Australia-only inference profiles. Prompts and evidence text are subject to zero retention and are not used for model training.
- Speech transcription: Azure AI Speech operates in Australia East. Interview and site audio is held only for the duration of the transcription request.
- Handwriting and document OCR: Azure AI Vision operates in Australia East, with scanned statements and field notes held only for the duration of the request.
- Operational monitoring: Azure Monitor and Log Analytics run in Australia East in a workspace bound to the Australian environment.
This is materially different from selecting an Australian location for the primary database while allowing AI processing, support telemetry or backups to cross the boundary. The sovereign option addresses the application, evidence, database, backup, monitoring and inference layers together.
How the design supports customer compliance
The architecture is designed to help customers meet Australian data-sovereignty, privacy, security and assurance requirements through:
- environment isolation, with sovereign tenants separated from the standard deployment
- data minimisation, including in-memory or request-duration processing where persistence is unnecessary
- controlled persistence, with defined Australian locations for cases, evidence, audit records and backups
- encryption, including field-level protection for sensitive prompt, content and result data
- AI data controls, including Australia-only inference, zero retention and no training on customer prompts or evidence
- traceability and accountability, combining an Australian audit trail with MineGuard AI’s evidence-linked outputs and human approval model
These controls support a defensible compliance posture, but technology architecture does not replace a customer’s own legal, privacy and cyber-risk assessment. Applicable obligations, contractual settings, identity and access configuration, retention rules and incident-response arrangements still need to be confirmed for each deployment.
MineGuard AI’s approach is therefore practical: make the sovereign boundary explicit, keep the complete sensitive data path inside it, minimise unnecessary retention, and preserve human ownership of safety decisions.
The leadership test
Before approving AI for sensitive mining information, executives should be able to answer one question:
Can we demonstrate where our information goes, who can reach it, what the AI is permitted to do with it, and how we regain control when something changes?
If the answer depends on assumptions, the architecture is not ready.
Sovereign AI is not about rejecting cloud technology. Well-designed cloud services can provide strong security, resilience, and monitoring. It is about using those capabilities inside a boundary that the organisation understands, governs, and can defend.
For high-consequence work, control of the data is part of control of the risk.
Key sources
- Australian Signals Directorate: Cloud assessment and authorisation
- Australian Signals Directorate: Cloud shared responsibility
- OAIC: Privacy and commercially available AI
- OAIC: Cross-border disclosure guidance
- NIST: Generative AI Risk Management Profile
- European Commission: Cloud Sovereignty Framework
- MineGuard AI: Incident AI Subprocessor Register and Australian sovereign deployment