Por Canuto  

Un investigador de seguridad abandonó GPT-5.6 después de que el clasificador de ciberseguridad de OpenAI bloqueara varios intentos para analizar un fallo en ripgrep. Modelos de pesos abiertos de China le permitieron avanzar hacia la posible causa en el núcleo de Linux.
***

  • El investigador Daniel Fox Franke afirmó que el clasificador de ciberseguridad bloqueó incluso consultas limitadas al código de ripgrep y musl.
  • Kimi K3 identificó inicialmente indicios de un error del núcleo, mientras GLM 5.2 revisó la evidencia y consolidó el análisis.
  • El fallo de Linux todavía no tiene parche y, según Franke, no parece representar una vulnerabilidad explotable.

 

Las medidas de seguridad diseñadas para impedir que los modelos de inteligencia artificial ayuden a actores maliciosos también pueden obstaculizar investigaciones defensivas. Ese fue el problema que enfrentó Daniel Fox Franke, investigador de seguridad, mientras intentaba rastrear un fallo de segmentación relacionado con ripgrep.

Ripgrep es una herramienta de búsqueda de texto utilizada habitualmente en entornos de desarrollo y administración de sistemas. Franke observó que el programa fallaba repetidamente durante una sesión prolongada de Codex y pidió a un agente principal que generara un subagente para examinar la causa.

La investigación comenzó con una observación aparentemente rutinaria, pero pronto encontró los filtros automáticos del sistema. Franke explicó a The Register que el primer bloqueo apareció pocos minutos después de iniciar el trabajo.

Según su relato, el agente principal atribuyó la interrupción a un subagente que seguía una línea de investigación considerada inapropiada. El clasificador de ciberseguridad habría intervenido para desviar la conversación, aunque el objetivo del investigador consistía en entender un error de software.

Franke describió el sistema de OpenAI como un clasificador separado que censura las respuestas del modelo generativo. A su juicio, el problema no estaba en el modelo conversacional, que continuaba colaborando de buena fe, sino en esa capa automática de control.

La investigación quedó atrapada entre los filtros

El investigador intentó reducir el riesgo de nuevas interrupciones al cambiar el alcance de la tarea. Inició un contexto nuevo y ordenó que el análisis se limitara al código fuente de ripgrep y musl, sin reproducir el fallo ni examinar archivos de núcleo.

En ese momento, Franke todavía no sabía que podía estar ante un error del núcleo de Linux. Su intención era estudiar las rutas del programa y de la biblioteca musl que podían conducir a asignaciones en el montón administradas por mallocng.

La restricción no resolvió el inconveniente. El clasificador siguió bloqueando el trabajo, incluso después de que el investigador estableciera límites explícitos para evitar la reproducción del fallo y el análisis de archivos potencialmente sensibles.

Franke afirmó que los intentos de producir el error y analizar el montón parecían ser los principales detonantes de las interrupciones. Después de varios bloqueos en rápida sucesión, decidió abandonar la posibilidad de obtener resultados útiles con esa herramienta.

El episodio ilustra una tensión central en la seguridad asistida por IA. Las mismas capacidades que podrían servir para localizar una vulnerabilidad también pueden activar sistemas de prevención, aunque la persona que formula la consulta actúe con fines defensivos.

Los modelos abiertos toman el relevo

Ante las restricciones, Franke recurrió a modelos de pesos abiertos ofrecidos por proveedores chinos de inteligencia artificial. Utilizó Z’ai GLM 5.2 y Kimi K3 de Moonshot AI para completar el análisis técnico.

El investigador asignó funciones diferentes a cada modelo. Kimi K3 realizó el avance inicial y aportó la evidencia clave que apuntaba hacia un error en el núcleo de Linux.

Sin embargo, Franke consideró que el trabajo posterior de Kimi K3 resultó descuidado. Según su evaluación, el modelo saltó hacia conclusiones sin fundamento, deterioró su propio registro de evidencias y perdió el rumbo cuando el contexto de trabajo creció.

GLM 5.2 desempeñó una función de auditoría. Franke explicó que el modelo revisó nuevamente el trabajo de Kimi K3 y le ayudó a construir un caso más sólido alrededor de la hipótesis técnica.

El resultado no equivale a una confirmación definitiva. Los modelos abiertos ayudaron a organizar y revisar la investigación, pero Franke todavía debe verificar que el error identificado sea realmente la causa de los fallos observados.

Acceso confiable y disputa por el control

Los mensajes de error de OpenAI dirigieron al investigador hacia el programa de Acceso Confiable Empresarial. Franke no solicitó participar porque no cumple los requisitos de ese programa.

Más tarde descubrió que existe un programa de Acceso Confiable separado para individuos. Aun así, no se ha registrado, porque considera indignante el procedimiento de verificación exigido para obtener un acceso menos restringido.

Franke también dijo que no intentó probar los modelos de Claude debido a las restricciones que, en su opinión, han aplicado los modelos de Anthropic. Desde su perspectiva, no tenía sentido cambiar de proveedor si esperaba encontrar barreras similares.

El investigador sostuvo que una herramienta que no coopera es, en la práctica, una herramienta rota. También expresó escepticismo sobre la sostenibilidad de los límites impuestos por productos propietarios mientras existan alternativas de pesos abiertos capaces de realizar el mismo trabajo.

Su postura no representa un rechazo absoluto al software propietario. Franke afirmó que es pragmático y que no tiene problemas en utilizar productos cerrados cuando cumplen su función, aunque considera que el código abierto ofrece una ventaja natural para evitar que el proveedor priorice sus propios intereses.

Un error de Linux todavía sin confirmar

La investigación no ha concluido y el posible error de Linux todavía no cuenta con un parche. Franke indicó que el problema tampoco parece representar una vulnerabilidad explotable en su estado actual.

El investigador dijo tener dos conclusiones firmes. La primera es que los fallos observados son provocados por un error en el núcleo, y la segunda es que identificó un error dentro de ese núcleo.

La conexión entre ambas observaciones sigue siendo una conjetura. Franke necesita realizar más trabajo antes de considerar el envío de un informe a la Lista de Correo del Núcleo de Linux.

La cautela resulta relevante porque una relación temporal entre un fallo de ripgrep y un defecto del núcleo no demuestra por sí sola una relación causal. La confirmación exigirá reproducibilidad, revisión del código y evidencia técnica suficiente para que otros desarrolladores puedan evaluar la hipótesis.

El caso también muestra los límites de delegar investigaciones complejas a agentes automáticos. Kimi K3 ayudó a encontrar una pista, pero GLM 5.2 tuvo que revisar sus conclusiones, mientras que el sistema cerrado que Franke prefería utilizar bloqueó partes esenciales del proceso.

El debate sobre los pesos abiertos

El episodio ocurre en medio de una discusión más amplia sobre el acceso a modelos de inteligencia artificial. La semana anterior, una parte importante de la industria tecnológica de Estados Unidos expresó su apoyo a los modelos de pesos abiertos frente al proteccionismo promovido por Anthropic y OpenAI.

Los modelos de pesos abiertos permiten que investigadores y desarrolladores descarguen y ejecuten sistemas cuyos parámetros están disponibles. Esa característica no elimina los riesgos de abuso, pero puede ofrecer mayor control sobre el entorno de análisis y reducir la dependencia de filtros administrados por un proveedor.

Los modelos cerrados, en cambio, suelen centralizar el acceso y aplicar políticas de seguridad directamente sobre las solicitudes o las respuestas. Esos mecanismos pueden resultar útiles para reducir asistencia maliciosa, aunque también pueden generar falsos positivos en investigaciones de vulnerabilidades.

El gobierno de Estados Unidos todavía no ha articulado una política coherente sobre los modelos de pesos abiertos. La falta de una dirección clara deja abierta la discusión sobre cómo equilibrar seguridad, innovación, responsabilidad empresarial y acceso de investigadores independientes.

Para Franke, la competencia de modelos abiertos modifica el cálculo de los usuarios profesionales. Si una alternativa permite avanzar en una investigación defensiva mientras otra bloquea consultas legítimas, la libertad operativa puede pesar tanto como la capacidad técnica del modelo.

El caso no demuestra que los modelos abiertos sean siempre más precisos o seguros. Sí plantea una pregunta difícil para el sector: si los filtros impiden reparar un posible defecto de Linux, ¿hasta qué punto la protección del proveedor termina perjudicando al cliente que busca resolverlo?

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados