Las preguntas que hace quien conecta los datos

¿A qué bases de datos y ERPs se conecta?

A SQL Server, PostgreSQL, Oracle, SAP HANA, MySQL, MariaDB y SQLite. No hay un conector por ERP: el conector es por motor de base de datos.

Eso significa que sirve cualquier ERP, CRM o sistema propio que guarde sus datos en uno de esos motores, que es el caso de buena parte del software de gestión instalado en España. Sapioverse lee el esquema, lo documenta y trabaja sobre él; no necesita una integración a medida por fabricante.

Si tu ERP es un servicio en la nube que no da acceso a su base de datos, o si los datos están repartidos entre varios sistemas y hojas de cálculo, hace falta un paso previo: llevarlos a una base de datos consultable. Eso no lo resuelve el producto por sí solo, y lo decimos antes de vender nada — es justamente lo que cubren los servicios de datos.

¿Puede modificar o borrar datos?

No. Solo lee.

Toda consulta generada pasa por un validador antes de ejecutarse: solo se admiten lecturas (SELECT y WITH), y se rechaza cualquier instrucción que escriba, borre o cambie la estructura. La restricción no depende de que el modelo se porte bien: es una comprobación del código, delante de la base de datos.

Aun así, recomendamos siempre conectar con un usuario de base de datos que solo tenga permisos de lectura. Dos cerrojos son mejores que uno, y el segundo lo controlas tú.

¿Se inventa los números?

No. Las cifras no las escribe el modelo: salen de una consulta ejecutada contra tu base de datos.

El modelo hace dos cosas: traducir tu pregunta a una consulta y redactar el resumen con el resultado que vuelve. Los números que ves en la respuesta y en el gráfico son los que ha devuelto tu base de datos.

El modo de fallo real es otro, y preferimos contarlo: ante una pregunta ambigua, el modelo puede entenderla mal y consultar algo distinto de lo que querías. La cifra sería correcta y la pregunta, no. Por eso la consulta generada queda a la vista, y por eso el sistema pide que aclares la pregunta cuando admite varias lecturas.

¿Qué información sale hacia el modelo?

La estructura, el contexto de negocio y muestras pequeñas de datos. No la base de datos entera.

En concreto, para escribir la consulta el modelo recibe los nombres de tablas y columnas, el contexto de negocio que hayáis cargado y una muestra reducida de filas de ejemplo. Para redactar el resumen recibe además una muestra de los resultados de esa consulta: sin ver los datos, no podría describirlos.

Es la parte que conviene mirar con calma si trabajáis con datos personales o sensibles. Está detallada en la política de privacidad, junto con la lista de proveedores y dónde se procesa cada cosa.

¿Entrenáis modelos con mis datos?

No.

La cuenta desde la que llamamos a los modelos está configurada con retención cero: lo que se envía no se almacena ni se usa para entrenar. Además, cada petición lleva esa condición declarada de forma explícita, para que no dependa solo de un ajuste de la cuenta.

Tampoco reutilizamos los datos de un cliente para otro: el contexto de negocio que cargáis vive asociado a vuestra organización y no sale de ahí.

¿Tengo que abrir mi base de datos a internet?

Con el agente local, no. Hay dos formas de conectar, y en la primera no se abre ningún puerto.

Con el agente local. Instaláis un programa en un equipo de vuestra red que sí ve la base de datos. Ese agente es siempre quien inicia la conexión, hacia fuera, para preguntar si hay trabajo pendiente. No hay ninguna conexión entrante hacia vuestra red: no hay que abrir puertos, ni publicar la base de datos, ni tocar el cortafuegos. Está explicado paso a paso en cómo conectar tu base de datos.

Con conexión directa. Nuestro servidor alcanza la base de datos, y tampoco hace falta dejarla abierta a todo el mundo: lo habitual es un usuario de solo lectura y el acceso limitado a nuestra dirección IP, de modo que siga cerrada para cualquier otro origen.

Y si vuestra política no permite exponer la base de datos de producción por ninguna de las dos vías, queda la alternativa de siempre: replicar a una base intermedia, que además evita que las consultas de análisis compitan con el sistema en uso.

Tengo cientos de tablas. ¿Cómo sabe cuál es la de ventas?

Porque se lo decís vosotros. Cada tabla y cada columna llevan su contexto de negocio escrito.

No es una lista de sinónimos: es la regla de vuestra casa. Que las facturas anuladas no cuentan como venta, que el canal DI es distribuidor, que el importe neto va sin portes. Esa capa es la que hace que el número salga bien, y sin ella cualquier herramienta acierta la sintaxis y falla el resultado.

Si vuestra base ya está documentada con COMMENT, se importa de ahí al sincronizar el esquema: documentáis una vez, en vuestra propia base, y sirve para todo lo demás.

Si dejamos de ser clientes, ¿qué nos llevamos?

El código. Los procesos que montéis se transpilan a Python y SQL legibles.

El constructor de ETL es visual, pero lo que genera por debajo no es un formato propietario: es un script que vuestro equipo puede leer, versionar y ejecutar en su propia máquina. No es una exportación de cortesía preparada para el día de la baja, es el mismo código que se ejecuta en producción.

El contexto de negocio que hayáis escrito también es vuestro, y sale en texto plano.

¿Esto sustituye a nuestro equipo de datos?

No. Lo que quita de en medio es la cola de peticiones, no a quien la atiende.

Alguien tiene que conectar las fuentes, decidir cómo se modelan y escribir las reglas. Eso lo sigue haciendo vuestro equipo, y es la parte que aporta criterio. Lo que deja de llegarle es el «¿me sacas un Excel de esto?» de un martes a las siete, que es trabajo que interrumpe y no enseña nada.

Las preguntas que sí requieren criterio siguen llegando, y suelen llegar mejor planteadas: quien pregunta ya ha visto los datos antes de subir el asunto.

¿Tenéis SOC 2 o ISO 27001?

No, ninguna de las dos. Y preferimos decirlo aquí y no en la última reunión.

Son auditorías que hace un tercero independiente. Cuestan decenas de miles de euros y exigen meses observando que los controles funcionan de verdad, no un fin de semana de papeleo. Una empresa de nuestro tamaño todavía no las tiene, y decir lo contrario sería fácil de comprobar.

De paso, un apunte que os sirve para evaluar a cualquiera: un sello no es una auditoría. No existe un sello oficial de RGPD, y quien enseñe uno debería poder enseñar también el informe que hay detrás. Pedidlo, a nosotros y al resto.

Si vuestra política de compras exige una certificación para poder firmar, es un requisito legítimo: decídnoslo en la primera conversación y no en la última, y os decimos si tiene sentido seguir.

¿Quién más toca nuestros datos?

Tres proveedores, y os los damos con nombre y país.

• IONOS (Unión Europea): aloja la web y el correo.
• OpenRouter (Estados Unidos): recibe cada consulta y la enruta al modelo.
• Los proveedores de modelos a los que enruta (Google Vertex, Azure OpenAI, AWS Bedrock), en Estados Unidos: escriben la consulta y redactan el resumen.

Las transferencias a Estados Unidos se amparan en las cláusulas contractuales tipo de la Comisión Europea, en su módulo 2. Podemos daros el contrato de encargado del tratamiento antes de conectar nada, y una copia de esas garantías si vuestro equipo legal la pide; el detalle está en la política de privacidad.

Y lo que hoy no podemos prometeros: aviso previo si cambia el proveedor de modelos concreto que atiende una consulta. Ese aviso no nos llega a nosotros tampoco. Lo hemos preguntado por escrito y, mientras no haya respuesta, preferimos que lo sepáis a prometeros algo que no controlamos.

¿Qué medidas hay puestas, en concreto?

Estas. Son comprobables una a una, y cada una responde a una forma distinta de que algo salga mal.