I. Una verificación que llega tarde y con las mismas reglas
Los partidos políticos —la ANR, el PLRA, y el resto de las organizaciones con representación parlamentaria— ya realizaron, entre el 2 y el 27 de febrero de 2026, una auditoría técnica de las máquinas de votación electrónica convocada por el Tribunal Superior de Justicia Electoral. Esa auditoría concluyó. Los equipos técnicos de cada partido elaboraron informes. Esos informes existen. Están documentados. Y en ellos, todos los auditores coincidieron en algo fundamental, no se les permitió auditar con la profundidad necesaria para garantizar una verificación independiente.
Ahora, a fines de mayo de 2026, la ANR y el PLRA realizan una nueva "verificación técnica". Los titulares hablan de "desarme de máquinas", de "explicación componente por componente", de "preguntas respondidas al cien por ciento". Se respira un aire de satisfacción. Los presidentes de los tribunales electorales partidarios declaran su confianza en el sistema.
Pero conviene recordar lo que ya se sabe. Y conviene preguntarse qué es lo que esta nueva verificación —con los mismos actores, bajo el mismo control del TSJE y la misma empresa MSA— podrá realmente esclarecer.
II. Lo que los auditores de los partidos ya informaron
Los informes técnicos de los auditores de los partidos políticos —no solo del PLRA, sino de todas las fuerzas que participaron en el proceso de febrero— documentaron, sin ambages, un conjunto de restricciones que cualquier persona de buena fe debería considerar graves:
Sobre el acceso al código fuente: se permitió revisar el código, pero únicamente en las computadoras del laboratorio del TSJE, sin conexión a internet, sin posibilidad de imprimir, sin capacidad de copiar fragmentos o tomar el código para analizarlo fuera de ese entorno controlado. El tiempo resultó manifiestamente insuficiente: cualquier período medido en días, dijeron los auditores, resulta insuficiente frente a la enormidad del código por investigar.
Sobre la contraseña root: los auditores la solicitaron, siguiendo las normas básicas de ciberseguridad. La respuesta de MSA fue que el sistema es un "appliance cerrado", que no ofrece interfaces de autenticación interactivas y que, en consecuencia, no existe contraseña que entregar. Técnicamente, esa respuesta puede ser coherente con el diseño de un sistema embebido. Pero también implica, por definición, que ningún auditor independiente podrá nunca acceder al sistema a nivel de kernel, y por lo tanto no podrá verificar lo que realmente ocurre en su interior.
Sobre las pruebas de escenarios de fraude: se probaron múltiples escenarios con USBs, credenciales y chips RFID. Pero no se probó —porque no se permitió o no se pudo— el escenario más elemental y más temido: aquel en el que la pantalla muestra una opción y el software suma otra distinta. Ese escenario, documentado en los informes, es el corazón de cualquier posible fraude electrónico. Y no fue probado.
Sobre la cadena de custodia del código: los informes consignan que no existe ningún mecanismo documentado que garantice que el código auditado en el laboratorio sea el mismo que se cargará en los USB que llegarán a las mesas el día de la elección. La escritura del código, la compilación, la firma digital, la custodia de las claves privadas, la definición del protocolo de auditoría, el control del laboratorio —todo, absolutamente todo— está en manos del TSJE y de MSA. Los partidos auditores no tienen control compartido sobre ninguna función crítica.
Sobre la auditoría postelectoral: los informes documentan que la máquina, una vez apagada, no retiene ningún estado. No existe memoria permanente. Por lo tanto, cualquier intento de auditoría después del cierre de la mesa es lógicamente imposible por diseño. No hay registro independiente que pueda ser auditado.
Sobre los boletines electrónicos: los chips RFID que contienen la información del voto —la única prueba independiente que permitiría verificar el resultado— son legalmente inaccesibles. El TSJE argumenta que no está estipulado su recuento. Así, la única evidencia que podría confrontarse con el acta firmada por los veedores duerme para siempre en un sobre que nadie abrirá.
Eso es lo que los auditores de los partidos ya informaron. No son especulaciones. Son hechos documentados, firmados, presentados.
III. La ironía técnica de la máquina "auditable pero inaccesible" (O cómo explicar Python y JavaScript no es lo mismo que permitir auditarlos)
La documentación técnica de las máquinas de votación Vot.Ar revela una arquitectura que, en apariencia, fue diseñada para ser transparente. El sistema operativo es un kernel Linux minimalista. El código de la lógica de votación está escrito en Python —para el control del hardware, la gestión del RFID, la impresión térmica y la criptografía— y en JavaScript —para la interfaz táctil, el renderizado de candidaturas y la navegación del elector. Son lenguajes de alto nivel, legibles, no ofuscados. En teoría, esta arquitectura debería facilitar la auditoría.
Pero la teoría se estrella contra una realidad tozuda, explicar cómo funcionan Python y JavaScript no es lo mismo que permitir auditarlos. Y lo que los auditores de los partidos documentaron es que, en la práctica, el acceso a ese código fue tan restringido que la ventaja teórica de la legibilidad se convirtió en una ironía amarga.
El rol de Python: el motor interno que nadie pudo inspeccionar
Python, en esta arquitectura, controla la lógica de bajo nivel, se comunica con los puertos de la placa madre, lee el chip RFID cuando se introduce el boletín, da la orden de grabación, traduce la selección del elector en comandos para la impresora térmica y ejecuta los algoritmos de firma digital de las actas de escrutinio. Es, literalmente, el núcleo de la decisión electoral. Lo que Python haga con el voto es lo que realmente cuenta.
Ahora bien, para auditar ese código Python, no basta con mirarlo en una pantalla. Hace falta poder ejecutarlo en un entorno controlado, introducir casos de prueba, modificar variables, verificar que las funciones de suma no contienen instrucciones condicionales ocultas. Hace falta, sobre todo, poder comparar el código Python que se mostró en el laboratorio con el código Python que efectivamente se carga en el USB maestro y se ejecuta el día de la elección.
Nada de eso fue posible. El código se revisó en computadoras del TSJE, sin posibilidad de copiarlo. No se pudo tomar ningún fragmento para analizarlo fuera del laboratorio. No se pudo ejecutar una prueba propia que verificara, por ejemplo, si la función `sumar_voto(candidato)` realmente suma al candidato que la pantalla mostró. El motor Python quedó, así, como un libro cerrado dentro de una vitrina: visible, pero intocable.
El rol de JavaScript: la interfaz que muestra pero no garantiza
JavaScript, por su parte, es el encargado de la experiencia del elector. Corre en un navegador ligero en modo kiosco —probablemente Chromium Embedded Framework— y se comunica con el backend de Python mediante llamadas internas. El elector toca la pantalla; JavaScript captura la coordenada, la traduce a una opción de candidato y envía esa opción a Python.
La pregunta que ningún auditor pudo responder —porque no se le permitió probar— es la siguiente ¿qué impide que JavaScript muestre en pantalla "Candidato A" pero envíe a Python "Candidato B"? La respuesta es: nada. Absolutamente nada, si el auditor no puede inspeccionar el código JavaScript real que se ejecuta y no puede inyectar su propio código de prueba para verificar la correspondencia entre lo que se muestra y lo que se envía.
Esta es la vulnerabilidad fundamental de cualquier sistema que separa la interfaz de usuario de la lógica de negocio. En una aplicación bancaria, eso se controla con auditorías continuas y trazabilidad. En una máquina de votación, donde el voto es secreto y no hay registro independiente accesible, esa separación es una puerta abierta a un fraude perfectamente indetectable para cualquier testigo humano.
La paradoja de la legibilidad sin acceso
La arquitectura basada en Python y JavaScript se presenta como una ventaja para la auditoría: al ser lenguajes de alto nivel, el código es más legible que un binario compilado en C o C++. Eso es cierto en abstracto. Pero en concreto, la legibilidad no sirve de nada si el auditor no puede copiar el código que se le muestra; ejecutarlo en su propio entorno; compararlo con el código que realmente se cargará en las máquinas; modificarlo para probar escenarios de fraude y verificar en tiempo de ejecución que el código que corre es el mismo que se auditó.
La ironía, entonces, es doble. Por un lado se usan tecnologías abiertas y transparentes para construir un sistema que se administra como si fuera un secreto de estado. Y por otro lado se celebra la legibilidad del código como garantía de transparencia, pero se impiden todas las acciones que harían efectiva esa legibilidad.
Es como si un bibliotecario le mostrara un libro a través de un vidrio blindado y le dijera, "Mire, está escrito en un idioma que usted entiende, puede leer el lomo. ¿No es maravilloso? Ahora confíe en que el contenido es el que dice ser, porque no le voy a dar el libro para que lo abra."
IV. Lo que la nueva verificación técnica puede y no puede aportar
Ahora, en mayo de 2026, la ANR y el PLRA realizan una nueva verificación técnica. La noticia informa que se desarmó la máquina, que se explicaron las antenas, los sistemas físicos de seguridad, los componentes uno por uno. Que todos quedaron satisfechos. Que no hubo observaciones asentadas en actas.
Todo eso es, sin duda, útil. Verificar la integridad física del hardware —que no hay dispositivos ocultos de transmisión, que las soldaduras son las correctas, que los puertos USB están limitados como se declaró— es una condición necesaria. Nadie sensato podría objetarlo.
Pero una condición necesaria no es una condición suficiente. Y aquí reside el límite infranqueable de esta nueva verificación, especialmente a la luz de la arquitectura Python/JavaScript que acabamos de describir.
Lo que esta verificación puede hacer es mostrar que la placa madre no tiene componentes extraños. Demostrar que las antenas RFID están correctamente instaladas. Explicar cómo la pantalla táctil traduce el toque en coordenadas —algo que, dicho sea de paso, no dice nada sobre lo que JavaScript hace con esas coordenadas. Verificar que los puertos USB no aceptan dispositivos no autorizados. Comprobar que el sistema arranca desde un USB firmado.
Lo que esta verificación no puede hacer, bajo las mismas reglas de febrero, y especialmente considerando la arquitectura Python/JavaScript, no puede garantizar que el código Python que se ejecutará el día de la elección sea el mismo que se auditó en febrero, porque no se permitió copiar ese código para una comparación posterior. No puede garantizar que el código JavaScript que muestra la interfaz no contiene instrucciones que desvíen el voto antes de enviarlo a Python, porque ese código sigue siendo inaccesible para una auditoría independiente. No puede probar el escenario de divergencia entre pantalla (JavaScript) y suma (Python), porque para probarlo se necesita ejecutar código propio en la máquina, y eso sigue sin estar permitido. No puede acceder al kernel del sistema operativo, porque la contraseña root sigue sin entregarse bajo el mismo argumento del "appliance cerrado". No puede verificar la cadena de custodia desde la compilación del código Python/JS hasta el USB de mesa, porque esa cadena sigue siendo controlada exclusivamente por el TSJE y MSA. No puede garantizar que el software no contiene instrucciones internas de desviación escritas en Python o JavaScript, porque sin acceso al código final y sin capacidad de ejecutar pruebas independientes, esa garantía es lógicamente imposible. No puede convertir los boletines electrónicos en evidencia accesible, porque la ley y el reglamento siguen sin estipular su recuento.
En otras palabras, esta nueva verificación opera exactamente bajo el mismo protocolo que los auditores de los partidos ya denunciaron como insuficiente. El hardware se desarma y se explica. El software —ese software escrito en Python y JavaScript que, por su propia naturaleza, debería ser el más fácil de auditar— sigue siendo una caja negra a la que nadie puede entrar.
Y esa es la ironía más fina de todas, se eligieron lenguajes transparentes para un sistema opaco, y ahora se celebra la transparencia de los lenguajes mientras se mantiene la opacidad del acceso.
V. La falacia de la "satisfacción" sin acceso completo
Que los representantes técnicos de la ANR y el PLRA declaren estar "sumamente satisfechos" es, por supuesto, su derecho. Pero conviene recordar que la satisfacción declarada no es lo mismo que la verificación independiente.
Un auditor puede estar satisfecho porque, dentro de las reglas que le impusieron, no encontró irregularidades evidentes. Eso es técnicamente cierto. Pero también es técnicamente cierto que esas reglas le impidieron buscar donde un fraude sofisticado podría esconderse —por ejemplo, en una función Python que suma correctamente 999 de cada 1000 votos, y desvía uno, o en una llamada de JavaScript que envía a Python una opción distinta a la que el elector vio en la pantalla.
La diferencia es crucial. Y puede formularse del siguiente modo:
- Afirmación A (verdadera): "En lo poco que nos dejaron ver, no vimos nada raro."
- Afirmación B (no demostrada): "No existe fraude posible."
La primera es una declaración de ausencia de hallazgos. La segunda es una declaración de ausencia de problemas. Son dos cosas lógicamente distintas. Y la primera no implica la segunda, como los propios auditores de los partidos se encargaron de señalar en sus informes.
Cuando un presidente de tribunal partidario declara que "desde las máquinas de votación es prácticamente nula la posibilidad de fraude", está haciendo la afirmación B. Pero la evidencia disponible —los informes de los auditores, con todas sus restricciones documentadas, y la imposibilidad de auditar el código Python/JavaScript en ejecución— solo respalda la afirmación A.
La diferencia entre una y otra es la diferencia entre una auditoría real y una auditoría teatral.
VI. Lo que aún falta para que una verificación sea creíble
Si el TSJE, MSA y los partidos políticos quisieran realmente generar confianza ciudadana, no bastaría con desarmar la máquina y explicar sus componentes. Haría falta, como mínimo, y atendiendo específicamente a la arquitectura Python/JavaScript:
Primero: permitir que los auditores copien el código fuente auditado —tanto el Python del backend como el JavaScript del frontend— y lo guarden bajo su propia custodia, para poder compararlo después con el código que se cargue en los USB.
Segundo: entregar la contraseña root o, en su defecto, proporcionar un método alternativo de acceso de bajo nivel que permita a los auditores verificar el estado interno del sistema operativo y, crucialmente, que el intérprete de Python y el motor de JavaScript que se ejecutan son los mismos que se declararon.
Tercero: diseñar y ejecutar pruebas específicas para el escenario de divergencia entre pantalla (JavaScript) y suma (Python), permitiendo a los auditores ejecutar su propio código de prueba en la máquina, inyectar eventos táctiles simulados y verificar qué llega realmente al backend.
Cuarto: documentar públicamente la cadena de custodia completa —desde la compilación del código Python/JS hasta la carga en los USB de mesa— con participación de los partidos en cada paso.
Quinto: modificar la normativa para que los boletines electrónicos (chips RFID) sean accesibles para una verificación posterior independiente, como única prueba que permitiría confrontar el acta firmada con el registro electrónico.
Nada de esto se ha hecho. Nada de esto se anuncia en la noticia. Y mientras no se haga, cualquier declaración de "satisfacción absoluta" será, cuanto menos, prematura.
VII. Conclusión: la verificación que no verifica lo que importa
La nueva verificación técnica de la ANR y el PLRA es, sin duda, un gesto político. Muestra que los partidos están presentes, que hacen preguntas, que desarman máquinas. Eso tiene valor en términos de imagen. Pero no tiene el valor que se le atribuye en términos de garantía técnica.
Porque la pregunta central —la que los ciudadanos harían si alguien se tomara el trabajo de explicársela con claridad— no es si la máquina tiene antenas bien soldadas o si la pantalla responde al tacto. La pregunta central es "¿Alguien que no sea el TSJE y MSA puede garantizar, con pruebas, que el software escrito en Python y JavaScript —ese software que controla el RFID, la impresora, la criptografía y la interfaz que el elector toca— es honesto, que suma lo que muestra, que no contiene instrucciones ocultas para desviar votos, y que el código que se ejecutará el día de la elección es exactamente el mismo que se mostró en la auditoría?"
La respuesta, a la luz de los informes de los auditores de los partidos y de la arquitectura técnica ahora conocida, es no.
Y esta nueva verificación —con las mismas reglas, las mismas limitaciones, el mismo control exclusivo del auditado, la misma imposibilidad de tocar el código Python/JavaScript en ejecución— no cambia esa respuesta.
El hardware se desarma. El software —ese software que, por estar escrito en Python y JavaScript, debería ser el más fácil de auditar— permanece cerrado. Las preguntas se responden. Las pruebas decisivas no se hacen. Los auditores declaran su satisfacción. Los informes previos documentan lo contrario.
El ciudadano, mientras tanto, solo puede esperar que esta vez —a diferencia de todas las veces en que la confianza ciega ha resultado traicionada— el lobo realmente esté cuidando el rebaño. O que alguien, algún día, le permita a los auditores abrir la caja negra de verdad. Porque mientras el código Python y JavaScript siga siendo un espectáculo que se mira sin tocar, la transparencia será solo eso: un espectáculo.
No hay comentarios:
Publicar un comentario