El sistema operativo corporativo de datos e IA.
Las empresas que quieren una plataforma de datos e IA eligen hoy entre pagar Databricks o Snowflake más Palantir, o integrar a mano quince piezas open source. HORUS es la tercera vía: el stack completo ya integrado y gobernado, en tu propia infraestructura. Montar la plataforma de un cliente no es un despliegue: es crear un proyecto, con su entorno aislado aprovisionado en una transacción.
Una instalación, N proyectos aislados.
Una Postgres, un almacén de objetos, un gateway LLM. Cada proyecto con sus esquemas, roles y bucket. Si el SQL generado por un modelo intenta tocar otro proyecto, Postgres devuelve permission denied: el aislamiento no depende de que el código se acuerde de filtrar.
Del origen al cuadro de mando, gobernado
Ingesta con dlt dentro del aislamiento del proyecto, dbt con tests y unit tests, linaje y calidad en el catálogo, cuadros declarados como código y una API pública de datos con una clave por proyecto.
Tejida, no pegada
Gateway LLM con claves virtuales y presupuesto por proyecto, RAG por proyecto con fuentes citadas, agentes con cola y evaluaciones, text-to-SQL ejecutado con el rol de solo lectura del proyecto, y una capa MCP que da a los modelos herramientas reales sobre la plataforma.
Los datos no salen
Transcripción en tu propio hardware, modelos locales opcionales, sin puertos abiertos, copias cifradas verificadas con un drill de restauración mensual. Todo Apache, MIT o MPL: nada que no se pueda ceder.
Un catálogo de capas, cada una una app instalable.
Capas Docker Compose numeradas tras Traefik y Authentik. Un proyecto compone lo que necesita.
| Capa | Qué te da |
|---|---|
| Identidad y borde | SSO Authentik con grupos por aplicación y por proyecto, Traefik con TLS automático, forward-auth delante de cada herramienta |
| Plano de datos | Postgres/Supabase con pooler, almacén de objetos con un bucket por proyecto, Redis |
| Aplicaciones | Portal, gateway LiteLLM, agentes, transcripción, servidores MCP, guardrail de PII con Presidio |
| Analítica y gobierno | Superset con conexión por proyecto, OpenMetadata con dominio por proyecto, dbt, API pública de datos |
| Trabajo y conocimiento | OpenProject, Twenty CRM, wiki Outline, JupyterLab |
| Operación (solo admins) | Uptime Kuma, Dozzle, Netdata, n8n maestro, Airbyte maestro, secretos con OpenBao, OpenTelemetry + Prometheus + Jaeger + VictoriaLogs |
Un aislamiento que se puede demostrar.
No es «filtramos en la aplicación». Dar de alta un proyecto crea, en una transacción, todo lo que lo mantiene aparte, y los tests que lo prueban corren contra un Postgres real.
Postgres p_<slug>_raw · p_<slug>_staging · p_<slug>_marts
roles p_<slug>_rw / _ro / _bi / _api · RLS fail-closed
Objetos bucket p-<slug> + access key con policy limitada
Identidad grupos proj-<slug> · proj-<slug>-admin
Catálogo Domain <slug> BI conexión con p_<slug>_biY dentro de un proyecto, inquilinos
Una mancomunidad con nueve municipios, un grupo con N filiales: una capa segura de vistas filtradas por inquilino, fail-closed por diseño. Una tabla con pinta de dato por inquilino y sin clave registrada se expone cerrada, nunca abierta.
O tus datos en tu propio Postgres
Residencia de datos: el plano de control sigue compartido, el dato del proyecto vive en la base de datos del cliente, en su red.