Identidad centralizada en construcción: arquitectura SSO para escalar inteligencia artificial en construcción a varios clientes

Cuando una consultora despliega inteligencia artificial en construcción para varias promotoras al mismo tiempo, el mayor riesgo operativo no está en los modelos: está en cómo se gestiona el acceso a cada plataforma. En Vidra dábamos servicio a varias constructoras, cada una con su propia plataforma web a medida (licitaciones, precios, documentación técnica), y cada plataforma nació con su propio sistema de login. El resultado, tras el segundo o tercer cliente, fue previsible: contraseñas duplicadas, cuentas que nadie recordaba dar de baja y ningún registro fiable de quién había accedido a qué.

Ese problema no es exclusivo de la construcción, pero se agrava en un sector donde los usuarios cambian de empresa constructora a subcontrata con frecuencia, donde un jefe de obra puede necesitar acceso a tres plataformas de tres clientes distintos, y donde la trazabilidad de accesos a documentación de licitación tiene implicaciones contractuales reales. Multiplicar sistemas de login por cada plataforma no es solo ineficiente: es un pasivo de seguridad que crece con cada cliente nuevo.

La solución que construimos no fue un parche por plataforma, sino una capa de gobernanza compartida: un proveedor de identidad centralizado (SSO, Single Sign-On) y, sobre esa misma base, un panel interno de visibilidad de despliegues. Este artículo explica el razonamiento técnico detrás de ambos, los riesgos que evitan y las condiciones que hay que cumplir para que centralizar no cree un problema peor que el que resuelve.

El coste oculto de la identidad descentralizada en despliegues multi-cliente

Cuando cada plataforma gestiona sus propios usuarios y contraseñas, aparecen tres patrones de riesgo que rara vez se cuantifican hasta que causan un incidente.

El primero es la reutilización de contraseñas. Un usuario con acceso a tres plataformas de tres clientes distintos tiende a usar la misma contraseña en las tres, o variaciones triviales. Si una de esas plataformas sufre una brecha, las otras dos quedan expuestas sin que nadie lo sepa hasta que es tarde.

El segundo es la cuenta huérfana: un trabajador cambia de empresa o de proyecto y su acceso a la plataforma del cliente anterior sigue activo porque nadie centralizó ese proceso de baja. En documentación de licitaciones y precios, esto no es un detalle menor: es una cuenta activa con acceso a información comercial sensible que ya no debería tener nadie.

El tercero es la falta de trazabilidad. Sin un registro de auditoría unificado, responder a la pregunta “¿quién accedió a este documento y cuándo?” implica revisar logs distintos en sistemas distintos, con formatos distintos, si es que existen. En un contexto de disputa contractual o auditoría, esa respuesta puede tardar días en lugar de minutos.

Estos tres riesgos comparten una causa: la identidad se trata como un problema de cada aplicación, no como una capa de infraestructura propia. La solución técnica no es reforzar el login de cada plataforma; es sacarlo de cada plataforma.

Arquitectura del proveedor de identidad centralizado

El diseño que implementamos separa la gestión de identidad de la lógica de negocio de cada plataforma cliente. Cada plataforma deja de tener su propia tabla de usuarios y contraseñas; en su lugar, delega la autenticación a un servicio de identidad único que todas consumen mediante protocolos estándar de SSO.

Este servicio centraliza cinco funciones que antes estaban dispersas y duplicadas:

• Alta y baja de usuarios: un cambio en el estado de un usuario se propaga a todas las plataformas a las que tiene acceso, sin necesidad de replicarlo manualmente en cada una.
• Recuperación de contraseña: un único flujo, auditado y consistente, en lugar de una implementación distinta (y con distinto nivel de seguridad) por plataforma.
• Sesión recordada configurable: cada cliente define su propia política de expiración de sesión según su nivel de exposición (no es lo mismo un panel de precios internos que un portal de licitación pública).
• Registro de auditoría de accesos: cada inicio de sesión, cada intento fallido y cada cambio de permisos queda registrado en un único lugar, con formato consistente entre clientes.
• Roles distintos por cliente y por persona: un mismo usuario puede tener un rol de “revisor” en la plataforma del cliente A y de “administrador” en la del cliente B, sin que eso implique cuentas ni contraseñas separadas.

La analogía de obra es directa: es la diferencia entre que cada subcontrata gestione su propio control de acceso a la obra con su propia lista en papel, frente a un único control de acceso en la entrada que valida credenciales, registra horarios y aplica permisos distintos según el gremio y el proyecto. Un solo punto de control, con reglas distintas por caso.

El panel de despliegues: visibilidad como control de riesgo operativo

Sobre esa misma base de identidad construimos un segundo componente: un panel de control interno que muestra, en un único sitio, el estado de cada entorno (desarrollo y producción) de cada plataforma cliente, y permite lanzar despliegues sin acceso directo a los servidores.

Este panel resuelve un problema distinto pero conectado: el error humano al operar varios entornos de cliente en paralelo. Cuando un equipo gestiona cinco plataformas con dos entornos cada una, la superficie de error crece con cada acceso manual a servidor. Desplegar en el entorno equivocado, olvidar una variable de configuración específica de un cliente, o perder de vista qué versión corre en producción son errores comunes cuando la operación depende de memoria y disciplina individual en lugar de un sistema que impone estructura.

La visibilidad centralizada convierte esa operación en un proceso auditable: quién desplegó, cuándo, en qué entorno y con qué resultado queda registrado igual que los accesos de identidad. Este mismo principio (visibilidad operativa para reducir error humano en sistemas complejos) se aplica también a la operación de modelos de IA en producción, como detallamos en nuestro análisis de MLOps para visión artificial en obra y cómo detectar drift sin downtime.

Qué hay que resolver para que el SSO no sea un punto único de fallo

Centralizar identidad introduce una contrapartida que hay que gestionar explícitamente: si el proveedor de identidad cae, caen todas las plataformas que dependen de él. Esto no invalida el enfoque, pero exige tres decisiones de diseño que no son opcionales.

Riesgo introducido	Mitigación necesaria
Caída del servicio de identidad bloquea todos los clientes	Alta disponibilidad y monitorización dedicada del propio servicio de identidad, no compartida con la infraestructura de cada plataforma
Latencia añadida en cada inicio de sesión	Tokens de sesión con vida útil configurable para no depender de una validación en cada petición
Cambio en el proveedor de identidad afecta a todos los clientes a la vez	Despliegues por fases del propio servicio de identidad, con entorno de pruebas separado antes de producción
Concentración de datos sensibles de todos los clientes en un solo sistema	Aislamiento lógico estricto por cliente dentro del propio proveedor de identidad, con roles y auditoría separados

La condición de fondo es tratar el proveedor de identidad con el mismo rigor de ingeniería que cualquier sistema crítico de producción, no como un componente auxiliar. Es la pieza que, precisamente por resolver un riesgo, concentra otro nuevo si se construye sin esa disciplina.

Lo que esto significa para el sector

Para una consultora que despliega BIM e inteligencia artificial, modelos de predicción de costes construcción IA o sistemas de visión artificial en obra para varios clientes en paralelo, la arquitectura de identidad y despliegue no es un detalle de infraestructura: es la condición que permite escalar sin que cada cliente nuevo multiplique el esfuerzo operativo y el riesgo de seguridad.

Sin esta capa, cada plataforma nueva significa un sistema de login más que mantener, más contraseñas que rotar y más superficie de error humano en el despliegue. Con ella, el esfuerzo de incorporar un cliente se reduce a configurar roles y entornos sobre una base ya probada, algo que también aplica cuando la IA deja de ser una herramienta puntual y se convierte en infraestructura productiva de la empresa.

La gobernanza técnica, en este sentido, es tan parte de la propuesta de valor de una consultora de IA en construcción como los propios modelos predictivos o de visión. Un modelo con buen mAP o buen RMSE no protege a un cliente si la plataforma que lo sirve tiene contraseñas reutilizadas y cero trazabilidad de accesos.

Si tu organización está evaluando cómo desplegar varias plataformas a medida sin duplicar infraestructura de identidad ni perder visibilidad operativa, podemos ayudarte a diseñar esa capa antes de que el crecimiento la haga más costosa de resolver.