betool está diseñado para entornos regulados. La seguridad no es una capa añadida a posteriori: es el invariante que da forma a cada línea de código, cada migración, cada módulo.
1. Multi-tenancy estricto
Cada organización posee sus propios datos, pipelines, secretos, archivos y claves de LLM. El aislamiento se aplica:
- A nivel de base de datos — cada tabla de negocio lleva una columna
org_idindexada, y las consultas del lado servidor siempre filtran por la organización de la sesión. - A nivel de sistema de archivos — cada organización tiene su propia raíz en
<data_root>/orgs/<org_id>/. Sin rutas compartidas. - A nivel de caché — cachés por organización; ninguna entrada compartida sin un indicador
is_shared = TRUEexplícito. - A nivel de secretos — cada organización tiene sus propias claves de API y tokens, almacenados del lado del servidor y nunca reexpuestos en claro. Sin fallback global. Los secretos introducidos en la configuración de un nodo (secreto HMAC, token, contraseña) también quedan enmascarados en todos los lugares donde se vuelve a leer la configuración — editor, API, herramientas MCP leídas por una IA, propuestas.
2. Auditoría obligatoria del acceso cross-tenant
Ciertos roles (normalmente cuentas de operador de plataforma del lado del proveedor) pueden necesitar acceder al contenido de otra organización con fines de soporte. Dicho acceso es:
- Condicionado a un opt-in de la organización de destino — revocable en cualquier momento desde el panel de administración.
- Registrado en cada acceso — tabla de auditoría dedicada, acotada por organización de destino, expuesta a los clientes mediante
GET /api/admin/me/supervisor-reads. - Denegado si la escritura de auditoría falla — sin lectura sin rastro.
Consulta Auditoría RGPD.
3. Rechazo motivado en operaciones destructivas
Cualquier operación que destruya o reemplace el contenido de otra organización (REPLACE-IN-PLACE de hijos, DELETE) se rechaza si la organización de destino no ha activado el opt-in de lectura. Motivo: sin visibilidad, el operador estaría proponiendo un payload que podría sobrescribir a ciegas el contenido existente.
4. Soberanía sobre el modelo de LLM
- BYOK nativo — tus claves de OpenAI, Anthropic y Google las gestiona tu organización. Sin fuga entre organizaciones. BYOK es opcional (existen modelos gestionados, facturados en créditos) pero recomendado en entornos regulados.
- Modelos privados — Ollama, LM Studio o cualquier endpoint compatible con OpenAI (vLLM…) alojado en tus instalaciones o en tu nube privada. Los prompts y las respuestas nunca salen de tu perímetro.
- Sin pool compartido silencioso — si una organización usa un modelo compartido, es una decisión explícita con control de acceso.
Postura de ingeniería
Nuestro estándar es la precisión: robustez máxima, observabilidad total, determinismo, anti-alucinación, anti-regresión, pruebas en cada esquina.
Concretamente, en cada compromiso de arquitectura / código / prompt:
| Decisión | Decisión esperada | Por qué |
|---|---|---|
| Latencia × 2 vs. razonamiento abreviado | × 2 | La precisión perdida se paga con la confianza del usuario |
| Observabilidad de grano fino vs. solo logs esenciales | Grano fino | Sin visibilidad, la depuración es ciega |
| Atajo que degrada un comportamiento | Rechazo | El riesgo de comportamiento se mide en incidentes de clientes |
Mantra: «Si alguien encuentra un bug, significa que no pusimos suficientes salvaguardas, no que pusimos demasiadas.»