Skip to content

Koraku RealtyReal estate & privacy-first AI

Contact

How it works · Architecture

In development

Local control, minimized cloud context.

The PrivaGate AI gateway is designed to sit between the user, the in-tenant document store, and the Claude API. This page describes the target architecture. The actual data-handling terms depend on the deployment and the service contract.

The privacy boundary at a glance.

The figure shows which steps happen inside the customer-controlled environment, which step crosses the external API boundary, and where a person reviews the result. The numbered list inside the figure is its text description.

Planned privacy boundary

  1. LocalCustomer-controlled environment

    1. 01 Local documents
    2. 02 Authorization
    3. 03 Disclosure controls

  2. ExternalAPI boundary

    1. 04 Approved context → Claude API

    Requests that fail policy checks are not intended to cross this boundary.

  3. LocalBack inside the customer environment

    1. 05 Local validation and authorized restoration

  4. ReviewHuman accountability

    1. 06 Human review
Target architecture. In development.

Four steps, from request to reviewed output.

  1. Local 01

    Local ingestion & authorization

    The local layer confirms user identity, role, and document access before any retrieval happens. Only the minimum set of authorized documents is returned.

  2. Local 02

    Local disclosure controls

    Sensitive fields are redacted or replaced with reversible tokens. Originals, tokens, and restoration keys stay inside the customer environment. The minimized payload is checked against the configured disclosure policy.

  3. External 03

    Claude API processing

    Claude is the planned cloud reasoning engine. Only policy-approved, minimized context is sent through the official Claude API.

  4. Local 04

    Local validation & review

    Responses are checked for structure, source support, and disclosure risks. Restoration of original values is a separate authorization step. A licensed professional confirms the result.

The same flow in nine steps

  1. User request

    A user, authenticated to the brokerage’s own systems, asks a question that requires documents.

  2. Authorization and scoped retrieval

    The gateway confirms role, scope, and document access. Only authorized records are returned.

  3. Local sensitive-data controls

    Names, contact details, identifiers, and sector-specific fields are identified and tagged.

  4. Disclosure policy decision

    The minimized payload is checked against the configured disclosure policy. Three outcomes are possible: approved cloud, local-only, or blocked-and-review.

  5. Approved minimized context

    Only policy-approved and minimized context is prepared for cloud processing.

  6. Claude API

    Claude is the planned cloud reasoning engine. Approved context is sent through the official Claude API.

  7. Output checks

    The response is checked for structure, source support, and disclosure risks.

  8. Separately authorized restoration

    Restoring original values is a separate authorization step. Without it, the user sees the tokenized form.

  9. Human review

    A licensed professional reviews the result. The system never auto-issues a regulatory document.

What stays local, and what may cross.

Local · customer-controlled

  • Original records
  • Token mappings and restoration keys
  • Authorization decisions
  • Audit events (minimum event only)

External · only if policy approves

  • Policy-approved, minimized context sent to the Claude API
  • The model’s response, which returns for local checks

Requests that fail policy checks are not intended to cross the external API boundary. This describes design intent only.

Approved, local-only, or blocked.

Path A: Approved

Minimized context is sent to the Claude API. Output is checked, restoration is authorized, and the human reviewer confirms.

Final state: cloud + human-reviewed.

Path B: Local-only

The policy decides that no cloud processing is required. The answer is generated locally from the authorized subset.

Final state: local answer only.

Path C: Blocked / review

The policy refuses the request, or sends it to a human reviewer. No data is sent to the cloud.

Final state: blocked, escalated, or reviewed.

See the disclosure flow on synthetic data.

Concept illustration Synthetic data Browser-only

Illustrative example — not a live product response. No Claude request is made.

  1. A Tokenization (local)
  2. B Policy check (local)
  3. C Restoration (separately authorized; not performed here)

Synthetic source

Tenant name:  Yuki Tanaka-SYNTH
Contact:      tenant-001@example.invalid
Address:      1-1-1 SYNTHETIC_ADDRESS_001
Income:       JPY 6,200,000 / year (synthetic)
Co-signer:    SYNTHETIC_REF_42

Minimized context tokenized, not yet approved

Tenant name:  NAME:TENANT_001
Contact:      EMAIL:EMAIL_001
Address:      ADDRESS:ADDR_001
Income:       FINANCIAL:INC_001
Co-signer:    IDENTIFIER:REF_001

Policy result illustrative

  • Allowed Address (tokenized)
  • Blocked Income-to-rent ratio: not authorized for cloud context

Rental application received. Income-to-rent ratio and identity references are sensitive and are not sent without explicit authorization.

Open the interactive concept

Planned evaluation questions.

These are questions the planned synthetic-data evaluation is meant to answer. No results exist yet.

  • Does task-level minimization keep answers useful on synthetic real estate documents?
  • Can authorization checks be shown to limit retrieval to the permitted subset?
  • How often do output checks flag statements that the sources do not support?
  • What does a reviewer need to see to confirm a result accountably?

What this page is, and is not.

  • This page describes the target architecture of PrivaGate AI. Concrete data handling, retention, and SLAs depend on deployment configuration and the service contract.
  • Original records, token mappings, and restoration keys are intended to remain in the customer-controlled environment.
  • Token replacement does not, by itself, produce legally meaningful anonymization. Compliance must be evaluated against the actual data flow.
  • Removing names does not eliminate identification risk. Context, token shape, and other fields can re-identify a person or transaction.
  • This website is a marketing site. It is not the security gateway. The gateway is the planned PrivaGate AI product.

Contact

Interested in becoming a design partner?

Useful information is general: the kind of documents your team handles, who may see them, which steps need a human reviewer, and which languages are involved. Describe the workflow in general terms.

Please notePlease do not send confidential documents or personal data of third parties.

Request a workflow conversation