Conectar el ERP a un agente de IA sin exponer datos sensibles
Conectar un agente de IA al ERP no exige migrar datos ni abrir la red: basta un usuario de solo lectura, permisos por rol y un conector saliente si hace falta.
En resumen
- Un agente de IA que responde preguntas sobre el ERP no necesita permisos de escritura: el acceso se configura como un usuario de base de datos exclusivo, de solo lectura y limitado a las tablas expuestas. Con esa conexión, cualquier persona autorizada puede preguntarle al ERP en lenguaje natural desde WhatsApp.
- No hace falta migrar ni copiar la base del ERP: cada pregunta se resuelve con una consulta en el momento, sobre la base operativa, una réplica o un data warehouse.
- Cuando la base vive dentro de la red de la empresa, la conexión la abre un conector que el cliente instala y que sale hacia afuera, de modo que no hay que abrir puertos en el cortafuegos.
- Los permisos se aplican al construir la consulta, en dos capas que se suman: lo que el usuario de base de datos puede leer y qué tablas y columnas ve cada rol dentro de la plataforma.
- El riesgo más frecuente de estos proyectos no es el acceso sino la calidad del dato: automatizar sobre datos inconsistentes repite los mismos errores, más rápido y con más autoridad aparente.
Para conectar el ERP a un agente de IA sin exponer datos sensibles no hace falta migrar información ni abrir el sistema. Alcanza con un usuario de base de datos exclusivo, de solo lectura y limitado a las tablas del caso de uso; permisos por rol aplicados a cada consulta; y, si la base es interna, un conector saliente.
La primera objeción, en casi todas las conversaciones, es la misma: «no vamos a dejar que un sistema externo entre al ERP». Es una objeción correcta, que suele expresar dos preocupaciones distintas. Una es que algo modifique datos: que un proceso automatizado cambie un registro o dispare un movimiento en el sistema del que depende la facturación. La otra es que información confidencial salga de la organización o llegue a quien no corresponde. Ambas son legítimas, se resuelven de forma distinta, y ninguna obliga a renunciar al proyecto.
¿Cómo conectar el ERP a un agente de IA con el menor acceso posible?
Para conectar el ERP a un agente de IA con el menor acceso posible se le da lectura sobre un conjunto acotado de tablas, y nada más. Un agente de IA que responde preguntas no necesita otra cosa: su trabajo completo es consultar: leer registros, agregarlos, cruzarlos y devolver un resultado.
Por eso el acceso se configura en la base de datos, no como una política interna que alguien promete respetar. La diferencia es la misma que hay entre pedirle a alguien que no entre a una habitación y no darle la llave. Aplicado al principio de menor privilegio, el procedimiento tiene cuatro pasos:
- Crear un usuario exclusivo para el agente. No reutilizar uno existente: así se puede auditar qué consultó y revocarlo sin afectar a nadie más.
- Darle solo lectura. Permiso para conectarse, para ver el esquema y
SELECTsobre las tablas que el caso de uso requiere. No sobre el esquema completo por defecto. - Apuntarlo a una réplica si existe. Si el ERP tiene una réplica de lectura, el agente consulta ahí y la operación no se entera.
- Probar la conexión antes de guardarla. El panel de Igniten verifica por tramos —resolución de nombre, red, cifrado y autenticación— y dice en cuál falló si algo no anda.
Los motores sobre los que corren la mayoría de los ERP de empresas medianas —SQL Server, Oracle, PostgreSQL, MySQL— tienen cada uno su página con la lista exacta de permisos que conviene conceder. La versión general, con lo que conviene exigirle a cualquier proveedor, está en cómo darnos el menor privilegio posible.
¿Hay que migrar los datos del ERP?
No hay que migrar los datos del ERP: el agente los consulta donde ya están. Cada pregunta se resuelve con una consulta en el momento, y no se mantiene una copia de la base en otro lado.
Cuando el volumen crece o cuando las consultas analíticas empiezan a competir con la operación, la solución estándar es leer desde una réplica o desde un data warehouse en lugar de la base transaccional. Es una decisión de rendimiento, no un requisito de arranque, y se toma cuando el problema aparece. Mientras tanto, cada consulta que genera Igniten tiene un tope de tiempo y de filas para no cargar la base de producción.
Hay un beneficio secundario: al no migrar, no hay un proyecto de integración de meses antes de la primera respuesta útil. La empresa puede evaluar si esto le sirve sobre datos reales, sin haber comprometido una inversión previa.
¿Cómo se conecta un ERP que vive dentro de la red de la empresa?
Un ERP que vive dentro de la red se conecta con un conector que la empresa instala y que abre la sesión hacia afuera; nunca al revés. No hay que abrir nada en el cortafuegos ni publicar ningún servicio interno.
El transporte es TLS con autenticación mutua por certificado, saliente sobre el puerto de tráfico web. Cada conector tiene su propio certificado, revocable de forma individual. La lista de destinos que el conector puede alcanzar es un archivo del cliente, que vive en su infraestructura y que solo su equipo edita: Igniten puede solicitar un destino nuevo, pero la solicitud no surte efecto hasta que alguien del cliente la incorpora. El proveedor tampoco aprende la topología de la red: direcciona un destino lógico y la resolución ocurre del lado del cliente.
El código del conector no es abierto: está disponible para revisión del equipo de seguridad del cliente, a pedido y bajo acuerdo de confidencialidad. Si la empresa prefiere no instalar nada, hay dos alternativas documentadas: una red privada virtual estándar o, si la base ya está en la nube, una conexión directa cifrada con lista de direcciones autorizadas. La ficha técnica del conector está publicada en el centro de confianza.
¿Cómo se controla quién ve qué información?
Quién ve qué se controla al construir la consulta, en dos capas que se suman, y no con un filtro aplicado al resultado.
La primera capa es el usuario de base de datos: si no tiene permiso sobre una tabla, ninguna pregunta la alcanza. La segunda es el rol de cada persona dentro de la plataforma, que define qué tablas y columnas ve. Una persona de compras que pregunte por nómina no recibe una negativa cortés después de que el sistema consultó: el sistema nunca consulta esa información para ella.
La identidad de quien pregunta se resuelve según el canal:
| Canal | Cómo se identifica a la persona |
|---|---|
| Microsoft Teams | Contra el directorio de Microsoft 365 |
| Google Chat | Con su cuenta de Google Workspace |
| Por su teléfono, habilitado por el administrador en el panel, sobre la WhatsApp Business API | |
| Panel web | Usuario propio con contraseña y segundo factor obligatorio; en el plan Empresa, además, identidad federada |
Cada conversación queda registrada y es auditable. Ese registro sirve para auditoría y, además, para entender qué está necesitando saber la organización.
¿Qué ve el proveedor de los datos del ERP?
El proveedor ve lo mínimo necesario para responder, y conviene exigir que lo diga por escrito. En el caso de Igniten, eso es:
- Al conectar: la estructura de las tablas expuestas —nombres, columnas y relaciones— y unas pocas filas de ejemplo por tabla, para entender qué guarda cada columna.
- Después: solo los datos que devuelve cada consulta que alguien pide.
- La credencial: se guarda cifrada y es de solo escritura. El panel no la devuelve nunca; solo muestra los últimos cuatro caracteres.
Dentro de la plataforma, los datos de cada organización se separan con Row Level Security aplicada por el motor de base de datos, y con cifrado de sobre con una clave distinta por organización. Nadie de Igniten tiene acceso permanente a datos de producción: el acceso es efímero, se solicita con justificación escrita, expira solo y le genera un aviso al cliente en el momento. El detalle mecánico completo está en la documentación de seguridad, y la lógica de pedir menos acceso está explicada en por qué le pedimos a nuestros clientes el menor acceso posible.
¿Puede un agente de IA modificar registros del ERP?
Sobre la base de datos del ERP, no: las conexiones a bases de datos son de solo lectura sin excepción, con dos candados independientes. El usuario de base de datos no tiene permisos de escritura, y cada consulta generada se verifica como de lectura antes de ejecutarse.
Igniten tiene una función de escritura en los planes Equipo y Empresa, pero es otra cosa y funciona de otra manera: está acotada por el rol de quien la pide y cada acción se presenta como una propuesta explícita que una persona tiene que confirmar. No existe una ruta de ejecución que evite esa confirmación. El porqué está en por qué nuestro asistente no puede ejecutar nada sin que alguien lo confirme.
Checklist para el equipo de IT
Antes de conectar el ERP a cualquier agente de IA, estas son las preguntas que conviene tener respondidas:
| Riesgo | Control que lo cubre | Cómo se verifica |
|---|---|---|
| Que el agente modifique datos | Usuario exclusivo de solo lectura | Revisar los permisos del usuario en la base |
| Que lea más de lo necesario | SELECT solo sobre las tablas expuestas | Listar las tablas concedidas |
| Que alguien vea lo que no le corresponde | Permisos por rol aplicados al construir la consulta | Probar con un usuario de otra área |
| Que haya que abrir la red | Conector saliente con lista de destinos del cliente | Revisar la regla de salida y el archivo de destinos |
| Que la credencial se filtre | Credencial cifrada, de solo escritura | Confirmar que el panel no la muestra |
| Que no quede rastro | Conversaciones registradas y registro de accesos del proveedor visible para el cliente | Revisar el registro en el panel después de una consulta de prueba |
¿Cuál es el riesgo del que casi nadie habla?
El riesgo más frecuente de estos proyectos no es el acceso sino la calidad del dato. Un agente conversacional sobre datos inconsistentes produce respuestas rápidas y equivocadas, redactadas con la misma seguridad que tendrían si fueran correctas.
Una persona frente a una cifra rara se detiene y verifica; un agente la procesa y concluye. Automatizar sobre datos malos no genera errores nuevos: genera los mismos errores de siempre, más rápido y con más autoridad aparente. Por eso la calidad de datos y la gobernanza de datos no son una etapa burocrática previa, sino la condición para que lo que viene después sea confiable. Si en su empresa dos áreas reportan cifras distintas para la misma métrica, ese es el problema a resolver primero, y es de lo que se ocupa la gobernanza de IA.
Una vez resuelto, lo que el agente hace con esa conexión —traducir preguntas a consultas— está explicado en text-to-SQL empresarial, y el panorama completo en la guía de analítica conversacional.