Si la IA rechaza el análisis, la revisión sigue abierta

Cuando una IA rechaza un análisis de seguridad, la inspección solicitada queda sin terminar. Eso no demuestra que el archivo sea malicioso ni que sea seguro. Conserva el archivo original, deja constancia de lo que el asistente no pudo examinar y encarga a una persona autorizada que decida cómo continuar el análisis. Mantén la revisión abierta hasta que las pruebas permitan llegar a una conclusión.

Esta distinción importa cuando tu equipo depende de un asistente para entender código que desconoce. Una negativa convincente puede parecer un hallazgo: la herramienta menciona material peligroso, rechaza la tarea y devuelve una respuesta que parece definitiva. Tu proceso sigue necesitando una respuesta a la pregunta original sobre el archivo.

Una investigación reciente sobre un script de identificación del navegador ofrece un caso útil. La lección práctica es sencilla: cuando una herramienta de análisis se detiene, alguien debe seguir siendo responsable de resolver la pregunta pendiente.

¿Qué ocurrió en la investigación del script de identificación del navegador?

Un investigador señaló que la presencia de texto alarmante dentro de un archivo JavaScript coincidió con la negativa de algunos asistentes a desofuscarlo. Según su relato, otro asistente sí completó la tarea. El caso muestra respuestas distintas entre herramientas; no demuestra que se pueda detener de la misma forma a todas las herramientas de seguridad con IA.

En la investigación publicada el 28 de octubre de 2026, veritas describe cómo encontró nombres de símbolos engañosos e instrucciones ocultas mientras examinaba un script que obtiene la huella digital del navegador. Interpreta esos elementos como una probable ofuscación contra los modelos de lenguaje (LLM): material destinado a dificultar la inspección con ayuda de IA.

El autor describe funciones de identificación del navegador, pero también analiza código sospechoso vinculado a determinados entornos. Su relato no permite declarar inofensivo todo el archivo. No hemos descargado ni ejecutado la muestra, ni hemos realizado nuestra propia ingeniería inversa. Además, el informe no es una evaluación controlada de modelos.

No necesitas confirmar la hipótesis del autor sobre la intención de ese contenido para extraer una lección del caso. Las negativas que describe dejaron una revisión incompleta. El siguiente paso debe formar parte de tu proceso de investigación, con independencia de por qué se detuvo un asistente concreto.

¿Qué te dice realmente una negativa de la IA?

Una negativa te dice algo sobre el intento de interacción con una herramienta. Para emitir un veredicto sobre la presencia de malware hacen falta pruebas del comportamiento o las capacidades del archivo. Mantén separadas ambas observaciones en el informe.

El nombre de una función puede describir algo que el programa nunca hace. El texto incrustado en un archivo puede ser un dato, un señuelo, una instrucción dirigida a quien lo lee o parte de la lógica ejecutable. Para determinar de qué se trata, hay que examinarlo. Una respuesta sobre el tema aparente de ese texto no completa el análisis.

La conclusión contraria tiene igual de poco fundamento. Aunque sospeches que el contenido alarmante se introdujo para obstaculizar la inspección, tampoco puedes declarar seguro el archivo por ese motivo. Tu hipótesis sobre un señuelo no explica el resto del programa.

Usa un estado que describa el trabajo, como análisis incompleto, junto con los hallazgos que se hayan confirmado por separado. Evita reunir la disponibilidad de la herramienta, el avance de la inspección y la disposición de seguridad en un único indicador verde o rojo.

Esta tabla propone un criterio de trabajo, no un sistema de clasificación de amenazas. Ayuda a quien retome el informe a entender por qué la revisión sigue abierta, sin tratar todos los fallos como si fueran el mismo suceso.

La distinción también resulta útil al evaluar informes sobre sondeos de seguridad realizados por IA. Aquí, sin embargo, la pregunta inmediata es más concreta: ¿quién termina una inspección que quedó incompleta?

¿Qué debes conservar antes de pasar el archivo a otra persona?

Conserva el archivo recibido y el contexto de su obtención antes de modificar una copia de trabajo. Quien lo analice después debe poder distinguir qué llegó, qué examinaste y qué transformaciones realizaste.

La publicación NIST SP 800-86, de 2006, recomienda examinar copias y comprobar su integridad mediante resúmenes criptográficos. Esos principios de conservación de pruebas siguen siendo útiles en este caso; por su antigüedad, el documento no es una buena referencia para elegir las herramientas de análisis actuales.

Para facilitar el traspaso, guarda el original en la ubicación protegida que tu equipo ya utiliza para las pruebas. Registra de dónde procede, cuándo lo obtuviste y qué relación tiene con tu copia de trabajo. Si tu proceso utiliza una referencia de integridad, consérvala junto con el registro.

No sobrescribas el archivo recibido con una versión depurada. Una copia normalizada o anotada puede facilitar la lectura, pero debes identificarla como una versión derivada. De lo contrario, un compañero podría confundir tus cambios con el contenido que envió el investigador.

Trata con el mismo cuidado la respuesta del asistente. Conserva el contexto suficiente para explicar la limitación: la tarea solicitada, la herramienta aprobada y su versión, si se conoce, y la respuesta o el fallo observado. No hace falta copiar material sensible en cada comentario para que el registro resulte útil. Facilita a las personas autorizadas un enlace a la ubicación con acceso controlado.

Esta es nuestra aplicación de las prácticas de conservación de pruebas a una negativa de la IA. No afirmamos que NIST prescriba un procedimiento especial para estos casos, ni que guardar la transcripción de un chat establezca una cadena de custodia forense.

¿Quién se responsabiliza de la revisión cuando se detiene el análisis con IA?

Una persona identificada debe responsabilizarse de la pregunta pendiente y elegir el siguiente paso de análisis permitido. La negativa del asistente debe cambiar el plan de trabajo sin cerrar el informe de forma implícita ni determinar su severidad.

Parte de las autorizaciones que ya tienes. Un informe sobre tu aplicación no te autoriza automáticamente a realizar sondeos contra terceros, subir código confidencial a otro servicio o ejecutar una muestra desconocida en un equipo de trabajo. La persona encargada de la revisión debe elegir herramientas y un entorno adecuados para el archivo y el alcance acordado.

Puede optar por una inspección estática manual, que examina el código sin ejecutarlo. También puede utilizar herramientas de análisis convencionales en un entorno aislado o consultar a un especialista con permiso para acceder al material. La elección depende de la pregunta que necesitas resolver y de la capacidad de tu equipo.

No conviertas la tarea en «encontrar un prompt que obtenga una respuesta». Concrétala: identificar los datos que recopila el script, determinar si un comportamiento descrito se produce en una prueba autorizada o explicar una rama sospechosa del código. Una pregunta clara ofrece un punto de partida útil a quien deba revisar el archivo.

Fija una fecha para la siguiente revisión y asigna una persona responsable. Tener a alguien asignado sin una próxima acción acordada puede bloquear el informe tanto como dejarlo sin responsable en la cola. Si el equipo carece de la capacidad necesaria, registra esa limitación y decide cómo obtenerla, en lugar de dar la revisión por terminada sin decirlo.

La guía de respuesta a incidentes de NIST de abril de 2025 proporciona un contexto más amplio para la respuesta. Aplicar esa disciplina aquí significa mantener visible la tarea pendiente y dejar claro quién se responsabiliza de ella. No implica afirmar que toda inspección rechazada sea un incidente.

¿Qué debe incluir el traspaso del informe?

El traspaso debe permitir que otra persona autorizada retome el trabajo sin tener que adivinar qué ocurrió. Incluye la referencia al archivo, la pregunta que se intentó resolver, la limitación observada y la persona responsable del siguiente paso.

Este ejemplo ficticio se puede adaptar a tu proceso. Los campos son una propuesta editorial, no un estándar del sector ni un formulario de Kit:

Archivo: Original JavaScript en el repositorio de pruebas de acceso restringido del equipo; el contexto de obtención y la referencia de integridad constan allí.

Tarea intentada: Inspección estática de la recopilación de datos y las comunicaciones salientes del archivo.

Limitación observada: El asistente aprobado rechazó la inspección. Su respuesta está enlazada en el registro de la investigación.

Trabajo completado: Se conservó el archivo. Este intento no ha permitido establecer un veredicto sobre su comportamiento.

Pregunta pendiente: ¿Qué información recopila el script y adónde puede enviarla?

Responsable y próxima acción: El analista asignado elegirá un método de análisis autorizado y actualizará el informe en la fecha de revisión acordada.

Limita las afirmaciones a lo que sabes. «El asistente rechazó la tarea» es una observación. «El archivo derrotó nuestros controles de seguridad» es una afirmación más amplia que este registro no demuestra. «No se encontraron problemas» también describiría mal una inspección que nunca llegó a terminarse.

Cuando una persona llegue después a una conclusión, debe identificar a qué archivo y entorno se aplica. Si solo se examinó una ruta de ejecución, indícalo. Si las pruebas siguen sin permitir una conclusión, mantén visible esa incertidumbre en lugar de inventar una disposición definitiva.

La necesidad de un registro útil para otra persona está relacionada con la gestión del volumen de informes generados por IA. En ambos casos, una respuesta bien redactada no basta si no ayuda a tomar la siguiente decisión. El informe debe mostrar qué se sabe y qué trabajo queda pendiente.

¿Cómo puede ayudar Kit en este proceso?

Un proceso de gestión de informes puede mantener visible una revisión pendiente mientras tu equipo utiliza herramientas autorizadas para analizar el archivo. La recepción, el análisis y la disposición son actividades distintas; un fallo en la fase intermedia debe quedar reflejado en el registro.

El flujo de trabajo de Security de Kit permite gestionar informes con responsables, conversaciones y una cronología. Su cribado con IA también muestra un estado de fallo que requiere atención humana. Esa visibilidad ayuda al equipo a detectar trabajo sin terminar y a registrar su seguimiento.

El cribado con IA de Kit evalúa la calidad del informe, no analiza exploits. Un fallo visible del cribado no significa que Kit haya detectado ofuscación contra los LLM ni reconocido una negativa inducida del modelo. Tampoco envía automáticamente un archivo sospechoso a un especialista.

Tu equipo sigue eligiendo y realizando el análisis. Kit no ejecuta ni desofusca estas muestras, no calcula los hashes de las pruebas descritos antes ni exige los campos de traspaso propuestos. Conserva los archivos y realiza la inspección técnica en tus sistemas aprobados; utiliza el informe para registrar las responsabilidades y el avance.

Una negativa de la IA deja una pregunta sin responder. Conserva lo que recibiste, explica la limitación y asigna una próxima acción concreta a una persona autorizada. Si necesitas un lugar compartido donde mantener visibles el informe, su responsable y el seguimiento, conoce el flujo de trabajo de Security de Kit.