Multi-tenant es la norma, no la excepción — pero no todos lo implementan igual
Casi cualquier plataforma de soporte que uses hoy es multi-tenant: una misma infraestructura atiende a muchas empresas distintas al mismo tiempo, cada una con sus propios clientes, conversaciones y base de conocimiento. Eso no es un problema en sí mismo. El problema aparece cuando el aislamiento entre esas empresas no está garantizado a nivel de arquitectura, sino que depende de que el código de la aplicación se acuerde de filtrar bien en cada consulta.
La diferencia entre "filtramos por cliente en el código" y "el motor de datos lo garantiza"
Hay dos formas muy distintas de implementar aislamiento multi-tenant. En la primera, cada consulta a la base de datos incluye un filtro escrito a mano en cada endpoint — y si un desarrollador se olvida ese filtro una sola vez, los datos de un cliente pueden quedar expuestos a otro. En la segunda, el aislamiento se define como una política a nivel del motor de base de datos (en Postgres, mediante Row Level Security), de forma que ninguna consulta puede devolver filas de otro cliente, porque la base de datos misma lo impide antes de que el resultado llegue a la aplicación.
Preguntas concretas para hacerle a un proveedor
Antes de confiarle tus datos y los de tus clientes a una plataforma compartida, conviene preguntar directamente: ¿el aislamiento entre clientes está implementado a nivel de base de datos o depende de filtros en el código de aplicación? ¿Qué pasa si un desarrollador de la plataforma comete un error de código — hay una capa que igual protege los datos? ¿El equipo interno del proveedor tiene acceso irrestricto a los datos de todos los clientes, o también pasa por controles de acceso?
Por qué esto importa tanto como la funcionalidad
Es fácil evaluar un proveedor por sus funciones visibles y dejar el aislamiento de datos como una casilla de "seguro que está bien" sin verificar. Pero si tu empresa maneja datos de clientes en una plataforma compartida con otras empresas, una falla de aislamiento no es un bug menor — es una filtración de datos de terceros, con las implicancias legales y de confianza que eso conlleva.
Cómo se ve el aislamiento bien hecho, en la práctica
En una arquitectura bien diseñada, cada tabla que contiene datos de clientes tiene una política explícita que ata cada fila a un tenant, y esa política se aplica automáticamente sin importar qué consulta se ejecute ni quién la escriba. Aunque el equipo de desarrollo cometa un error al escribir una nueva función, el peor caso posible es que esa función no funcione — no que exponga datos de una empresa a otra.
No es un tema solo técnico, es una decisión de negocio
Elegir un proveedor de soporte multi-cliente sin preguntar cómo está implementado el aislamiento de datos es delegar una decisión de seguridad crítica sin haberla evaluado. No hace falta ser técnico para hacer la pregunta correcta — alcanza con pedir que te la respondan en términos concretos, y desconfiar de una respuesta vaga tipo "nuestros datos están seguros" sin ninguna explicación de cómo.