Privacy Act AI development for Australian teams that ship.

The Privacy Act does not have a third-party vendor certification scheme that AI vendors typically hold. What the Act requires is documented evidence of compliance with the 13 Australian Privacy Principles — and that is what Aiinfox provides. We sign a DPA before any personal information is shared, run a Privacy Impact Assessment for engagements processing personal information at scale or involving sensitive information (special protections under APP 3), document the APP 8 cross-border disclosure flow explicitly, write audit logs on every model and tool call, and record the lawful basis and consent capture per processing purpose. For state-level health privacy law (HRIP NSW, HRA VIC, IP ACT QLD), we layer those controls on top of the federal baseline. We will not market a certification we cannot hold; we will sign the DPA, document the controls, and stand behind them in writing.

No, and we will say so up front rather than burying it in the fine print. Aiinfox is a foreign engineering provider, not an Australian-hosted SaaS, so IRAP assessment of our own platform is not the relevant control. What we do for federal-adjacent and defence-adjacent clients is structure the engagement to fit inside an existing IRAP-assessed cloud boundary that the customer already owns — typically AWS Australia at PROTECTED or Azure Australia Central. The deployment runs inside the customer's IRAP-assessed environment; our engineers connect over a privileged-access path that the customer's security team controls. The customer's existing IRAP assessment covers the runtime; our role is the engineering inside it. If your engagement requires our own IRAP assessment of Aiinfox as a vendor, we will tell you on the first call and recommend an Australian-domiciled alternative.

Every engagement includes a documented NDB playbook covering detection, assessment, containment, and notification — aligned with the obligations under Part IIIC of the Privacy Act. The playbook spells out the 30-day eligible-data-breach assessment window, the criteria for 'serious harm' that trigger notification, the OAIC notification template, the affected-individuals notification template, and the technical evidence we will produce (audit logs, system state at the time of the incident, prompt versions, model call records, retrieval sources). We treat the playbook as a working document — it gets a tabletop exercise in week one before the system sees real users, not a tick-box at handover.

Inside your AWS, Azure, or GCP Australian account by default — AWS ap-southeast-2 (Sydney), AWS ap-southeast-4 (Melbourne), Azure Australia East (Sydney), Azure Australia Central (Canberra) for federal-adjacent work, GCP australia-southeast1 (Sydney), or GCP australia-southeast2 (Melbourne). For inference, you have three options. One: managed LLMs with documented APP 8 cross-border disclosure — Anthropic Claude via AWS Bedrock, OpenAI via Azure OpenAI Service, with the cross-border flow disclosed in the privacy notice and DPA. Two: self-hosted Llama 3 / 3.1 on vLLM inside your Australian VPC — zero cross-border LLM exposure. Three: hybrid — non-personal-information prompts route to managed LLMs, personal-information-bearing prompts route to self-hosted Llama. For clients who have ruled out cross-border LLM disclosure under APP 8, option two is the default.

Australia is one of our better overlap windows. Indian Standard Time is UTC+5:30, Australian Eastern Daylight Time is UTC+11, so our 9:30am IST is your 3pm AEDT — roughly a four-hour afternoon overlap with Sydney, Melbourne, and Brisbane working days every weekday. For Perth (AWST, UTC+8), the overlap is stronger — our 9:30am IST is your noon AWST, giving most of an afternoon together. Daily standups and twice-weekly demos run inside your business hours. Written async updates land before your morning. For engagements that need synchronous morning coverage as well, we extend to early IST starts on a planned cadence. We will not pretend the overlap is 24/7 — it is what it is, and it is workable.

Yes. We have shipped KYC automation, AUSTRAC-aware transaction monitoring, fraud signal extraction, and deterministic-output compliance copilots for fintech and lending operators in Australia and the broader APAC market. Every model and tool call is audit-logged with input, output, prompt version, retrieval sources, and operator identity — so the accountable person under APRA's CPS 234 (information security) or CPS 230 (operational risk) has the evidence they need for a regulator examination. CPG 235 (managing data risk) shapes the data governance design. For AUSTRAC, transaction-monitoring builds are designed for typology coverage and SMR / TTR workflow integration, with humans approving every regulatory output.

Most v1 engagements at Aiinfox land between AUD $40,000 and AUD $180,000 fixed-price for a focused build — an AI agent, a RAG system, a voice pipeline, or a bespoke ML model. Larger multi-quarter engagements with fine-tuning, custom evals, and Privacy Act + APP-aligned compliance work typically reach AUD $220,000 to AUD $400,000. IRAP-fit-inside-customer-boundary engagements for federal-adjacent clients sit toward the upper end because of the additional documentation, change management, and privileged-access controls. Pilots are AUD $15,000 to AUD $28,000 with acceptance criteria written into scope. We invoice in AUD or USD. We are a registered Indian entity invoicing as a foreign corporation — GST does not apply on B2B services supplied from India to Australia (general rule; your tax adviser should confirm against your situation).

Yes — takeover audits for Privacy Act-scoped builds are routine. Step one is a data-flow audit: where does personal information actually touch storage, inference, and logging; which APP obligations apply; and which cross-border disclosures have a documented APP 8 mechanism? Step two is reading the code, evals, refusal layer, NDB playbook (if any exists), and audit-log schema, then shipping the smallest valuable change to prove the system is operable. Step three is the longer-term remediation plan — incremental fixes, a parallel rebuild, or shutting it down. Most takeovers we have seen did not need a full rewrite; they needed a documented PIA, APP 8 disclosure diagram, residency pinning, and audit logs that could survive an OAIC inquiry.