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.