Define adónde pueden ir tus datos

Separa dos flujos de datos

El vibe coding sirve para explorar un flujo de trabajo con registros ficticios. El riesgo cambia cuando entra información real de la empresa en la herramienta. Eso puede ocurrir antes de que la aplicación tenga usuarios.

Hay que inspeccionar dos flujos. El de desarrollo incluye prompts, contexto del repositorio, archivos adjuntos, resultados de herramientas y logs de diagnóstico. El de la aplicación incluye solicitudes de usuarios, bases de datos, integraciones, telemetría y copias de seguridad. Cada flujo puede tener destinatarios y controles distintos.

Considera una aplicación ficticia de gastos. Su base de datos se ejecuta en una cuenta de nube autorizada. Un desarrollador pega una solicitud real de reembolso en un asistente para corregir un analizador. La solicitud incluye el nombre de un empleado, un recibo y datos bancarios. La ubicación autorizada de la base de datos no implica permiso para esta divulgación independiente.

Inspecciona el recorrido completo

Dibuja el recorrido antes de añadir datos confidenciales. Identifica el servicio y la cuenta concretos en cada paso. Una etiqueta de producto como «enterprise» no es un diagrama de flujo de datos.

Registra el contrato y la configuración aplicables. Comprueba los subencargados del tratamiento, el comportamiento de borrado, las condiciones de entrenamiento y las transferencias internacionales cuando corresponda. Pide a las personas responsables de privacidad y seguridad que resuelvan las dudas.

Los requisitos del RGPD dependen del contexto del tratamiento. Entre sus disposiciones pertinentes están la minimización de datos, los acuerdos con encargados, la seguridad y la evaluación de impacto. La confidencialidad empresarial también abarca información que no es personal, como código fuente o planes comerciales. Lee el reglamento.

Empieza con datos de prueba ficticios y útiles

Un ejemplo seguro sigue necesitando una estructura realista. Sustituye nombres, identificadores y números de cuenta. Conserva las condiciones que causaron el defecto: un campo ausente, una fecha inusual o una descripción larga.

No llames «sintético» a un registro copiado de producción después de cambiar un nombre. Los campos restantes pueden identificar a una persona o revelar una transacción. Crea un registro nuevo a partir del esquema y de la condición que produce el fallo.

Mantén las credenciales fuera de los prompts y los datos de prueba. Si la tarea necesita un secreto, usa el mecanismo autorizado con acceso limitado. La instrucción «mantén esto privado» no impone un límite técnico.

Verifica antes de ampliar el uso

Redacta una decisión breve sobre el uso permitido: categorías de datos, configuración autorizada del servicio, acciones permitidas y persona responsable. Incluye una fecha de caducidad o una condición que obligue a revisarla. Un nuevo conector, una ruta distinta al modelo o un cambio en los logs pueden alterar la decisión.

Si la información llega a un destinatario no autorizado, detén cualquier divulgación adicional y sigue el proceso de incidentes. Registra qué se compartió y dónde. Evita copiar el material sensible en más tickets o chats.

El objetivo práctico es un uso controlado. Los datos ficticios permiten explorar con rapidez. Los límites de tratamiento verificados permiten dar el siguiente paso hacia los flujos de trabajo de la empresa. Ni una demostración pulida ni una región de nube responden a todas las preguntas necesarias.