Agentes de IA Conectados al ERP y al CRM

Un agente de IA conectado al ERP y al CRM no responde preguntas, ejecuta: crea el presupuesto, mueve la etapa, reserva el stock. Eso cambia la arquitectura, porque un error deja de ser una respuesta mala y pasa a ser un registro mal escrito. Lo montamos en los desarrollos de integración de Codezone.

El trabajo que se quiere quitar es real: alguien copia del correo al CRM, de ahí al ERP, y comprueba que el pedido coincide con la oportunidad. Teclazos que nadie audita hasta que alguien reclama.

Al terminar sabrás qué puede ejecutar solo y qué no. Lo que lee para decidir sale de la capa de recuperación sobre documentos internos.

Qué es un agente conectado al ERP y al CRM

Es un sistema donde el modelo recibe un objetivo, dispone de un catálogo cerrado de herramientas que envuelven las APIs del ERP y del CRM, y decide qué llamar en qué orden. La diferencia con un asistente está en el verbo: el asistente lee y el agente escribe, y escribir exige permisos, idempotencia y registro.

La capa de herramientas, no la API en crudo

Nunca se le da al modelo acceso directo a la API del ERP. Entre medias va una capa de herramientas con contrato estrecho: `crear_presupuesto` acepta cliente, líneas y validez. La llamada se valida antes de salir.

OWASP llama agencia excesiva a lo contrario y lo recoge entre sus diez riesgos para aplicaciones con LLM. Las medidas que nombra incluyen minimizar las extensiones y su funcionalidad, evitar las de propósito abierto, reducir permisos, ejecutarlas en el contexto del usuario y exigir aprobación para las acciones de impacto, según el riesgo de agencia excesiva de OWASP. Una herramienta que acepte consulta libre incumple media lista.

Abanico de herramientas holográficas alrededor de un núcleo de IA, con una conectada por un haz de luz — Una herramienta por tarea, con el contrato escrito.

Mínimo privilegio e identidad propia del agente

El agente no usa las credenciales de un administrador ni las del usuario que le habla. Tiene usuario propio en el ERP y en el CRM, con los permisos exactos de lo que puede hacer: todo movimiento queda atribuido a él y es revocable.

Esos permisos se cruzan con los del usuario: si un comercial no ve los márgenes, el agente en su nombre tampoco. Es el reparto que ordena qué datos sincronizar y quién manda en cada sistema, junto a la elección entre CRM a medida y CRM comercial.

Qué Puede Hacer Solo, Qué Pide Confirmación, Qué No Toca Nunca

Solo: leer stock y disponibilidad. Crear o actualizar un contacto. Registrar la actividad de una llamada. Crear una tarea de seguimiento.
Con confirmación: enviar un presupuesto al cliente. Mover la etapa de una oportunidad. Reservar stock. Aplicar un descuento del rango autorizado.
Nunca: emitir o rectificar una factura. Cambiar condiciones de pago o datos bancarios. Dar de alta un proveedor. Borrar registros.

El criterio: confirmación cuando la acción llega al cliente o mueve dinero, y nunca se delega lo que un auditor revisaría. La tercera lista va por los flujos de aprobación de compras, con el cuidado de los riesgos de usar IA en facturas.

Idempotencia, trazabilidad y marcha atrás

Un agente reintenta. Si la llamada al ERP da timeout y la repite, sin clave de idempotencia tienes dos presupuestos iguales. Stripe lo describe bien: la clave la genera el cliente, la plataforma guarda el código y el cuerpo de la primera respuesta, y las siguientes con esa clave devuelven el mismo resultado, según la referencia de peticiones idempotentes de Stripe.

La trazabilidad es la otra mitad: por cada acción se guarda quién la pidió, qué herramienta se llamó con qué argumentos y qué identificador creó. Sin eso, ante un registro raro no sabrás si fue el agente, otra integración o una persona.

Hay que decidir cómo se deshace cada cosa. Unas tienen inversa limpia: la tarea se cierra, la reserva se libera. Un correo enviado no se recoge, y eso lleva confirmación, como en la automatización de procesos administrativos con control.

Dos peticiones holográficas idénticas hacia una base de datos: la primera escribe un registro y la segunda se absorbe — Dos intentos, un solo registro escrito.

CodeZone Pro Tip: define cada herramienta con esquema validado, comprobación de permisos del usuario y clave de idempotencia antes de escribir en el CRM, para que un reintento del agente no cree dos registros.

import { z } from "zod";
import crypto from "node:crypto";

// Esquema estrecho: el modelo no puede colar campos ni consultas libres.
const Entrada = z.object({
  contactoId: z.string().uuid(),
  importe: z.number().positive().max(60000),
  moneda: z.literal("EUR"),
});

export const crearOportunidad = {
  nombre: "crear_oportunidad",
  permiso: "crm:oportunidad:crear",
  async ejecutar(args, ctx) {
    const datos = Entrada.parse(args);          // falla antes de llamar
    // El permiso se comprueba contra el usuario que pide, no contra
    // el usuario tecnico del agente: un comercial no abre fuera de su zona.
    if (!ctx.usuario.permisos.includes(this.permiso)) {
      return { ok: false, motivo: "sin_permiso" };
    }
    // Clave derivada de la intencion: el reintento repite la misma
    // y el CRM devuelve el registro ya creado en vez de duplicarlo.
    const clave = crypto.createHash("sha256")
      .update(`${this.nombre}|${ctx.tareaId}|${datos.contactoId}|${datos.importe}`)
      .digest("hex");
    const res = await ctx.crm.post("/oportunidades", datos, {
      headers: { "Idempotency-Key": clave },
    });
    // Traza con actor, argumentos y id creado: sin esto no hay auditoria.
    await ctx.auditoria.registrar({
      actor: ctx.usuario.id, agente: ctx.agenteId, herramienta: this.nombre,
      argumentos: datos, resultado: res.data.id, clave,
    });
    return { ok: true, id: res.data.id };
  },
};

Esas comprobaciones evitan los fallos del primer mes: argumentos inventados por el modelo, acciones fuera del alcance de quien las pidió y duplicados por reintento. Diez líneas que ahorran limpiar el CRM a mano.

Lo que Pasa el Día que el Agente se Equivoca

Se equivocará: entenderá mal una instrucción o recibirá respuesta parcial del ERP. Se juzga por lo que pasa después. Si el registro permite reconstruir la cadena y la acción tenía inversa, es un incidente de media hora. Si no, alguien cuadra a mano todo el día.

Empieza por un proceso acotado con una sola herramienta de escritura y quita confirmaciones solo donde el registro demuestre que acertó. Saltarse ese orden es el riesgo de montarlo sobre una herramienta sin control, y el encaje con lo que ya tienes se decide en un proyecto de IA en Madrid con su seguridad y su coste y en la conexión de sistemas sin crear silos.

Orbe de acción holográfico detenido ante un control con escáner de palma de luz que debe aprobarlo — La acción que llega al cliente pasa por una mano.

Antes de conectar nada, escribe esas tres listas con tus procesos y enséñaselas a quien responde si algo sale mal. Define el proyecto mejor que la elección de modelo y pesa en el coste de automatizar con IA en Madrid.