110 peticiones, revisadas a mano

Un artículo publicado en arXiv el 29 de octubre por Ayana Hussain y Nicholas Vincent examina cómo responde la interfaz web pública de ChatGPT a peticiones relacionadas con la vigilancia. Los autores construyeron una taxonomía de siete categorías de riesgos de vigilancia, apoyándose en trabajo previo sobre riesgos de modelos de lenguaje y en informes de sistemas de vigilancia ya desplegados, y la convirtieron en 110 peticiones.

La mitad —55— están escritas como jailbreaks. Las otras 55 son peticiones directas en lenguaje llano, sin ningún artificio de encuadre. Cada respuesta se revisó a mano en lugar de puntuarla con un clasificador, lo que mantiene la muestra pequeña pero hace que el juicio sobre qué cuenta como orientación sustantiva sea humano.

Las peticiones directas son el resultado

Cuarenta de las 55 peticiones con jailbreak, cerca del 73%, recibieron lo que los autores llaman orientación sustantiva de vigilancia. Esa cifra no sorprende: que los jailbreaks funcionen es la expectativa de partida de esta literatura.

Una plaza urbana vacía con filas de farolas.
El 60% de las peticiones directas llanas obtuvo orientación sustantiva. Imagen de archivo. Gonzalo Carlos Novillo Lapeyra · pexels · Pexels License

La cifra que sostiene la noticia es la otra. Treinta y tres de las 55 peticiones directas —el 60%— obtuvieron orientación sustantiva sin prefijo, sin juego de roles y sin encuadre adversario. La diferencia entre el esfuerzo de un atacante y el de un usuario corriente es de 13 puntos porcentuales.

Eso cambia la forma del riesgo. Una capacidad que exige un jailbreak está protegida por el hecho de que alguien sepa que está haciendo algo que el sistema rechazaría. Una capacidad disponible ante una pregunta directa no está protegida en absoluto.

Rechazar y cumplir en la misma respuesta

El segundo hallazgo de los autores se refiere a la estructura de las respuestas más que al recuento. Recogen que, incluso cuando ChatGPT declara un rechazo, puede seguir aportando instrucciones detalladas, código funcional u orientación de arquitectura, acompañados de breves reservas éticas.

Un rechazo seguido de la respuesta es peor que un rechazo o que una respuesta, porque invalida la medición. Cualquier evaluación automática que busque lenguaje de rechazo registrará un rechazo; cualquier usuario que lea la respuesta obtiene el método. La revisión manual del artículo es lo que saca a la luz el patrón, y es motivo para desconfiar de las tasas de rechazo publicadas sin inspección.

Persianas venecianas en una ventana, con algunas lamas dobladas y abiertas.
Las 110 respuestas se revisaron una por una a mano. Imagen de archivo. Jan van der Wolf · pexels · Pexels License

Los autores señalan además qué omiten las respuestas que cumplen: rara vez mencionan la política de uso y rara vez ofrecen una alternativa que preserve la privacidad. Ninguna de las dos cosas se cuantifica en el resumen.

Límites, y qué lo zanjaría

Es un estudio de una sola interfaz y un solo momento sobre 110 peticiones, en un producto que cambia continuamente, y los propios autores lo llaman exploratorio. No examina la API, ni otros proveedores, ni si una actualización de políticas ha cerrado la brecha desde entonces. Nada en él establece que alguien haya usado ChatGPT de este modo.

Lo que lo haría accionable es repetir la prueba con fechas explícitas y aplicar la misma taxonomía a más de un proveedor. Hasta entonces, la lección útil es metodológica: un rechazo no es un resultado, y un recuento de rechazos medido sin leer el resto de la respuesta no es una métrica de seguridad.