Compare

Hedy vs cloud AI employees

A whole category of excellent SaaS products will rent you an AI coworker. Every one of them asks the same price beyond the invoice: your knowledge base, credentials and chat history, hosted on their side. Hedy takes the opposite bet.

Cloud AI employees live in a vendor's tenant, so your knowledge base, API credentials, and chat history sit on their infrastructure and pass through their sub-processors. Hedy inverts custody: it deploys inside your own Docker or Kubernetes cluster, even air-gapped. Documents, embeddings, credentials, and logs never leave your network because there is no outbound path by design. You bring your own model key, including local vLLM or Ollama, and Hedy has zero sub-processors.

At a glance

HedyCloud AI employees
Where your data livesYour VPC — or air-gappedVendor cloud
Source auditableYesRarely
Credentials custodyNever leave your networkStored vendor-side
Model spendYour keys, metered at costVendor keys, marked-up credits
Compliance postureYour controls, your auditors, our evidenceVendor SOC2 / DPA paperwork
Time to start~30 minutes on one VMMinutes, zero infra
Chat platformsFeishu / Lark / SlackUsually Slack / Teams only

Based on public information as of July 2026. Corrections welcome: hello@hedy.one

Where Cloud AI employees shines

  • Zero infrastructure and instant start
  • Vendor-managed scaling and upgrades
  • Often broader consumer-app integration catalogs

Where Hedy wins

  • Data residency by architecture, not by contract clause
  • Air-gap capability for regulated and security-first industries
  • Flat seat pricing — the meter belongs to you
  • Governance readable in code: allowlists, approval tiers, append-only audit, conduct tests

Which should you choose?

If a vendor-cloud AI employee passes your security review, the category has strong options. If the review keeps stalling on "where exactly does our data go?" — that is the question Hedy was built to end. It goes nowhere. That is the product.

In depth

The custody question is simple: when an AI employee reads your contracts and holds your API keys, whose disk are they on? With cloud AI employees the answer is the vendor's. Your knowledge base is uploaded, your embeddings are stored in their vector database, your chat logs are retained under their policy, and every prompt traverses their sub-processors on the way to a model. You inherit their breach surface and their data-handling terms. Hedy is self-hosted: one docker compose install, roughly 30 minutes, running entirely on infrastructure you own.

Because Hedy runs inside your perimeter, data-residency is a property of the architecture, not a promise in a contract. Ingested documents, generated embeddings, retrieved chunks, and audit records all stay on your volumes. There is no telemetry channel shipping content back to us and there are no sub-processors in the path. You point Hedy at your own model endpoint, your key, your account, and if you require full isolation you run a local model via vLLM or Ollama so that even inference never crosses the network boundary. Air-gapped deployment is supported, licensed offline with Ed25519.

Credentials get the same treatment. Cloud employees ask you to hand write-scoped tokens to their tenant; Hedy keeps secrets in your environment injection and never in the repo. Write actions are default-deny against an allowlist, retrieval is ACL-scoped to the person asking, and approvals are graded L0/L1/L2. So the credential that lets Hedy act is governed where it lives, and the blast radius of any single action is bounded by policy you control, not by trust in an external operator.

Custody also means provability. Every action Hedy takes lands in an append-only audit log you host and cannot silently edit. The evidence gate forces answers to cite their sources verbatim, so you can trace what was read and why. Combined with Feishu/Lark and Slack as first-class surfaces, you get a working AI employee whose entire data footprint, from knowledge to keys to conversation history, stays inside the boundary you already secure.

Questions

Where does Hedy store my knowledge base and chat history?
On your own infrastructure. Hedy is self-hosted via Docker or Kubernetes, so ingested documents, embeddings, retrieved chunks, and chat logs live on volumes you own. Nothing is uploaded to a Hedy tenant, and there are no sub-processors in the path. Cloud AI employees, by contrast, keep all of this inside the vendor's environment.
Do my prompts or data leave the network when Hedy calls a model?
Only if you choose a remote model. You bring your own model key, so calls go directly from your deployment to your provider account. If you require zero egress, run a local model with vLLM or Ollama and inference stays entirely inside your perimeter. Air-gapped deployment is supported and licensed offline with Ed25519.
How are the credentials Hedy uses to act kept safe?
Secrets are injected through your environment, never committed to a repo, and never handed to an external tenant. Write actions are default-deny against an allowlist, retrieval is ACL-scoped to the asker, and approvals are graded L0/L1/L2. So the credential lives where you control it and each action's blast radius is bounded by policy.
Can I prove what Hedy accessed and did?
Yes. Every action lands in an append-only audit log you host, with no update or delete API. The evidence gate requires answers to cite sources verbatim, so you can trace exactly which documents were read. Because the whole system runs inside your boundary, the audit trail is yours, not a report exported from a vendor.

Related

hedy.one

See Hedy on your own infrastructure.

Book a demo