Skip to content

Koraku RealtyReal estate & privacy-first AI

Contact

PrivaGate AI

In development

A shared privacy and authorization foundation.

PrivaGate AI is the planned local control layer that sits between Japanese SME document workflows and the Claude API. EstateVault is the first industry module built on top of it.

Status In development. No public product, paying customers, or benchmark results yet.

Positioning

Between your documents and the cloud model.

PrivaGate AI is the shared foundation. EstateVault adds real-estate-specific document templates, important-matters language handling, agreement comparison rules, and disclosure defaults. Future modules (professional offices, dental clinics, pharmacies) are planned to reuse the same foundation and replace only the sector-specific rules and review process.

How it works
EstateVault

Permission-aware workflow · Target architecture

Four steps, with the boundary stated.

  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.

Data boundary

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

Token replacement does not, by itself, produce legally meaningful anonymization. Removing names does not eliminate identification risk. Compliance must be evaluated against the actual data flow.

Planned capabilities

Nine intended capabilities, all local-first.

  1. Permission-aware retrievalConfirm who the user is, what they may see, and which documents they can pull. Retrieval is constrained to the authorized subset.
  2. Local sensitive-data identificationDetect names, contact details, identifiers, and domain-specific fields. The detector runs in the customer environment.
  3. Task-level minimizationStrip the payload to the smallest context that still answers the question. The policy is per task, not global.
  4. Reversible tokenizationReplace sensitive values with reversible tokens. Tokens are useless outside the local mapping table.
  5. Disclosure policy decisionThe minimized payload is checked against a configured policy. Three paths: approved, local-only, or blocked-and-review.
  6. Cloud reasoningClaude is the planned cloud reasoning engine. Approved and minimized context is sent through the official Claude API.
  7. Output checksResponses are checked for structure, source support, and disclosure risks before any token restoration is considered.
  8. Separately authorized restorationRestoring original values is a separate authorization step, not the default. Without it, the user sees the tokenized form.
  9. Audit eventsRecord the minimum event needed for accountability. The audit log does not store full confidential content.

Differentiation

What is different by design.

  • A control layer, not a chat front endThe product is the local layer that decides what may leave the environment. The cloud model is one planned component behind it.
  • Minimization per taskThe disclosure policy is evaluated for each task rather than applied as one global filter.
  • Restoration is a separate decisionSeeing original values again needs its own authorization. Tokenization alone is not approval.
  • The reviewer stays in the loopThe workflow ends with a licensed professional, not with a model response.

Development status

Where this stands.

  1. NowArchitecture & evaluation design
  2. NextMinimal permission-aware gateway and synthetic-data evaluation
  3. ThenEstateVault validation in internal workflows
  4. LaterPlanned expansion marketsProfessional offices, dental clinics, pharmacies. Planned only; none is a customer or a deployed module.

No dates or completion percentages are published.

FAQ

Questions we expect.

Is PrivaGate AI available?

No. It is in development. There is no public product, no paying customers, and no benchmark results yet.

Does the cloud model receive the original documents?

That is not the design intent. Originals, tokens, and restoration keys are intended to stay in the customer environment. Only policy-approved, minimized context is intended to be sent.

Is tokenization the same as anonymization?

No. Token replacement is not, by itself, legally meaningful anonymization, and removing names does not eliminate identification risk.

Does it replace a licensed professional?

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

What will it cost?

Pricing is not finalized, and no plans are listed.

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