La IA dentro de un ERP aporta valor cuando reduce clasificación, búsqueda y preparación de decisiones, pero no debe adquirir permisos equivalentes a una persona administradora. Las funciones de bajo impacto pueden automatizarse con muestreo; pagos, cierres, altas de proveedor, cambios fiscales y decisiones sobre personas requieren reglas deterministas, validación y aprobación.
Casos de uso por nivel de riesgo
| Caso | Beneficio | Control |
|---|---|---|
| Clasificar documentos | Menos trabajo manual | Muestreo |
| Extraer campos | Registro más rápido | Validación por campo |
| Predecir demanda | Planificación | Comparación con línea base |
| Detectar anomalías | Alerta temprana | Investigación humana |
| Preparar asiento | Ahorro | Aprobación contable |
| Crear pago | Alto impacto | Doble aprobación |
| Cambiar maestro | Efecto transversal | Flujo controlado |
La autonomía aumenta solo con evidencia.
Arquitectura
La IA no debería escribir directamente en las tablas del ERP. El sistema expone herramientas delimitadas mediante APIs o servicios que validan esquema, identidad, permiso, regla y contexto antes de ejecutar cualquier acción.
Las capas de esta arquitectura son:
- Identidad del usuario y del agente.
- Política de acceso.
- Recuperación de datos autorizados.
- Modelo.
- Herramienta.
- Validación determinista.
- Aprobación.
- Trazabilidad.
Datos y maestros
Un modelo que trabaja sobre datos duplicados o incompletos acelera los errores en lugar de reducirlos. Antes de desplegar cualquier funcionalidad se revisan clientes, productos, impuestos, proveedores, unidades y estados.
Las salidas inferidas se marcan como propuestas, nunca como hechos. El sistema conserva la fuente, el nivel de confianza y la persona que validó cada dato.
Extracción documental
Para facturas, pedidos o contratos se mide la exactitud campo a campo. El NIF, el importe, la fecha, el IBAN y el impuesto tienen distinto impacto si fallan. Los campos críticos requieren validaciones matemáticas y contraste contra los maestros.
La IA no decide por sí sola si un documento es legítimo.
Predicción
El forecasting de demanda o de tesorería debe compararse siempre con métodos simples. Las métricas de referencia son:
- Error absoluto.
- Sesgo sistemático.
- Cobertura.
- Estabilidad.
- Coste de sobreestimación e infraestimación.
Si el modelo no supera una referencia sencilla, no justifica la complejidad añadida.
Agentes con herramientas
Un agente puede consultar el stock y crear el borrador de un pedido, pero no debe aprobar la compra sin límites. Cada herramienta separa lectura y escritura, y define cantidad máxima, proveedores permitidos e idempotencia.
OWASP identifica la agencia excesiva como un riesgo propio de estos sistemas. Los controles deben residir fuera del prompt, no dentro de él.
Supervisión humana
La pantalla de aprobación debe mostrar siempre:
- La acción propuesta.
- Los datos de origen.
- La regla aplicada.
- Los cambios exactos.
- El impacto.
- La alternativa.
- La posibilidad de revertir.
Aprobar a ciegas no es supervisión.
Permisos
El agente utiliza una identidad propia, nunca la de una persona administradora. Los permisos se restringen por:
- Empresa.
- Módulo.
- Operación.
- Importe.
- Horario.
- Entorno.
- Destinatario.
La baja o el cambio de rol de una persona debe revocar automáticamente los permisos del agente asociado.
Seguridad
Las principales amenazas a vigilar son:
- Prompt injection en facturas o correos.
- Proveedor falso.
- Extracción de datos.
- Cambio de IBAN.
- Acciones duplicadas.
- Memoria contaminada.
- Fuga de información entre empresas.
Se aplican listas permitidas, segregación, autenticación multifactor, validación y alertas. Un texto contenido dentro de un documento no puede cambiar las instrucciones del sistema.
Trazabilidad
Cada ejecución debe registrar:
- Modelo y versión.
- Prompt y política aplicada.
- Datos consultados.
- Herramientas utilizadas.
- Argumentos.
- Validaciones realizadas.
- Aprobación.
- Resultado.
- Coste y latencia.
Los registros se minimizan y se protegen.
Calidad y regresión
El conjunto de pruebas debe incluir cierres, impuestos, devoluciones, duplicados, datos incompletos y ataques. Se ejecuta cada vez que cambia el modelo, el prompt, el conector o la versión del ERP.
Las clases críticas tienen tolerancia cero.
Coste y ROI
Se calcula el coste por tarea válida, sumando modelo, infraestructura, integración, revisión, soporte e incidentes. El ahorro teórico no cuenta si termina aumentando el retrabajo.
Plan de 90 días
Días 1–30
Caso acotado, línea base, datos y permisos.
Días 31–60
Integración, pruebas, trazas y supervisión.
Días 61–90
Piloto, métricas, riesgo y decisión.
Errores frecuentes
- Activar funciones sin propietario.
- Dar permisos administrativos al agente.
- Confiar en datos maestros de mala calidad.
- Medir solo la velocidad.
- Permitir escritura directa en el ERP.
- No validar IBAN e impuestos.
- Aprobar por defecto.
- No versionar los prompts.
- Mezclar datos entre empresas.
- Escalar sin pruebas de regresión.
Checklist
- Caso y línea base definidos.
- Datos y maestros revisados.
- Identidad y permisos configurados.
- Herramientas delimitadas.
- Validación determinista implementada.
- Supervisión efectiva.
- Seguridad adversarial contemplada.
- Registros y versiones controlados.
- Coste por tarea válida calculado.
- Plan de parada definido.
Preguntas frecuentes
¿Puede la IA contabilizar automáticamente?
Puede preparar propuestas de asiento. La automatización final depende del riesgo, las reglas, la evidencia acumulada y la aprobación humana.
¿Puede la IA hacer pagos?
No debería hacerlo sin controles estrictos, límites de importe y doble aprobación fuera del propio modelo.
¿La IA sustituye al BI?
No. El BI describe y monitoriza; la IA puede predecir o asistir, pero necesita datos de calidad y métricas para hacerlo con fiabilidad.
En Summum Sistemas ayudamos a integrar IA en el ERP con permisos, pruebas y supervisión adecuados a cada nivel de riesgo.