La IA invisible está superando los inventarios de red empresariales

KnowBe4 ha puesto bajo nueva presión una vieja premisa de seguridad: un inventario aprobado ya no demuestra que se conozcan todos los activos activos. El artículo de Google News destaca servicios de IA, dispositivos ocultos y otros activos que los registros convencionales pueden pasar por alto. Esa combinación convierte una debilidad administrativa en un problema de seguridad activo.

El conflicto importante no es entre un proveedor de seguridad y otro. Es entre registros estáticos y evidencia continua. Las bases de datos de compras describen lo que una organización cree poseer, mientras que la telemetría de red, endpoints, identidades y navegadores revela lo que las personas realmente usan.

Esa brecha se ha ampliado a medida que las funciones de IA se extienden por el software, las extensiones de navegador, las interfaces de programación de aplicaciones y las suites de productividad existentes. Un servicio puede no llegar nunca como un producto adquirido por separado. Puede aparecer mediante una actualización, una cuenta personal, una clave API o un dispositivo propiedad de un empleado.

Por tanto, el argumento de KnowBe4 va más allá de la gestión rutinaria de activos. Los equipos de seguridad ahora deben descubrir el comportamiento del software, el movimiento de datos, las identidades y los servicios externos junto con el hardware físico. También deben hacerlo sin tratar cada conexión inusual como maliciosa.

El artículo de Google News expone un fallo de inventario más amplio

El cambio central es sencillo: los inventarios de seguridad deben describir la actividad observada, no solo la propiedad aprobada.

El artículo de Google News presenta el problema mediante tres clases de activos. Las herramientas de IA representan servicios externos y software integrado. Los dispositivos ocultos representan hardware que eludió el proceso normal de incorporación. Los activos desconocidos abarcan todo lo que sigue siendo visible en la telemetría, pero está ausente de los registros autorizados.

Estas clases se superponen, pero generan preguntas diferentes. Un portátil personal podría acceder a un servicio de IA aprobado mediante un navegador no gestionado. Un portátil aprobado podría utilizar un modelo no aprobado mediante una API. Una plataforma de productividad autorizada podría activar una nueva función de IA sin un evento de compra independiente.

Un inventario tradicional puede registrar el portátil y la suite de productividad, pero no detectar el comportamiento arriesgado. También podría registrar a un proveedor de IA sin mostrar qué empleados lo utilizan. Ninguno de los dos registros explica qué datos cruzan el límite.

Por ello, una lista de dispositivos por sí sola no puede respaldar las decisiones de riesgo modernas. Los equipos de seguridad necesitan un mapa de relaciones que conecte usuarios, endpoints, aplicaciones, identidades, datos y destinos. Cada observación requiere contexto antes de que sea procesable.

El problema también va más allá de la IA generativa. Cámaras, impresoras, equipos de laboratorio, controles de edificios, máquinas virtuales, contenedores y recursos temporales en la nube pueden eludir los registros manuales. Algunos carecen de agentes de gestión estándar. Otros aparecen brevemente y desaparecen antes de la siguiente revisión programada.

NIST formalizó este alcance más amplio en CSF 2.0. Sus resultados de gestión de activos abarcan hardware, software, sistemas, servicios, proveedores, datos y flujos de red. El marco también trata la identificación como una gestión continua del riesgo, no como un ejercicio contable anual.

Esta distinción importa porque desconocido no significa hostil. Un dispositivo recién observado podría ser un reemplazo autorizado que espera documentación. Un dominio extraño podría pertenecer al sistema de distribución de contenido de un proveedor aprobado. Un endpoint relacionado con IA podría admitir una función que los empleados nunca activaron conscientemente.

Por tanto, el descubrimiento debería crear una cola para su clasificación. No debería activar automáticamente sanciones ni aislamiento. Los equipos necesitan suficiente evidencia para determinar la propiedad, el propósito, la sensibilidad y la importancia para el negocio.

El titular de KnowBe4 funciona porque condensa estos casos en una pregunta incómoda: ¿pueden los defensores proteger activos que no pueden identificar? La respuesta depende menos de comprar otro escáner que de reconciliar varias visiones incompletas.

Shadow AI presiona a los equipos de seguridad desde ambas direcciones

Los líderes de seguridad enfrentan presión para revelar el uso no autorizado de IA sin bloquear trabajo útil ni crear una vigilancia excesiva de los empleados.

Shadow AI se refiere a servicios o funciones de IA utilizados fuera del proceso tecnológico aprobado por una organización. El término abarca más que empleados que visitan chatbots públicos. También incluye cuentas API personales, asistentes de programación, extensiones de navegador, funciones integradas y modelos que se ejecutan en hardware local.

Cada vía deja evidencias distintas. El acceso desde el navegador puede aparecer en registros web o de nombres de dominio. La actividad de API podría aparecer en registros de nube, repositorios o gestión de secretos. Los modelos locales pueden no producir ninguna conexión externa después de descargar sus archivos.

Esta fragmentación sitúa a los equipos de seguridad entre dos exigencias. Los directivos quieren un inventario fiable de IA porque la información confidencial puede entrar en sistemas externos. Los empleados quieren acceder a herramientas que les ayuden a investigar, redactar, programar, analizar y comunicarse.

Un bloqueo general ofrece una política clara, pero poca visibilidad operativa. Las personas pueden cambiar a dispositivos personales, conexiones móviles o servicios menos conocidos. La organización pierde entonces la oportunidad de observar el uso, orientar el comportamiento u ofrecer una alternativa más segura.

El acceso sin restricciones crea el problema opuesto. Los trabajadores pueden enviar información de clientes, contratos, código fuente, notas de reuniones o estrategia interna a servicios con reglas de retención desconocidas. Incluso un proveedor reputado puede ser inadecuado para una clase de datos determinada.

La guía de Microsoft sobre descubrimiento de aplicaciones de IA ilustra el giro hacia controles a nivel de comportamiento. Describe visibilidad sobre visitas, cargas, contenido pegado y otras interacciones de riesgo. Es una tarea distinta de comprobar si una aplicación aparece en una lista de compras.

La identidad añade otra capa. Una cuenta corporativa y una cuenta personal pueden llegar al mismo servicio a través del mismo endpoint. La monitorización a nivel de dominio puede identificar el destino, pero no el contrato aplicable, la configuración de retención ni la autorización del usuario.

La IA integrada complica aún más la clasificación. Una aplicación conocida puede añadir resumen, transcripción, predicción o generación de contenido mediante una actualización rutinaria. El producto subyacente sigue aprobado, mientras cambia su comportamiento de procesamiento de datos.

Por ello, los equipos de seguridad se ven presionados a mantener dos inventarios relacionados. El primero cubre los activos y servicios técnicos. El segundo cubre los casos de uso aprobados, las clases de datos, las identidades, los propietarios y los requisitos de control.

Ese segundo inventario no puede pertenecer solo a seguridad. Compras conoce los contratos. El área jurídica entiende las condiciones de uso. Los equipos de privacidad evalúan el tratamiento de datos. Los líderes de departamento saben por qué los empleados necesitan una herramienta. Los responsables de plataforma entienden la configuración y el registro.

La respuesta obligada es tanto organizativa como técnica. Seguridad debe construir un proceso repetible que convierta los descubrimientos en decisiones de propiedad. De lo contrario, los sistemas de detección producen alertas sin crear gobernanza.

Los empleados también necesitan una vía útil para informar. Un trabajador que descubre una función de IA útil debería poder solicitar una revisión sin esperar un rechazo automático. Ese proceso revela la demanda antes de que se traslade completamente fuera de los canales gestionados.

La presión persistirá porque la adopción de IA cambia más rápido que los ciclos de revisión anuales. Un inventario trimestral aún puede pasar por alto un servicio que acumuló miles de interacciones internas en cuestión de días. El descubrimiento continuo debe alimentar un proceso más rápido de aprobación y remediación.

La evidencia continua está sustituyendo a la lista estática de activos

El enfoque ganador combina varias señales imperfectas y luego mide las discrepancias entre ellas.

Ningún sensor único puede identificar todos los activos. El escaneo activo sondea sistemas accesibles, pero puede interrumpir equipos operativos sensibles. La monitorización pasiva observa el tráfico de forma segura, pero los dispositivos silenciosos pueden seguir siendo invisibles. Los agentes de endpoint ofrecen detalle, pero el hardware no gestionado carece de esos agentes.

Un programa de descubrimiento fiable trata cada fuente como evidencia parcial. Los registros de red muestran conexiones. Los sistemas de identidad muestran cuentas y autenticación. Las plataformas de endpoint muestran aplicaciones instaladas, procesos, extensiones y archivos locales. Los planos de control en la nube muestran recursos y relaciones de servicio.

Las bases de datos de compras y configuración siguen siendo importantes. Aportan contexto sobre propiedad, contratos, ciclo de vida y negocio. Su debilidad no es que sean inútiles. Su debilidad es que a menudo describen la intención en lugar del comportamiento actual.

El primer paso práctico es definir expectativas autorizadas. Los equipos necesitan listas de dispositivos, servicios, identidades, herramientas de IA, clases de datos y rutas de red aprobados. Estas listas forman una línea base, pero nunca deberían convertirse en la única versión de la realidad.

El segundo paso es recopilar observaciones de forma continua. Los registros DHCP y de resolución de direcciones pueden revelar hardware conectado. Los registros de nombres de dominio y proxies pueden revelar servicios externos. Los registros de autenticación pueden vincular la actividad con identidades. Los datos de endpoint pueden identificar procesos que iniciaron tráfico.

Los entornos de nube requieren sus propias vías de descubrimiento. Los recursos pueden aparecer mediante automatización y desaparecer cuando termina una carga de trabajo. Los contenedores, las funciones sin servidor, las bases de datos gestionadas y los entornos de desarrollo temporales pueden no parecerse a dispositivos tradicionales.

El uso de IA añade evidencia en la capa de aplicación. Los equipos pueden buscar categorías de servicios conocidas, extensiones de navegador, concesiones OAuth, claves API relacionadas con modelos y transferencias inusuales hacia destinos externos. También pueden revisar qué productos aprobados añadieron recientemente funciones de IA.

El tercer paso es la reconciliación. Cada objeto observado debería cotejarse con un registro esperado. Cada registro esperado debería contar con evidencia reciente que demuestre que todavía existe. La discrepancia se convierte en la cola de trabajo.

Esa cola necesita categorías claras. Un activo puede estar autorizado y documentado, autorizado pero no documentado, no autorizado pero benigno, ser sospechoso o ya no estar presente. Desconocido debería ser una clasificación temporal, no un área de retención permanente.

La priorización debería seguir la exposición y las consecuencias. Una puerta de enlace desconocida expuesta a Internet merece una revisión más rápida que un dispositivo de prueba aislado. Un servicio que recibe datos regulados requiere más atención que uno que procesa texto de marketing público.

La tecnología operativa exige cautela adicional. Estos sistemas suelen tener ciclos de vida largos, protocolos especializados y tolerancia limitada al escaneo activo. La guía sobre inventario de OT, elaborada por varias agencias, recomienda combinar documentación, inspección física e información derivada de la red.

La guía también identifica atributos útiles, entre ellos el rol del dispositivo, nombre de host, dirección de red, fabricante, modelo, sistema operativo, ubicación, protocolos, puertos, servicios y cuentas de usuario. Estos atributos ayudan a convertir una dirección observada en una decisión de riesgo.

Este mecanismo cambia la forma de medir el éxito. Un inventario amplio no es automáticamente un buen inventario. Un programa útil mide cobertura, actualidad, tiempo de reconciliación, propiedad y antigüedad de los elementos desconocidos sin resolver.

También debería rastrear con qué frecuencia los activos conocidos pasan a ser desconocidos tras los cambios. Esa métrica revela fallos en los procesos de incorporación, desvinculación, compras y configuración. A continuación, el descubrimiento puede mejorar los sistemas que generaron esa brecha.

El resultado no es una visibilidad perfecta. Es un proceso defendible que detecta cambios, registra la incertidumbre y asigna responsabilidades. Eso es más valioso que una hoja de cálculo impecable cuya exactitud nadie puede demostrar.

Las herramientas de IA y los dispositivos ocultos dejan pistas diferentes

Los activos desconocidos se vuelven gestionables cuando los equipos investigan sus señales según el tipo de activo.

Un dispositivo físico oculto suele dejar evidencias en la capa de red. Solicita una dirección, resuelve nombres, anuncia servicios, se comunica con pares o contacta un destino externo. A veces es posible inferir su fabricante a partir de su dirección de hardware, aunque esa pista no es concluyente.

El equipo puede entonces plantear preguntas concretas. ¿Qué segmento de red lo detectó? ¿Cuándo apareció por primera vez? ¿Regresa con cierta frecuencia? ¿Qué protocolos utiliza? ¿Su tráfico se parece al de una impresora, cámara, teléfono, servidor o controlador?

Los controles de acceso a la red pueden exigir autenticación o ubicar dispositivos desconocidos en segmentos restringidos. Sin embargo, el aislamiento debe tener en cuenta el impacto operativo. Un dispositivo médico, de fabricación o de control de edificios desconocido puede respaldar funciones esenciales pese a estar mal documentado.

Un activo desconocido en la nube presenta otro patrón. Puede contar con una cuenta, etiqueta de propietario, plantilla de despliegue o identidad de servicio. Los investigadores deberían vincular su evento de creación con un usuario, canalización de automatización, ticket, repositorio o proyecto.

Un servicio de IA oculto puede ser más difícil de clasificar porque el destino puede ser visible mientras el caso de uso sigue siendo incierto. Ver el dominio de un proveedor de modelos no indica si un usuario envió texto público o código fuente confidencial.

El contexto del navegador y del endpoint ayuda a cerrar esa brecha. Un navegador gestionado puede distinguir visitas, cargas, contenido pegado, descargas y tipos de cuenta. Los controles de endpoint pueden identificar la aplicación de origen y aplicar reglas según la sensibilidad de la información.

El uso basado en API requiere pruebas distintas. Los equipos de seguridad deberían examinar almacenes de secretos, repositorios de código fuente, sistemas de integración continua, puertas de enlace en la nube, registros de gastos y llamadas salientes a servicios. Las claves personales pueden eludir las cuentas gestionadas de forma centralizada y los límites de uso.

Las autorizaciones OAuth también merecen atención. OAuth permite que un servicio acceda a otro en nombre de un usuario. Un asistente de IA con acceso al correo, calendario, unidad o repositorio puede convertirse en una relación de activos significativa incluso sin un dispositivo nuevo.

Los modelos locales invierten el problema de visibilidad. Su actividad de inferencia puede permanecer en un endpoint, mientras que las descargas de modelos y las herramientas de apoyo generan eventos observables. El crecimiento del almacenamiento, la instalación de paquetes, la ejecución de procesos y el uso de procesadores gráficos pueden aportar contexto útil.

Las funciones integradas requieren revisión del proveedor. Los equipos deberían supervisar las notas de versión, los ajustes administrativos, los subprocesadores y los cambios contractuales de las aplicaciones aprobadas. Un proveedor conocido puede introducir una nueva ruta de datos sin cambiar el nombre familiar de su producto.

Los trabajadores del conocimiento también plantean un desafío de documentación. Pueden combinar varias herramientas durante una misma tarea, trasladando contenido entre un grabador de reuniones, chatbot, editor de documentos y plataforma de proyectos. Cada herramienta puede estar aprobada mientras que el flujo combinado infringe la política.

Mantener una clara base de conocimientos de IA puede ayudar a los equipos a documentar flujos de trabajo aprobados, propietarios, evidencias y límites de datos. La documentación debe respaldar la investigación, no sustituir la observación técnica.

El proceso de clasificación debería terminar con una acción. Los activos aprobados entran en inventarios gestionados. Los servicios innecesarios pierden acceso. Las herramientas mal configuradas reciben ajustes más seguros. Los sistemas sospechosos pasan a la respuesta ante incidentes. Los casos poco claros mantienen acceso restringido hasta que aparezca un propietario.

Este enfoque evita tratar todos los elementos desconocidos por igual. También reconoce que el descubrimiento de activos no está completo cuando un escáner genera un nombre. La organización debe comprender el propósito, el control y la exposición de datos.

Una mayor visibilidad puede generar sus propios riesgos de seguridad y privacidad

El descubrimiento continuo se vuelve contraproducente cuando la recopilación excede un propósito de seguridad definido.

La objeción más sólida a la supervisión amplia se refiere a la privacidad. Los registros de navegador, endpoint, identidad y red pueden revelar el comportamiento de los empleados con considerable detalle. Combinar esos registros aumenta el valor investigativo, pero también incrementa el potencial de uso indebido.

Las organizaciones deberían definir qué recopilan, por qué lo recopilan, quién puede acceder a ello y durante cuánto tiempo lo conservan. Un programa de IA en la sombra debería centrarse en eventos relevantes para la seguridad. No debería convertirse en un sistema general para clasificar la actividad de los empleados.

Los dispositivos personales crean un límite especialmente difícil. Una empresa puede controlar el acceso a datos corporativos sin reclamar visibilidad sobre todo el dispositivo de un empleado. Las aplicaciones gestionadas, los espacios de trabajo protegidos y el acceso condicional pueden preservar esa separación.

Los falsos positivos crean otro riesgo. La infraestructura compartida, las redes de distribución de contenido, las integraciones de proveedores y los servicios en segundo plano pueden hacer que el tráfico normal parezca desconocido. El bloqueo automático basado en un dominio o una etiqueta puede interrumpir el trabajo legítimo.

Las bases de datos de clasificación también envejecen rápidamente. Aparecen nuevos servicios de IA, los proveedores renombran productos y las plataformas existentes añaden funciones basadas en modelos. Las reglas de detección que dependen de listas estáticas de proveedores pasarán por alto servicios nuevos y clasificarán erróneamente los antiguos.

El cifrado limita la inspección de red. Una puerta de enlace a menudo puede ver el destino y los metadatos de conexión, pero no siempre puede determinar qué envió un usuario. Descifrar el tráfico aumenta la visibilidad, pero genera preocupaciones de privacidad, certificados, rendimiento y operación.

La supervisión de endpoints cubre algunas brechas, aunque introduce problemas de cobertura. Contratistas, sistemas no gestionados, dispositivos móviles y equipos especializados pueden carecer de agentes. Los equipos de seguridad deberían informar de esos puntos ciegos en lugar de presentar una cobertura parcial como certeza.

También existe un riesgo de gobernanza al equiparar descubrimiento con control. Encontrar un servicio de IA no explica si su uso era necesario, aprobado de manera informal o cubierto por un acuerdo existente. La evidencia técnica necesita un responsable de negocio que rinda cuentas.

Por lo tanto, el planteamiento de KnowBe4 debería considerarse una advertencia sobre visibilidad, no una prueba de que todo activo no identificado sea peligroso. La fuente proporcionada no establece una brecha medida, una tasa de detección universal ni un único producto que resuelva el problema.

El marco de NIST aporta una restricción importante. Pide a las organizaciones priorizar los activos según clasificación, criticidad, recursos e impacto en la misión. Eso disuade a los equipos de dedicar el mismo esfuerzo a cada anomalía.

Un programa maduro también mide las limitaciones de los sensores. Cada informe debería indicar qué redes, endpoints, identidades, cuentas en la nube y usuarios remotos estaban cubiertos. Debería distinguir la ausencia observada de la ausencia real.

Los equipos de seguridad pueden poner a prueba sus propias afirmaciones mediante ejercicios controlados. Pueden introducir dispositivos de prueba autorizados, recursos temporales en la nube, extensiones de navegador y llamadas a API de IA. El objetivo es medir qué señales detectan cada caso y con qué rapidez los analistas lo clasifican.

Esas pruebas deberían incluir condiciones de fallo. ¿Qué ocurre cuando un dispositivo permanece silencioso? ¿Puede el tráfico de API personal eludir una puerta de enlace gestionada? ¿Una función de IA integrada aparece como un servicio independiente? ¿Puede el equipo identificar al propietario de sus datos?

Las respuestas variarán entre entornos. Esa variación es precisamente la razón por la que las organizaciones deberían resistirse a afirmar que tienen visibilidad completa. El objetivo defendible es una cobertura medible, puntos ciegos conocidos y períodos de incertidumbre cada vez más breves.

Tres señales mostrarán si el descubrimiento de red se está poniendo al día

La próxima prueba es si las organizaciones pueden convertir más telemetría en decisiones más rápidas y seguras.

La primera señal es la velocidad de conciliación. Los equipos deberían medir el intervalo entre la primera observación y la clasificación. Un intervalo más corto indica que los procesos de descubrimiento, propiedad y respuesta están funcionando conjuntamente.

Esa métrica debería separarse por clase de activo. Un dispositivo físico, recurso en la nube, aplicación SaaS e integración de API de IA requieren evidencias diferentes. Combinarlos en un solo promedio puede ocultar retrasos graves.

Si los tiempos de conciliación bajan mientras los falsos positivos se mantienen controlados, el modelo de evidencia continua gana respaldo. Si las colas crecen más rápido de lo que los analistas pueden resolverlas, los sensores adicionales están produciendo ruido en lugar de visibilidad útil.

La segunda señal es la cobertura de la IA integrada y basada en API. Muchos controles empiezan por categorías de sitios web porque el tráfico del navegador es más fácil de identificar. Eso deja fuera las claves personales, los flujos de trabajo de desarrolladores, los modelos locales y las funciones de IA dentro de plataformas aprobadas.

Las organizaciones deberían comparar los descubrimientos de los registros de red con los hallazgos de endpoints, autorizaciones de identidad, sistemas en la nube, repositorios y revisiones de proveedores. Las grandes discrepancias revelan dónde la arquitectura de supervisión sigue incompleta.

Una cobertura más amplia reforzaría la advertencia subyacente de KnowBe4 y la respuesta propuesta aquí. La dependencia continua de listas de dominios web debilitaría las afirmaciones de que las empresas comprenden su exposición a la IA.

La tercera señal es si la gobernanza se vuelve más rápida sin recurrir por defecto al bloqueo universal. Los equipos de seguridad necesitan evidencias de que los servicios útiles pueden pasar de desconocidos a revisados y aprobados. También necesitan pruebas de que los usos riesgosos pueden limitarse por identidad, clase de datos o función.

Un proceso de aprobación saludable debería contar con propietarios designados, requisitos de evidencia definidos y plazos de decisión claros. Debería producir alternativas más seguras cuando un servicio solicitado no puede cumplir la política. El silencio o una revisión indefinida anima a los empleados a sortear los controles.

Observe cómo los proveedores exponen los ajustes administrativos, eventos de auditoría, destinos de modelos y opciones de retención de datos. Una mejor telemetría de producto facilitará la gobernanza de la IA integrada. Los registros limitados dejarán a los clientes dependientes de pistas indirectas de red.

La lección más amplia de esta historia de Google News no es que todo activo invisible sea malicioso. Es que cada activo sin resolver representa una pregunta sin respuesta sobre propiedad, acceso, datos y responsabilidad.

Los líderes de seguridad deberían plantear una pregunta práctica este trimestre: ¿cuánto tiempo puede operar un dispositivo o servicio de IA no registrado antes de que alguien le asigne un propietario? Después, deberían poner a prueba la respuesta con ejemplos controlados.

Si el resultado se mide en semanas, la organización sigue teniendo un problema de inventario estático. Si se mide en horas, con evidencias documentadas y controles proporcionales, el descubrimiento se está convirtiendo en una capacidad operativa de seguridad.

El siguiente paso es claro. Seleccione un segmento de red, un entorno de nube y un flujo de trabajo de empleados de uso intensivo. Concilie los registros esperados con la actividad observada, clasifique cada discrepancia y registre los puntos ciegos. Ese ejercicio revelará más que otra hoja de cálculo de inventario y mostrará si la organización puede realmente desenmascarar aquello que sus controles existentes no pueden ver.