La evaluación de un software HSE empresarial no termina cuando HSE confirma que la plataforma cubre sus procesos. Para TI, la pregunta es diferente: ¿puede incorporarse de forma segura y sostenible al ecosistema tecnológico de la compañía?
En organizaciones industriales, el software HSE puede gestionar información operacional, incidentes, cumplimiento, riesgos, usuarios internos y contratistas. Además, puede necesitar integrarse con identidad corporativa, ERP, RR. HH., herramientas de BI y otros sistemas.
Por eso, TI debería evaluar mucho más que funcionalidades. Este artículo propone un marco práctico para revisar arquitectura, seguridad, acceso, integraciones, continuidad, administración y soporte antes de aprobar una plataforma.
¿Qué es un software HSE empresarial?
Un software HSE empresarial es una plataforma digital de gestión de salud, seguridad y medioambiente diseñada para operar dentro de una organización con múltiples procesos, usuarios, estructuras, ubicaciones e integraciones tecnológicas.
El componente “empresarial” no debería entenderse únicamente como número de usuarios.
Implica que la plataforma pueda convivir con las políticas de identidad, seguridad, arquitectura, integración y gobierno de datos de la organización.
NIST, en su guía específica para servicios cloud, señala que los modelos SaaS tienen características particulares de control de acceso y que los mecanismos deben considerar roles, atributos, jerarquías y relaciones entre usuarios.
Por eso, la aprobación de TI debería comenzar con una pregunta: ¿cómo encaja esta plataforma en la arquitectura existente?
1. Arquitectura: entender qué se está contratando
Antes de revisar controles específicos, TI necesita conocer la arquitectura.
La evaluación debería identificar:
- modelo de servicio y componentes principales;
- infraestructura cloud utilizada;
- ubicación y tratamiento de los datos;
- separación entre ambientes;
- mecanismos de comunicación entre componentes;
- dependencias con servicios externos;
- modelo de actualización de la plataforma.
No es necesario que todas las compañías adopten exactamente la misma arquitectura. Lo importante es determinar si el modelo propuesto cumple con los estándares internos y los requisitos de riesgo de la empresa.
En el caso de ZYGHT, la información pública describe la solución como SaaS en la nube y señala que utiliza infraestructura Microsoft Azure. (ZYGHT)
Eso permite iniciar la conversación técnica, pero TI debería solicitar igualmente la documentación específica que corresponda a su proceso de evaluación.
2. Identidad y SSO: evitar crear otro sistema de usuarios aislado
Un software empresarial debería encajar con la estrategia corporativa de identidad.
TI debería comprobar:
¿La plataforma soporta SSO? ¿Qué protocolo utiliza? ¿Cómo se aprovisionan y deshabilitan usuarios? ¿Qué ocurre cuando una persona cambia de rol?
CISA destaca que SSO puede centralizar autenticación, facilitar el control de cuentas y simplificar auditoría y permisos, aunque también recomienda gestionar cuidadosamente los riesgos asociados al punto central de autenticación.
La pregunta no debería ser simplemente “¿tiene SSO?”, sino “¿cómo se integra con nuestro modelo de identidad y ciclo de vida de usuarios?”
ZYGHT declara públicamente integración con Active Directory / Single Sign-On. También señala integración mediante API y conectores con ERP, RR. HH. y herramientas de BI. (ZYGHT)
3. Roles y permisos: comprobar el principio de mínimo privilegio
HSE puede involucrar usuarios muy diferentes: administradores, profesionales HSE, supervisores, trabajadores, contratistas y ejecutivos.
No todos deberían necesariamente tener acceso a la misma información o funciones.
NIST recomienda considerar modelos como RBAC y ABAC y diseñar las autorizaciones teniendo en cuenta roles y jerarquías.
Durante una evaluación, TI debería comprobar:
- cómo se crean roles;
- qué permisos puede tener cada rol;
- si el acceso puede segmentarse por unidad o estructura;
- qué ocurre con usuarios externos;
- cómo se revoca el acceso;
- si existe registro de actividades relevantes.
Una buena prueba consiste en crear tres perfiles ficticios —administrador, supervisor y usuario operativo— y comprobar qué puede ver y modificar cada uno.
4. APIs e integraciones: evaluar el contrato técnico, no solo la existencia de una API
“Tenemos API” no es suficiente.
TI necesita saber qué recursos están disponibles, cómo se autentican las llamadas, qué límites existen, qué datos pueden intercambiarse y cómo se gestionan errores y versiones.
OWASP identifica entre los riesgos principales de seguridad de APIs problemas de autorización a nivel de objeto, autenticación, autorización de funciones, configuración e inventario de APIs.
Por eso conviene preguntar:
¿Qué endpoints existen? ¿Cómo se autentican? ¿Qué mecanismos de autorización aplican? ¿Hay versionado? ¿Cómo se documentan los cambios? ¿Existen ambientes de prueba?
La evaluación debería incluir al menos un caso de integración real.
Por ejemplo: sincronizar usuarios desde una fuente corporativa o intercambiar información con la plataforma de BI.
5. Seguridad de los datos: identificar qué información manejará el sistema
No toda la información HSE tiene el mismo nivel de sensibilidad.
La plataforma puede contener datos sobre trabajadores, incidentes, investigaciones, documentación contractual, permisos, riesgos y otros registros operacionales.
Antes de aprobarla, TI debería determinar:
- qué información se almacenará;
- qué usuarios accederán a ella;
- cómo se protege durante transmisión y almacenamiento;
- cómo se controla el acceso;
- qué mecanismos de registro y auditoría existen;
- qué procesos aplican cuando un usuario deja la organización.
El objetivo no es pedir una certificación genérica y cerrar la evaluación. La seguridad debe analizarse respecto del uso concreto que tendrá la aplicación.
NIST destaca que las aplicaciones SaaS requieren mecanismos específicos de control de acceso y que los modelos de autorización deben considerar las características del servicio cloud.
6. Disponibilidad y continuidad: qué ocurre cuando el sistema no está disponible
TI también debe revisar escenarios de interrupción.
Las preguntas relevantes son:
¿Cuál es el nivel de disponibilidad comprometido? ¿Cómo se gestionan incidentes? ¿Existe respaldo? ¿Qué ocurre ante una falla de infraestructura? ¿Cómo se recupera el servicio?
No existe una respuesta universal para todas las organizaciones. La exigencia debería basarse en la criticidad de los procesos que se ejecutarán en la plataforma.
También conviene distinguir entre disponibilidad del sistema y continuidad del trabajo en terreno.
En ZYGHT, la aplicación móvil permite registrar determinados procesos desde terreno sin conexión y sincronizar posteriormente la información al recuperar señal. (ZYGHT)
Para TI, esto abre una cuestión específica que debe probarse: qué operaciones pueden ejecutarse offline, qué datos quedan almacenados temporalmente y cómo se produce la sincronización.
7. Gestión de usuarios: revisar todo el ciclo de vida
Con cientos o miles de usuarios, administrar cuentas manualmente puede convertirse en una carga operativa.
TI debería analizar el ciclo completo:
alta → asignación de permisos → cambio de rol → suspensión → baja.
Esto adquiere importancia cuando la organización tiene contratistas o múltiples faenas.
La pregunta clave es qué parte del ciclo puede automatizarse mediante integración y qué parte requiere intervención manual.
ZYGHT declara integraciones con sistemas corporativos como Active Directory/SSO y RR. HH., además de soporte para organizaciones con operaciones complejas o distribuidas. (ZYGHT)
La capacidad debe validarse contra la estructura real de cada compañía.
8. Mobile y offline: evaluar el comportamiento fuera de la oficina
En software HSE empresarial existe un criterio que a veces queda fuera de las revisiones tradicionales de TI: la experiencia técnica en terreno.
Una aplicación HSE puede ser utilizada en lugares con conectividad intermitente, dispositivos compartidos y usuarios que no trabajan frente a un escritorio.
La evaluación debería comprobar:
- sistemas operativos compatibles;
- mecanismos de autenticación;
- almacenamiento temporal;
- comportamiento sin conexión;
- sincronización;
- manejo de conflictos;
- actualización de la aplicación;
- administración de dispositivos, cuando corresponda.
En ZYGHT, la app móvil está disponible para iOS y Android y permite registrar incidentes, inspecciones y permisos sin conexión. (ZYGHT)
La mejor práctica es probarlo en una condición que reproduzca el terreno real, no en una conexión Wi-Fi de oficina.
9. Reporting y disponibilidad de información
TI debería comprobar cómo la plataforma entrega información a otras capas del ecosistema.
Aquí entran preguntas de arquitectura de datos:
¿Puede extraerse información? ¿Qué formatos están disponibles? ¿Existe API? ¿Cómo se integra con BI? ¿Qué frecuencia de actualización tiene la información?
La página actual de Reportería BI de ZYGHT señala que los dashboards se actualizan diariamente y permiten analizar KPI, tendencias y desempeño HSE. (ZYGHT)
Su versión BI Premium permite dashboards avanzados, exportación y descarga de datos y una visión de cumplimiento y desviaciones desglosada por agrupadores, áreas y responsables. (ZYGHT)
Para una aprobación técnica, TI debería confirmar además qué mecanismos de extracción o integración necesita la organización y bajo qué condiciones.
10. Configuración y gobierno de cambios
Una plataforma HSE empresarial normalmente será configurada para reflejar procesos y estructuras específicas.
TI debería distinguir entre:
configuración estándar, parametrización avanzada y desarrollo personalizado.
La diferencia afecta mantenimiento, actualizaciones, dependencia del proveedor y costo total de propiedad.
Pregunte:
- ¿qué puede configurar el cliente?
- ¿qué requiere soporte?
- ¿qué requiere desarrollo?
- ¿cómo se prueban los cambios?
- ¿cómo se promueven entre ambientes?
- ¿cómo impactan las actualizaciones futuras?
La página de soluciones de ZYGHT señala que la plataforma funciona con parámetros predeterminados y puede adaptarse a las necesidades de cada organización mediante módulos y funcionalidades configurables. (ZYGHT)
11. Soporte y modelo operativo del proveedor
TI no solo evalúa tecnología. También evalúa al proveedor.
Debe conocer:
- canales y horarios de soporte;
- niveles de atención;
- responsables de escalamiento;
- gestión de incidentes;
- proceso de actualización;
- documentación técnica;
- acompañamiento durante implementación.
ZYGHT declara públicamente que su implementación contempla configuración, carga de datos y capacitación, y que los clientes cuentan con Customer Success Manager y soporte técnico continuo en español. (ZYGHT)
Estos elementos no sustituyen un SLA o contrato de servicio. Deben contrastarse con las condiciones comerciales y de seguridad aplicables al proyecto.
12. Escalabilidad: validar el futuro, no solo el piloto
Un piloto exitoso puede ocultar problemas que aparecen al incorporar más usuarios, faenas o procesos.
TI debería modelar al menos tres escenarios:
Piloto → despliegue corporativo → crecimiento.
La evaluación puede considerar número de usuarios, operaciones, contratistas, registros, integraciones y necesidades de reporting.
La página de demo de ZYGHT presenta una arquitectura modular que permite incorporar capacidades como gestión de riesgos, incidentes, requisitos legales, auditorías, planes de acción, permisos y reportería. (ZYGHT)
La clave es comprobar que ese crecimiento sea técnica y operacionalmente viable para la arquitectura específica de la organización.
¿Qué documentos debería solicitar TI al proveedor?
Antes de emitir una aprobación, es razonable solicitar un paquete técnico que permita responder las preguntas relevantes.
Por ejemplo:
| Área | Evidencia a solicitar |
| Arquitectura | Diagrama lógico y descripción de componentes |
| Seguridad | Controles, políticas y documentación aplicable |
| Identidad | Especificación SSO, roles y ciclo de vida |
| Integraciones | Documentación API y mecanismos de autenticación |
| Datos | Flujo, almacenamiento, retención y exportación |
| Continuidad | Esquema de respaldo, recuperación y disponibilidad |
| Mobile | Soporte de plataformas y comportamiento offline |
| Operación | Modelo de soporte y actualización |
| Escalabilidad | Límites, supuestos y arquitectura de crecimiento |
| Cumplimiento | Certificaciones o evidencias pertinentes al alcance |
No todos estos documentos serán necesariamente públicos. En una evaluación empresarial es normal que parte de la información se entregue bajo procesos de confidencialidad o durante el due diligence.
Pregunta clave: ¿qué debería probar TI en una demo técnica?
La respuesta no es “todo”.
TI debería elegir casos de prueba que representen riesgos reales de la implementación.
Una secuencia útil sería:
- Iniciar sesión con SSO.
- Crear usuarios con diferentes roles.
- Ejecutar un proceso HSE desde móvil.
- Repetirlo sin conexión.
- Recuperar conectividad y comprobar sincronización.
- Consultar el dato desde reporting.
- Ejecutar una llamada API de prueba.
- Verificar permisos sobre el mismo registro con dos perfiles diferentes.
Este enfoque permite transformar declaraciones comerciales en evidencia observable.
Cómo encaja ZYGHT en una evaluación tecnológica empresarial
ZYGHT se presenta como una plataforma SaaS para gestión HSE orientada a organizaciones con operaciones complejas o distribuidas. Su oferta pública combina procesos HSE —riesgos, incidentes, cumplimiento, controles, auditorías, planes de acción y otros— con capacidades de reportería e integración. (ZYGHT)
Desde la perspectiva de TI, hay varios puntos concretos para llevar al proceso de due diligence: infraestructura Microsoft Azure, integración con Active Directory/SSO y APIs, aplicaciones móviles iOS/Android, funcionamiento offline, integración con ERP/RR. HH./BI y un modelo de implementación y soporte declarado por el proveedor. (ZYGHT)
Eso puede posicionar a ZYGHT dentro de un proceso de evaluación empresarial, pero la recomendación sigue siendo la misma que para cualquier plataforma: comprobar las capacidades contra los requisitos técnicos, de seguridad y arquitectura de la compañía antes de aprobarla.
FAQ
¿Qué debe evaluar TI en un software HSE empresarial?
Debe evaluar arquitectura, seguridad, identidad, permisos, integraciones, APIs, continuidad, disponibilidad, gestión de usuarios, mobile/offline, datos, escalabilidad, soporte y compatibilidad con los estándares tecnológicos de la organización.
¿Por qué un software HSE necesita SSO?
SSO permite integrar la aplicación con el sistema corporativo de identidad y centralizar autenticación y administración de acceso. La implementación concreta debe evaluarse según la arquitectura de identidad y seguridad de cada empresa.
¿Qué debe revisar TI en las APIs de un software HSE?
Debe revisar autenticación, autorización, endpoints disponibles, documentación, versionado, límites, gestión de errores, monitoreo y controles de seguridad de las APIs.
¿Cómo evaluar la seguridad de un software HSE SaaS?
Debe revisarse cómo se protegen los datos, cómo se gestionan usuarios y permisos, cómo se registra el acceso, qué controles cloud aplica el proveedor y qué evidencias de seguridad puede entregar para el proceso de due diligence.
¿Qué debe probar TI antes de aprobar un software HSE?
Debe probar escenarios representativos de identidad, permisos, integraciones, uso móvil, funcionamiento offline, sincronización, disponibilidad de información y acceso a datos, además de revisar la documentación técnica y contractual correspondiente.
Una plataforma que se incorpore de forma segura
La aprobación de un software HSE empresarial no debería depender solo de que la plataforma “cumpla con los requerimientos de HSE”. TI necesita demostrar que puede incorporarse de forma segura, integrarse con el ecosistema existente y mantenerse administrable cuando aumenten usuarios, operaciones y procesos.
Antes de cerrar el proceso, convierta los principales requisitos técnicos en pruebas concretas y solicite evidencia documental para aquello que no pueda validarse durante la demo.
Para evaluar cómo ZYGHT responde a ese proceso, puede solicitar una demo y coordinar una revisión técnica con el equipo.
