En la nube

Infraestructura administrada por nosotros sobre Google Cloud, en clúster privado sin exposición a Internet. Sin inversión inicial en servidores, parches de seguridad sin interrupción y disponibilidad 99,98% respaldada por SLA.

En sus servidores

Para instituciones con requisitos de residencia de datos o infraestructura ya consolidada. Usted mantiene el control físico del dato; nosotros, el mantenimiento del sistema.

Híbrido

Operación local con réplica en la nube para contingencia y analítica.

Depende del alcance y del tamaño de la institución. Un despliegue del núcleo asistencial toma habitualmente entre 1 y 2 meses; una implantación completa con integraciones y migración histórica, entre 1 y 3 meses.

Sí. Migramos pacientes, historia clínica, catálogos y datos administrativos desde sistemas propios o de terceros. El alcance exacto se define en el diagnóstico inicial.

Con cualquiera que soporte HL7, FHIR o DICOM, además de integraciones a medida vía API.

Contamos con un proceso de requerimientos evolutivos. Las funcionalidades de valor general se incorporan al producto; los desarrollos específicos se evalúan caso a caso.

En todos los tramos, en tránsito y en reposo. El tráfico externo entra por HTTPS con TLS 1.3; entre microservicios se cifra con mTLS estricto, con certificados de corta duración que se rotan automáticamente; y la aplicación conversa con la base de datos por un túnel cifrado sobre la interfaz local, de modo que ese tráfico nunca sale a la red sin cifrar. En reposo, los secretos del clúster se cifran con llaves gestionadas en Cloud KMS con respaldo de módulos de hardware (HSM), y los discos de base de datos con claves de cifrado administradas.

En la modalidad nube, la plataforma opera en regiones de Google Cloud seleccionadas con el cliente, con la base de datos y los respaldos residentes en la región acordada. Si la institución requiere residencia estricta, existe la opción on-premise.

La contraseña sola no abre nada: el segundo factor es obligatorio. Las claves se almacenan con Argon2, no en texto ni con hash débil, y cada sesión emite un token firmado de corta duración que puede revocarse de inmediato. Además, todo acceso a datos clínicos queda registrado, así que ante una credencial comprometida no solo se corta el acceso: el registro muestra exactamente qué se consultó y cuándo.

Por rol y con privilegio mínimo: cada perfil accede solo a lo que su función requiere. Las lecturas y escrituras sobre datos clínicos se registran en un log de auditoría inalterable —quién, qué y cuándo— exportado de forma inmutable para análisis forense. Esos registros no se pueden modificar ni borrar desde la plataforma, ni por un administrador.

Con un cortafuegos de aplicaciones web en el borde que filtra el OWASP Top 10 —inyección SQL, cross-site scripting, ejecución remota de código— antes de que el tráfico llegue a la red privada, sobre la red global de Google, capaz de absorber ataques de denegación de servicio en capas 3, 4 y 7. Y algo más básico: los servidores del clúster no tienen dirección IP pública. No hay un puerto expuesto a internet al que atacar.

Con análisis continuo de registros y tráfico mediante la detección de amenazas de Google Cloud, que identifica intentos de escape de contenedor, elevación no autorizada de privilegios y conexiones a direcciones de reputación dañada. Los eventos críticos generan alerta inmediata al equipo de operaciones de seguridad.

Los parches de los servidores se aplican de forma progresiva, nodo por nodo, sin interrumpir el servicio. Antes de eso, ninguna versión llega a producción sin atravesar el proceso de entrega: revisión de código obligatoria, detección de secretos filtrados, escaneo de vulnerabilidades conocidas (CVE) sobre cada imagen de contenedor y aprobación explícita registrada. Nadie despliega a mano en producción, y si una versión se comporta mal, la reversión a la anterior es automática.

La base de datos opera en alta disponibilidad, con réplicas y conmutación automática ante falla. Hay respaldos automáticos y recuperación a un punto en el tiempo, de manera que un borrado accidental o una corrupción se pueden revertir al instante anterior al problema. Los nodos con falla se reemplazan solos, y los entornos de desarrollo, pruebas y producción están aislados entre sí: un incidente en uno no se propaga a los demás.

Sí. La plataforma se audita contra las salvaguardas técnicas de ambos marcos —cifrado, control de acceso y trazabilidad— con una matriz que asocia cada control implementado a su artículo de GDPR y su sección de HIPAA. Los controles son verificables en auditoría bajo acuerdo de confidencialidad.

No. Toda salida de la IA es una propuesta. Una orden médica, una receta o una epicrisis solo existen cuando un profesional las firma. El sistema no ejecuta nada por su cuenta.

No. La información clínica de la institución no se usa para entrenar modelos propios ni de terceros, y el procesamiento ocurre dentro del perímetro contratado.

Cada afirmación generada enlaza al documento, examen o nota que la respalda. Si no hay fuente trazable en el expediente, la afirmación no se muestra. El profesional puede verificar el origen antes de firmar, sin salir de la ficha.

Qué se propuso, con qué información, quién la aceptó, editó o descartó, y cuándo. El registro es exportable para auditoría, así que siempre se puede reconstruir cómo se llegó a un texto que quedó en la ficha.

Sí. Cada capacidad se habilita por módulo y por rol, y se desactiva sin afectar al resto del sistema ni al trabajo ya registrado. Se puede partir con un servicio, medir, y recién entonces decidir si se extiende.

Sí. El reconocimiento trabaja sobre vocabulario clínico en español, incluidos los giros locales y las abreviaturas de uso habitual en el país.

Con un tablero de uso que muestra tasa de aceptación de las sugerencias, correcciones aplicadas y tiempo ahorrado por rol. El criterio es explícito: si el indicador no mejora, la capacidad se revisa o se retira.

Levantamos el caso con su equipo

Identificamos junto a los usuarios el proceso donde un agente aporta valor real y definimos qué debe hacer y qué no.

Desarrollamos el agente sobre su HIS

El agente opera con los datos y permisos de MasterKey, dentro del mismo perímetro de seguridad y con las mismas reglas de gobernanza.

Lo ponemos en producción y lo mantenemos

Monitoreo de uso y resultados, ajustes con su equipo y evolución del agente a medida que cambia el proceso.