Validación automatizada y auditable de expedientes del Examen Único
Lo que hoy toma semanas de validación manual se procesa en horas, y cada decisión queda asentada en un registro que no se puede alterar.
Presentación directiva · Colegio de Bachilleres
Cada aspirante entrega identificación oficial (INE), certificado de estudios y fotografía. Hoy, una persona revisa cada documento: que esté completo, que se lea bien y que los datos coincidan entre sí.
El criterio varía
Entre auditores y a lo largo de la jornada: el cansancio pesa.
No queda evidencia
Nada registra por qué se aceptó o se rechazó cada expediente.
El talento se desperdicia
La gente más experimentada se va en los casos sencillos.
Expediente completo, legible y con datos consistentes.
Algo requiere criterio humano: se turna a un auditor con la evidencia ya organizada.
Solo por fallas objetivas y demostrables: falta un documento, no se puede leer, o los datos son inválidos.
Motor de validación. Pasa cada expediente por verificaciones sucesivas y emite un veredicto con su evidencia.
Plataforma de auditoría. Aplicación web donde el equipo ve los resultados de cada periodo, filtra los casos turnados al auditor y registra su dictamen final.
Registro de auditoría. Cada decisión, tanto de la máquina como del humano, queda sellada criptográficamente y no puede alterarse después.
Todo opera en la nube de Google (GCP), dentro de la infraestructura del proyecto: los documentos no salen a servicios de terceros.
Puerta de entrada Sin IA
¿Están los tres documentos? ¿Son archivos válidos y legibles?
Extracción con IA de visión IA · solo lectura
Un modelo de visión (VLM) lee los documentos una sola vez y extrae los datos: nombre, CURP, folio, institución, fechas.
Verificaciones con reglas fijas Sin IA
Reglas escritas en código comparan y validan: formato de CURP y folio, que los nombres coincidan entre documentos, vigencias y señales de la fotografía.
Veredicto + registro de auditoría sellado
Cada resultado queda documentado con su evidencia.
El mismo expediente da siempre el mismo veredicto.
Decisiones predecibles
Las reglas de validación son código, no criterio de un modelo: el mismo expediente, procesado dos veces, da exactamente el mismo resultado.
Cientos de pruebas automáticas verifican cada regla cada vez que algo cambia en el sistema.
La extracción con IA de visión es el único componente probabilístico, y está aislado detrás de una interfaz: si mañana existe un modelo mejor, se reemplaza sin tocar las reglas de decisión.
Filosofía conservadora
Vera valida que el expediente esté completo, legible y consistente. No juzga autenticidad: lo ambiguo se turna a un auditor.
Las señales complementarias, como la comparación facial o el QR del certificado, solo informan al auditor; no vetan a nadie.
Nadie es rechazado por una corazonada de un algoritmo.
Auditoría inmutable
Todo veredicto se guarda con un sello criptográfico (HMAC-SHA256), con qué se recibió, qué se extrajo, qué verificaciones corrieron y quién dictaminó al final.
| Dimensión | Validación manual | Con Vera |
|---|---|---|
| Velocidad | Semanas por periodo | Horas de procesamiento por lote |
| Consistencia | Varía por auditor, hora y fatiga | El mismo criterio, aplicado idéntico a cada expediente |
| Trazabilidad | Notas dispersas, si existen | Registro sellado e inalterable por cada decisión |
| Escalabilidad | Contratar y capacitar más gente en cada pico | El mismo sistema absorbe el pico; costo marginal mínimo por expediente |
| Uso del talento | Expertos revisando casos triviales | Expertos enfocados solo en los casos que requieren criterio |
| Errores por fatiga | Inevitables en jornadas largas | Inexistentes: el software no se cansa |
| Defensa ante controversias | Palabra del auditor | Evidencia criptográficamente verificable |
Con Vera, auditar deja de ser trabajo de línea de producción y vuelve a ser trabajo de criterio.
Cada caso turnado llega con
Los tres documentos a la vista.
Los datos extraídos de cada uno, lado a lado.
El detalle de cada verificación: cuáles pasaron, cuáles generaron la duda y por qué.
Un flujo de dictamen de un clic, que queda registrado y sellado.
El auditor ya no busca la discrepancia: la discrepancia le llega señalada. Su tiempo se dedica a decidir, no a detectar.
La lectura con el VLM ocurre dentro de la misma nube; nada pasa por servicios de terceros.
La plataforma exige identidad verificada (Google Sign-In) y solo entran los dominios de correo autorizados; todo lo demás se rechaza.
Los datos extraídos (CURP, nombres) solo los ve el personal autorizado, dentro de una herramienta interna.
Llaves y credenciales viven en Secret Manager, no en archivos ni en código.
Cierre
La pregunta no es si automatizar la revisión. Es si cada decisión sobre un aspirante quedará documentada, será consistente y podrá defenderse.
Vera: más rápido que todo un equipo auditor, más consistente que cualquier persona, y con memoria perfecta de cada decisión.
Material de respaldo
Láminas de respaldo para preguntas de perfil técnico.
Nube. Google Cloud Platform, región us-central1.
API. Servicio en Cloud Run: contenedores administrados, escala a cero.
Procesamiento por lotes. Cloud Run Job: un trabajo por periodo, ejecutado bajo demanda.
Base de datos. Cloud SQL (PostgreSQL) es la única fuente de verdad; la plataforma lee de la API, nunca de archivos estáticos.
Plataforma de auditoría. SPA (React) servida por Firebase Hosting, con la API bajo el mismo origen.
Extracción de visión. Un VLM alojado dentro del perímetro de GCP.
Infraestructura como código. Terraform; despliegue continuo vía GitHub Actions con identidad federada, sin llaves persistentes en el repositorio.
| Capa | Qué hace | Tecnología |
|---|---|---|
| 0a · Intake | Valida estructura del expediente: presencia de los 3 documentos, integridad de archivos, manejo de PDF. | Python puro, sin IA |
| 0b · Extracción | Una sola lectura de visión por expediente: extrae campos de INE, certificado y foto. | VLM en la nube, con reintentos ante errores transitorios |
| 1–4 · Verificaciones | Formato y validez de CURP/folio, consistencia de nombres entre documentos (con tolerancia a variaciones tipográficas), vigencias, señales de foto y QR. | Python puro, determinista, cubierto por pruebas |
Sello. HMAC-SHA256 con llave gestionada en Secret Manager; el sello se calcula al escribir y se verifica al leer.
Solo se agrega, nunca se modifica. No existen rutas de UPDATE/DELETE sobre registros de auditoría; los dictámenes humanos son filas nuevas selladas.
Contenido. Documentos recibidos, campos extraídos, resultado de cada verificación con su evidencia, veredicto, fecha y hora, identidad del dictaminador.
Cualquier alteración posterior del registro invalida el sello y es detectable de inmediato.
Pruebas automatizadas. Un conjunto extenso de pruebas del motor corre con cada cambio (integración continua sobre varias versiones de Python).
Análisis estático. Tipado verificado (mypy) y linting (ruff) como requisitos obligatorios para integrar cambios.
Escaneo de secretos en cada push (gitleaks).
Contrato de API congelado (OpenAPI): la plataforma se genera a partir del contrato; es imposible que se desalineen sin que se note.
Arquitectura desacoplada. El motor no depende de librerías pesadas de IA; cada integración (visión, base de datos, nube) es un adaptador reemplazable.
Revisiones adversariales de arquitectura y código, orientadas a encontrar fallas antes de que lleguen a operación.
Implicaciones de diseño
Las discrepancias de identidad (CURP o nombre) se turnan siempre a un auditor, nunca a rechazo automático.
La comparación facial es una señal informativa, jamás un veto.
El QR del certificado es una señal local complementaria; la verificación autoritativa contra portales oficiales es un paso futuro explícito.
Este modelo acota la responsabilidad del sistema a lo verificable y deja el juicio donde debe estar: en la institución.