UmbralSeguro empezó resolviendo un problema concreto: cómo calibrar umbrales de decisión en un lector de doble modalidad sin disparar la tasa de rechazos legítimos. Ese trabajo derivó en una práctica de documentación abierta sobre FAR, FRR y arquitecturas de acceso adaptativo que hoy consultan equipos de seguridad física en plantas industriales, hospitales y sedes corporativas.
Los primeros proyectos se hicieron en accesos perimetrales con lectores de huella y tarjeta. La prioridad era medir con honestidad: registrar cada intento, separar fallos de sensor de fallos de política y revisar los umbrales cada vez que cambiaba la plantilla de turnos. De ahí salió la costumbre de publicar curvas de error en lugar de cifras sueltas.
Con más sedes conectadas apareció el problema real: un umbral que servía en recepción generaba rechazos en el muelle de carga. Empezamos a trabajar con umbrales por zona y por franja horaria, apoyados en eventos de contexto. La reducción de FRR sin subir FAR dejó de ser una promesa de folleto y pasó a ser una tarea de ingeniería con métricas semanales.
El paso siguiente fue sacar las reglas de las hojas de cálculo. Diseñamos una capa de políticas que consume eventos de la planta, roles de RRHH y señales de comportamiento para decidir en el punto de acceso. Documentamos los errores de tipo I y II que introduce cada automatismo, porque aplicar una política sin medir su costo en falsos positivos es la forma más rápida de perder la confianza del personal.
Cuando los modelos de reconocimiento entraron al flujo diario, el foco cambió a la degradación silenciosa. Incorporamos control de deriva de datos, revisión de la distribución de confianza y pruebas periódicas sobre conjuntos retenidos. Casos como el cambio de uniforme o la iluminación de invierno dejaron de ser sorpresas y pasaron a ser hipótesis que se verifican antes de tocar el modelo.
Hoy UmbralSeguro reúne notas técnicas, criterios de diseño y observaciones de campo para quienes tienen que decidir la arquitectura de control de acceso, no solo operarla. El objetivo sigue siendo el mismo que en el primer piloto: que cada umbral, cada política y cada modelo se pueda explicar con datos y sostener ante una auditoría.
No vendemos una plataforma cerrada. Publicamos criterios, mediciones y arquitecturas para quienes tienen que decidir dónde poner el umbral de aceptación, cómo medir FAR y FRR en producción y qué hacer cuando un modelo deja de responder igual que el primer día.
Arquitectos de seguridad, responsables de identidad y equipos de operaciones que ya tienen lectores biométricos instalados y necesitan ajustar políticas sin detener el flujo de personas. También para quienes están evaluando una primera integración y quieren entender el costo real de mantener un modelo vivo.
Un sistema que reconoce a la mayoría de las personas autorizadas sin obligarlas a repetir el gesto, y que rechaza lo suficiente como para no convertirse en una puerta abierta. Ese equilibrio no se logra con un producto, se logra calibrando umbrales, midiendo errores de tipo I y II por separado y revisando los datos cada vez que cambia la plantilla o la iluminación del edificio.
Preferimos políticas que se puedan auditar. Una regla que combina rol, horario, ubicación y nivel de riesgo es útil solo si alguien puede explicar por qué se activó. Por eso insistimos en separar la lógica de decisión del motor de inferencia, y en registrar cada evento con el contexto suficiente para reconstruirlo después.
Directo y sin promesas de precisión absoluta. Cuando un método tiene límites, los nombramos. Cuando una métrica depende del contexto de despliegue, lo aclaramos. Si algo todavía no está resuelto en la práctica, lo decimos en lugar de presentarlo como una función terminada.
Si tu equipo está revisando un despliegue de biometría o quiere contrastar criterios de calibración, escríbenos a info@footdrip.com o llámanos al +54 9 11 8262 2779. Atendemos consultas desde Las Orquídeas, Municipio de Formosa, Formosa, P3600IDK, Argentina.
Trabajamos con fabricantes de lectores, integradores de control de acceso y equipos de operaciones que ya operan en planta. La lista refleja acuerdos vigentes, no intenciones de marketing: cada nombre implica pruebas conjuntas, soporte cruzado y responsables técnicos identificables.
Este espacio nació de una constatación incómoda: la mayoría de los despliegues de control de acceso biométrico no fallan por falta de sensores, sino por decisiones de umbral tomadas a ciegas. Arquitectos y responsables de seguridad física necesitan un lugar donde comparar criterios, revisar curvas de error reales y entender qué cambia cuando se combinan modalidades. Aquí reunimos esa práctica, sin promesas de producto.
Cada recomendación que publicamos parte de una métrica concreta: tasa de falsos positivos, tasa de falsos rechazos, latencia de verificación o porcentaje de plantillas desactualizadas. Si un enfoque no puede medirse con esos indicadores, no lo presentamos como mejora.
Efecto esperado: menos pilotos que se estancan por falta de criterios de aceptación.Las políticas adaptativas que describimos siempre dejan un rastro auditable: qué evento disparó la decisión, qué regla se aplicó y qué modelo la respaldó. La automatización sin trazabilidad es un pasivo operativo, sobre todo cuando hay que justificar un rechazo ante auditoría o ante el propio empleado.
Efecto esperado: revisiones post-incidente que se resuelven en horas, no en semanas.No existe una configuración universal. Un banco con acceso a bóveda tolera un FRR alto; una planta con miles de entradas por turno no. Trabajamos el ajuste como una negociación documentada entre riesgo y fricción, con revisión periódica cuando cambia la plantilla de usuarios o el entorno físico.
Efecto esperado: umbrales que se defienden con datos ante cualquier comité de riesgo.Un modelo que funcionaba en laboratorio puede degradarse con un cambio de iluminación, una nueva dotación de uniformes o una actualización de firmware en los terminales. Publicamos métodos de monitoreo de deriva y protocolos de reentrenamiento pensados para equipos que no pueden detener la operación.
Efecto esperado: degradaciones detectadas antes de convertirse en incidentes de seguridad.No vendemos licencias ni recomendamos una marca por defecto. Comparamos arquitecturas, protocolos y costes operativos reales para que la decisión técnica quede en manos de quien va a mantener el sistema durante los próximos años.
Efecto esperado: elecciones tecnológicas sostenibles más allá del ciclo comercial del proveedor.