/ Proyectos / Industria / Control de acceso con reconocimiento facial
Control de acceso con reconocimiento facial: de notebooks sueltos a un sistema que se puede desplegar
Detección y reconocimiento de rostros en tiempo real para registrar entradas y salidas en una planta, con un umbral de confianza que sabe cuándo decir "no te reconozco".
El objetivo era identificar personas por rostro al entrar o salir de una instalación, sin gafetes ni claves, usando solo una cámara y hardware modesto. El punto de partida era una serie de notebooks independientes: uno grababa el video de referencia, otro extraía el rostro, otro entrenaba el modelo, otro reconocía en tiempo real. Cada uno funcionaba por separado, con rutas de una sola máquina, y ninguno se podía correr fuera de ese entorno.
El reto técnico real no era solo entrenar un clasificador de rostros: era decidir qué hacer cuando la cámara ve a alguien que el sistema no conoce. Un control de acceso que siempre asigna la identidad más parecida, sin importar qué tan lejos esté esa coincidencia, es más peligroso que uno un poco menos preciso. Y el reto de ingeniería, menos evidente pero igual de importante, era convertir ese conjunto de scripts sueltos en algo que otra persona pudiera desplegar.
Mapa del casoContenido
- Diagrama de la solución. Los bloques del pipeline, de la cámara al registro de entrada/salida
- Construcción de la solución. Cómo pasar de scripts sueltos a un sistema desplegable
- Condiciones del proyecto. Restricciones reales y opciones descartadas antes de construir
- Pasos. Qué se dejó al agente y qué criterio se aplicó en cada uno
- Proceso de iteración. El ajuste documentado del umbral de confianza
- Descargables. Notebook, diagrama y repositorio del proyecto
- Lecciones importantes. La lección concreta que deja este caso
Estructura de alto nivelDiagrama de la solución
Pasa el cursor sobre cada bloque para ver qué hace ese paso.
Detección y reconocimiento se mantuvieron como dos funciones independientes, no un solo bloque, para poder cambiar el detector o el reconocedor por separado sin reescribir todo el pipeline.
Cómo se construyóConstrucción de la solución
Condiciones del proyecto
| Restricción | Dato |
|---|---|
| Hardware disponible | Una sola cámara y CPU modesta, sin GPU dedicada |
| Fotos por identidad | Pocas, del orden de una decena por persona |
| Requisito de seguridad | Distinguir "reconocido" de "desconocido", no solo dar el match más cercano |
| Estado del código original | 6 notebooks independientes, cada uno con rutas de una sola máquina |
| Opción | Por qué se descartó |
|---|---|
| Modelo preentrenado de embeddings faciales (tipo FaceNet/ArcFace) | Agrega precisión, pero también dependencia y latencia que no se justifican con tan pocas identidades |
| Reconocer siempre con el match más cercano, sin umbral | Da falsos positivos peligrosos en un sistema de control de acceso |
| Dejar los notebooks tal cual, "porque ya funcionaban" | No se podían desplegar ni reutilizar fuera del entorno donde se crearon |
| Consolidar en funciones reutilizables + LBPH liviano + umbral de confianza explícito | Corre en el hardware disponible y decide con seguridad cuándo no reconocer a alguien |
Pasos
Refactorización del código disperso en funciones
Agente: propuso mantener cada notebook igual, solo documentarlos mejor.
Criterio aplicado: consolidar todo en funciones reutilizables (detectar_rostro, registrar_evento) para que el sistema se pudiera importar y correr fuera del entorno original.
Elección del modelo de reconocimiento
Agente: sugirió un modelo preentrenado de embeddings faciales para mejor precisión.
Criterio aplicado: usar LBPH, más liviano e interpretable, suficiente para el volumen de identidades y el hardware disponible, dejando la puerta abierta a embeddings si el número de identidades crece.
Manejo de rostros no registrados con un umbral de confianza
Agente: dejó el sistema devolviendo siempre la identidad más parecida (top-1), sin importar qué tan lejos estuviera.
Criterio aplicado: definir un umbral de distancia explícito para declarar "desconocido" en vez de forzar un match, priorizando seguridad sobre cobertura.
Separación de detección y reconocimiento
Agente: mezclaba detección y reconocimiento en un mismo bloque de código.
Criterio aplicado: separarlos en funciones independientes, detectar primero, reconocer después, para poder cambiar una pieza sin tocar la otra.
Proceso de iteración
Ajuste documentado, no forzado
Las primeras pruebas del umbral de confianza rechazaban identidades válidas cuando la iluminación del video de referencia no coincidía con la del punto de acceso real. Un umbral genérico, copiado de otro proyecto, no funcionó: tuvo que calibrarse con ejemplos capturados en las condiciones reales de la cámara final. Incluso así, el sistema necesita recalibrarse si cambia la iluminación del sitio, una limitación real que no desaparece solo con mejor código.
CierreLecciones importantes
El cambio de mayor impacto no fue el modelo, fue la refactorización: pasar de seis notebooks con rutas fijas de una sola máquina a funciones que cualquiera puede importar. Eso es lo que separa un proyecto que se queda archivado de uno que se puede desplegar de verdad.
Y el umbral de "desconocido" pesa más que la precisión bruta del modelo. Un sistema de control de acceso que nunca admite no reconocer a alguien es más riesgoso que uno un poco menos preciso pero honesto sobre sus límites.
Si quieres ver un enfoque publicado reciente sobre reconocimiento facial ligero para control de acceso en entornos con recursos limitados, este es un buen punto de referencia del nivel técnico: Real-time face recognition based access control system.
Termina ya tu proyecto
¿Tienes un proyecto similar y no sabes por dónde empezar? Yo te ayudo a diseñarlo.
El 92% de los profesionales de datos desbloquea sus proyectos al ver ejemplos completos resueltos.
Sin registro. Acceso inmediato