Security and data handling
Security for support data before AI launch.
Meihaku handles help-center content, macros, ticket-derived patterns, policy documents, and reviewer decisions. The controls below explain how that readiness work stays scoped, reviewable, and separate from customer-facing automation.
Trust posture
Readiness data stays bounded by source, workspace, and review.
- Read-only connector posture
- No foundation-model training on customer content
- Citation and approval records for audit review
- Clear path for privacy and security questions
Read-only source access
Meihaku connects to support sources to run readiness audits and does not write changes back to help centers, ticketing systems, or internal documents.
Workspace-scoped data
Customer source excerpts, readiness maps, citations, and approved answer records are scoped to the workspace that created them.
No model training on support content
Support content is processed to provide the service. We do not train foundation models on customer support data.
Operator approval boundary
Meihaku separates draft findings from approved answers so customer-facing AI scope can be reviewed before it is reused downstream.
Compliance checklist
Review the AI support launch boundary before customers see it.
Use the compliance checklist to align support, security, legal, and risk reviewers on source evidence, data boundaries, human-only topics, and post-launch QA.
Operating controls
The security questions buyers ask before AI support goes live.
This page is intentionally concrete. It states current posture and avoids claims that need formal attestation.
Connector access
Connectors are designed for the readiness job: reading the support material needed to map customer intents, detect gaps, and preserve citations.
Where a source supports it, teams should grant the smallest practical scope and disconnect sources that are no longer needed for an audit.
AI processing
Meihaku may use contracted AI and infrastructure providers to classify intents, compare source evidence, and draft cited answers.
Customer support content is processed for the customer's workspace and is not sold or used to train foundation models.
Retention and deletion
Readiness maps, citations, hashes, reviewer decisions, and run metadata may be retained while a workspace is active so teams can review why an intent was approved, restricted, conflicted, or blocked.
Raw source handling is focused on ingest and evidence generation. Customers can ask us to export or delete account data where law and operational requirements allow.
Access control
Meihaku requires authenticated access for customer workspaces and separates public marketing pages from private readiness data.
Teams should keep identity-provider access, email allowlists, and connected-source permissions aligned with their own support and compliance policies.
Compliance path
Meihaku is an early-stage product. We do not claim SOC 2 attestation today.
Our security work is oriented around the controls buyers ask for first: source provenance, access boundaries, retention clarity, approval records, and incident contact paths.
Reporting concerns
Security, privacy, or data-handling questions can be sent to team@meihaku.com.
Include the affected workspace, source connector, approximate time, and a short description so we can investigate quickly.
FAQ
Security questions before rollout.
Does Meihaku train AI models on our support content?
No. Meihaku processes support content to provide the readiness audit, but does not train foundation models on customer support data.
Does Meihaku write back to Zendesk, Google Drive, or other sources?
No. The readiness audit is read-only. Your team decides what to update in the source system after reviewing gaps, conflicts, and approved answers.
Is Meihaku SOC 2 certified?
Not today. Meihaku is early-stage and does not claim SOC 2 attestation. This page states the current operating posture and the controls we are building around.
Who should review security questions before we launch AI support?
Support, IT, security, legal, and compliance teams should agree on source access, retention, escalation, human-only topics, and the approved answer boundary before customer-facing launch.