Una página web no puede observar directamente quién está al otro lado de la conexión. Recibe pulsaciones, respuestas, tiempos y datos enviados por un navegador, pero esas señales pueden proceder de una persona, de un programa o de una combinación de ambos. CAPTCHA nació como una forma de convertir esa incertidumbre en una prueba: el sistema genera un desafío, conoce cómo evaluarlo y espera que la diferencia entre capacidades humanas y automatizadas haga costoso el abuso.

El nombre fue formulado como acrónimo de Completely Automated Public Turing test to tell Computers and Humans Apart. La expresión invierte parcialmente la escena del test de Turing. No hay un interrogador humano tratando de descubrir si conversa con una máquina.

Es una máquina la que administra una prueba pública y automática para clasificar al visitante. El diseño exige que la generación y la corrección no dependan de una persona que prepare cada caso, porque esa dependencia impediría desplegar millones de desafíos.

Los trabajos fundacionales de Carnegie Mellon describieron varias condiciones. La prueba debía ser sencilla para una población humana amplia, difícil para los programas disponibles y capaz de producir muchos ejemplos distintos. Además, su código y su método podían ser públicos sin que la publicidad ofreciera inmediatamente la respuesta. La seguridad no debía descansar solo en ocultar el mecanismo, sino en la dificultad computacional de resolver cada instancia con suficiente fiabilidad y velocidad.

Los CAPTCHA de texto aprovecharon durante un tiempo una diferencia concreta. Las personas podían reconocer letras deformadas, separarlas de fondos ruidosos y reconstruir palabras cuando los sistemas de reconocimiento óptico todavía fallaban. Pero el desafío contenía una paradoja. Si se hacía demasiado limpio, los programas podían leerlo; si se deformaba en exceso, también las personas empezaban a equivocarse. La seguridad se compraba aumentando una fricción que recaía sobre usuarios legítimos.

El problema no era únicamente comodidad. El W3C documentó que muchas pruebas visuales excluían a personas ciegas, con baja visión, dislexia u otras dificultades cognitivas. Las alternativas de audio podían trasladar la barrera a personas sordas o con problemas para distinguir habla degradada. Añadir dos canales no garantizaba acceso universal: podía crear dos puertas diferentes que seguían cerradas para grupos distintos.

La prueba también dependía del momento histórico. Una tarea que separaba a humanos y máquinas en 2003 podía dejar de hacerlo cuando mejoraban el reconocimiento de imágenes, el aprendizaje automático, los servicios de resolución y los ataques de retransmisión. El propio éxito de una familia de CAPTCHA generaba datos, incentivos y técnicas para romperla. La frontera que el sistema intentaba medir no era fija; se desplazaba con la tecnología y con la economía del abuso.

Los autores propusieron además una relación entre seguridad y problemas abiertos de inteligencia artificial. Si una prueba utilizaba una tarea que la investigación todavía no sabía automatizar bien, cada avance del atacante podía convertirse en información sobre ese problema.

Esta idea era fértil, pero no convertía automáticamente cualquier desafío molesto en investigación útil. Para cumplir esa promesa, la tarea debía estar bien definida, las respuestas humanas debían ser fiables y los fallos automáticos debían aportar algo más que una carrera de obstáculos.

En la práctica, un CAPTCHA no demuestra que el usuario sea humano en sentido filosófico. Demuestra que una interacción concreta superó una regla concreta en un instante. Una persona puede delegar la respuesta en otra; un programa puede pagar a humanos para resolver pruebas; una sesión humana puede automatizar las acciones posteriores. La clasificación tiene alcance local y temporal. Confundirla con identidad, intención o confianza produce una seguridad más fuerte en apariencia que en realidad.

La mejor lectura del sistema es económica. El objetivo suele ser elevar el coste de crear cuentas, enviar formularios, extraer datos o probar credenciales a gran escala. Incluso una prueba imperfecta puede reducir la velocidad de un ataque. Sin embargo, si el coste para millones de usuarios legítimos supera el coste añadido al atacante, el mecanismo deja de ser una defensa eficiente. Seguridad, accesibilidad y usabilidad no son capas independientes: determinan juntas quién soporta el precio del control.

Las recomendaciones actuales del W3C insisten en minimizar la dependencia de tareas cognitivas o sensoriales inaccesibles y en considerar alternativas. Señales de riesgo, límites de velocidad, autenticación, verificación fuera de banda o análisis del comportamiento pueden distribuir la decisión entre varias capas. Ninguna sustituye universalmente a las demás, y cada una introduce sus propios riesgos de privacidad, error y exclusión.

CAPTCHA hizo visible una tensión fundamental de la web. Un servicio necesita defender recursos compartidos sin saber quién toca la puerta. La solución original convirtió una diferencia provisional entre personas y programas en un control automático. Su límite apareció cuando esa diferencia se estrechó y cuando el sistema trató como sospechosos a usuarios que simplemente no podían percibir o ejecutar la tarea diseñada.

Mirar un CAPTCHA de este modo cambia la pregunta. Ya no basta con preguntar si detiene bots. Hay que preguntar qué comportamiento bloquea, durante cuánto tiempo, con qué tasa de error y a quién obliga a demostrar una capacidad irrelevante para el servicio. La prueba no separa dos especies estables. Administra una frontera móvil entre automatización, accesibilidad y coste.