Multi-tenant en ERP: qué es y por qué importa para tu PyME

La pregunta que nadie hace al contratar un ERP en la nube

Cuando contratas un ERP SaaS, tus datos conviven en la misma base de datos con los de cientos o miles de otras empresas. La pregunta es: ¿cómo garantiza el proveedor que tus datos no se mezclen con los de otros clientes?

La respuesta está en la arquitectura multi-tenant y en los mecanismos de aislamiento.

¿Qué significa "tenant"?

Un tenant es una empresa o cliente que usa el sistema. En un ERP multi-tenant, múltiples tenants comparten la misma infraestructura (servidores, base de datos, código), pero cada uno ve y opera solo sus propios datos.

Analogía: es como un edificio de departamentos. Todos los inquilinos comparten el edificio, los elevadores y los sistemas de plomería — pero cada uno tiene su propio departamento con llave.

Los 3 modelos de arquitectura multi-tenant

Modelo 1: Base de datos separada por tenant

Cada cliente tiene su propia base de datos. La separación es máxima.

Ventajas: aislamiento perfecto, backup independiente, migración más fácil.

Desventajas: caro (N bases de datos), más difícil de actualizar (hay que aplicar cambios a cada BD).

Usado por: ERPs enterprise con clientes grandes que pagan por personalización.

Modelo 2: Esquema separado por tenant

Una sola base de datos, pero cada tenant tiene su propio schema (namespace de tablas).

Ventajas: mejor aislamiento que el modelo 3, más económico que el modelo 1. Desventajas: aún caro en escala, difícil de consultar cross-tenant.

Modelo 3: Tabla compartida con org_id (RLS)

Todas las empresas comparten las mismas tablas. Cada fila tiene un campo org_id que identifica a qué tenant pertenece. La base de datos aplica una política de Row Level Security (RLS) que garantiza que un usuario solo ve filas de su propia empresa.

Ventajas: más económico, escala mejor, actualizaciones simples. Desventajas: requiere implementación cuidadosa de RLS — un bug puede exponer datos de otro tenant.

Nubli usa el Modelo 3 con RLS en Supabase (PostgreSQL). Es el modelo estándar de ERPs SaaS modernos como Netsuite, SAP Business One Cloud y QuickBooks Online.

Row Level Security: el mecanismo que te protege

RLS es una función de PostgreSQL que permite definir políticas a nivel de fila:

-- Política: un usuario solo puede ver facturas de su organización
CREATE POLICY "facturas_por_org" ON invoices
  USING (org_id = auth.current_setting('app.org_id')::uuid);

Esta política se aplica automáticamente a todas las consultas. Aunque un programador cometiera el error de olvidar el filtro de org_id en una query, PostgreSQL lo aplica de todas formas.

Qué preguntar a tu proveedor de ERP:

• ¿Tienen RLS habilitado en todas las tablas con datos de clientes?
• ¿Tienen un proceso de auditoría que verifique que RLS esté activo?
• ¿Cuándo fue la última auditoría de seguridad de datos?

El problema del tenant isolation mal implementado

Los errores más comunes en implementaciones multi-tenant:

Error 1: RLS deshabilitado en alguna tabla

Si RLS está activo en invoices pero no en inventory_movements, un usuario malintencionado puede ver los movimientos de inventario de otras empresas a través de esa tabla.

Error 2: Bypass de RLS con service role

Muchos ERPs usan un "superusuario" (service role) para ciertas operaciones administrativas. Si ese service role se usa para queries que devuelven datos a usuarios finales, las políticas RLS no aplican.

Error 3: Queries sin filtro de org_id en app layer

RLS protege a nivel de base de datos. Pero si la aplicación también construye queries sin filtro de org_id y luego devuelve resultados, puede haber fugas de datos a nivel de lógica de negocio (aunque RLS los filtre a nivel BD).

Multi-empresa en un ERP: diferente a multi-tenant

Multi-tenant = múltiples clientes del ERP (empresas distintas, sin relación entre sí). Multi-empresa = una empresa que tiene múltiples RFCs o subsidiarias y quiere verlos todos desde una sola cuenta.

Son conceptos distintos. El Plan Contador Pro de Nubli, por ejemplo, permite que un contador gestione múltiples RFCs de sus clientes desde una sola cuenta — eso es multi-empresa para el despacho, no multi-tenant.

Qué verificar antes de contratar un ERP en la nube

1. Certificaciones de seguridad: ¿tienen SOC 2, ISO 27001 o equivalente?
2. Donde viven tus datos: ¿en servidores en México? ¿en AWS/GCP/Azure con región MX o USA?
3. Cifrado en reposo y en tránsito: ¿TLS 1.3 mínimo? ¿cifrado AES-256 en BD?
4. Backup: ¿cuántas copias? ¿en dónde? ¿cada cuánto? ¿puedo hacer restore yo mismo?
5. Exportar mis datos: ¿puedo descargar TODOS mis datos en cualquier momento?
6. Portabilidad: si cancelo, ¿cuánto tiempo tengo para exportar?

La promesa de Nubli

• RLS habilitado en 100% de las tablas con datos de clientes (auditado regularmente)
• Datos en Supabase con región USA (East), backup automático cada 24h con 7 días de retención
• Export completo de todos los módulos en cualquier momento desde Configuración → Datos → Exportar
• TLS 1.3 en tránsito, AES-256 en reposo
• Sin contratos de permanencia — puedes exportar y cancelar cuando quieras

Conclusión

Multi-tenant no es bueno ni malo por sí mismo — lo que importa es la implementación del aislamiento. Un ERP con RLS bien implementado es tan seguro como uno con bases de datos separadas, a un costo mucho menor (que es lo que permite precios accesibles para PyMEs). La clave es verificar que el proveedor realmente haya implementado las protecciones que dice tener.