Tu agente de IA que cotiza, factura o consulta el ERP de un cliente debería ver solo a ese cliente, nunca a los demás. La pregunta incómoda es quién garantiza eso de verdad: ¿el sistema, o que a nadie se le olvide configurarlo bien? En AutoBoost nos la hicimos sobre nuestro propio sistema de gestión de colaboradores y clientes, y la respuesta que teníamos hasta hace poco era la mala: funcionaba, pero por casualidad.
El problema: "funciona bien" no es lo mismo que "está garantizado"
Hasta hace unas semanas, que un colaborador externo de AutoBoost solo tocara el trabajo de un cliente concreto dependía de una sola cosa: que quien le asignaba proyectos no le diera ninguno de otro cliente por error. No había ninguna regla en el sistema que lo impidiera. Si alguien se equivocaba al rellenar un formulario, o si alguien manipulaba a mano la petición que manda ese formulario, nada en el servidor lo frenaba.
Nunca llegó a pasar. Pero "nunca pasó" y "no podía pasar" son dos frases muy distintas, y solo la segunda es una garantía real. Es exactamente el mismo problema que tiene cualquier negocio que conecta un agente de IA a su ERP, su CRM o su sistema de facturación con acceso a varios clientes a la vez: que el agente solo toque los datos del cliente correcto suele depender de cómo se escribió el prompt o la consulta ese día, no de una regla que el sistema imponga siempre, pase lo que pase.
La diferencia entre las dos cosas es la que separa un incidente que no pasa nunca de uno que tarde o temprano pasa, el día que alguien (una persona o un agente) hace algo que nadie previó.
Qué cambiamos: de una puerta a dos cerrojos
La solución no fue complicar el sistema, fue dejar de confiar en un único punto de control y poner dos, cada uno vigilando algo distinto:
- El formulario ya no ofrece lo que no debería. Al dar de alta a un colaborador, se le asignan uno o más clientes concretos. Desde ese momento, cualquier pantalla donde se le pueda asignar un proyecto nuevo solo le muestra proyectos de esos clientes. No puede elegir mal porque la opción incorrecta ni aparece.
- El servidor rechaza lo que el formulario no debería haber permitido, por si acaso. Esto es el cerrojo que de verdad importa: aunque alguien manipule la petición a mano, o un fallo en el formulario deje pasar algo que no debería, el servidor vuelve a comprobar la regla antes de guardar nada, y la rechaza si no cuadra.
El primer cerrojo evita el error por torpeza. El segundo evita el error por manipulación, por un fallo de la interfaz, o por cualquier cosa que nadie llegó a imaginar cuando se escribió el formulario. Un agente de IA que actúa solo (sin que una persona revise cada paso antes de darle el visto bueno) es exactamente el tipo de actor que más necesita ese segundo cerrojo: no comete errores por torpeza, pero sí puede llegar a un estado que nadie anticipó si el contexto que recibe está mal construido o si una instrucción se interpreta de forma inesperada.
Qué pasa cuando le quitas un cliente a alguien (o a un agente)
Hay una tercera regla, más pequeña, que importa casi tanto como las dos anteriores: quitarle a un colaborador el acceso a un cliente le quita también el acceso a los proyectos de ese cliente, pero las horas que ya había registrado se quedan intactas. El cerrojo corta el acceso hacia delante, no borra ni corrompe lo que ya existía.
Es una distinción que cualquier negocio que dé y quite accesos (a un empleado que cambia de cuenta, a un colaborador que termina un contrato, a un agente de IA al que se le reduce el alcance) tiene que resolver explícitamente. Si revocar el acceso también mete la mano en los datos históricos, el cerrojo se convierte en un riesgo nuevo en lugar de resolver el que ya había.
Checklist: antes de dar acceso multicliente a una IA o a un externo
| Pregunta | Por qué importa |
|---|---|
| ¿Quién decide qué clientes puede tocar esta identidad (persona o agente)? | Si la respuesta es "quien le asigna trabajo, caso por caso", no hay regla, hay costumbre |
| ¿La interfaz solo ofrece lo permitido, o depende de que quien la usa no se equivoque? | El primer cerrojo reduce el error, no lo elimina |
| ¿Qué pasa si alguien (o algo) manda la petición directamente, sin pasar por la interfaz? | Si el servidor no vuelve a comprobar la regla, el primer cerrojo es decorativo |
| ¿Quitar un acceso borra o afecta a los datos ya generados con ese acceso? | Revocar el futuro y proteger el pasado son dos cosas distintas que hay que garantizar por separado |
| ¿La regla se aplica igual si quien entra es una persona o un agente de IA que actúa solo? | Un agente sin supervisión humana constante necesita el segundo cerrojo más que nadie |
La regla de decisión es corta: si el aislamiento entre clientes depende de que nadie se equivoque al configurarlo, no es aislamiento, es suerte. Solo cuenta como garantía cuando el sistema lo impone en más de un punto, y el último de esos puntos es el que recibe y guarda el dato, no el que lo pide.
Dónde se nota esto de verdad
Esto deja de ser una cuestión teórica en el momento en que una IA actúa sin que nadie revise cada paso. En el comercial de IA que cotiza por WhatsApp dentro del ERP de una distribuidora industrial con más de 50.000 productos (caso completo), cada mensaje que llega valida primero de qué cliente se trata antes de aplicar tarifa, comprobar stock y crear la oportunidad o el pedido. Si esa validación dependiera solo de que el prompt estuviera bien escrito, un mensaje ambiguo o manipulado podría acabar aplicando la tarifa de un cliente a otro, o mostrando stock que no le corresponde ver.
Dar acceso multicliente a una IA (o a cualquier colaborador externo) es parte del mismo trabajo de integración que hacemos en AutoBoost antes de dejar que un agente toque datos reales de producción: puedes ver más en /servicios.
Si tu empresa está evaluando conectar un agente de IA a un sistema con datos de varios clientes y no tienes claro si el aislamiento entre ellos es una regla o una costumbre, cuéntanos tu caso y lo revisamos contigo.
