Qué datos ve realmente un modelo de IA cuando consulta tu ERP

Es la primera pregunta que hace cualquier responsable de sistemas cuando se propone conectar inteligencia artificial al ERP, y la que más veces se contesta con vaguedades tipo «tus datos están seguros». La respuesta concreta depende por completo de la arquitectura, y hay tres. No son equivalentes. ## Arquitectura 1: los datos van tal cual El sistema consulta el ERP y envía los resultados al modelo para que redacte la respuesta. Es la forma más directa y la más común en integraciones hechas a medida. Lo que sale de tu red: **los valores reales**. Nombres de clientes, importes, correos, identificadores fiscales. Si preguntas por la deuda de un cliente, el nombre y el importe de ese cliente salen literalmente. Puede ser aceptable —depende de tu evaluación de riesgo, del proveedor del modelo y de sus condiciones de tratamiento— pero hay que saber que es lo que está pasando, porque tiene implicaciones directas de RGPD: hay una comunicación de datos personales a un tercero, y eso exige base jurídica, información al interesado y encargo de tratamiento. ## Arquitectura 2: el modelo no toca los datos Aquí el modelo no recibe datos: recibe la pregunta y devuelve **qué consulta hay que hacer**. La consulta se ejecuta dentro de tu sistema y el resultado no se le envía. Lo que sale: la pregunta del usuario y metadatos de estructura, como qué modelos y campos existen. Es la más restrictiva y tiene un límite claro: el modelo no puede interpretar, resumir ni comentar el resultado, porque no lo ha visto. Sirve para consultas mecánicas y no para «explícame por qué ha caído el margen». ## Arquitectura 3: los datos van, pero no identificables El sistema consulta el ERP, **sustituye los valores sensibles por marcadores antes de salir de tu red**, y envía la estructura con esos marcadores. El modelo razona sobre datos no identificables y, al volver la respuesta, los marcadores se reemplazan por los valores reales dentro de tu sistema. Lo que sale: la forma del dato, no el dato. El modelo sabe que hay un cliente con un importe vencido y puede razonar sobre ello, pero no sabe qué cliente ni cuánto. Es el enfoque de Robin, y la razón de elegirlo es que conserva la capacidad de interpretar sin comunicar datos identificables a un tercero. ## Las tres preguntas que hay que hacer a cualquier proveedor Independientemente de con quién habléis, estas tres separan una respuesta seria de un folleto: **1. ¿Qué sale exactamente de mi red en una consulta concreta?** Pide un ejemplo real: la petición que se envía al modelo para una pregunta como «deuda vencida por cliente». Si no te lo pueden mostrar, no lo saben o no quieren decirlo. **2. ¿Con qué permisos se ejecuta la consulta?** Es la pregunta que más se olvida y la que más agujeros abre. Si el sistema consulta con un usuario técnico con permisos amplios, cualquiera que pregunte puede ver cualquier cosa, aunque en el ERP no tuviera acceso. Lo correcto es que herede los permisos del usuario que pregunta. **3. ¿Qué queda registrado?** Sin registro por consulta no puedes auditar quién consultó qué, y eso es una obligación en cuanto haya datos personales de por medio. Pregunta qué se guarda, dónde y cuánto tiempo. ## Lo que ninguna arquitectura arregla Conviene decirlo, porque es donde fallan los proyectos: **el control de acceso es tuyo**. Si en tu Odoo los permisos están mal puestos y medio equipo ve lo que no debe, ninguna capa de IA lo va a corregir; lo que hará es hacerlo más cómodo de consultar. Antes de conectar nada, revisa los grupos y permisos del ERP. Es un trabajo poco agradecido y es el que de verdad determina el riesgo. Tenemos desarrollada la arquitectura completa, con el flujo de anonimización y el registro de auditoría, en [cómo conectar IA con Odoo sin exponer datos sensibles](/seguridad/). Y las dudas más frecuentes sobre esto, en las [preguntas frecuentes sobre IA para Odoo](/faq/).