Permisos y control
Dar permisos de escritura a una IA sobre tu ERP sin firmar un cheque en blanco
La respuesta por defecto a «¿dejo que una IA escriba en mi ERP?» es no, y es la respuesta correcta mientras la pregunta se plantee así de grande. Esta página la parte en trozos que sí se pueden responder: qué operación, sobre qué campo, con qué límite, quién lo aprueba y qué queda registrado.
¿Es seguro dar permisos de escritura a una IA sobre el ERP?
Depende por completo de quién toma la decisión de escribir, y esa es la pregunta que hay que hacer en vez de la otra. Si quien decide es el modelo de lenguaje, no es seguro y no lo va a ser: un modelo es probabilístico, puede equivocarse de forma plausible y no se puede auditar pidiéndole que explique por qué. Si quien decide es una regla determinista escrita por ti —que se lee, se prueba y da siempre el mismo resultado con la misma entrada— entonces lo que escribe en tu ERP no lo ha decidido una IA: lo ha decidido tu política, y la IA solo ha preparado el trabajo.
Así funciona el núcleo de control, que es la parte del producto que está construida y en producción: la IA propone, las reglas deciden, y las reglas no son la IA. No hay ningún modelo de lenguaje en el camino crítico de una escritura.
¿Cómo se abren los permisos sin abrirlos todos de golpe?
Por niveles, empezando por uno que no escribe nada. La razón no es comercial, es de método: nadie puede evaluar el riesgo de una automatización que todavía no ha visto funcionar, así que el primer nivel existe para que puedas verla trabajar sin que pueda tocar nada.
| Nivel | Qué hace el agente | Qué puede escribir | Quién decide cada acción |
|---|---|---|---|
| 1 · Observación | Detecta la incidencia, reúne el contexto de los sistemas implicados y propone la resolución | Nada. Permisos de solo lectura | Nadie: no se ejecuta. Sirve para comparar durante semanas lo que habría hecho con lo que hizo tu equipo |
| 2 · Preparado para una persona | Deja la acción lista con todo el contexto delante | Nada hasta que alguien aprueba | Una persona, viendo qué se va a hacer, en qué sistema y cuánto dinero hay en juego |
| 3 · Autónomo dentro de la regla | Ejecuta lo que cae dentro de los límites escritos | Solo las operaciones y los campos que la regla autoriza | La regla determinista. Lo que se sale de ella sube al nivel 2 automáticamente |
| 4 · Parada | Se detiene en frío al instante | Nada | Cualquiera con permiso, sin desplegar nada y sin llamar a nadie |
Si un agente hace algo raro en mi ERP, ¿cómo lo sé y cómo lo demuestro?
Cada decisión queda encadenada en un registro que no se puede modificar ni borrar. Si alguien tocase un apunte antiguo, la verificación deja de cuadrar y dice exactamente en cuál. No es una copia de seguridad ni un fichero de log que se pueda reescribir: es un encadenamiento en el que cambiar un eslabón rompe todos los siguientes, y por eso se puede enseñar a un auditor.
La parte que importa para tu tranquilidad, y que conviene comprobar antes de firmar nada: tu auditor lo puede verificar por su cuenta, sin pedirnos permiso y sin depender de que nosotros sigamos existiendo. Un registro que solo puede validar el proveedor que lo escribe no prueba nada.
¿Qué pasa si el agente se equivoca y ya ha escrito?
Que la escritura queda registrada con quién la autorizó, bajo qué regla y con qué datos, y se deshace por el mismo camino por el que se hizo. Esa es la diferencia práctica entre un agente gobernado y un script: no es que no se pueda equivocar —se puede— es que cada acción tiene un responsable identificable y un rastro para revertirla, en vez de aparecer como un cambio anónimo en una tabla el martes por la mañana.
Por eso los límites se escriben en euros y en operaciones concretas, no en intenciones: hasta qué importe se abona sin preguntar, qué desviación de precio pasa sola, qué campos no se tocan nunca. Un límite que no se puede expresar como número es un límite que no existe.
¿Qué me podéis enseñar hoy funcionando, y qué no?
Hoy se puede enseñar funcionando un caso completo: el cambio de número de cuenta de un proveedor. Llega un correo pidiendo cambiar el IBAN de una ficha; el sistema lo compara con el que hay registrado, detecta que es distinto y, en vez de aplicarlo, lo manda a una persona con las dos cuentas delante y el histórico de ese proveedor. Esa pieza está construida y en producción, y está contada entera en cómo saber si quien pide cambiar una cuenta es de verdad tu proveedor. Si quieres una cifra propia de lo que pesa ese riesgo en tu casa, puedes estimar cuánto cuesta al año no detectar un cambio de cuenta con tu volumen de facturas y tu gasto anual a proveedores.
Lo que no se puede enseñar todavía, dicho sin rodeos: el expediente durable que sostiene un caso de varios días, la vista única del estado de un pedido y la contabilidad de horas eliminadas. Están en construcción con las primeras distribuidoras. Si en una demostración alguien te enseña todo eso funcionando, o tiene un producto distinto del nuestro o te está enseñando un prototipo.
¿Qué NO podéis garantizar?
Cuatro cosas, y conviene que estén escritas antes de una reunión y no durante. La primera: no garantizamos que el modelo no se equivoque al proponer. Garantizamos que una propuesta equivocada no se ejecuta sola si se sale de la regla, y que si se ejecuta dentro de la regla queda registrada con su autorización.
La segunda: no garantizamos escribir en un sistema que no lo permite. Si una aplicación solo deja leer, el trabajo se deja preparado para que una persona lo confirme. Cuáles son esas aplicaciones sale del inventario técnico, antes de prometer nada: está detallado en qué se puede leer y escribir en cada tipo de sistema.
La tercera: no garantizamos ahorro. No tenemos todavía datos propios de cliente, así que cualquier cifra de ahorro que te diéramos sería una cifra inventada. Lo que sí hacemos es medir tu situación de partida en el diagnóstico operativo antes de empezar, para que el resultado se pueda comparar contra algo. Y la cuarta: no sustituimos el control de accesos de tus sistemas — los permisos que damos son un límite adicional por encima de los tuyos, nunca un sustituto de ellos.
Todo el detalle técnico —identidades por agente, segregación de funciones, alojamiento europeo y cómo se verifica el registro— está en cómo se controlan los permisos y dónde se guardan los datos.
Preguntas frecuentes
¿Puede una IA escribir directamente en mi ERP?
Técnicamente sí, y es justo lo que no conviene hacer sin una capa de decisión en medio. En nuestro diseño el modelo de lenguaje nunca escribe: propone una acción, y quien autoriza o rechaza esa acción es una regla determinista escrita por el cliente, que da siempre el mismo resultado con la misma entrada y se puede leer y probar. Lo que se sale de la regla lo aprueba una persona con el contexto delante. No hay ningún modelo de lenguaje en el camino crítico de una escritura.
¿Qué es el modo observación y para qué sirve?
Es el nivel inicial, en el que el agente trabaja con permisos de solo lectura: detecta las incidencias, reúne el contexto de los sistemas implicados y propone qué haría, pero no ejecuta nada. Sirve para que durante unas semanas puedas comparar lo que habría hecho con lo que efectivamente hizo tu equipo, y decidir con datos propios qué operaciones te compensa automatizar y cuáles no. Es la forma de evaluar el riesgo antes de asumirlo, en vez de después.
¿Cómo sé qué ha hecho un agente en mis sistemas?
Cada decisión queda encadenada en un registro que no se puede modificar ni borrar, con qué se hizo, en qué sistema, bajo qué regla y quién lo autorizó. Si alguien alterase un apunte antiguo, la verificación deja de cuadrar e indica exactamente en cuál falla. Ese registro lo puede verificar tu auditor por su cuenta, sin pedirnos permiso, que es la diferencia entre un rastro auditable y un fichero de log que cualquiera con acceso puede reescribir.
¿Se puede parar un agente en caliente?
Sí, al instante y sin desplegar nada. Un agente se detiene en frío desde la propia herramienta, sin tener que avisar a nadie ni esperar a una ventana de mantenimiento, y sin tocar el resto de la operación. Es una decisión de diseño deliberada: un control que exige abrir una incidencia con el proveedor para ejecutarse no es un control, porque en el momento en que hace falta usarlo no está disponible.
¿Qué permisos hay que darle a Pliuz sobre el ERP para empezar?
Para empezar, de solo lectura, y se abren después uno a uno según qué procesos decidas activar. Los permisos se definen por operación y por campo —no «acceso al ERP», sino qué operación concreta sobre qué campo y con qué límite en euros— y se acompañan de una identidad propia para cada agente, de modo que en el registro se distinga siempre qué actuó y en nombre de quién. El alcance exacto sale del inventario técnico, que es lo primero que se hace.
¿Cumple esto con el Reglamento Europeo de IA?
Las piezas que el Reglamento pide para supervisión humana y trazabilidad —registro de la actividad, capacidad de intervención de una persona y responsabilidad identificable de cada acción— están construidas y en producción. Dicho eso, el cumplimiento no es una propiedad de una herramienta sino de cómo la usa cada organización, así que ningún proveedor honesto puede decirte que comprarle algo te deja conforme. Lo que sí podemos es aportar la evidencia técnica que tu responsable de cumplimiento necesite, y enseñar cómo se verifica.
La primera pregunta no es qué permisos das. Es qué está pasando hoy sin que nadie lo mire
Antes de abrir un solo permiso de escritura conviene saber qué cadena de tu operación merece la pena tocar, y eso se decide con datos. El diagnóstico operativo son dos sesiones sobre una cadena concreta, sin acceso a tus sistemas y sin credenciales, e incluye el inventario de qué se puede leer y escribir de verdad en cada aplicación.
Si de ahí no salen al menos 40 horas al mes eliminables, te lo decimos por escrito y no hay proyecto.
Pedir el diagnóstico operativo