Fallas del Sistema Electoral Honduras 2025: Análisis Técnico del ICR, Biométrico y TREP
Evaluación Técnica de Fallas Electorales en Honduras (2025): Claves para un Sistema Robusto
Aclaración Necesaria:
En ZelvaIT, creemos que la tecnología debe fortalecer las instituciones. Publicamos este análisis técnico, libre de afinidades políticas, como un aporte al debate profesional sobre los estándares de ingeniería en sistemas de misión crítica. Nuestro único interés es promover las mejores prácticas de desarrollo robusto, seguro y auditable.
Carlos Zelaya Irías – CEO ZelvaIT
1. Introducción
Los sistemas de transmisión, identificación del votante y divulgación de resultados constituyen infraestructura crítica para cualquier democracia. En las elecciones generales de Honduras de 2025, estos componentes quedaron nuevamente bajo escrutinio público por fallas técnicas, retrasos y dudas sobre su confiabilidad.
Este ensayo analiza, desde una perspectiva estrictamente técnica e imparcial:
- La arquitectura general del sistema electoral digital.
- Las fallas en:
- el sistema de transmisión y divulgación (TREP + portal web),
- los dispositivos biométricos,
- el módulo de reconocimiento automático de actas (ICR/OCR).
- La evidencia empírica disponible, incluyendo:
- un acta específica (JRV 07213) con su JSON de transmisión,
- un análisis agregado sobre más de 17,000 urnas digitalizadas a nivel nacional.
El objetivo no es dirimir disputas políticas, sino evaluar si el diseño e implementación tecnológica cumplen con los estándares mínimos de robustez, integridad y auditabilidad exigibles a un sistema electoral moderno.
2. Arquitectura general del sistema electoral digital (2025)
En 2025, el ecosistema tecnológico electoral hondureño puede dividirse en tres capas principales:
2.1 Capa de identificación del votante (Biométrico)
- Dispositivos en cada Junta Receptora de Votos (JRV) para validar la huella dactilar del elector.
- Herramienta central para prevenir suplantación de identidad.
- Proveedor principal responsable del sistema biométrico a nivel nacional.
2.2 Capa de captura y transmisión de resultados (TREP)
Digitalización de los datos del acta en la JRV. Transmisión de imágenes y datos a servidores centrales. Registro de metadatos, incluyendo:
- hash del acta,
- dirección IP,
- código de equipo,
- fechas de digitalización, procesamiento ICR, transmisión y recepción.
- Módulo ICR/OCR para leer numéricamente los datos manuscritos de las actas.
- Corrección manual sobre los datos ICR cuando se detectan errores o inconsistencias.
Recepción y validación inicial de resultados. Una vez que el acta llega a los servidores centrales, el sistema debería ejecutar una serie de validaciones técnicas esenciales antes de permitir que continúe el proceso:
- Verificación de integridad del archivo (coincidencia del hash transmitido con el hash calculado en recepción).
- Confirmación de estructura y formato del archivo JSON asociado al acta.
- Validación de rangos numéricos (ningún valor puede exceder el total de papeletas, ni valores negativos, ni campos vacíos en datos críticos).
- Reglas de coherencia interna, como:
- votos totales = suma de votos por partido + blancos + nulos,
- total de votantes = ciudadanos + miembros de JRV,
- papeletas utilizadas = papeletas recibidas – sobrantes.
- Clasificación automática del acta en una de estas categorías:
- válida para procesamiento,
- inconsistente (requiere revisión manual),
- pendiente por error estructural.
2.3 Capa de digitalización automática y divulgación
- Portal web de divulgación de resultados preliminares al público.
En teoría, el flujo debería ser:
- Identificación biométrica del votante.
- Cierre de mesa, llenado de acta, escaneo y aplicación de ICR.
- Validación automática y, cuando sea necesario, validación manual.
- Transmisión al centro de cómputo y consolidación.
- Publicación en el portal de resultados.
En la práctica, las fallas en cada capa debilitaron el sistema completo.
3. Fallas críticas identificadas
3.1 Disponibilidad del portal de resultados
Durante la noche electoral y las horas posteriores, el portal oficial de resultados presentó:
- Caídas repetidas.
- Periodos de inactividad.
- Suspensión de la publicación con el argumento de “mantenimiento” sin aviso previo.
Técnicamente, esto indica:
- Arquitectura de alta disponibilidad insuficiente (falta de redundancia activa-activa).
- Ausencia de mecanismos de failover geográfico.
- Monitoreo principalmente reactivo, no preventivo.
En sistemas electorales, la disponibilidad debe ser cercana a 99.99 % en la ventana crítica. Las interrupciones minan la capacidad de la ciudadanía y los veedores de seguir la evolución del conteo.
3.2 Capacidad y rendimiento insuficientes
La plataforma de resultados fue diseñada contractualmente para soportar del orden de cientos de miles de consultas por segundo, pero en la práctica colapsó ante la demanda real, dejando al público sin acceso durante periodos prolongados.
Desde un punto de vista de ingeniería de rendimiento:
- No se evidencian pruebas de carga masivas previas a nivel nacional.
- Es probable la existencia de cuellos de botella en:
- balanceadores de carga,
- motor de base de datos,
- capa de API,
- almacenamiento de imágenes.
El resultado: un sistema vulnerable a una especie de “auto-DDoS” legítimo (simplemente por el tráfico ciudadano) y sin margen frente a ataques externos dirigidos.
3.3 Integridad y pipeline de procesamiento de actas
Registros oficiales y comunicaciones públicas reconocen que:
- Hubo actas transmitidas que quedaron “pendientes de procesamiento” durante horas.
- Se marcaron miles de actas con “inconsistencias”, requiriendo revisión especial.
Esto apunta a problemas en el pipeline de datos:
- Colas de mensajes saturadas.
- Procesos asincrónicos sin mecanismos de idempotencia.
- Posibles bloqueos o tiempos de espera en la base de datos bajo alta concurrencia.
- Falta de reglas automáticas robustas de validación cruzada entre campos, como:
- “total de votantes”,
- “votos por partido”,
- “votos nulos/blancos”.
Aunque estos problemas pudieron ser corregidos posteriormente de manera manual, en un sistema electoral crítico no debería dependerse de correcciones ex post, sino de validaciones robustas ex ante.
3.4 Auditoría y trazabilidad insuficientes
Un sistema electoral digital robusto debe ofrecer:
- Logs inmutables (WORM).
- Hashing criptográfico end-to-end por acta.
- Trazabilidad desde la captura en mesa hasta la publicación.
- Acceso supervisado a auditores independientes.
En 2025:
- No hay evidencia pública de un mecanismo de auditoría integral accesible a observadores externos.
- No se ha publicado un esquema claro de cómo se registran, custodian y auditan:
- los logs técnicos del TREP,
- los modelos y parámetros del sistema ICR/OCR.
Esto no prueba manipulación, pero sí limita la capacidad de demostrar lo contrario. Se trata de una falla de diseño de gobernanza tecnológica.
3.5 Fallas en el sistema de identificación biométrica
La capa biométrica también presentó problemas relevantes:
- Múltiples reportes de fallas operativas, incluyendo lectores que no capturaban huellas, fallas de conectividad y necesidad de intentar varias veces.
- Casos documentados de ciudadanos que debieron repetir la lectura de huella 2 o 3 veces para poder ejercer el voto.
- Retrasos en la apertura de urnas y aglomeraciones en centros de votación por problemas en el dispositivo biométrico.
Desde la óptica técnica:
- Hay un desacople entre el diseño del sistema y la realidad del usuario: un lector de huellas para fines electorales debe tolerar variaciones relevantes en la calidad de las huellas y operar adecuadamente en condiciones de campo, no solo en laboratorio.
- La dependencia excesiva en la biometría como “puerta de entrada” al proceso, aun cuando existan protocolos alternos en caso de fallo, introduce un punto único de falla que afecta la fluidez de la jornada.
Conclusión técnica parcial: el sistema biométrico no estaba preparado para la combinación de hardware, condiciones de uso y perfil de huella de la población hondureña; además, su desempeño dependió de una capacitación que resultó insuficiente para el personal de mesa.
3.6 Fallas del módulo ICR/OCR – Caso puntual JRV 07213
La información disponible de la JRV 07213 (Choluteca) permite analizar con precisión el comportamiento del módulo ICR/OCR. El archivo JSON de transmisión contiene los siguientes datos:
"votos": [
{
"cantidadVotos": 344,
"cantidadVotosICR": 4,
"correccionManual": true,
"nombreCandidato": "RECIBIDAS SEGUN ACTA DE APERTURA"
},
{
"cantidadVotos": 147,
"cantidadVotosICR": 0,
"correccionManual": true,
"nombreCandidato": "NO UTILIZADAS / SOBRANTES"
},
{
"cantidadVotos": 197,
"cantidadVotosICR": 0,
"correccionManual": true,
"nombreCandidato": "UTILIZADAS"
},
{
"cantidadVotos": 189,
"cantidadVotosICR": 14,
"correccionManual": true,
"nombreCandidato": "CIUDADANOS QUE VOTARON SEGUN CUADERNO DE VOTACION"
},
{
"cantidadVotos": 6,
"cantidadVotosICR": 811,
"correccionManual": true,
"nombreCandidato": "MIEMBROS JRV"
},
{
"cantidadVotos": 2,
"cantidadVotosICR": 80,
"correccionManual": true,
"nombreCandidato": "CUSTODIOS INFORMATICOS ELECTORALES"
},
{
"cantidadVotos": 197,
"cantidadVotosICR": 80,
"correccionManual": true,
"nombreCandidato": "TOTAL DE VOTANTES"
},
{
"cantidadVotos": 6,
"cantidadVotosICR": 656,
"correccionManual": true,
"nombrePartido": "PARTIDO DEMOCRATA CRISTIANO DE HONDURAS",
"nombreCandidato": "PARTIDO DEMOCRATA CRISTIANO DE HONDURAS"
},
{
"cantidadVotos": 15,
"cantidadVotosICR": 66,
"correccionManual": true,
"nombrePartido": "PARTIDO LIBERTAD Y REFUNDACION",
"nombreCandidato": "PARTIDO LIBERTAD Y REFUNDACION"
},
{
"cantidadVotos": 3,
"cantidadVotosICR": 881,
"correccionManual": true,
"nombrePartido": "PARTIDO INNOVACION Y UNIDAD SOCIAL DEMOCRATA",
"nombreCandidato": "PARTIDO INNOVACION Y UNIDAD SOCIAL DEMOCRATA"
},
{
"cantidadVotos": 55,
"cantidadVotosICR": 841,
"correccionManual": true,
"nombrePartido": "PARTIDO LIBERAL DE HONDURAS",
"nombreCandidato": "PARTIDO LIBERAL DE HONDURAS"
},
{
"cantidadVotos": 117,
"cantidadVotosICR": 818,
"correccionManual": true,
"nombrePartido": "PARTIDO NACIONAL DE HONDURAS",
"nombreCandidato": "PARTIDO NACIONAL DE HONDURAS"
},
{
"cantidadVotos": 0,
"cantidadVotosICR": 850,
"correccionManual": true,
"nombrePartido": "TOTALES",
"nombreCandidato": "VOTOS EN BLANCO"
},En este mismo JSON de transmisión de esta urna se observa:
correccionManual: trueinconsistencias: truefechaIcr: "2025-11-30 22:40:22"
Para cada concepto (partido o categoría de voto), se registran dos campos:
cantidadVotosICR: lectura automática del acta manuscrita.cantidadVotos: valor corregido manualmente.
En el ejemplo se observa:
- PARTIDO LIBERAL DE HONDURAS
cantidadVotosICR: 841cantidadVotos: 55
- PARTIDO NACIONAL DE HONDURAS
cantidadVotosICR: 818cantidadVotos: 117
- PARTIDO LIBERTAD Y REFUNDACIÓN (LIBRE)
cantidadVotosICR: 66cantidadVotos: 15
- PARTIDO INNOVACIÓN Y UNIDAD (PINU)
cantidadVotosICR: 881cantidadVotos: 3
- PARTIDO DEMÓCRATA CRISTIANO (DC)
cantidadVotosICR: 656cantidadVotos: 6
- VOTOS EN BLANCO
cantidadVotosICR: 850cantidadVotos: 0
- VOTOS NULOS
cantidadVotosICR: 480cantidadVotos: 1
En todos los casos, los valores provenientes del ICR:
- Exceden por mucho el máximo razonable de votos por una JRV (unas pocas centenas).
- No guardan relación proporcional con los valores reales manuscritos.
- Presentan magnitudes del orden de 600–800 votos por campo, claramente imposibles para una sola mesa.
La imagen del acta muestra números manuscritos claros y legibles, que cualquier humano podría interpretar correctamente en segundos. Sin embargo, el módulo ICR:
- Interpreta ruido visual, sombreado o trazos accesorios como dígitos adicionales.
- No aplica reglas mínimas de validación de rango (por ejemplo, que ningún campo supere el total de papeletas recibidas).
- No realiza controles de coherencia (por ejemplo, que la suma de votos por partido no exceda el “gran total”).
Por ello, el sistema marca esta acta como:
inconsistencias: truecorreccionManual: true
y, en la práctica, todo el conteo de votos de la JRV 07213 fue corregido manualmente antes de divulgarse. Sin embargo, esta corrección introdujo datos que no corresponden a los que están manuscritos en el acta original.
Es necesario aclarar que en el sistema del Consejo Nacional Anticorrupción esta misma acta está digitada correctamente –> Ver Aquí
3.7 Fallas del módulo ICR/OCR – Evidencia agregada (17,000+ urnas)
Más allá del caso puntual, un análisis estadístico sobre más de 17,000 urnas permite evaluar el desempeño del ICR a nivel nacional.
El conjunto de datos incluye, por departamento:
- Total de actas.
- Número de actas con corrección manual.
- Totales de votos manuales e ICR por partido y tipo de voto (blancos, nulos).
- Totales de votos manuales e ICR sumando todos los partidos y categorías.
3.7.1 Corrección manual en el 100 % de las actas
En todos los departamentos se cumple que:
Actas con corrección manual = Total de actas
Es decir, cada urna del país requirió intervención manual sobre los datos provenientes del ICR. No existe un solo departamento donde el módulo ICR pueda considerarse confiable por sí mismo.
3.7.2 Inflación masiva de votos ICR
El cociente:
Total de votos ICR / Total de votos manuales
oscila aproximadamente entre 5.3 y 7.2, con un promedio cercano a 6.4 veces más votos en la lectura ICR que en los resultados manuales reales.
Ejemplos ilustrativos:
- Departamento de Atlántida
- Total de votos manuales (partidos + blancos + nulos): ≈ 142,713
- Total de votos ICR: ≈ 881,207
- Relación ≈ 6.17 veces más votos por ICR que en el conteo real.
- Departamento de Choluteca
- Votos manuales: ≈ 225,595
- Votos ICR: ≈ 1,381,065
- Relación ≈ 6.12 veces más.
Esta magnitud de error es estadísticamente incompatible con un sistema OCR medianamente funcional; muestra un error estructural, no un ruido marginal.
Este patrón se repite en los distintos departamentos y en todas las fuerzas políticas, sin favorecer sistemáticamente a una sola. Técnicamente, esto describe un algoritmo disfuncional, no un sesgo selectivo.
Observaciones técnicas:
Todas las fuerzas políticas están afectadas, incluyendo explícitamente al Partido Liberal de Honduras, al Partido Nacional, Libre, DC, PINU, votos en blanco y nulos.
Para el Partido Liberal, el ICR asigna en ese ejemplo alrededor de 2.5 veces más votos que los registrados manualmente.
Para partidos pequeños como DC y PINU, el ICR llega a inflar los votos en órdenes de magnitud mucho mayores (decenas de veces), lo que confirma que el sistema está reconociendo ruido como si fueran dígitos válidos.
3.7.3 Conclusión técnica sobre el ICR
A partir del caso puntual y del análisis agregado:
- El módulo ICR/OCR no cumple ningún estándar mínimo de calidad para su uso en procesos electorales.
- Sus salidas son:
- masivamente infladas,
- no correlacionadas de forma lineal con los valores reales,
- incapaces de respetar los límites lógicos del sistema (máximo de votos por urna).
- La necesidad de corrección manual en el 100 % de las actas indica que, en la práctica, el conteo efectivo se basa en el trabajo humano, no en la digitalización automática.
En otras palabras: el ICR fue, en la práctica, un ruido costoso e ineficiente interpuesto entre el acta y el sistema, que luego hubo que limpiar manualmente.
3.8 Gobernanza tecnológica y captura institucional
Aunque este ensayo evita afirmaciones sobre intencionalidad política, sí es relevante, desde el punto de vista técnico-institucional, que:
- La contratación de proveedores clave se ha realizado en varias elecciones bajo fuerte presión temporal.
- No existe una unidad técnica permanente, independiente de los ciclos políticos, que defina estándares, supervise implementaciones y certifique proveedores.
- El diseño y los cambios al sistema (incluyendo TREP, biométrico e ICR) han estado sometidos a negociaciones políticas, no solo a criterios técnicos.
Este marco de gobernanza débil actúa como multiplicador de riesgo: incluso una buena tecnología puede fracasar si se inserta en un contexto institucional mal diseñado.
3.9 Dimensión socio-técnica: procesos y capacitación
Finalmente, las observaciones de campo describen:
- Falta de capacitación adecuada a miembros de JRV y personal técnico.
- Errores en el uso de equipos biométricos.
- Retrasos en la apertura por improvisación en el montaje de hardware y software.
El problema no es únicamente “tecnología que falla”, sino un ecosistema donde:
- Los usuarios no son entrenados exhaustivamente.
- Los manuales no están adaptados a condiciones reales.
- Los procesos no contemplan todos los escenarios de fallo (conectividad, energía, reemplazo de dispositivos, etc.).
4. Patrón técnico recurrente (2017–2021–2025)
Al observar tres ciclos electorales consecutivos se identifica un patrón:
- Contratación tardía y bajo presión de proveedores tecnológicos.
- Implementación acelerada sin simulacros nacionales suficientes.
- Fallas graves en componentes clave (biométrico, TREP, divulgación, ahora ICR).
- Necesidad de correcciones manuales masivas.
- Ausencia de auditoría técnica abierta y verificable.
- Crisis de confianza pública.
Este patrón no demuestra por sí mismo manipulación de resultados, pero sí evidencia una arquitectura institucional y tecnológica vulnerable, en la que fallas previsibles se repiten sin correcciones estructurales.
5. Lecciones técnicas y recomendaciones
5.1 Arquitectura de transmisión y divulgación
- Migrar hacia una arquitectura orientada a eventos con colas distribuidas (por ejemplo, Kafka o RabbitMQ) y microservicios.
- Definir umbrales de carga y autoescalado con pruebas de estrés que superen el peor escenario posible.
- Replicar el sistema en múltiples regiones geográficas con failover automático.
5.2 Sistema biométrico
- Sustituir o recalibrar el hardware para entornos de alta fricción (huellas desgastadas, humedad, variaciones ambientales).
- Implementar un modelo de autenticación multi-factor sencillo (biometría + documento + lista) en lugar de depender únicamente del lector.
- Realizar simulacros masivos con ciudadanos reales, no solo pruebas de laboratorio.
5.3 Módulo ICR/OCR
- Suspender su uso como fuente primaria de conteo mientras no cumpla estándares de precisión verificables.
- Rediseñar el pipeline de procesamiento:
- Preprocesamiento de imagen (contraste, binarización, corrección de perspectiva).
- Segmentación por zonas (Zonal OCR) con plantillas fijas para cada tipo de acta.
- Entrenamiento del modelo con actas reales hondureñas, incluyendo variaciones de caligrafía.
- Validaciones de rango (ningún campo puede exceder el máximo teórico de papeletas).
- Validaciones de consistencia (suma de votos por partido = gran total, coherencia entre “utilizadas”, “total de votantes” y “votos emitidos”).
- Publicar métricas de desempeño (tasa de error por campo, por partido, por departamento) y someter el modelo a auditoría independiente.
5.4 Auditoría y transparencia
- Implementar logs WORM para todos los eventos críticos, con hash público verificable.
- Publicar el código fuente del sistema de conteo e ICR bajo un modelo de auditoría abierta (“open audit”).
- Otorgar acceso supervisado a universidades y organismos especializados para revisar modelos, parámetros y datos.
5.5 Gobernanza tecnológica
- Crear una unidad técnica electoral permanente con autonomía respecto al ciclo político.
- Establecer normas técnicas obligatorias (simulacros, métricas mínimas de precisión, SLAs de disponibilidad).
- Prohibir el uso en producción de componentes (como un ICR de baja precisión) que no hayan superado baterías de prueba con estándares internacionales.
6. Conclusión
El análisis de la infraestructura digital electoral hondureña en 2025 revela un sistema que, más que estar respaldado por la tecnología, queda expuesto por ella. Las fallas en la disponibilidad del portal, en el rendimiento del TREP, en la identificación biométrica y, de manera especialmente grave, en el módulo ICR/OCR, muestran un ecosistema que no ha sido diseñado ni gobernado como infraestructura crítica, a pesar de que su impacto social y político sí lo es.
La evidencia empírica —desde el caso puntual de la JRV 07213 hasta el análisis agregado de más de 17,000 urnas— demuestra que:
- El ICR produce resultados masivamente erróneos para todas las fuerzas políticas, incluyendo explícitamente al Partido Liberal de Honduras, al Partido Nacional, Libre, DC, PINU, votos en blanco y nulos.
- El sistema biométrico no está calibrado para la realidad operativa y social del país.
- La robustez del proceso depende, en última instancia, del trabajo manual de miles de personas, no de los sistemas automatizados que deberían asistirlas.
Corregir esta situación exige mucho más que cambiar un proveedor o ajustar un algoritmo: requiere una reingeniería completa de la arquitectura técnica, de los procesos de prueba y de la gobernanza tecnológica electoral. Sin ello, la desconfianza seguirá repitiéndose en cada ciclo, independientemente de quién gane o pierda.