El control de accesos se compra normalmente como producto de seguridad y luego se engancha a recursos humanos con un CSV de números de tarjeta. En un entorno Odoo, la misma integración puede ser una tubería de autorización controlada con rastro de auditoría, o una exportación nocturna que mantiene autorizado a un contratista seis semanas después de que terminó su contrato. La diferencia es diseño, no hardware.

El control de accesos es un proceso de autorización que acaba en una puerta

La cerradura responde si la credencial es válida en este segundo; el ERP responde si la persona debería estar aquí.

La emisión de tarjetas, el permiso por zona y la revocación son procesos de datos maestros con dueños.
Cada paso manual entre RRHH y la puerta es una escalada de privilegios silenciosa.
Seguridad necesita pruebas tras un incidente y operaciones necesita velocidad durante un turno.
Odoo suele ser el único lugar donde se cruzan empleados, contratistas y proyectos.
Decide qué sistema manda en cada campo y déjalo por escrito.

Reparte responsabilidades según la latencia

Una decisión de puerta no puede esperar una petición web, y una nómina no debería editarse desde una puerta.

El controlador manda en milisegundos, anti-passback y funcionamiento sin red.
Odoo manda en el padrón, la matriz de zonas, las fechas de vigencia y la consulta de auditoría.
Empuja permisos hacia fuera; no pidas a Odoo que abra puertas en tiempo real.
Diseña la política en caché para que la sede siga segura y usable sin Odoo.
Registra la divergencia: las excepciones locales solo son legítimas si quedan visibles después.

Modela personas, credenciales y zonas por separado

Casi todas las integraciones funden tres objetos en una fila y luego no responden preguntas simples.

Una persona -empleado, contratista o visitante- puede tener varias credenciales con el tiempo.
Una credencial es un objeto físico con ciclo de vida: emitida, activa, perdida, revocada, sustituida.
Una zona es un ámbito lógico con política; las puertas son hardware colgado de ella.
Un permiso une persona y zona durante un periodo, con motivo y aprobador.
Nunca guardes un único indicador de acceso; guarda el permiso con fechas, o la revocación se vuelve adivinación.

Qué vive en Odoo y qué no

El ERP es buen sistema de registro para autorizaciones y mal lugar para secretos.

hr.employee más un modelo de contratistas aporta identidad, responsable y fin de contrato.
Un modelo de permisos pequeño basta: persona, zona, desde, hasta, aprobador, estado.
Mantenimiento y proyectos dicen quién se espera en planta y cuándo.
Evita replicar números de tarjeta; guarda un token o una referencia con hash.
Fotos y plantillas biométricas se quedan en el sistema de accesos, con su propia retención.

Empuja permisos, recoge eventos

Dos direcciones, dos contratos, y ninguno debería ser un acoplamiento síncrono.

Salida: Odoo calcula el estado deseado por persona y envía deltas al controlador.
Entrada: el controlador envía eventos de concedido, denegado, puerta abierta y forzado a una cola.
Ambas direcciones necesitan una clave de persona estable ante reorganizaciones y reingresos.
Sincroniza la salida por lotes cada pocos minutos; la propagación por clic no es necesaria ni fiable.
Alerta sobre desviaciones, sobre todo permisos que existen en el controlador y no en Odoo.

Un flujo de eventos idempotente y reproducible

Los eventos son el rastro de auditoría y deben sobrevivir reintentos, reinicios y tardes malas.

Da a cada evento un identificador generado por el controlador y deduplica al ingerir.
Aterriza los eventos en una tabla de staging antes de proyectarlos en modelos de Odoo.
Conserva los eventos según la política y borra con calendario, no por accidente.
Las reproducciones no deben duplicar asistencia, partes de horas ni órdenes de trabajo.
Informa el retraso: la edad del evento más reciente es mejor señal que un panel verde.

Mínimo privilegio con horario, escolta y caducidad

El acceso permanente debería ser la excepción, y cada excepción necesita un dueño con nombre.

Los permisos caducan por defecto; uno permanente exige aprobación y fecha de revisión.
Los permisos de contratistas deben terminar con el contrato, no con la memoria de alguien.
Ventanas horarias y reglas de escolta pertenecen a la política, no a un post-it en la puerta.
Separa poder entrar de poder operar: una sala de máquinas no es un pasillo de oficinas.
Revisa la matriz de zonas cada trimestre; el entregable es el informe, no la puerta.

Los fallos que de verdad provocan incidentes

Casi todos los incidentes de acceso son fallos de integración que parecen errores humanos.

Una tarjeta revocada sigue funcionando porque el controlador la cacheó y la sincronización paró.
La deriva de reloj entre controlador y servidor hace improbable el orden de los eventos.
Un anti-passback demasiado estricto deja a la gente fuera al reingresar tras una evacuación.
El colado se trata como problema de software cuando es físico y cultural.
Un contratista con contrato vencido sigue en el padrón porque nadie cerró el registro de RRHH.

Auditoría, privacidad y las preguntas que llegarán

Tras un incidente, la pregunta nunca es si la puerta funcionó, sino quién tenía permiso.

Poder responder quién estaba autorizado en la zona X en una fecha, desde los permisos guardados.
Aplica limitación de finalidad: los datos de acceso sirven a seguridad, no a evaluación de desempeño.
Define retención por clase de dato y automatiza el borrado en lugar de prometerlo.
El acceso al sistema de accesos es privilegiado; registra los cambios de administrador aparte.
Si hay biometría, documenta la base legal y mantén las plantillas fuera del ERP.

Despliegue: primero en sombra, luego en aplicación

Secuencia la integración para que las primeras denegaciones salgan baratas.

Modo sombra: Odoo calcula permisos, el controlador conserva su lista y se compara a diario.
Limpia el padrón antes de aplicar, porque datos de identidad sucios producen denegaciones falsas.
Aplica una zona cada vez, empezando por la puerta de menor riesgo y una población pequeña.
Ensaya el escenario sin red y el de evacuación con el equipo de seguridad.
Publica un proceso de excepciones de una página, o los supervisores inventarán el suyo.

Documenta además el criterio de éxito del piloto: cuántas denegaciones se revisaron, cuánto tardó resolver una excepción y si al cierre del periodo quedó algún acceso sin justificar. Sin ese criterio, la fase de sombra se eterniza y la organización vuelve al CSV.