Casi toda plataforma de IA conversacional está construida sobre un supuesto: una empresa, una cuenta, un conjunto de bots. El supuesto es invisible mientras evaluás el producto y caro el primer mes en que corrés trescientos agentes encima.
Bajo ese número se archivan dos problemas, y solo uno de los dos es difícil. Trescientos agentes dentro de una empresa sin divisiones es capacidad: más tráfico, más definiciones, más logs, y se resuelve comprando un martes. Trescientos agentes repartidos en veinte organizaciones que no pueden verse los datos entre sí es aislamiento, y el aislamiento es lo único que no se compra un martes. Si no estaba en el modelo de datos el día uno, es una migración.
Todo lo que sigue trata del segundo. Vale ser preciso sobre quién lo tiene, porque la respuesta obvia es solo la mitad.
- Vendés agentes. Un reseller, un integrador, una software factory: veinte empresas cliente, cada una con su marca, sus datos y su respuesta para el auditor.
- Sos la empresa. Una multinacional con quince unidades de negocio, un holding con ocho subsidiarias, un estado con nueve ministerios. Nadie le compra nada a nadie, y todas las fronteras del primer caso siguen ahí: legales no puede leer las conversaciones de recursos humanos, el gasto de cada unidad tiene que ser imputable, y los datos de una región no pueden salir de ella.
El segundo caso se descubre más tarde y duele más, porque la plataforma se eligió cuando el piloto tenía un agente y un equipo. En los dos, no estás administrando una empresa. Estás operando una flota.
Lo que sigue es qué tiene que significar "multi-tenant" estructuralmente para que la etiqueta valga algo, y cinco preguntas que separan a un proveedor que lo construyó de uno que agregó una columna customer_id.
Los dos caminos llegan a la misma arquitectura
El problema de flota parece hoy un problema de especialistas. No va a seguir siéndolo.
En un comunicado de abril de 2026, Gartner proyectó que la empresa promedio del Fortune 500 global va a estar operando más de 150.000 agentes en 2028, contra menos de 15 en 2025. En el mismo comunicado: el 13% de las organizaciones cree tener la gobernanza de agentes adecuada. Gartner llama agent sprawl a la distancia entre esos dos números, y su senior director analyst Max Goss plantea el trabajo como gobernar la flota sin bloquear a la gente que la construye.
McKinsey llega al mismo lugar por otro camino. Su lectura 2026 sobre confianza en IA ubica alrededor de un tercio de las organizaciones en un nivel de madurez de gobernanza adecuado para los agentes autónomos que ya están corriendo.
Leelo como señal arquitectónica antes que como estadística alarmista. Ciento cincuenta mil agentes no van a estar en un pozo único: van a estar en divisiones, regiones y funciones que no pueden leerse entre sí, que es el mismo dibujo que veinte empresas cliente con otra etiqueta en las cajas. El que vende agentes para vivir se encuentra con ese dibujo tres años antes, a un tamaño en el que todavía es barato cambiarlo. El que dirige una organización grande se lo encuentra cuando termina el piloto, a un tamaño en el que ya no.
La parte que no aparece en una prueba
Supongamos que operás agentes para veinte organizaciones en una plataforma por cuenta — veinte clientes, o veinte unidades de negocio, la aritmética es idéntica. El total de las suscripciones es el costo evidente y el menos interesante. Lo que viene después:
- Veinte logins. Nadie en tu equipo tiene una vista única de nada.
- Veinte relaciones de facturación, cada una renovando en su propia fecha, cada una con un techo de plan que vas a tocar un martes distinto.
- Veinte copias de la misma configuración. Construiste un buen flujo de calificación de leads. Ahora existe en veinte lugares y deriva en veinte direcciones.
- Veinte juegos de credenciales. Cada clave de modelo, cada token de CRM, cada número de mensajería se configura, se rota y se audita por separado.
- Ningún agregado. "¿Cuánto gastamos en inferencia el mes pasado, entre todos los clientes?" es una tarde de planilla.
Nada de eso aparece en una prueba de catorce días. Todo eso aparece en el mes seis.
La asimetría de esa imagen es todo el argumento. A la izquierda, el cliente veintiuno es una instalación nueva. A la derecha, es una llamada de aprovisionamiento.
Cinco fronteras, y cuatro de ellas es ninguna
Multi-tenancy no es un nivel de precio ni es una columna. Es una propiedad del modelo de datos: una instalación sirve a muchas organizaciones, y las fronteras se sostienen por debajo de la aplicación en vez de porque todos se acordaron de agregar un filtro.
Son cinco. Una plataforma que hace cumplir cuatro efectivamente no hace cumplir ninguna, porque la que se le escapó es justo la que va a filtrar.
| Frontera | Qué tiene que garantizar | Dónde se pierde habitualmente |
|---|---|---|
| Datos | Ningún camino de consulta devuelve filas de otro tenant — agentes, workflows, bases de conocimiento, documentos, herramientas, historial, métricas, conexiones | Un filtro aplicado en la capa de servicio en vez del repositorio. Un where olvidado y la frontera desaparece sin que se levante ningún error |
| Credenciales | La clave de modelo del cliente A es inalcanzable desde el runtime del cliente B | Variables de entorno compartidas, o claves guardadas en la definición del workflow en lugar de un secret store con alcance por tenant |
| Sesiones | Las conversaciones nunca se mezclan, tampoco entre canales | Claves de sesión construidas solo con la identidad del usuario, de modo que el hilo de mensajería de una persona hereda el estado de su chat web |
| Orígenes | Otro sitio no puede hacer POST al endpoint del agente de tu cliente | CORS configurado por instalación en vez de por tenant |
| Memoria | Los hechos de largo plazo extraídos para un cliente se quedan ahí | Memoria agregada después como store global, una vez que el alcance por tenant ya estaba diseñado |
La línea de canales merece una pausa, porque es donde se cruzan corrección y privacidad. Una clave de sesión (tenant, agente, canal, usuario_externo) se comporta distinto de (usuario) exactamente en el caso que importa: la misma persona hablándole a la misma marca en dos superficies. Si la plataforma no puede distinguirlos, "multi-tenant" nunca fue lo primero que hizo mal.
La línea de datos merece el mismo escrutinio, y es la más difícil de verificar desde afuera. El alcance por tenant impuesto en el repositorio —donde cada método recibe el tenant como parámetro obligatorio y no como filtro opcional— falla ruidosamente cuando alguien se olvida. El alcance por tenant sostenido por convención en la capa de servicio falla en silencio, en producción, frente a un cliente, más o menos a los dieciocho meses.
Aislamiento sin herencia son veinte instalaciones con un sobretodo
El aislamiento por sí solo te da veinte cajas selladas, que es la mitad del problema. La otra mitad es que no querés configurar lo mismo veinte veces.
La estructura que lo resuelve es una jerarquía de tenants: vos sos el tenant padre, tus clientes son tenants debajo, y la configuración fluye hacia abajo. Un padre registra sus conexiones de modelo una vez; los hijos las resuelven subiendo por el árbol, y no pueden modificar lo que heredaron. Esa propiedad de solo lectura es lo que lo hace seguro y no meramente cómodo: el equipo del cliente puede operar sus agentes sin poder leer, rotar ni exportar una credencial que pagás vos.
La forma general de la regla: heredar hacia abajo, sobrescribir localmente, nunca mutar hacia arriba. Branding, límites, conexiones y política de guardrails quieren el mismo tratamiento. Todo lo que el operador tenga que poder cambiar una vez y que surta efecto en todos lados pertenece a la cima del árbol; todo lo que un cliente legítimamente posee pertenece a su nivel, como sobrescritura.
Qué compra la arquitectura aguas arriba
Estas son decisiones de ingeniería con consecuencias comerciales, que es la parte que normalmente queda sin decir en un escrito de arquitectura.
El white-label deja de ser un favor. Cuando el branding es una propiedad por tenant, cada superficie lleva la identidad que le corresponde —la marca del cliente, o la de la subsidiaria— en vez de la tuya o la del proveedor. Esa es la diferencia entre entregar una plataforma y revender una con un logo pegado encima.
El costo marginal deja de seguir al organigrama. El precio por cuenta crece linealmente con los tenants por construcción. Una instalación se amortiza entre todos, y el costo del veintiuno tiende a inferencia más soporte.
La residencia de datos se vuelve contestable. Un cliente de salud o de finanzas va a preguntar dónde viven las conversaciones. Si la respuesta depende de la lista de regiones de un proveedor, estás negociando. Si controlás la instalación, estás respondiendo.
El riesgo de salida pasa a ser tuyo para ponerle precio. Una plataforma que podés desplegar es una plataforma que podés seguir desplegando. Esa es una conversación materialmente distinta con un área de compras que "dependemos de este SaaS".
Cuándo no hacer esto
Un producto gestionado de un solo tenant es menos trabajo el día uno. Otro lo parchea, lo escala y se come el llamado a las 3am. Si atendés uno o dos clientes y esperás que siga así, por cuenta es la decisión correcta: operar una plataforma tiene un costo operativo que no se vuelve cero porque la arquitectura sea mejor.
Anidar tampoco es gratis. Tenant por cliente significa una frontera que aprovisionar, permisos que modelar y una jerarquía sobre la cual razonar. A muchos operadores les sirve más agente por cliente dentro de un solo tenant, compartiendo un juego de credenciales que controlan ellos. La pregunta que divide no es la escala, es la propiedad: elegí tenant por cliente cuando el cliente necesita una frontera —su propio login, sus datos aislados, su propio auditor preguntando dónde están las cosas—. Elegí agente por cliente cuando lo que necesita es un bot.
El cruce llega antes de lo que la mayoría planifica: vimos la dispersión de cuentas superar al costo de operar la plataforma alrededor del quinto o sexto cliente. Es una observación a lo largo de varios despliegues, no una ley, y se mueve según cuán parecidas sean las configuraciones de tus clientes. Veinte flujos casi idénticos y la dispersión muerde antes. Veinte a medida y muerde después.
Cinco preguntas para hacerle a cualquier proveedor
Llevalas a la próxima evaluación. Cada una se responde en una frase si la construyeron, y cada una produce una pausa visible si no.
- "Con veinte clientes, ¿cuántos logins necesita mi equipo?" Cualquier respuesta que contenga "veinte" termina la evaluación.
- "¿Puede el equipo de un cliente operar su agente sin poder leer ni exportar mi clave de proveedor?" Prueba específicamente la herencia de credenciales en solo lectura, no el almacenamiento de credenciales en general.
- "Quiero mover todos los agentes de todos los clientes a otro modelo. Mostrame cómo." Escuchá si la cantidad de pasos depende de la cantidad de agentes.
- "¿La conversación de mensajería del mismo usuario final comparte estado con su chat web?" Prueba si la identidad de sesión incluye el canal.
- "¿Dónde viven los datos, y puedo correr esto yo mismo si hace falta?" Residencia y riesgo de salida en un solo movimiento.
La pregunta útil al evaluar una plataforma de agentes ya no es "¿puede construir un buen agente?". Casi todas pueden. Es qué pasa el día que tenés veinte —y si la respuesta involucra veinte de algo, estás mirando una herramienta construida para una empresa y no una plataforma construida para un operador.
El Fortune 500 de Gartner está a tres años de hacerse esa pregunta sobre seis dígitos de agentes. La forma de la respuesta no cambia con el número.
