¿Y mis datos? Qué pasa al conectar IA a tu ERP

“Vale, pero como conectéis esto a nuestro ERP, ¿por dónde va a andar nuestra información?” Es la pregunta que llega justo después de que un cliente industrial se convence de que el proyecto tiene sentido. Antes hablaba de horas perdidas y de procesos manuales; en cuanto se habla de dar acceso a sus sistemas, cambia de tema. Y tiene motivo: en su ERP viven los datos de sus clientes, de sus proveedores y de su facturación, y nadie regala eso a la ligera.

Lo que casi nunca se pregunta es cómo va a andar esa información, y esa es la pregunta que de verdad importa.

Qué pasa con tu dato según la vía de conexión

Depende de la vía de conexión, no de la IA en sí. Con la API de un proveedor cloud, el dato pasa por sus servidores según el contrato que firmes. Con un modelo desplegado en tu propia infraestructura, no sale de la empresa. La pregunta correcta no es “¿es segura la IA?”, es “¿por dónde entra y sale mi dato?”.

Ya explicamos que hay tres vías reales para conectar IA a un ERP sin cambiar de sistema: la API nativa, el modelo local y el export periódico. Cada una implica algo distinto para el dato, y esa diferencia es la que responde a la objeción.

API nativa (cloud). La automatización llama a los servidores del proveedor de IA cada vez que necesita procesar algo: por ejemplo, leer una factura, redactar un resumen o clasificar un pedido. El dato viaja, y lo que pase con él después depende del contrato: si el proveedor lo usa para reentrenar su modelo, cuánto tiempo lo conserva, si hay un acuerdo de encargado del tratamiento firmado. No es automáticamente inseguro, pero exige leer la letra pequeña antes de dar acceso.

Modelo local. El modelo corre dentro de la infraestructura de la empresa, en un servidor propio. No hay llamada a ningún proveedor externo: el dato entra, se procesa y sale sin cruzar la puerta de la empresa. Es la opción que elimina de raíz la pregunta de qué hace un tercero con la información, a cambio de un servidor con más capacidad y de que alguien lo mantenga.

Export periódico. El ERP genera un volcado (un CSV, un informe) que recoge un proceso automático en lugar de una persona. El dato sigue moviéndose, pero solo dentro de los sistemas que la empresa ya controla; no hay un tercero nuevo en la ecuación, salvo que ese export alimente después una herramienta cloud.

Quién responde si algo sale mal

Aquí es donde más se confunde la gente: piensan que si la IA se equivoca o filtra algo, la responsabilidad se diluye entre el proveedor y el sistema. No es así.

La guía de la AEPD sobre adecuación al RGPD de tratamientos con IA lo deja explícito: la decisión de adoptar una solución basada en IA la toma el responsable del tratamiento, que es quien “determina los medios y fines del tratamiento”, y en él recae la obligación de ser diligente al seleccionarla, exigir sus especificaciones de calidad y responder de las consecuencias de esa decisión. La propia guía lo dice sin margen: “lo que en ningún caso resulta aceptable es trasladar la responsabilidad al propio sistema IA”. Si tu empresa decide automatizar un proceso con IA, tu empresa sigue siendo la responsable; el sistema que usas no absorbe esa carga.

El proveedor al que contratas ese tratamiento actúa como encargado del tratamiento, siempre que no use tus datos para sus propios fines. Esa distinción no es cosmética: un encargado tiene obligaciones contractuales concretas (artículo 28 del RGPD) sobre cómo trata, dónde guarda y cuándo borra la información. Sin ese contrato firmado, no hay encargado: hay un tercero al que le has dado acceso sin marco legal.

No es paranoia gremial. Según el Thales 2026 Data Threat Report, el 61% de las organizaciones encuestadas señala hoy la IA como su principal riesgo para la seguridad de los datos, no por la tecnología en sí, sino por accesos mal delimitados y controles que no se han adaptado a lo rápido que se ha desplegado. El riesgo real está casi siempre en cómo se ha configurado el acceso, no en el modelo que se usa.

Qué pedir a un proveedor de IA antes de darle acceso a tu ERP

Antes de conectar cualquier automatización a un sistema con datos de clientes o proveedores, hay cuatro cosas que pedir por escrito, no dar por supuestas.

Un contrato de encargado del tratamiento firmado, no una cláusula genérica en los términos de uso. Confirmación explícita de que tus datos no se usan para reentrenar el modelo del proveedor, salvo que lo hayas autorizado tú. Claridad sobre dónde viven los servidores donde se procesa la información, porque no es lo mismo un centro de datos en la UE que uno fuera con transferencia internacional. Y un compromiso de borrado cuando termine la relación, no una promesa verbal de que “se puede pedir”.

Hemos visto proveedores tardar semanas en contestar estas cuatro preguntas con claridad, y esa demora ya es información: dice cómo se va a comportar el resto del proyecto.

Cuándo compensa un modelo local y cuándo es pagar de más por miedo

El modelo local no es la opción “más segura por defecto”. Es la opción que elimina una categoría de riesgo (el tercero externo) a cambio de asumir otra (mantener tú la infraestructura), y eso solo compensa en casos concretos: cuando el sector o el contrato con un cliente exigen que el dato no salga físicamente de la empresa, cuando ya trabajáis en una red aislada sin salida a internet (un caso real y más frecuente de lo que parece en industria), o cuando una decisión interna previa así lo fija, con independencia de la IA.

Fuera de esos casos, exigir modelo local “por si acaso” suele salir caro sin motivo: la entrada es más cara y el mantenimiento recae en vosotros, cuando un contrato de encargado del tratamiento bien firmado con un proveedor cloud serio cubre el mismo riesgo a un coste menor. La pregunta que hay que hacerse no es “¿qué me da más tranquilidad?”, sino “¿qué exige de verdad mi sector, mi cliente o mi contrato?”. La respuesta a esa pregunta, no el miedo genérico a la nube, es la que decide la vía.

Si no sabes cuál de las tres vías encaja con lo que de verdad exige tu negocio, eso es justo lo que responde un diagnóstico de procesos en tres semanas: qué sistema tenéis, qué dato mueve y por dónde conviene entrar sin exponer nada que no haga falta exponer.

Y si lo que te falta todavía es decidir por dónde conectar la IA a tu ERP, esa parte está en integrar IA con un ERP antiguo sin cambiar de sistema, y si el copiloto que ya trae tu ERP no resuelve lo que de verdad te cuesta, está tratado en el copiloto de tu ERP no basta para automatizar tu empresa.

Escrito por Daniel Magarzo, CTO de Made to Scale, que se dedica a integrar estos sistemas.