La guía de seguridad con IA de Ivanti redujo horas, pero su skill de Claude inventó detalles
Ivanti reveló que su skill de análisis de parches basada en Claude inventó detalles, pese a reducir un flujo de trabajo recurrente de horas a minutos. El sistema de guía de seguridad con IA de Ivanti confundió ediciones de Microsoft Office e interpretó erróneamente en repetidas ocasiones la cadencia de lanzamientos de Adobe durante el desarrollo.
Esta admisión importa porque el resultado ayuda a los equipos de seguridad a priorizar vulnerabilidades tras el Patch Tuesday mensual de Microsoft. Una fabricación plausible puede distorsionar qué sistemas reciben atención primero, incluso cuando todas las vulnerabilidades citadas son reales.
Ivanti respondió con una puerta de aprobación humana e identificó públicamente el papel de Claude en un gráfico de junio. CrowdStrike y Palo Alto Networks también mantienen a personas involucradas en automatizaciones de seguridad con consecuencias relevantes, pero ninguna ha descrito públicamente haber detectado una fabricación comparable.
Por tanto, la historia es más amplia que un modelo cometiendo errores. Es una prueba de si los proveedores revelarán cómo la IA da forma a la orientación operativa, qué verifican realmente sus revisores y qué errores siguen siendo invisibles.
La guía de seguridad con IA de Ivanti entró en producción tras meses de correcciones
Ivanti llevó su skill de Claude a producción solo después de que sus desarrolladores detectaran repetidamente detalles fabricados o combinados indebidamente durante el entrenamiento.
Chris Goettl, vicepresidente de gestión de producto para la seguridad de endpoints en Ivanti, diseñó la skill en torno a un proceso que había realizado manualmente durante aproximadamente una década. Esta ingiere avisos publicados por proveedores y las propias hojas de cálculo de Ivanti, y luego aplica el método de priorización de riesgos de amenazas de la compañía.
Una skill, en este contexto, es un conjunto reutilizable de instrucciones, fuentes y reglas de flujo de trabajo proporcionadas a un modelo de IA. No significa que el modelo comprenda de manera independiente el sistema de divulgación de cada proveedor.
Goettl entrenó el sistema con un proveedor a la vez. Microsoft fue el primero porque sus hojas de cálculo descargables ofrecían datos de entrada relativamente estructurados. Adobe requirió un enfoque distinto porque el modelo tenía que interpretar páginas individuales y sus diseños cambiantes.
Esa diferencia expuso una debilidad importante. La skill produjo repetidamente una cadencia de lanzamientos de Adobe incorrecta. También confundió ediciones de Microsoft Office, que Microsoft separa en varias familias de productos.
No se trataba de defectos estilísticos. La cadencia de lanzamientos y la identidad del producto afectan a cómo los analistas interpretan actividad inusual, software afectado y urgencia de aplicar parches. Un resumen pulido con un patrón incorrecto aún puede enviar a un equipo en la dirección equivocada.
Goettl describió cómo confrontó al sistema cuando una respuesta parecía claramente no estar respaldada. Según su relato en el pipeline asistido por IA, Claude reconoció que el material inventado carecía de una base que pudiera citarse como referencia.
Ivanti afirma que la skill utiliza únicamente avisos públicos de proveedores y hojas de cálculo controladas por la empresa. No procesa datos de clientes, y cada resultado generado sigue siendo un borrador hasta que una persona lo aprueba.
Todd Schell, gerente sénior de producto, volvió a ejecutar el sistema con dos meses de informes previamente elaborados a mano. Ivanti informó una alineación del 98 %, aunque reconoció que persistían casos límite.
Esta cifra requiere una interpretación cuidadosa. VentureBeat no auditó de forma independiente los datos fuente, el método de puntuación, la taxonomía de errores ni los resultados de la repetición. La alineación tampoco establece que todas las vulnerabilidades relevantes aparecieran en el resultado generado.
La primera ejecución en producción tuvo lugar en agosto de 2026 mientras Goettl estaba de vacaciones. Según se informó, una hoja de cálculo que antes requería unas cuatro horas de cada uno de dos empleados se procesó en menos de 30 minutos.
El flujo de trabajo mensual más amplio había consumido unas 48 horas combinadas en torno a cada Patch Tuesday. Ivanti estimó que ese esfuerzo representaba al menos el 5 % del tiempo de trabajo combinado de Goettl y Schell.
La ganancia operativa es fácil de entender. Una máquina puede recopilar, normalizar y ordenar un lanzamiento grande más rápido de lo que dos especialistas pueden copiar manualmente campos entre hojas de cálculo.
Sin embargo, Ivanti no eliminó al especialista del proceso. La empresa cambió el trabajo del especialista: pasó de ensamblar cada fila a revisar un borrador producido por una máquina.
Esa distinción define el conflicto central. La automatización ahorra tiempo al reducir la elaboración manual, mientras que una guía de seguridad fiable sigue dependiendo del juicio humano y de la verificación a nivel de fuente.
Ivanti también dejó una divulgación visible antes de que surgiera la historia más amplia. Su publicación de Patch Tuesday de junio identificó un gráfico como generado con Claude mediante prompts diseñados por el autor y el conjunto de datos de Goettl.
Ninguna regulación exigía ese texto. Ningún estándar común de la industria dictaba su redacción. La divulgación permaneció disponible públicamente durante unos tres meses antes de recibir un escrutinio más amplio.
Ese discreto texto se volvió significativo una vez que se conocieron los fallos de desarrollo. Conectaba un artefacto generado por IA con un modelo identificado, un autor humano, una fecha y un conjunto de datos definido.
Eso ofrece más transparencia que una etiqueta genérica de “asistido por IA”. Aun así, no revela qué filas se comprobaron, cómo se midió la exhaustividad ni si los niveles de riesgo publicados recibieron validación independiente.
El problema de datos de Patch Tuesday hizo atractiva la automatización
La presión inmediata procedía de un proceso de Patch Tuesday que se volvió más grande, menos estandarizado y más dependiente de la interpretación de cada proveedor.
El 8 de septiembre de 2026, Microsoft publicó lo que varios investigadores de seguridad describieron como su Patch Tuesday más grande. Sin embargo, los totales publicados diferían sustancialmente entre organizaciones que analizaban el mismo lanzamiento.
Tenable contabilizó 964 vulnerabilidades, incluidas 104 calificadas como críticas y 860 como importantes. Su análisis de septiembre también identificó dos vulnerabilidades explotadas activamente antes de que los parches estuvieran disponibles.
Ivanti contabilizó 973. Senserva contabilizó 1.169 porque relacionó vulnerabilidades con artículos de la base de conocimientos, en lugar de usar el mismo método centrado en avisos que otros rastreadores.
La diferencia entre los totales de Tenable y Senserva fue de 205 vulnerabilidades. Esa brecha superó el récord anterior de Patch Tuesday citado por Ivanti, de 175 vulnerabilidades en octubre de 2025.
Estas diferencias no prueban que un modelo de IA haya cometido un error. Pueden resultar de decisiones legítimas sobre alcance, entradas duplicadas, variantes de productos, límites de los avisos y mapeos de la base de conocimientos.
Sí muestran por qué un único total mensual no puede tratarse como un hecho neutral. Cada recuento publicado refleja ahora un método de análisis y una definición de qué pertenece al conjunto.
Microsoft intensificó ese problema cuando dejó de presentar una lista mensual consolidada de CVE en su Security Update Guide. Rapid7 documentó el cambio mientras preparaba su revisión de parches de julio.
Ahora cada proveedor de seguridad debe reconstruir el lanzamiento a partir de los datos disponibles de Microsoft. Esa reconstrucción puede implicar código determinista, análisis manual, un modelo de IA o una combinación de los tres.
Un analizador determinista sigue reglas explícitas y produce el mismo resultado al recibir datos idénticos. Un modelo de lenguaje grande puede interpretar páginas inconsistentes con mayor flexibilidad, pero también puede generar relaciones no respaldadas.
Esta disyuntiva se vuelve especialmente importante cuando el resultado no es simplemente un recuento. Los equipos de seguridad necesitan priorización basada en explotación activa, divulgación pública, gravedad, exposición de activos e importancia empresarial.
Un recuento incorrecto puede confundir los informes. Una prioridad incorrecta puede desviar una capacidad limitada de aplicación de parches de una amenaza que los atacantes ya están explotando.
Según se informó, la sesión informativa por webinar de Ivanti llega cada mes a entre 500 y 700 asistentes. Esos participantes no necesariamente copian cada recomendación directamente a producción, pero la audiencia da a cada decisión de priorización un alcance significativo.
La presión de tiempo también es real. Los equipos de seguridad no pueden inspeccionar tranquilamente casi mil entradas antes de que actúen los atacantes.
CrowdStrike informó que el 88 % de la explotación observada que involucraba una prueba de concepto pública comenzó dentro de las 48 horas. Una prueba de concepto es código o documentación técnica disponible públicamente que demuestra cómo puede explotarse una vulnerabilidad.
Los requisitos federales pueden ser aún más estrictos. La Binding Operational Directive 26-04 de CISA estableció una ventana de remediación de tres días para las vulnerabilidades de mayor riesgo en agencias civiles federales.
En esas condiciones, los proveedores tienen un fuerte incentivo para automatizar la recopilación y la clasificación preliminar. Esperar una revisión manual perfecta puede crear riesgo por sí mismo.
El problema no es si las organizaciones deben usar IA. Es si pueden demostrar que la aceleración no ha omitido vulnerabilidades críticas, corrompido mapeos de productos ni elevado señales débiles.
La experiencia de Ivanti muestra por qué esta prueba no puede basarse en la fluidez. El resultado incorrecto del modelo parecía lo suficientemente convincente como para requerir reconocimiento experto y confrontación directa.
Por ello, los compradores de seguridad sufren presión desde ambos lados. Necesitan una guía más rápida, pero no pueden asumir que un informe más rápido y bien redactado contiene un conjunto completo o priorizado con precisión.
La verdadera inversión es la divulgación, no la fabricación
La parte sorprendente no es que Claude fabricara detalles; es que Ivanti describiera los fallos y mantuviera una puerta humana visible.
Los modelos de lenguaje grandes generan texto prediciendo secuencias probables a partir de su entrenamiento y del contexto proporcionado. No garantizan de forma inherente que cada afirmación se corresponda con una fuente proporcionada.
La fabricación, a menudo llamada alucinación, ocurre cuando un modelo presenta información no respaldada como si estuviera fundamentada. En este flujo de trabajo, el fallo apareció como patrones de proveedores incorrectos y familias de software combinadas indebidamente.
Estas debilidades ya son conocidas en los sistemas de IA de propósito general. Lo que cambia las consecuencias es su ubicación dentro de un pipeline que produce recomendaciones de seguridad.
Un error de un chatbot de consumo puede hacer perder tiempo a un lector. Una fila de vulnerabilidad ausente en una guía operativa puede retrasar la remediación de un sistema expuesto.
La divulgación de Ivanti no eliminó ese riesgo. Hizo que el riesgo pudiera examinarse.
La empresa vinculó el nombre de un modelo y la responsabilidad humana a al menos un gráfico publicado. Goettl también explicó qué problemas surgieron durante el entrenamiento y por qué seguía siendo necesaria la puerta de revisión.
Ese nivel de especificidad ayuda a los clientes a hacer mejores preguntas. Pueden distinguir entre la recopilación asistida por modelos y la priorización autónoma, y pueden preguntar qué etapa recibe verificación humana.
La admisión también complica los mensajes convencionales sobre confianza. Los proveedores suelen destacar mejoras de precisión, velocidad de procesamiento o productividad de analistas al anunciar funciones de IA.
Los fallos de desarrollo rara vez reciben la misma atención. Ese desequilibrio anima a los compradores a evaluar un flujo de trabajo según su mejor referencia, en lugar de según sus modos de fallo conocidos.
La alineación del 98 % comunicada por Ivanti ilustra el peligro. La cifra suena tranquilizadora, pero su significado práctico depende de qué quedó dentro de la diferencia restante.
Una discrepancia de formato sin importancia y una vulnerabilidad explotada activamente omitida no deberían recibir el mismo peso. Una evaluación útil debe clasificar los errores según su consecuencia operativa.
La exhaustividad merece un tratamiento independiente de la corrección. Un revisor puede detectar una gravedad incorrecta o una descripción malformada en una fila visible, pero no puede advertir fácilmente una fila ausente.
Este es el desafío más agudo para la narrativa de la revisión humana. Leer resultados generados no equivale a conciliarlos con un inventario de fuentes autorizado.
Kayne McGladrey, director independiente virtual de seguridad de la información y miembro sénior de IEEE, sostuvo que los clientes necesitan una explicación por escrito del proceso. Afirmó que los proveedores deberían explicar dónde opera el modelo, cómo se analizan los CVE, quién revisa los resultados y qué proporción recibe verificación contra las fuentes.
Su crítica fue más allá de pedir una firma humana. Una repetición frente a meses anteriores producidos por personas puede medir la similitud sin demostrar la corrección del mes actual.
Un revisor humano también puede compartir el punto ciego del modelo. Si ambos se centran en entradas visibles, ninguno descubrirá un elemento que desapareció antes de que comenzara la revisión.
Por tanto, el estándar relevante es la trazabilidad. Cada recomendación publicada debería estar vinculada a una entrada autorizada, mientras que cada entrada autorizada debería tener una disposición registrada.
Esa segunda dirección es la más importante. Convierte la revisión de «¿Este borrador parece razonable?» en «¿Se puede dar cuenta de cada elemento de origen?».
Aquí es donde una combinación de conocimientos disciplinada cobra relevancia más allá de la aplicación de parches. Combinar fuentes solo es útil cuando el flujo de trabajo preserva la procedencia y expone los conflictos en lugar de ocultarlos.
La divulgación de Ivanti ofrece un punto de partida, no un estándar terminado. Indica a los compradores que la IA participó y que las fabricaciones conocidas dieron forma al proceso de revisión.
No establece públicamente la trazabilidad a nivel de fila, pruebas independientes de niveles de riesgo, tasas de falsos negativos ni el porcentaje de material de origen conciliado automáticamente.
Aun así, la admisión ejerce presión sobre los competidores. Un proveedor que comercializa orientación de seguridad asistida por IA sin describir su cadena de validación ahora ofrece a los clientes menos información que Ivanti.
El giro resulta incómodo, pero constructivo. Reconocer públicamente los fallos de un modelo puede convertirse en prueba de madurez de procesos, mientras que el silencio puede ocultar controles excelentes o la ausencia total de controles.
La revisión humana solo funciona cuando puede encontrar evidencia faltante
Un revisor solo aporta valor cuando el diseño de la revisión busca omisiones, afirmaciones sin respaldo y errores de clasificación de alto impacto.
El flujo de trabajo de Ivanti mantiene a una persona entre el borrador de Claude y el informe publicado. Eso es más seguro que permitir que un modelo publique la priorización automáticamente.
Sin embargo, «humano en el circuito» es una descripción de diseño, no una medida de calidad. Su eficacia depende de lo que la persona ve, verifica y puede detener.
Un revisor que examina textos puede identificar redacciones extrañas, un producto conocido asignado a la familia equivocada o un patrón de lanzamiento inverosímil. La experiencia de Goettl parece haber detectado esas anomalías visibles durante el entrenamiento.
El fallo más difícil es la exclusión silenciosa. Si un analizador o modelo nunca crea una fila para una vulnerabilidad, un revisor que examina únicamente la hoja de cálculo final no recibe ninguna advertencia evidente.
Un sistema más sólido necesita controles de conciliación fuera del modelo de lenguaje. Las comprobaciones deterministas pueden comparar identificadores de origen, señalar registros sin correspondencia, detectar CVE duplicados y contar los elementos esperados por proveedor.
El modelo puede entonces encargarse de tareas que se benefician de la interpretación. Podría resumir avisos, normalizar descripciones incoherentes o proponer categorías de riesgo para su aprobación por expertos.
Esta división asigna responsabilidades distintas a las máquinas. El código protege la exhaustividad y la repetibilidad, mientras que el modelo ayuda con el lenguaje ambiguo y el contexto de priorización.
También crea señales de fallo más claras. Una discrepancia de conciliación puede detener la publicación incluso cuando la narrativa generada parece pulida.
La validación de niveles de riesgo necesita un rigor similar. El sistema debería registrar por qué un elemento recibió su clasificación, qué hechos de origen respaldaron esa decisión y qué cambió tras la revisión humana.
Sin ese registro, una aprobación final establece responsabilidad, pero ofrece evidencia limitada sobre la calidad. No puede demostrar si el revisor examinó cada recomendación o simplemente tomó muestras de las filas de mayor riesgo.
Ivanti afirma que sus señales de explotación conocida, divulgación pública y volumen anómalo activan una escalada. Es un conjunto de reglas sensato, pero los informes públicos no verifican de forma independiente su aplicación.
Los fallos de Adobe y Office también muestran por qué importan las pruebas específicas de cada proveedor. Un flujo de trabajo que funciona bien con hojas de cálculo de Microsoft puede fallar cuando otro editor utiliza páginas web, convenciones de nomenclatura diferentes o calendarios de lanzamiento irregulares.
Por tanto, la evaluación debe cubrir cada fuente de datos y cada etapa de transformación. Un promedio combinado puede ocultar un conector débil para un proveedor bajo un sólido rendimiento con Microsoft.
CrowdStrike describió un patrón de revisión diferente en Fal.Con 2026. Según se informó, su enfoque de «humano sobre el circuito» hace que un analista trabaje en paralelo con el agente sobre la misma detección y luego compare los veredictos.
El trabajo paralelo puede revelar desacuerdos que la revisión secuencial no detecta. También conserva más esfuerzo humano que un flujo en el que una persona revisa un borrador ya terminado.
Palo Alto Networks presentó Cortex XSIAM AgentiX en febrero de 2026 con agentes preconfigurados y puntos de aprobación para acciones de alto impacto. Su diseño de SOC agéntico preserva de forma similar el control humano allí donde las decisiones automatizadas tienen mayores consecuencias.
Ninguno de los dos diseños resuelve automáticamente el problema de las entradas faltantes. Un humano y un agente pueden razonar ambos a partir de una fuente incompleta, mientras que un punto de aprobación puede autorizar una acción basándose en evidencia defectuosa.
No obstante, la comparación revela un consenso emergente. Los principales proveedores no consideran la autonomía sin restricciones como una configuración predeterminada aceptable para operaciones de seguridad de alto impacto.
Ese consenso importa porque el lenguaje de la industria suele difuminar la asistencia y la autonomía. Un sistema que redacta un informe difiere sustancialmente de uno que despliega un parche, aísla un dispositivo o cierra un incidente.
Los compradores deberían relacionar cada acción de IA con su reversibilidad y daño potencial. Los resúmenes de bajo impacto pueden tolerar controles más ligeros que las decisiones que modifican sistemas de producción.
También deberían exigir evidencia de casos de fallo reales. Un benchmark que solo informa sobre concordancia oculta si los errores afectaron la redacción, el alcance, la gravedad o las omisiones.
Las detecciones de fabricaciones conocidas de Ivanti ofrecen información más útil que una mera afirmación de precisión. Identifican condiciones concretas en las que el sistema se volvió poco fiable.
La cuestión sin resolver es si los controles de producción detectan nuevos modos de fallo, y no solo los descubiertos durante el entrenamiento. Los sitios de los proveedores cambian, las taxonomías evolucionan y los lanzamientos inusuales pueden invalidar las suposiciones de análisis de ayer.
La revisión humana sigue siendo necesaria, pero debería integrarse en un sistema de control medible. De lo contrario, la expresión puede convertirse en una garantía sin demostrar que los errores más peligrosos pueden descubrirse.
La admisión de Ivanti eleva el estándar para todos los proveedores de seguridad
Los proveedores de seguridad ahora enfrentan presión para revelar no solo que utilizan IA, sino exactamente cómo influye la IA en las prioridades de cara al cliente.
Ivanti no está sola en la automatización del análisis de seguridad. CrowdStrike, Palo Alto Networks y otros proveedores están incorporando modelos y agentes en flujos de trabajo de detección, investigación, triaje y respuesta.
La diferencia competitiva expuesta aquí es la transparencia. Ivanti nombró su modelo, describió sus entradas, identificó patrones conocidos de fabricación y explicó que la publicación requiere aprobación humana.
VentureBeat informó que no encontró una divulgación pública comparable de fabricaciones por parte de CrowdStrike o Palo Alto Networks. Esa ausencia no demuestra que sus sistemas fallaran ni que sus controles sean más débiles.
Significa que los clientes carecen de información comparable. Un proveedor ha expuesto parte de su historial de fallos, mientras que otros describen principalmente arquitectura y salvaguardas.
La divulgación pública crea un difícil problema de incentivos. Una empresa que informa sobre errores puede parecer menos fiable que un competidor que solo publica evaluaciones exitosas.
La adquisición de soluciones de seguridad puede invertir ese incentivo al recompensar la evidencia. Los compradores pueden hacer las mismas preguntas a cada proveedor y considerar las respuestas ausentes como una brecha de control sin resolver.
En primer lugar, los clientes deberían preguntar qué artefactos genera la IA. La respuesta debería distinguir entre recopilación, análisis, resumen, puntuación, recomendación y acción automatizada.
En segundo lugar, deberían preguntar cómo se verifica la exhaustividad. Una respuesta válida debería abordar filas faltantes, registros duplicados, cambios en las fuentes e ingesta fallida.
En tercer lugar, deberían preguntar quién revisa el resultado y qué cubre esa revisión. Un rol de aprobación identificado es útil, pero una lista de verificación documentada y un registro de auditoría ofrecen una garantía más sólida.
En cuarto lugar, deberían solicitar categorías de error en lugar de un único porcentaje de precisión. Los compradores necesitan saber si los fallos afectan a la gramática, la atribución de productos, el estado de explotación, la gravedad o la inclusión.
Estas solicitudes son proporcionales a la decisión en juego. Los equipos de parches utilizan la priorización porque no pueden corregir todos los problemas simultáneamente.
La publicación de septiembre demuestra el problema de escala. Tenable identificó 964 CVE, Ivanti identificó 973 y Senserva identificó 1.169 con un enfoque de conteo diferente.
Un comprador no necesita necesariamente que todos los proveedores produzcan un número idéntico. Sí necesita que cada proveedor explique su alcance y concilie sus recomendaciones con ese alcance.
La misma lógica se aplica a los niveles de riesgo. Los proveedores pueden ponderar razonablemente la explotabilidad, la exposición y el contexto empresarial de manera diferente, pero esos juicios deberían seguir siendo trazables.
La transparencia también protege a los proveedores de comparaciones injustas. Una metodología documentada puede demostrar que dos totales difieren por un alcance definido, no porque un sistema haya perdido datos silenciosamente.
Este problema va más allá de la ciberseguridad. Cualquier investigación generada por IA, informe de cumplimiento, resumen financiero o informe operativo puede contener omisiones plausibles que una revisión superficial no detectará.
La seguridad hace que el problema sea especialmente visible porque los CVE cuentan con identificadores y avisos autorizados. Esa estructura ofrece a los proveedores una forma práctica de probar la exhaustividad.
Las organizaciones que trabajan con evidencia menos estructurada afrontan una tarea más difícil. Aun así, necesitan procedencia, detección de conflictos y tratamiento explícito del material faltante.
Por tanto, el enfoque de Ivanti es notable, aunque no suficiente. Su divulgación ofrece a los clientes más información que el silencio, mientras que sus controles reportados todavía dejan sin responder preguntas importantes de verificación.
El contexto de seguridad previo de la empresa hace que el escrutinio sea especialmente importante. Los clientes que evalúan la orientación sobre parches juzgarán no solo la eficiencia del modelo, sino también la capacidad de Ivanti para comunicar el riesgo con precisión.
Ese escrutinio debería seguir basándose en evidencia. La habilidad de Claude analizada aquí examinó datos públicos de parches y, según se informó, no accedió a entornos de clientes.
No era un agente autónomo de remediación. Produjo borradores para un informe recurrente, con una persona responsable de su publicación.
Confundir esas categorías exageraría el acontecimiento. Minimizar la fabricación porque «un humano la revisó» subestimaría el desafío de control.
La conclusión mesurada se sitúa entre esos extremos. Ivanti creó un proceso materialmente más rápido, detectó fallos reales del modelo, reveló la participación de la IA y mantuvo la revisión experta.
No ha demostrado públicamente que su proceso detecte todas las vulnerabilidades faltantes ni que valide de forma independiente cada decisión de prioridad. Ese es el estándar que los clientes deberían pedir ahora a Ivanti y a sus competidores.
Tres señales mostrarán si la orientación de parches con IA se gana la confianza
La próxima prueba será si los proveedores convierten la amplia supervisión humana en una validación visible, repetible y completa respecto a las fuentes.
La primera señal llegará con el próximo Patch Tuesday, el 13 de octubre de 2026. Los analistas deberían comparar los totales publicados, las definiciones de alcance, las etiquetas de vulnerabilidades conocidas explotadas y el tratamiento de datos inusuales de los proveedores.
Si la producción de Ivanti sigue siendo rápida y, al mismo tiempo, explica claramente las discrepancias entre fuentes, se reforzará su argumento a favor de la automatización supervisada. Una omisión o un error de mapeo sin explicación lo debilitaría.
La segunda señal será una divulgación más detallada por parte de Ivanti o sus competidores. Una documentación útil identificaría dónde operan los modelos, qué controles deterministas protegen la integridad y qué decisiones requieren aprobación humana.
Esa información reforzaría el argumento de que la transparencia puede convertirse en un estándar competitivo. La dependencia continua de expresiones amplias como “human in the loop” dejaría sin resolver la brecha central de verificación.
La tercera señal será la evidencia procedente de evaluaciones en producción. Los proveedores deberían informar sobre categorías de errores, cobertura de fuentes, anulaciones por parte de revisores y falsos negativos de alto impacto, sin exponer detalles explotables de los clientes.
Esa evidencia mostraría si los sistemas mejoran tras encontrarse con nuevos formatos y casos límite. La concordancia agregada por sí sola no respondería a esa pregunta.
El informe de CrowdStrike sobre la rápida explotación explica por qué este trabajo no puede volver por completo al procesamiento manual. Sus hallazgos sobre explotación muestran que los defensores a menudo operan dentro de un margen de respuesta cada vez más reducido.
Por tanto, el resultado adecuado no es menos automatización. Es una automatización cuya evidencia pueda inspeccionarse antes de que sus recomendaciones orienten a personas o máquinas.
Para los responsables de seguridad, la respuesta práctica es inventariar todas las fuentes externas de orientación que utilizan IA. Pregunte si el modelo cuenta, interpreta, clasifica o actúa, porque cada función crea una vía de fallo diferente.
Después, ponga a prueba la afirmación del proveedor sobre la revisión con una pregunta difícil: ¿Cómo detectaría el proceso una vulnerabilidad que nunca apareció en el borrador generado?
Si la respuesta depende de que una persona detecte algo ausente, el control es incompleto. Si incluye conciliación de fuentes, gestión de excepciones y decisiones humanas registradas, el flujo de trabajo resulta más creíble.
La orientación de seguridad de Ivanti sobre IA ofrece ahora un caso de estudio público para esa conversación. Su habilidad de Claude ahorró una cantidad considerable de tiempo a los analistas, fabricó detalles durante el desarrollo y obligó a la empresa a diseñar el sistema teniendo en cuenta esos fallos.
La divulgación no debería generar confianza automática, pero merece atención. Ofrece a los clientes debilidades concretas que examinar y proporciona a los competidores un referente de transparencia que pueden superar.
Antes de confiar en el próximo informe de seguridad asistido por IA, solicite información sobre el papel del modelo, la comprobación de integridad de las fuentes y la tarea real del revisor. Esas respuestas revelarán más que cualquier puntuación de precisión destacada.
