1. Alcance
Esta página describe el sitio público y la demo. El gestor autenticado opera con los mismos controles base y con controles adicionales por organización (roles, auditoría y expediente clínico).
2. Aislamiento y control de acceso
- Cada consulta del gestor filtra los datos por organización: una clínica no puede ver expedientes de otra, ni siquiera por error de folio.
- Control de acceso por rol (RBAC): el personal de recepción no tiene acceso a notas clínicas, imágenes ni expedientes confidenciales.
- La sesión viaja en cookie segura y la API valida el token en cada solicitud; el inicio de sesión con Google u otros proveedores se apoya en Clerk.
3. Navegador y transporte
- HTTPS/TLS en todas las conexiones.
- Política de seguridad de contenido (CSP) estricta:
default-src 'none',object-src 'none', scripts con nonce en producción y transporte forzado a HTTPS. frame-ancestors 'self': nuestro contenido no puede embeberse en sitios de terceros (anti-clickjacking).- Las violaciones de CSP se reportan a un endpoint propio para detectarlas y corregirlas.
4. Auditoría
El gestor registra una bitácora de acciones (quién hizo qué y cuándo) sobre pacientes, agenda, finanzas y configuración. Es la base de trazabilidad que exige un expediente clínico serio.
5. IA y datos clínicos (PHI)
- Por defecto, la nota clínica no se envía a ningún proveedor de IA.
- Si se activa IA en la nube, el texto pasa por un scrub determinista de PHI (correo, CURP/RFC, teléfonos, fechas, folios) y el envío se bloquea si queda PHI residual sin consentimiento de la organización.
- Con claves propias (BYOK), tu clínica controla la cuenta del proveedor.
Detalle completo de niveles en Privacidad de IA.
6. Datos de la demo
Los datos clínicos de la demo son ficticios. No cargues información de salud identificable en el entorno de demostración.
7. Lo que NO tenemos
- Sin TEE (enclaves) ni cifrado de extremo a extremo de inferencia.
- Sin certificación formal vigente: NOM-024, HIPAA, ISO 27001 o SOC 2 no están acreditadas ante ninguna autoridad.
- En fase demo no ofrecemos SLA ni un plan de continuidad de negocio formal; dependemos de las capacidades de la infraestructura base.
- Sin programa de bug bounty.
8. Reporte de vulnerabilidades
Si encuentras una vulnerabilidad, escríbenos a poncepretelin@gmail.com con el asunto «[SECURITY]». Buscamos responder en un plazo razonable. No realices pruebas destructivas, denegación de servicio ni accesos a datos de terceros.
9. Sub-encargados
Nos apoyamos en proveedores de infraestructura e identidad: Vercel (sitio web), Railway (API y base de datos) y Clerk (autenticación). Si tu organización activa IA en la nube, aplican además los avisos de los proveedores de modelo configurados (p. ej. Google, Groq, OpenAI, NVIDIA), siempre bajo scrub y consentimiento.
Para clínicas, las obligaciones y responsabilidades de cada parte se formalizan en el acuerdo de encargado de tratamiento (DPA).