Caso de uso · 25 de agosto de 2026

Qué mira exactamente un sistema con IA sobre tu ERP

Es la primera pregunta que hace cualquier área de sistemas, y casi siempre se responde mal. Este caso de uso explica qué ve y qué no ve un modelo cuando se conecta a tu sistema de gestión, cómo se acota ese acceso, qué pasa con los datos personales, y las siete preguntas que conviene hacerle a cualquier proveedor antes de firmar.

La respuesta que deberías desconfiar

Si preguntás si la inteligencia artificial va a ver los datos de tu empresa y te contestan que no, que el modelo nunca accede a tu base, hay dos posibilidades: o el sistema no hace nada útil, o te están simplificando la respuesta hasta volverla falsa.

Un asistente que responde "cuánto vendimos ayer en Córdoba" tiene que consultar los datos para contestar eso. No hay manera de esquivarlo. La pregunta útil no es si los consulta, sino bajo qué condiciones, con qué permisos y con qué límites.

Las capas entre tu ERP y el modelo

Lo que casi nadie explica es que el modelo no se conecta al sistema de gestión. Entre uno y otro hay varias capas, y esas capas son lo que hace que esto sea seguro y estable.

1. Una réplica, no tu sistema en vivo

La copia de los datos se hace contra una réplica de la base, no contra la base que usa tu gente. Esto tiene un motivo operativo antes que de seguridad: las consultas analíticas son pesadas, y nadie quiere que el sistema se ponga lento un sábado a la tarde porque un reporte está corriendo.

2. Un almacén de datos propio

Desde esa réplica se copian las tablas que se declararon, y solo esas, a un almacén separado. Ahí los datos se normalizan: se unifican los códigos que cada sucursal escribe distinto, se resuelven las fechas, se arman las métricas. En una cadena con una base por local, este paso es el que convierte varias bases sueltas en una sola verdad consultable.

3. Métricas, no tablas crudas

La capa que el asistente consulta no son las tablas del ERP sino las métricas ya construidas: ventas por día y local, stock por variante, cobros conciliados. Esto importa por una razón práctica además de la seguridad: si el modelo tuviera que interpretar el esquema crudo de un ERP en cada pregunta, se equivocaría seguido y de formas difíciles de detectar.

4. Herramientas acotadas, no acceso libre

El modelo no escribe consultas sueltas contra la base. Usa herramientas definidas de antemano, que solo permiten leer, con tiempo máximo de ejecución y tope de filas devueltas. Si una consulta se pasa de ahí, se corta.

Qué puede hacer y qué no, en concreto

No puede escribir. Y esto no es una promesa comercial, es una configuración verificable: el usuario con el que se conecta el sistema no tiene permisos de escritura en la base de datos. Aunque alguien se lo pidiera explícitamente, la base lo rechaza. Tu área de sistemas puede confirmarlo en dos minutos mirando los permisos de ese usuario.

No puede ver lo que no se declaró. Se copian las tablas acordadas. Si una tabla no está en esa lista, no existe para el sistema.

No modifica tu ERP. Todo lo que produce vive del lado del almacén. Las decisiones que se toman a partir de sus sugerencias las ejecuta tu gente en tu sistema, como siempre.

Los datos personales

Un ERP tiene nombres de clientes, documentos, domicilios, y a veces datos de empleados. Conviene resolver esto antes de conectar nada, y la pregunta correcta es más simple de lo que parece: ¿el sistema necesita ese dato para responder lo que le vamos a preguntar?

Para casi todo lo operativo la respuesta es que no. Saber cuánto se vendió, qué stock falta o qué cobro no cerró no requiere saber quién compró. Cuando el dato personal no hace falta, lo correcto es que no salga del ERP, o que salga reemplazado por un identificador que no permita reconstruir a la persona.

Cuando sí hace falta, por ejemplo para un aviso a un cliente puntual, eso debe quedar explícito y acotado a ese uso. La regla general es que la comodidad de copiar todo por las dudas no justifica mover datos personales.

Las siete preguntas para cualquier proveedor

Sirven para evaluarnos a nosotros y a cualquier otro. Si alguna no tiene respuesta clara, ahí hay un problema.

• ¿Con qué usuario se conecta y qué permisos tiene? La respuesta correcta se puede verificar en la base, no se toma de palabra.
• ¿Se conecta a producción o a una réplica?
• ¿Qué tablas se copian, exactamente? Tiene que haber una lista, no un "las que hagan falta".
• ¿Por dónde viaja la conexión? Red privada o túnel, sin puertos abiertos a internet.
• ¿Dónde corre el sistema y quién puede entrar? Y si tu política lo exige, si puede correr dentro de tu propia infraestructura.
• ¿Qué pasa con los datos personales? Ver la sección de arriba.
• Si mañana cortamos, ¿qué me llevo? La respuesta que sirve es un export completo del almacén más la documentación de cada métrica, en formato abierto. Sin eso, lo que parecía un proveedor es una jaula.

Por qué esto se pregunta tarde

En general estas preguntas aparecen en la última reunión, cuando la decisión ya se tomó y aparece el área de sistemas a revisar. Ahí el proyecto se frena semanas, no porque las respuestas sean malas sino porque nadie las había escrito.

Conviene al revés: que estén contestadas antes de la primera reunión técnica. Si el proveedor no las tiene por escrito, es una señal en sí misma.