Responsible AI for Australian real estate agencies
EstateOS treats responsible AI as platform principles — non-negotiable rules every feature must respect.
Eight principles
The rules every AI feature ships under
Platform principles every EstateOS AI feature must respect.
Human-in-the-loop by default
Every AI output that will reach an external party — vendor, landlord, buyer, tenant, contractor — is a draft for agent review. The reviewer, the timestamp, and the before/after content are captured in the audit log.
No code path may bypass this. It is enforced in the API layer: client-facing endpoints refuse to surface AI-generated content that has not been reviewed. Required for ACCC content accuracy and the December 2026 Privacy Act ADM transparency deadline.
Decision audit trail
Every AI-assisted output, the human reviewer, the timestamp, and the before/after edits are captured in AuditEvent. The audit log is queryable for regulatory review.
Available for DSAR fulfilment (Privacy Act 1988) and for AU competition / consumer regulator inquiry. Designed to be exportable in a regulator-acceptable format.
Explainability on demand
Any AI feature that produces a score, classification, or accept/reject signal about a person — lead qualification, tenant screening, churn risk — must emit a plain-English explanation of the factors used.
The explanation is stored alongside the output and is retrievable on request by the affected individual under Privacy Act ADM obligations. Legal advice is obtained before any scoring feature launches.
Prompt-injection defence
AI features that process attacker-controllable text — after-hours response, maintenance triage, contact note summarisation — treat every inbound message as untrusted.
BridgeOS guardrails reject or sanitise instruction-like patterns (ignore-previous attempts, system-role spoofing), refuse to execute tool actions (booking, dispatch, transfer) without a human approval step, and flag suspicious input on the AI Interaction record for security review.
OAIC consent tracking
Contact records carry explicit consent status per communication type. Open home sign-in captures consent at the point of entry. Communication channels respect consent at send time — not at the recipient level only.
DSAR fulfilment is a workflow, not a CSV export: identity verification, 30-day statutory clock, automated extraction across every entity, third-party redaction queue, legal-hold flag, principal approval.
ACCC content accuracy
Prompts are designed to describe only what the agent has input. Disclaimers appear in the UI before every publish action. The audit trail distinguishes AI-generated and agent-edited content per field.
Misleading-or-deceptive-conduct exposure is the agent — but the system makes it as easy as possible to comply, and as hard as possible to publish content the agent has not seen.
PII pseudonymisation before external AI calls
Before any prompt is sent to OpenAI, Anthropic, or Gemini, the contact name and identifying PII is pseudonymised server-side. A contact named Alex Smith becomes Buyer #B12. The mapping stays in the agency tenant; only the pseudonym reaches the LLM.
On response, EstateOS reverses the mapping before the output reaches a human. Domestic-violence-flagged fields, medical-equivalent allied health notes, and counsellor-equivalent case notes are never sent externally under any circumstances — even pseudonymised.
No PII to non-AU regions without consent
AI provider region pinning is applied where available — Anthropic and OpenAI AU/APAC endpoints. Where a fallback region is required, it is disclosed in the privacy policy and the user-facing consent flow.
Postgres, Redis, S3-equivalent — all in ap-southeast-2 (Sydney). The schema is multi-region ready for NZ/UK expansion, but for v1 every byte of agency data lives in AU.
Where this is headed
By December 2026, automated-decision transparency obligations under Privacy Act 1988 come into force. The OAIC has signalled aggressive enforcement of consent and DSAR obligations. The ACCC is paying attention to AI-generated marketing content.
We've designed EstateOS against those obligations from day one. If you have concerns about how a specific feature handles AI obligations, email us — we'll send you the underlying principle documentation and the prompt audit trail.
FAQ
Responsible AI — questions from principals and privacy officers
What EstateOS does and does not automate for client-facing communications.
- Does EstateOS send AI-generated messages to clients automatically?
- No. Client-facing endpoints refuse to surface AI-generated content that has not been reviewed. Staff must approve before email, SMS, portal updates, or tradie communications go out.
- How does EstateOS handle Privacy Act automated decision-making?
- Where AI scores or classifies a person (for example maintenance urgency shown to staff), a plain-English explanation is stored with the output and can be retrieved for access requests. Legal review is required before any high-stakes scoring feature launches.
- Is client PII sent to OpenAI or Anthropic?
- Identifying details are pseudonymised server-side before external LLM calls; mappings stay in your agency tenant. Address-suppressed and safety-sensitive fields are not sent externally, even pseudonymised.
- What happens if someone tries to manipulate the AI in an enquiry?
- Inbound text in after-hours, maintenance, and summarisation flows is treated as untrusted. Guardrails flag suspicious patterns; tool actions like dispatch or booking require human approval.
- Are AI prompts versioned and auditable?
- Yes. Calls reference a registered prompt name and version via BridgeOS. Usage is logged with model, tokens, cost, feature, and reviewer where applicable — supporting internal review and regulator questions.
- Does responsible AI mean we are fully compliant with OAIC and ACCC rules?
- No software vendor can guarantee your agency’s legal compliance. EstateOS provides workflows and controls aligned to common Australian obligations; your agency remains responsible for how you use AI and published content.