Seguridad

Principios

La plataforma administra información de salud, así que el diseño parte de tres reglas: cada clínica ve solo lo suyo, cada persona ve solo lo que su rol necesita, y toda acción relevante queda registrada. Esta página describe lo que efectivamente está construido; lo que aún no lo está aparece más abajo, declarado como tal.

Los estados que ves aquí no están escritos a mano: se leen del mismo módulo que la plataforma usa para decidir si una clínica puede operar con datos de pacientes reales.

Acceso y autenticación

• Todo el tráfico viaja cifrado por HTTPS.
• Las contraseñas se almacenan con scrypt y una sal aleatoria distinta por usuario. Nunca se guardan ni se transmiten en texto plano, y no podemos verlas.
• La sesión se mantiene con un testigo firmado mediante HMAC-SHA256, en una cookie HttpOnly, SameSite=Lax y Secure en producción, inaccesible desde JavaScript.
• Al cambiar o restablecer la contraseña, todas las sesiones abiertas en otros dispositivos quedan invalidadas de inmediato.
• Los intentos de inicio de sesión están limitados por dirección IP y por correo, para frenar ataques de fuerza bruta.
• Las solicitudes que modifican datos verifican el origen, como defensa contra peticiones falsificadas desde otros sitios.

Recuperación de contraseña

Quien pierde su contraseña la recupera desde /recuperar con un testigo de un solo uso, válido por 60 minutos. En la base únicamente se guarda el resultado de aplicarle SHA-256: ni leyendo la tabla se puede reconstruir el enlace. Al usarlo, el testigo se invalida y se cierran todas las sesiones abiertas de esa cuenta. La página responde exactamente lo mismo exista o no la cuenta —así no sirve para averiguar quién está registrado— y las solicitudes están limitadas por dirección IP y por correo.

Lo que todavía no hacemos: enviar ese enlace por correo. No hay proveedor de correo conectado, así que la plataforma no lo envía y en ninguna pantalla decimos que lo hizo: el enlace queda registrado y lo entrega el administrador de la clínica desde la propia plataforma. Cuando se contrate un proveedor, el envío se activa sin cambiar el resto del mecanismo.

Aislamiento entre clínicas

Cada registro de la base de datos —paciente, cita, presupuesto, pago, insumo— está asociado a una clínica, y todas las consultas filtran por ella. Una clínica no puede acceder a información de otra, ni siquiera conociendo un identificador ajeno: la verificación ocurre en el servidor, no en la interfaz.

Además de estar diseñado así, se comprueba: la plataforma revisa en vivo que ningún registro de las tablas de dominio quede apuntando a una clínica inexistente y que ninguna cuenta con rol de clínica esté sin clínica asignada. Si esa comprobación falla, la instancia no puede declararse productiva.

Permisos por rol

El acceso se rige por mínimo privilegio. Existen roles diferenciados: propietario, administrador, gerente, recepcionista, coordinador de tratamientos, odontólogo, asistente dental, encargado de cobranza, encargado de inventario y solo lectura. Cada uno tiene un conjunto explícito de capacidades.

Un ejemplo concreto: quien administra inventario no accede a fichas de pacientes; quien está en recepción gestiona la agenda y registra pagos, pero no ve los indicadores financieros del negocio. Los permisos se verifican en cada acción del servidor: ocultar un botón nunca es la única barrera.

Trazabilidad

La plataforma mantiene un registro de auditoría por clínica que deja constancia de quién hizo qué y cuándo, incluidas las consultas a fichas de pacientes y los cambios de estado de citas, presupuestos y pagos. Cada cita conserva además su propio historial de modificaciones.

Infraestructura y respaldos

La aplicación se ejecuta en un contenedor sobre infraestructura de nube, con la base de datos en un volumen persistente. La región depende de la configuración del despliegue y te la confirmamos por escrito si tu clínica lo requiere; no afirmamos alojamiento en Chile por defecto.

El respaldo es un proceso concreto, no una promesa comercial: una tarea programada genera la copia con la API de respaldo en línea de SQLite —no copiando el archivo, que con la base en uso produce copias inservibles—, abre la copia y le corre una verificación de integridad, aplica una retención de 14 días y deja registrado el resultado, correcto o fallido y con su motivo, en la propia base. Dentro de la plataforma, quien administra la configuración ve el último respaldo, el próximo esperado, la retención y el historial de errores, y puede lanzar uno en cualquier momento.

Contar con un respaldo verificado de menos de 48 horas es uno de los requisitos para que una clínica pueda declararse productiva. La exportación de tu información sigue disponible en cualquier momento, y si la continuidad operacional es crítica para tu clínica, conversemos el esquema de respaldo antes de contratar.

Controles previos a datos reales

Antes de que una clínica cargue fichas de pacientes reales, la plataforma evalúa un conjunto de controles y bloquea la habilitación mientras alguno falle. No es una recomendación escrita en un manual: es una comprobación en el servidor, cada vez.

• Recuperación de contraseña disponible. Una persona que pierde su contraseña debe poder recuperarla con un enlace de un solo uso, sin que nadie tenga que ver ni inventar su clave.
• Respaldo verificado reciente. Debe existir una copia de la base verificada con integrity_check en las últimas 48 horas.
• Aislamiento entre clínicas verificado. Ningún registro de dominio puede quedar fuera de una clínica existente.
• Secreto de sesión definido. AUREVIA_SECRET debe estar definido en el entorno, con al menos 16 caracteres.
• Instancia de producción. Los datos reales solo pueden vivir en una instancia desplegada con AUREVIA_DEMO=0 y en una clínica que no esté marcada como ficticia.

El resultado de cada control en una instancia concreta se muestra dentro de la plataforma, en Configuración → Seguridad, a quienes tienen permiso de configuración. No lo publicamos aquí a propósito: el estado de las defensas de un servidor no es información que convenga dejar abierta.

Sobre esta instancia: es la instancia de demostración. Opera con una clínica ficticia y, por diseño, no admite datos de pacientes reales. Las instancias de clínicas clientes se despliegan por separado, con su propio volumen y sin ningún dato de demostración.

Comunicaciones e integraciones

Mientras una clínica no conecte un canal externo (WhatsApp, correo o SMS), los mensajes que genera la plataforma se registran dentro de la ficha del paciente y no salen del sistema. La interfaz lo indica explícitamente: nunca decimos "enviado" cuando no hubo envío. Al conectar un canal, los envíos pasan a realizarse a través del proveedor que la clínica contrate a su nombre.

Las automatizaciones respetan siempre el consentimiento de contacto de cada paciente: si no está otorgado, la ejecución se omite y queda registrado el motivo.

Inteligencia artificial

Distinguimos con claridad tres cosas distintas: reglas automáticas (condiciones definidas sobre los datos), análisis estadístico (comparaciones y tendencias) y funciones con modelos de lenguaje. La mayor parte del asistente de gestión son reglas y análisis que se ejecutan localmente sobre la base de datos de la clínica, sin enviar información a terceros.

Las funciones que usan un modelo de lenguaje están desactivadas salvo que la clínica las habilite aportando su propia clave de API, y lo indicamos en la interfaz cuando corresponde.

Qué está en desarrollo

Para ser precisos, esto todavía no está implementado:

• Segundo factor de autenticación.
• Cifrado de campos sensibles en reposo, adicional al cifrado del volumen.
• Replicación del respaldo fuera del proveedor principal: hoy la copia queda donde apunte la variable BACKUP_DIR, y por defecto ese destino está en la misma infraestructura.
• Envío de mensajes a pacientes por un canal externo: sin proveedor conectado se registran en la ficha y no salen del sistema.

No contamos con certificaciones ISO 27001, SOC 2 ni equivalentes, y no declaramos cumplimientos normativos que no hayan sido auditados por un tercero.

Reportar un problema

Si encuentras una vulnerabilidad, escríbenos a aurevia@inteligenciaempresaliaraplicada.com con el detalle técnico. Agradecemos el reporte responsable: te confirmaremos la recepción y te informaremos cuando esté corregido. Te pedimos no acceder a datos de terceros ni degradar el servicio durante la prueba.

AUREVIA es una herramienta de apoyo administrativo, comercial y operacional. No reemplaza el criterio, diagnóstico ni responsabilidad del profesional odontológico.

Identificación de la sociedad

Estos son los datos con los que AUREVIA contrata. Puedes verificarlos por tu cuenta en el registro público antes de firmar.

Razón social

AUREVIA SpA

Nombre de fantasía

Inteligencia Empresarial Aplicada SpA

RUT

78.481.222-7

Tipo de sociedad

Sociedad por Acciones

Domicilio

Av. Pdte. Jorge Alessandri Rodríguez 450, of. J, Concepción 4090070, Región del Biobío, Chile

Constituida

2 de agosto de 2026

Representante legal

Lucas Luciano Orellana Garrido

Registro

Registro de Empresas y Sociedades del Ministerio de Economía

Verificar en www.registrodeempresasysociedades.cl↗Certificado de estatuto actualizado · CVE CRBu0rCb3c4w

Objeto social pertinente. Prestación de servicios tecnológicos y administrativos a empresas, clínicas, centros médicos y otros prestadores, sin realizar prestaciones de salud ni adoptar decisiones clínicas. Por eso la plataforma se limita al apoyo administrativo, comercial y operacional: ninguna funcionalidad emite diagnósticos ni sustituye la decisión del profesional tratante.