Hay que distinguir dos momentos que la palabra «datos» tiende a confundir. Durante la generación, lo que usted ESCRIBE, su descripción y el texto de los archivos que adjunta, se transmite a un proveedor de modelos para producir la especificación y el código; los proveedores están nombrados en la política de privacidad. Una vez que la aplicación está en marcha, nada más sale: el código entregado no contiene ningún cliente de inteligencia artificial entre sus dependencias, y el archivo de configuración que se escribe en el servidor no incluye ninguna clave de API. Es decir, sus clientes, sus intervenciones, sus miembros, todo lo que introduzca después, no pueden alcanzar, por diseño, ningún modelo. La única materia que se envía a un modelo es la que usted ha redactado para describir su necesidad: su descripción y el texto extraído de los archivos adjuntos.
Qué se envía a un modelo y cuándo
La generación necesita comprender su actividad profesional: es su descripción la que le proporciona ese contexto, por lo que se transmite a un proveedor de modelos, junto con el texto de los archivos adjuntos que añada. La política de privacidad los nombra explícitamente, Anthropic, OpenAI, xAI y Google, y aclara que estos tratamientos pueden realizarse fuera de la Unión Europea, amparados por las cláusulas contractuales tipo de la Comisión Europea. No se trata de un detalle que deba leerse entre líneas: es la materia prima de la generación, y no existe ninguna versión del producto en la que su descripción permanezca localmente mientras se genera una aplicación que le recuerde.
Este intercambio tiene un final definido. Se produce únicamente durante la generación, para elaborar primero la especificación y luego el código, y solo se repite en la siguiente generación, cuando reinicie el proceso o solicite una modificación. Entre una generación y otra, no ocurre nada: no hay sincronización continua, ni remisión de datos de uso a un modelo, ni análisis en segundo plano del contenido de su aplicación.
Qué nunca se envía: los datos que introducirá después
La aplicación desplegada es un software convencional, y esto se puede verificar en tres puntos del código entregado. Su lista de dependencias no incluye ningún cliente de inteligencia artificial, solo Next.js, React, Prisma y bibliotecas de presentación. El archivo de configuración que se escribe en el servidor al desplegarse consta de cuatro líneas: la dirección de la base de datos, dos secretos técnicos y un número de compilación; ninguna clave de API aparece en él. Y las cifras de su panel de control se calculan mediante consultas deterministas sobre su base de datos, nunca mediante un modelo al que se le pida que lea sus registros.
La consecuencia es la que más importa para la preocupación más frecuente: el entrenamiento de los modelos. Incluso bajo el supuesto más desfavorable, la única información susceptible de verse afectada sería su descripción inicial: la frase en la que explica que gestiona un taller, intervenciones y clientes. Nunca el contenido de sus fichas de clientes, el historial de sus intervenciones ni la lista de sus miembros, ya que esos registros no tienen, en ningún momento, una vía de acceso hacia un modelo.
Archivos adjuntos: dos rutas, pero solo una pasa por un modelo
Un archivo adjunto no siempre sigue la misma ruta, y la distinción está claramente implementada en el código. Una hoja de cálculo, un CSV, un PDF o un archivo de texto se lee EN EL SERVIDOR mediante extractores convencionales: ningún modelo examina directamente el archivo. En cambio, una fotografía o una captura de pantalla sí se envía efectivamente a un modelo de visión, cuya función específica es describirla, es la única forma de interpretar un formulario en papel o una tabla fotografiada.
Hay un punto que conviene dejar claro, porque afecta a una decisión práctica: el texto extraído de un archivo sí se incorpora al contexto enviado al modelo, con un límite de doce mil caracteres por archivo. Por tanto, si adjunta una hoja de cálculo para mostrar la estructura de sus datos, ese texto se envía junto con su descripción. Si dicho archivo contiene datos personales reales, la buena práctica se resume en una frase: adjunte únicamente la fila de encabezados y algunas filas de ejemplo anonimizadas. El generador necesita la FORMA de sus columnas, no los nombres de sus clientes.
Qué está garantizado y qué no lo está
Primero, una garantía concreta, escrita literalmente en el código: cuando adjunta un CSV para comenzar con sus registros reales, dichos registros se insertan en su base de datos mediante una coincidencia determinista, detección del delimitador, correspondencia entre sus encabezados y los campos, conversión tipada, y ningún modelo interviene en este paso. La razón está expresada con total claridad en esa parte del código: los datos del usuario no se reinventan. Un modelo que «completara» una tabla de miembros produciría filas verosímiles pero falsas, lo cual constituye el único resultado verdaderamente inaceptable.
En segundo lugar, lo que esta página no pretende garantizar: la política interna de cada proveedor de modelos respecto a la reutilización de los contenidos que le transmita. Eso corresponde a sus compromisos contractuales, no al comportamiento de este producto; la política de privacidad los nombra y describe el marco regulatorio de los traslados, y es allí donde debe consultar. Lo que sí garantiza el producto es el PERÍMETRO, qué sale, cuándo y, sobre todo, qué nunca sale. Precisamente porque ese perímetro es tan estrecho, la cuestión del entrenamiento no afecta a su archivo de clientes.