Cuando una operación de alimentación corporativa crece a múltiples sedes, turnos y equipos, la seguridad de la información deja de ser un tema exclusivamente de IT. El encargado de cocina de una sede no debería poder ver los costos de otra. El cliente corporativo no debería acceder a los datos de otros clientes. El operador de turno noche no debería poder modificar el menú de la próxima semana.
Estos son problemas de diseño de accesos, no de tecnología. La tecnología los implementa, pero el diseño lo tienen que hacer las personas que conocen la operación.
Por qué RBAC en gastronomía no es opcional
RBAC (control de acceso basado en roles) es el modelo estándar para gestionar permisos en sistemas empresariales. En gastronomía corporativa con equipos distribuidos, aplicarlo bien tiene implicaciones directas en la operación:
- Confidencialidad comercial: los márgenes por cliente, los precios de contrato y las condiciones con proveedores son información sensible que no todos los empleados deben ver.
- Integridad operativa: un cambio no autorizado en una receta o en los precios del menú puede tener consecuencias en cadena (costos incorrectos, facturas erróneas, producción mal calculada).
- Responsabilidad trazable: cuando ocurre un error, hay que poder saber quién hizo qué y cuándo. Sin roles bien definidos, la auditoría es imposible.
Diseño de roles para operaciones gastronómicas
No existe un esquema de roles universal, pero el siguiente modelo cubre la mayoría de los casos en alimentación corporativa argentina:
Operador de cocina
- Acceso a: planilla de producción del día, recetas asociadas a su turno, registro de merma.
- Sin acceso a: costos de insumos, información de otros clientes, configuración de menú, datos de facturación.
- Restricción de sede: solo ve la información de la sede donde opera.
Supervisor de operaciones
- Acceso a: planillas de producción de todas las cocinas bajo su supervisión, reportes de cumplimiento, alertas de desvío.
- Sin acceso a: configuración de contratos, precios a cliente, información financiera.
- Restricción de sede: según el alcance de su supervisión (puede ser multisede).
Administrador de cuenta
- Acceso a: toda la información operativa y comercial del cliente o los clientes a su cargo.
- Sin acceso a: configuración del sistema, gestión de otros administradores, datos de clientes que no gestiona.
Finanzas / Administración
- Acceso a: reportes de facturación, histórico de consumo, datos de proveedores y condiciones de pago.
- Sin acceso a: configuración operativa, gestión de usuarios.
Superadministrador
- Acceso completo al sistema.
- Debe ser una cuenta de servicio o de gerencia, nunca asignada a personal operativo. El número de superadministradores activos debe ser mínimo.
Gestión de accesos en la práctica
Los roles se definen una vez, pero los accesos cambian constantemente: hay incorporaciones, bajas, cambios de función y cambios de sede. Sin un proceso de revisión periódica, los accesos se acumulan y el modelo de seguridad se degrada.
Alta de usuarios
Cada usuario nuevo debe activarse con el rol mínimo necesario para su función. No asignar rol de supervisor a alguien que solo necesita cargar producción "por si acaso necesita ver algo más". El escalado de permisos debe ser explícito y documentado.
Revisión periódica de accesos
Una vez por trimestre, el administrador del sistema debe revisar:
- Usuarios activos que no tienen actividad en los últimos 30 días (candidatos a deshabilitar).
- Usuarios con roles más amplios que los que su función actual justifica.
- Cuentas de personas que ya no están en la organización.
En organizaciones con alta rotación —frecuente en el sector gastronómico— esta revisión debería ser mensual.
Baja de usuarios
La baja de un usuario no debe ser un proceso que dependa de que alguien se acuerde. Debe estar vinculada al proceso de offboarding del empleado. La cuenta debe deshabilitarse el mismo día que la persona deja de operar, no cuando alguien lo reporta a IT.
Qué datos restringir por sede
En operaciones multisede, la restricción por ubicación es tan importante como la restricción por rol. Un usuario con rol de supervisor en la sede de Palermo no debería poder ver los pedidos ni los costos de la sede de Belgrano, a menos que su función lo justifique explícitamente.
Los datos que siempre deben estar restringidos por sede:
- Pedidos de clientes corporativos (cada cliente tiene contrato con sedes específicas).
- Costos de producción (pueden variar por sede según acuerdos con proveedores locales).
- Incidentes y reclamos (visibles solo para la sede involucrada y para administración central).
Auditoría: qué registrar y por cuánto tiempo
El log de auditoría no es solo un requisito de compliance: es una herramienta operativa para entender qué pasó cuando algo sale mal.
Acciones que siempre deben generar un registro de auditoría:
- Login y logout de usuarios.
- Modificaciones a recetas o fichas técnicas.
- Cambios en precios de menú o condiciones de contrato.
- Creación o modificación de órdenes de compra.
- Exportación masiva de datos.
- Cambios en permisos de usuarios.
Retención recomendada: 12 meses de logs activos con acceso rápido, 36 meses en archivo. En contextos con auditorías externas (grandes empresas cliente que auditan a sus proveedores de alimentación), puede requerirse hasta 5 años.
Un error común: la seguridad como obstáculo
El argumento más frecuente contra un modelo de accesos bien definido es que "complica la operación". La respuesta correcta es que la seguridad mal diseñada complica la operación; la seguridad bien diseñada la simplifica, porque cada persona ve solo lo que necesita y los datos que ve son confiables.
Un operador de cocina que no puede modificar el menú por error no necesita que alguien lo supervise todo el tiempo. Un supervisor que solo ve sus sedes puede tomar decisiones más rápido. El diseño correcto de accesos es, en última instancia, una forma de escalar la operación sin escalar la supervisión.