AI development company for Australian teams that ship.

Our engagement defaults are aligned with the Privacy Act 1988 and the 13 Australian Privacy Principles (APPs). DPAs are signed before any personal information is shared, and we run a Privacy Impact Assessment (PIA) for engagements processing personal information at scale or involving sensitive information. For APP 8 (cross-border disclosure of personal information), we explicitly map the data flow and the safeguards in place — your DPA spells out exactly where personal information is processed and which third-party endpoints (if any) receive it. For state-level health privacy law (HRIP NSW, HRA VIC, IP ACT QLD), we layer those controls on top of the federal Privacy Act baseline.

Every engagement includes a documented breach playbook covering detection, assessment, containment, and notification — aligned with the Notifiable Data Breaches scheme obligations under Part IIIC of the Privacy Act. The playbook spells out the 30-day assessment window, the criteria for an 'eligible data breach,' the notification template for affected individuals and the OAIC, and the technical evidence we will provide (audit logs, system state, prompt versions, model call records). We treat the playbook as a working document — it gets a tabletop exercise in week one, not a tick-box.

Yes — 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 — that gives roughly a four-hour afternoon overlap with Sydney, Melbourne, and Brisbane working days every weekday. For Perth (AWST, UTC+8), the overlap is even 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 a synchronous morning coverage as well, we can extend to early IST starts on a planned cadence.

Yes — that is the standard Australian deployment pattern. We run inside your AWS ap-southeast-2 (Sydney), AWS ap-southeast-4 (Melbourne), Azure Australia East (Sydney), Azure Australia Central (Canberra) for federal-adjacent work, or GCP australia-southeast1 (Sydney) / australia-southeast2 (Melbourne) account, using your IAM, your VPC, and your customer-managed encryption keys. For inference, we route to Australian or US endpoints depending on your DPA, or we self-host Llama 3 on vLLM inside your Australian VPC for zero third-party inference. No data leaves your cloud unless your runbook says it should.

Aiinfox itself does not currently hold an IRAP assessment — we are a foreign engineering provider, not an Australian-hosted SaaS, so IRAP assessment of our own platform is not the relevant control. What we do is structure engagements for federal and defence-adjacent clients to fit inside an existing IRAP-assessed cloud boundary (typically AWS Australia or Azure Australia Central with PROTECTED classification). 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. If your engagement requires our own IRAP assessment, we will say so on the first call and recommend an alternative path.

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 / IRAP-boundary compliance work typically reach AUD $220,000 to AUD $400,000. Pilots are usually AUD $15,000 to AUD $28,000 with acceptance criteria written into scope. Australian clients invoice in AUD via bank transfer or USD by preference. 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. 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, and operator identity — so the responsible person under APRA's CPS 234 (information security) or CPS 230 (operational risk) has the evidence they need for a regulator examination. We do not make autonomous regulatory decisions; humans approve everything that touches a regulated outcome.

Yes — takeover audits are routine. Step one is reading the code, the data pipelines, the eval results (if any exist), the prompts, and the cost telemetry. Step two is shipping the smallest valuable change to prove we understand the system in a way the previous vendor did not. Step three is the longer-term plan — incremental stabilisation, a parallel rebuild, or shutting it down and starting over. We will be honest on the first call about which is the right move. Most takeovers we see did not need a rewrite; they needed evals, guardrails, and a senior engineer on the build.