Comparativa

Hedy vs empleados de IA en la nube

Toda una categoría de excelentes productos SaaS le alquila un compañero de trabajo de IA. Todos piden el mismo precio más allá de la factura: su base de conocimiento, sus credenciales y su historial de chat, alojados en el lado del proveedor. Hedy hace la apuesta contraria.

Los empleados de IA en la nube viven en el tenant de un proveedor, de modo que su base de conocimiento, sus credenciales de API y su historial de chat residen en la infraestructura del proveedor y pasan por sus subencargados (sub-processors). Hedy invierte la custodia: se despliega dentro de su propio clúster de Docker o Kubernetes, incluso air-gapped (aislado de red). En modo Self-hosted / BYO — el modo insignia — los documentos, los embeddings, las credenciales y los logs nunca salen de su red porque, por diseño, no existe ruta de salida: usted aporta su propia clave de modelo, incluidos vLLM u Ollama locales, y Hedy tiene cero subencargados. En modo Managed (gestionado), solo el tráfico de modelo pasa por el gateway de Hedy, que almacena metadatos de medición, nunca contenido; todo lo demás sigue residiendo en sus máquinas.

De un vistazo

HedyEmpleados de IA en la nube
Dónde residen sus datosSu VPC — o air-gappedNube del proveedor
Código fuente auditableRara vez
Custodia de credencialesNunca salen de su redAlmacenadas en el lado del proveedor
Gasto en modelosSus claves, medido al costoClaves del proveedor, créditos con margen
Postura de cumplimientoSus controles, sus auditores, nuestra evidenciaPapeleo SOC2 / DPA del proveedor
Tiempo de puesta en marcha~30 minutos en una VMMinutos, sin infraestructura
Plataformas de chatFeishu / Lark / SlackNormalmente solo Slack / Teams

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; en modo Managed, el tráfico de modelo pasa por el gateway de Hedy (solo metadatos de medición, nunca contenido) y el uso se factura como créditos.

Dónde destacan los empleados de IA en la nube

  • Cero infraestructura y arranque inmediato
  • Escalado y actualizaciones gestionados por el proveedor
  • A menudo, catálogos de integraciones con apps de consumo más amplios

Dónde gana Hedy

  • Residencia de datos por arquitectura, no por cláusula contractual
  • Capacidad air-gapped para sectores regulados y con la seguridad como prioridad
  • Precio fijo por puesto — el contador es suyo
  • Gobernanza legible en el código: listas de permitidos (allowlists), niveles de aprobación, auditoría append-only, pruebas de conducta

¿Cuál debería elegir?

Si un empleado de IA en la nube del proveedor supera su revisión de seguridad, la categoría ofrece opciones sólidas. Si la revisión se atasca una y otra vez en «¿a dónde van exactamente nuestros datos?», esa es la pregunta que Hedy nació para zanjar. Self-hosted, no van a ninguna parte. Ese es el producto.

En detalle

La cuestión de la custodia es simple: cuando un empleado de IA lee sus contratos y guarda sus claves de API, ¿en el disco de quién están? Con los empleados de IA en la nube, la respuesta es: en el del proveedor. Su base de conocimiento se sube, sus embeddings se almacenan en la base de datos vectorial del proveedor, sus registros de chat se retienen bajo la política del proveedor y cada prompt atraviesa sus subencargados (sub-processors) de camino a un modelo. Usted hereda su superficie de brecha y sus términos de tratamiento de datos. Hedy es self-hosted: una instalación con docker compose, unos 30 minutos, ejecutándose por completo en infraestructura de su propiedad.

Como Hedy se ejecuta dentro de su perímetro, la residencia de datos es una propiedad de la arquitectura, no una promesa en un contrato. Los documentos ingeridos, los embeddings generados, los fragmentos recuperados y los registros de auditoría permanecen todos en sus volúmenes. En modo Self-hosted / BYO no hay canal de telemetría que nos envíe contenido y no hay subencargados en la ruta: usted apunta Hedy a su propio endpoint de modelo, su clave, su cuenta, y si requiere aislamiento total ejecuta un modelo local mediante vLLM u Ollama, de modo que ni siquiera la inferencia cruza el límite de la red. El despliegue air-gapped está soportado, con licencia offline mediante Ed25519. Si en cambio elige el modo Managed por su rapidez sin configuración, el intercambio se declara, no se oculta: el tráfico de modelo pasa por el gateway de Hedy, por lo que Hedy y el proveedor del modelo se convierten en subencargados para ese tráfico — el gateway almacena metadatos de medición, nunca contenido de prompts ni de respuestas.

Las credenciales reciben el mismo tratamiento. Los empleados en la nube le piden entregar tokens con permisos de escritura a su tenant; Hedy mantiene los secretos en la inyección de entorno que usted controla y nunca en el repositorio. Las acciones de escritura se deniegan por defecto contra una lista de permitidos (allowlist), la recuperación está acotada por ACL a la persona que pregunta y las aprobaciones se gradúan en L0/L1/L2. Así, la credencial que permite a Hedy actuar se gobierna allí donde reside, y el radio de impacto de cualquier acción individual está acotado por políticas que usted controla, no por la confianza en un operador externo.

La custodia también significa demostrabilidad. Cada acción de Hedy queda registrada en un log de auditoría append-only que usted aloja y que nadie puede editar en silencio. La puerta de evidencia (evidence gate) obliga a que las respuestas citen sus fuentes de forma literal, de modo que puede rastrear qué se leyó y por qué. Sumado a Feishu/Lark y Slack como superficies de primera clase, obtiene un empleado de IA operativo cuya huella de datos completa — del conocimiento a las claves y al historial de conversaciones — permanece dentro del límite que usted ya protege.

Preguntas

¿Dónde almacena Hedy mi base de conocimiento y mi historial de chat?
En su propia infraestructura. Hedy es self-hosted mediante Docker o Kubernetes, así que los documentos ingeridos, los embeddings, los fragmentos recuperados y los registros de chat residen en volúmenes de su propiedad. Nada se sube a un tenant de Hedy. En modo Self-hosted / BYO no hay subencargados (sub-processors) en la ruta; 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, en cambio, mantienen todo esto dentro del entorno del proveedor.
¿Mis prompts o mis datos salen de la red cuando Hedy llama a un modelo?
Solo para las llamadas al modelo, y usted elige la ruta. En modo Self-hosted / BYO usted aporta su propia clave, así que las llamadas van directamente de su despliegue a su cuenta de proveedor — o a un modelo local vLLM u Ollama si requiere cero egreso; el despliegue air-gapped (aislado de red) está soportado y se licencia offline con Ed25519. En modo Managed, las llamadas al modelo pasan por el gateway de Hedy, que almacena metadatos de medición (tokens, costo, modelo, latencia), nunca contenido de prompts ni de respuestas.
¿Cómo se protegen las credenciales que Hedy usa para actuar?
Los secretos se inyectan a través de su entorno, nunca se suben a un repositorio y nunca se entregan a un tenant externo. Las acciones de escritura se deniegan por defecto contra una lista de permitidos (allowlist), la recuperación está acotada por ACL a quien pregunta y las aprobaciones se gradúan en L0/L1/L2. Así, la credencial reside donde usted la controla y el radio de impacto de cada acción está acotado por políticas.
¿Puedo demostrar a qué accedió Hedy y qué hizo?
Sí. Cada acción queda registrada en un log de auditoría append-only que usted aloja, sin API de actualización ni de borrado. La puerta de evidencia (evidence gate) exige que las respuestas citen las fuentes de forma literal, de modo que puede rastrear exactamente qué documentos se leyeron. Como todo el sistema se ejecuta dentro de su límite, la traza de auditoría es suya, no un informe exportado por un proveedor.

Relacionado

hedy.one

Vea Hedy en su propia infraestructura.

Solicitar una demo