La IA que hoy solo lee tu ERP, mañana probablemente escriba en él: cotice, facture, cree pedidos. Y el día que eso pasa, alguien tiene que darle una clave de acceso a un sistema real, con datos reales, que un error puede estropear de verdad. Es la misma decisión que tomamos hace unos días en AutoBoost al abrir la empresa a su primer colaborador externo, y la resolvimos con dos reglas que valen exactamente igual si quien entra por esa puerta es una persona o un agente de IA.
La pregunta que casi todo el mundo se salta
Cuando se conecta una IA a un ERP, un CRM o un sistema de facturación, casi toda la conversación gira en torno a qué va a poder hacer: cotizar, consultar stock, crear un pedido. Es la pregunta correcta, pero no es la única. Falta la que suele quedarse fuera del presupuesto y del contrato: cómo se protege la clave que le vas a dar, y qué le impide hacer más de lo que le pediste.
Son dos preguntas distintas y conviene no mezclarlas:
- ¿Quién es? (identificación): la clave demuestra que quien llama es quien dice ser.
- ¿Qué puede hacer? (autorización): lo que esa identidad tiene permiso de tocar.
El error habitual es tratarlas como una sola cosa: "si tiene la clave, puede hacer lo que la API deje". Esa mezcla es la que convierte una fuga de datos pequeña en un desastre grande, y la que hace que un agente de IA con un fallo de razonamiento pueda tocar algo que nunca debería.
Regla 1: la clave identifica, nunca autoriza por sí sola
Cuando dimos de alta el primer colaborador externo de AutoBoost, construimos un sistema de claves propias por persona para registrar horas desde la terminal o desde un agente, sin tener que abrir el navegador cada vez. La decisión técnica de fondo fue esta: la base de datos solo guarda el hash (SHA-256) de cada clave, nunca la clave en sí. Así, aunque alguien accediera a la base de datos entera, no tendría ninguna clave utilizable: solo huellas que no se pueden revertir para recuperar el original.
Esto se aplica exactamente igual cuando quien va a usar la clave es un agente de IA que escribe en tu ERP:
- El sistema que recibe las llamadas de la IA nunca debería guardar esa clave en texto plano en ningún sitio: ni en la base de datos, ni en un log, ni en un fichero de configuración legible.
- Si tu proveedor de IA no sabe explicarte cómo guarda las credenciales que le diste, esa es la primera pregunta de seguridad que le tienes que hacer antes de dejarle escribir en tu sistema.
- Una clave filtrada (por un log mal configurado, una fuga en la base de datos, un prompt mal construido) no debería servir de nada por sí sola si el resto del sistema está bien diseñado.
Regla 2: los permisos salen del rol, no de la clave
La segunda pieza es la que de verdad limita el daño. En el sistema de colaboradores de AutoBoost, tener una clave válida no da acceso a todo: cada persona solo ve y registra horas en los proyectos donde está asignada, y los permisos que puede o no puede ejercer salen de su rol, exactamente igual que en la web. Ninguna clave, por válida que sea, permite fichar a nombre de otro ni tocar un registro que no es suyo.
Trasladado a un agente de IA con acceso de escritura, la regla es la misma: darle una clave no significa darle acceso a todo lo que esa clave técnicamente podría alcanzar. Hay que definir su rol con la misma precisión que el de una persona:
- Qué tablas, objetos o acciones puede tocar (y cuáles no, aunque técnicamente pudiera).
- Si puede crear pero no borrar, o modificar pero no aprobar pagos.
- Qué pasa si intenta algo fuera de su rol: ¿el sistema lo bloquea, o confía en que la IA "se va a portar bien"?
Dos casos reales de AutoBoost muestran cómo se ve esto aplicado de verdad. El comercial de IA que cotiza por WhatsApp dentro del ERP de una distribuidora (caso completo) puede validar cliente, aplicar tarifa, comprobar stock y crear una oportunidad o un pedido, y nada más: no puede tocar precios base ni borrar clientes, porque su rol no lo permite, aunque la clave que usa sea perfectamente válida. Y la IA que contabiliza facturas de un grupo veterinario (caso completo) solo puede actuar sobre lo que ella misma creó: si el total no le cuadra, borra su propia factura, pero no toca ninguna que no haya generado ella.
Qué pasa si te saltas estas dos reglas
Sin la regla 1, una fuga de base de datos (algo que le pasa hasta a empresas grandes) convierte una clave robada en acceso directo a tu ERP. Sin la regla 2, incluso sin ninguna fuga, un agente de IA que se equivoca (y todos se equivocan alguna vez) puede tocar algo que nunca debería haber podido tocar, simplemente porque nadie le puso un límite explícito más estrecho que "todo lo que la API permite".
La combinación de las dos es lo que separa un proyecto de IA bien construido de uno que funciona hasta el día que falla en grande.
Checklist antes de dar una clave a tu IA (o a cualquier colaborador)
| Pregunta | Mal | Bien |
|---|---|---|
| ¿Dónde se guarda la clave? | En texto plano, en la base de datos o en un log | Solo su hash (SHA-256 o equivalente) |
| ¿Qué puede hacer con ella? | Todo lo que la API técnicamente permite | Solo las acciones de su rol, definidas de antemano |
| ¿Puede actuar por otra persona o entidad? | Sí, si conoce la clave | No: la clave identifica, el rol autoriza |
| ¿Puede tocar registros que no ha creado ella? | Sí, sin distinción | No, salvo que su rol lo contemple explícitamente |
| ¿Qué pasa si la clave se filtra? | Acceso completo al sistema | Nada usable sin el rol y los permisos asociados |
Si tu proveedor no puede responder con claridad a estas cinco preguntas antes de conectar su IA a tu ERP o tu CRM, no tienes un problema de tecnología: tienes un problema de acceso sin límites, y ese es justo el que más caro sale cuando algo falla. En AutoBoost construimos cada integración con estas dos reglas por defecto, tanto si quien entra al sistema es una persona como si es un agente de IA. Si quieres revisar cómo está el acceso de tu sistema hoy, o estás valorando meter una IA que escriba en tu ERP, escríbenos y lo miramos juntos, o consulta cómo trabajamos en nuestros servicios.
