IA local: gobernanza antes de la compra de hardware
Benedikt Langer
10 min de lecturaCuatro desarrollos en dos semanas demuestran que la IA operada en local va mucho más ...
Leer artículo
5 Min. Lectura
Las cuentas de servicio, claves de API y agentes de IA superan a menudo a las cuentas humanas por un amplio margen. Muchas de estas accesos no son asignadas por nadie. Exactamente allí se abre la próxima brecha: fuera del endpoint endurecido.
Lo esencial en breve
- Las máquinas dominan el inventario de identidades. En entornos modernos, a menudo hay muchas identidades no humanas por cada identidad humana. Cada una de ellas tiene derechos, pero rara vez un propietario responsable.
- Accesos huérfanos son el verdadero riesgo. Las personas se desactivan al salir. Las cuentas de servicio y los tokens a menudo continúan funcionando durante años, con derechos completos y sin supervisión.
- La visibilidad precede al control. Quien no conoce el inventario no puede asegurarlo. El primer paso es una inventario honesta, no otra herramienta.
Relacionado:¿Qué control permanece tras el despliegue de agentes? / Kimi detiene suscripciones: 7 verificaciones para el CAPEX de IA
¿Qué son las identidades de máquinas? Las identidades de máquinas son accesos técnicos mediante los cuales los sistemas actúan. Incluyen cuentas de servicio, claves de API, tokens, certificados, bots y agentes de IA. Estas identidades autentifican sistemas entre sí, poseen derechos y crecen con cada integración. Sin propietario y sin ciclo de vida, a menudo permanecen activos después de que su propósito haya desaparecido.
Por qué la cifra de identidades de máquinas se descontrola
Cada migración a la nube, cada nuevo microservicio y cada automatización generan identidades. Una pipeline de despliegue necesita un token para lanzar código. Un servicio de monitorización necesita una clave para leer métricas. Una integración entre dos plataformas SaaS crea una cuenta técnica en segundo plano. Ninguno de estos elementos aparece en los procesos clásicos de RR.HH., porque detrás de estos accesos no hay un ser humano que sea onboarded o offboarded.
En muchas organizaciones, las identidades no humanas superan con creces a las humanas. Lo decisivo es menos la relación exacta que la dinámica de crecimiento. Las identidades humanas crecen de forma lineal con la plantilla. Las identidades de máquinas crecen con cada decisión arquitectónica, con cada herramienta del stack y, en la actualidad, con cada agente de IA que accede a los sistemas de forma autónoma. El volumen crece más rápido de lo que la mayoría de los programas de identidad pueden seguir.
El problema se agrava porque estas identidades están mal documentadas. Una clave de API se crea rápidamente para poner en marcha una integración. Termina en un archivo de configuración, un script o un gestor de secretos y rara vez se vuelve a tocar. Quien la creó, para qué sirve y si aún se necesita, suele desconocerse después de algunos cambios de personal.
Al salir, el reflejo de offboarding se activa. Las cuentas de máquinas a menudo siguen existiendo hasta que alguien las aborda.
Accesos huérfanos permanecen activos después del proyecto
Cuando una empleada abandona la empresa, entra en vigor un proceso establecido. Bloquear la cuenta, recuperar los equipos, retirar los permisos. En el caso de identidades de máquinas, ese reflejo casi no existe. Una cuenta de servicio, creada por un desarrollador que ya dejó la compañía para un proyecto, sigue activa. El token de una aplicación que se apagó nunca se revoca. La clave de prueba que logró introducirse por error en producción sigue vigente.
Estos accesos huérfanos resultan especialmente atractivos para los atacantes. Suelen estar dotados de amplios permisos, ya que el principio de privilegios mínimos se aplica con menos rigor a cuentas técnicas que a usuarios humanos. Rara vez se les supervisa, pues nadie espera que muestren conductas sospechosas. Además, eluden muchos mecanismos de protección diseñados para usuarios humanos. La autenticación de múltiples factores no sirve ante una clave API estática. Un token robado se comporta técnicamente como un token legítimo.
Credenciales comprometidas y secretos mal gestionados forman parte de los vectores de ataque recurrentes. Con frecuencia se encuentran claves y tokens en el código, en un repositorio o en un archivo de registro: más allá de la contraseña humana. Quien solo asegura la faceta humana protege solo una parte menor de la superficie de ataque.
Donde realmente reside el riesgo
La mayoría de las identidades en una pila moderna no son humanas. Exactamente esas cuentas permanecen sin supervisión durante el mayor tiempo, suelen contar con los permisos más amplios y eluden los mecanismos de protección diseñados para usuarios humanos. El endpoint está endurecido. La cuenta de servicio de 2021 no lo está.
Cuatro pasos para controlar el sprawl de identidad
El camino fuera del caos se aborda mediante una gestión estructurada del inventario. Un producto de seguridad adicional por sí solo no lo soluciona. Cuatro pasos forman un programa sólido.
Primero, descubrimiento e inventario. Antes de asegurar cualquier cosa, se necesita una visión general. ¿Qué cuentas de servicio, claves, tokens y bots existen, en qué sistemas, con qué permisos? Las plataformas en la nube, pipelines de CI/CD, gestores de secretos e integraciones SaaS son los lugares típicos. Una revisión manual inicial es mejor que esperar a la herramienta perfecta.
Segundo, asignar la propiedad. Cada identidad de máquina necesita un responsable humano. Una cuenta sin propietario es una cuenta que nadie desactivará, porque nadie se siente responsable. La asignación de la propiedad convierte un token anónimo en una decisión rastreable, que puede revisarse y revocarse.
Tercero, privilegio mínimo y rotación. Las cuentas técnicas a menudo reciben más permisos de los necesarios, porque es más rápido. Cada identidad debería tener solo los permisos que su tarea requiere. Los secretos estáticos e indefinidos deben reemplazarse por credenciales de acceso autogeneradas y rotativas. Una clave que se emite de nuevo cada pocas horas es un objetivo mucho más pequeño.
Cuarto, ciclo de vida y desprovisionamiento. Las identidades de máquina necesitan el mismo ciclo de vida que los humanos. Cuando se da de baja una aplicación, se finaliza un proyecto o se elimina una integración, el acceso asociado debe desaparecer automáticamente. Un análisis periódico revela cuentas que no muestran actividad desde hace meses. Estas “carta muertas” son los primeros candidatos para su revocación.
Agentes de IA multiplican el mismo error de ciclo de vida
La próxima ola proviene del propio departamento de innovación. Los agentes de IA autónomos, que ejecutan tareas de forma independiente, necesitan acceso a sistemas, datos y otros servicios. Cada uno de estos agentes es una nueva identidad de máquina, a menudo con amplios permisos para operar de forma flexible. A diferencia de un script rígido, un agente toma decisiones en tiempo de ejecución. Su comportamiento es más impredecible y, por tanto, más difícil de supervisar.
Quien no controle el desorden de identidades hoy, importará el problema con cada iniciativa de IA en una forma agravada. Un agente con permisos excesivos al que nadie le ha asignado un propietario es exactamente el tipo de acceso que, dentro de dos años, llamará la atención por estar huérfano. La disciplina que hoy se exige a las cuentas de servicio es la base para desplegar de manera segura agentes de IA.
El primer paso en los próximos 90 días
El inicio es poco espectacular y precisamente por eso resulta eficaz. Un inventario de las identidades no humanas en los entornos más críticos, empezando por la plataforma en la nube y las pipelines centrales. Cada identidad encontrada recibe tres datos: propósito, propietario y última actividad. Todo aquello sin un propósito claro o sin actividad en los últimos meses se añade a una lista de verificación. A partir de esa lista se lleva a cabo la primera acción de limpieza y, a partir de ella, se establece una regla para el futuro. No se crea un nuevo acceso técnico sin un propietario designado y sin una condición de caducidad definida. El número de identidades de máquinas seguirá aumentando. Si crecen de forma controlada o descontrolada depende de esta disciplina.
Preguntas frecuentes
¿Qué son las identidades no humanas o de máquinas?
Se refieren a todos los accesos detrás de los cuales no hay una persona: cuentas de servicio, claves API, tokens, certificados, bots y agentes de IA autónomos. Se autentican frente a sistemas y poseen permisos, pero rara vez se gestionan mediante los mismos procesos que las cuentas de usuarios humanos. En entornos actuales, suelen ser la mayoría en número.
¿Por qué los accesos huérfanos son tan peligrosos?
Porque siguen operando con privilegios completos aunque nadie tenga responsabilidad sobre ellos. La autenticación de múltiples factores no sirve ante una clave estática. Un token robado se comporta técnicamente como uno legítimo. Los atacantes aprovechan precisamente esas cuentas no supervisadas, ya que rara vez son vigiladas y suelen ofrecer amplios permisos.
¿Con qué comenzar si el inventario es inmanejable?
Con visibilidad antes que control. Una auditoría manual de los entornos más críticos, empezando por la plataforma en la nube y los pipelines centrales, supera la espera de una herramienta perfecta. Cada identidad recibe propósito, propietario y última actividad. Aquellas sin propósito o sin actividad se revisan y, si procede, se eliminan.
Más del medio MBF
mybusinessfuture
securitytoday
Fuente de la imagen: generada por IA (julio 2026)