Antes de conectar un agente de IA a tu ERP, define esto
Conectar un agente de IA a un ERP, CRM o sistema interno puede ahorrar muchas horas, pero tambien crear riesgos si no defines permisos, identidad, aprobaciones, limites y auditoria antes de darle acceso.
La pregunta ya no es si un agente de IA puede conectarse a tu ERP. Puede. Tambien puede consultar clientes, revisar facturas, preparar pedidos, actualizar campos del CRM, leer historicos, generar presupuestos y lanzar automatizaciones.
La pregunta importante es otra: deberia poder hacerlo sin limites?
Segun Deloitte, los agentes de IA estan escalando mas rapido que sus mecanismos de control. En su encuesta global de 2026, solo el 21% de las empresas afirma tener un modelo maduro de gobernanza para IA agente, aunque la adopcion crece con rapidez.
Para una PYME, esto importa mucho. Un agente conectado a datos reales deja de ser un chatbot. Se convierte en un usuario operativo dentro de la empresa.
Un agente es una identidad, no una funcion
Muchas empresas tratan al agente como "una herramienta de IA". Es un error. Si el agente puede entrar en sistemas internos, ejecutar acciones y mover datos, debe gestionarse como una identidad digital.
Eso significa responder a preguntas concretas:
- Quien es el propietario del agente?
- Que sistemas puede usar?
- Que datos puede leer?
- Que acciones puede ejecutar?
- Que acciones requieren aprobacion?
- Como se revocan sus permisos?
- Donde quedan registradas sus acciones?
Si no puedes responder esto, no deberias conectarlo todavia a un ERP.
Que puede leer
El primer nivel de control es la lectura. Parece inocente, pero no lo es. Leer datos de clientes, margenes, nominas, contratos o incidencias ya implica riesgo.
Un buen diseno empieza por el minimo acceso posible:
| Tipo de dato | Acceso recomendado |
|---|---|
| FAQs, manuales y procesos internos | Lectura amplia si no contienen datos sensibles |
| Documentos comerciales | Lectura limitada por departamento o rol |
| Datos de clientes | Lectura filtrada por caso de uso |
| Facturacion y contabilidad | Lectura restringida y auditada |
| Nominas, salud o datos legales | Solo si hay una necesidad clara y controles fuertes |
En bases de conocimiento internas, una solucion como Polp puede ayudar a organizar documentos, responder con fuentes y limitar el acceso segun el contexto. Pero la regla sigue siendo la misma: el agente no debe ver mas informacion de la que necesita.
Que puede escribir
La escritura es donde empieza el riesgo operativo. Un agente que solo responde se equivoca en texto. Un agente que escribe puede cambiar la realidad de tu negocio.
Acciones de bajo riesgo:
- Crear borradores de email
- Preparar propuestas pendientes de revision
- Etiquetar tickets
- Clasificar leads
- Actualizar campos no criticos
Acciones de riesgo medio:
- Cambiar estados de pedidos
- Crear tareas en CRM
- Programar reuniones
- Generar documentos comerciales
- Actualizar datos de contacto
Acciones de alto riesgo:
- Emitir facturas o abonos
- Aplicar descuentos
- Cancelar pedidos
- Modificar contratos
- Cambiar condiciones de pago
- Borrar registros
La recomendacion practica: empieza por lectura y borradores. Luego permite escritura en acciones reversibles. Deja las acciones economicas, legales o irreversibles con aprobacion humana.
Quien aprueba
Un agente no debe decidir solo cuando la accion tiene impacto real. Pero tampoco tiene sentido que todo pase por direccion.
Necesitas una matriz de aprobacion:
| Accion | Aprueba |
|---|---|
| Respuesta a FAQ | Agente automaticamente |
| Email a cliente con informacion de pedido | Agente si la fuente es fiable |
| Presupuesto nuevo | Comercial responsable |
| Descuento superior a cierto margen | Responsable comercial |
| Reembolso o abono | Administracion |
| Cambio contractual | Direccion o legal |
Esta matriz evita dos extremos: agentes demasiado peligrosos y agentes tan bloqueados que nadie los usa.
Limites de comportamiento
Los permisos tecnicos no bastan. Tambien hay que definir limites de comportamiento.
Por ejemplo:
- No prometer plazos si el ERP no devuelve fecha confirmada
- No ofrecer descuentos fuera de politica comercial
- No diagnosticar problemas legales, medicos o financieros
- No pedir datos personales innecesarios
- No continuar una conversacion si el usuario expresa enfado grave
- No ejecutar una herramienta si la intencion no esta clara
Estos limites deben estar en instrucciones, evaluaciones y reglas de negocio. Si solo viven en un prompt, son fragiles.
Auditoria: poder reconstruir cualquier decision
Deloitte advierte que muchos riesgos de agentes aparecen cuando no hay monitorizacion, limites claros ni trazas de auditoria. Para una empresa, auditar no es un lujo tecnico: es la forma de responder a una queja, un error o una revision legal.
Un registro minimo deberia incluir:
- Usuario que inicio la accion
- Agente que intervino
- Version del agente
- Sistemas consultados
- Datos usados
- Herramientas ejecutadas
- Resultado de cada herramienta
- Aprobador humano si lo hubo
- Fecha y hora
Sin esto, no puedes saber si el fallo fue del agente, de los datos, del prompt, del usuario o de una integracion.
El ERP no debe ser el primer experimento
Si tu empresa nunca ha usado agentes, no empieces conectando el ERP completo. Empieza con un entorno de menor riesgo:
- Base documental interna
- Bandeja de email
- CRM con permisos de lectura
- Tickets o soporte
- ERP en modo consulta
- ERP con acciones limitadas
- Automatizaciones con aprobacion humana
Este camino permite ganar confianza sin exponer el sistema central del negocio desde el dia uno.
Como podemos ayudarte
En Navel Digital implementamos agentes conectados a sistemas reales con gobernanza desde el inicio: permisos, roles, limites, aprobaciones, registros y fallback humano. Tambien podemos integrarlos con herramientas de conocimiento como Polp para que el agente consulte documentacion interna antes de actuar sobre un CRM o ERP.
Un agente conectado a tu ERP puede ahorrar muchas horas. Pero solo si antes decides exactamente que identidad tiene dentro de tu empresa.