Comparativa

Hedy vs Junior

Ambos venden la misma idea — un empleado de IA, no un chatbot. La bifurcación está en dónde se ejecuta y quién guarda las claves. Junior es un servicio en la nube; Hedy se despliega dentro de sus muros.

Hedy es un empleado de IA de despliegue privado: se ejecuta en su propia infraestructura Docker/K8s o air-gapped (aislada de red), usa sus propias claves de modelo (incluidos vLLM/Ollama locales) y se cobra por puesto. Los empleados de IA en la nube como Junior se ejecutan en los servidores de otro, le facturan por créditos de uso y guardan sus datos en el tenant del proveedor. Hedy mantiene la fuente de verdad, las ACL de recuperación y la auditoría append-only dentro de su perímetro, y es nativo en Feishu/Lark además de Slack. Un solo Hedy reemplaza la producción de un equipo, no un puesto de chat.

De un vistazo

HedyJunior
Dónde residen sus datosSu VPC — o totalmente air-gappedNube del proveedor (AWS)
Despliegue on-premSí — Compose o HelmNo se ofrece hoy
Código fuente auditableSí, por su equipo de seguridadNo
Plataformas de chatFeishu y Lark de primera clase, además de SlackSlack y Microsoft Teams
Claves de modeloSuyas — incl. modelos localesGestionadas por el proveedor
Modelo de preciosLicencia fija por puestoCréditos de uso, desde $100/mes
Pruebas de líneas rojas de conductaIncluidas en la puerta de evaluaciónNo divulgado
Amplitud de integracionesStack empresarial central, en crecimiento3.000+ mediante conectores

Basado en información pública a julio de 2026. Correcciones bienvenidas: hello@hedy.one. La columna de Hedy muestra el modo Self-hosted / BYO, el modo insignia. El modo Managed (gestionado) opcional de Hedy enruta el tráfico de modelo a través del gateway de Hedy (solo metadatos de medición, nunca contenido) y factura el uso de modelo como créditos prepagados.

Dónde destaca Junior

  • Operativo en minutos — sin infraestructura ni carga de operaciones
  • El catálogo de integraciones más amplio (3.000+ herramientas)
  • Pulido y onboarding de nivel consumidor
  • Encaja cuando su equipo vive en Slack/Teams y el SaaS en la nube es aceptable

Dónde gana Hedy

  • Residencia de datos: conocimiento, memoria, auditoría y medición permanecen en su Postgres
  • Se despliega air-gapped con modelos locales — sectores regulados bienvenidos
  • Nativo en Feishu / Lark para equipos del mercado chino
  • Precio fijo por puesto: un empleado que trabaja más no cuesta nada extra
  • Gobernanza que puede leer: las listas de permitidos (allowlists), los niveles de aprobación y la auditoría son código, no páginas de políticas

¿Cuál debería elegir?

Elija Junior si quiere un empleado de IA hoy mismo, sin infraestructura, y su listón de cumplimiento admite la nube del proveedor. Elija Hedy si su base de conocimiento, su historial de chat y sus credenciales no deben salir de su red — o si su equipo trabaja en Feishu/Lark. La misma especie, distinto modelo de custodia.

En detalle

La división central es dónde se ejecuta el trabajo. Un empleado de IA en la nube vive en el tenant de otro: sus prompts, los documentos recuperados y los resultados cruzan el límite del proveedor, y usted acepta sus subencargados (sub-processors). Hedy se despliega en su propia infraestructura mediante Docker o Kubernetes, y funciona air-gapped cuando lo necesita. En modo Self-hosted / BYO no hay subencargados: usted aporta su propia clave de modelo y la apunta a una API alojada o a un endpoint local de vLLM/Ollama, de modo que la inferencia puede permanecer dentro de la misma red que sus datos. Un despliegue típico con compose toma unos 30 minutos.

El precio sigue al modelo. Los empleados de IA en la nube le facturan por créditos de uso, así que el costo escala con cada token y cada reintento, y la previsión es pura conjetura. Hedy se cobra por puesto, y cada llamada LLM pasa por un único gateway que es dueño de la medición y la cuota, de modo que el gasto es una cifra que usted controla, no una factura variable de un proveedor. El modo Managed (gestionado) opcional de Hedy es la excepción deliberada — el uso de modelo se factura como créditos prepagados, porque ahí la capa de modelo pasa por el gateway de Hedy; lo decimos en la página de precios, no en una nota al pie. La licencia es offline en ambos modos: una licencia firmada con Ed25519 se valida sin llamar a casa, que es lo que un despliegue air-gapped o regulado realmente requiere.

La gobernanza es el producto, no un ajuste. La recuperación está acotada por ACL a quien pregunta, de modo que un empleado de IA nunca muestra documentos que esa persona no podría abrir por sí misma. Las acciones de escritura se deniegan por defecto contra una lista de permitidos (allowlist), con aprobaciones por niveles (L0/L1/L2) para todo lo que deja huella. El log de auditoría es append-only, sin ruta de actualización ni de borrado. Una puerta de evidencia (evidence gate) exige que las respuestas citen sus fuentes de forma literal, para que las afirmaciones sean rastreables y no meramente plausibles. Las pruebas de conducta de líneas rojas se ejecutan contra el agente en lugar de confiar en instrucciones dentro de un prompt.

En integración, Hedy trata Feishu/Lark como canal de primera clase junto a Slack, de modo que el empleado de IA trabaja donde su equipo ya se coordina, en lugar de imponer un stack centrado en EE. UU. El encuadre también es distinto: un empleado de IA en la nube es un puesto más en un espacio de chat; un solo Hedy está pensado para producir el resultado de un equipo. Privado, no en la nube. Un empleado, no un asistente. Hacer el trabajo, no grabar la reunión.

Preguntas

¿Hedy está alojado en la nube como otros empleados de IA?
No. Hedy se despliega en su propia infraestructura mediante Docker o Kubernetes y admite instalaciones totalmente air-gapped (aisladas de red). En modo Self-hosted / BYO no hay subencargados (sub-processors) ni tenant del proveedor que guarde sus datos: los prompts, los documentos recuperados y los resultados nunca salen de su red. En modo Managed, solo el tráfico de modelo pasa por el gateway de Hedy, que almacena metadatos de medición, nunca contenido. Los empleados de IA en la nube se ejecutan por completo en los servidores del proveedor; el conocimiento, la memoria y la auditoría de Hedy permanecen dentro de su perímetro en ambos modos.
¿En qué se diferencia el precio de Hedy de los empleados de IA con créditos de uso?
Hedy se cobra por puesto, no por token. Cada llamada LLM pasa por un único gateway que es dueño de la medición y la cuota, así que el costo es una cifra fija y predecible que usted controla. La única excepción deliberada es el modo Managed, donde el uso de modelo se factura como créditos prepagados con un margen declarado. Los modelos de créditos de uso cobran por cada token y cada reintento, lo que dificulta la previsión y ata su factura al contador del proveedor, no al suyo.
¿Puede Hedy usar nuestro propio modelo en lugar de un proveedor fijo?
Sí. Usted aporta su propia clave de modelo y apunta Hedy a una API alojada o a un endpoint local de vLLM/Ollama. Eso significa que la inferencia puede ejecutarse dentro de la misma red que sus datos, algo que los empleados de IA en la nube generalmente no pueden ofrecer, ya que enrutan a través de su propia cuenta de proveedor.
¿Qué impide que un empleado de IA filtre datos o actúe sin aprobación?
La gobernanza se aplica en código, no en prompts. La recuperación está acotada por ACL a la persona que pregunta, las acciones de escritura se deniegan por defecto contra una lista de permitidos (allowlist) con niveles de aprobación L0/L1/L2, el log de auditoría es append-only y una puerta de evidencia (evidence gate) obliga a que las respuestas citen las fuentes de forma literal. Las pruebas de conducta de líneas rojas validan estos límites directamente.

Relacionado

hedy.one

Vea Hedy en su propia infraestructura.

Solicitar una demo