Definiu on poden anar les dades

Separeu dos fluxos de dades

El vibe coding és útil per explorar un flux de treball amb registres ficticis. El risc canvia quan la informació real de l’empresa entra a l’eina. Això pot passar abans que l’aplicació tingui cap usuari.

Cal inspeccionar dos fluxos. El flux de desenvolupament inclou prompts, context del repositori, fitxers adjunts, sortides d’eines i registres de diagnòstic. El flux de l’aplicació inclou peticions d’usuaris, bases de dades, integracions, telemetria i còpies de seguretat. Cada flux pot tenir destinataris i controls diferents.

Considereu una aplicació fictícia de despeses. La seva base de dades funciona en un compte de núvol aprovat. Un desenvolupador enganxa una sol·licitud real de reemborsament en un assistent per corregir un analitzador. La sol·licitud inclou el nom d’un empleat, un rebut i dades bancàries. La ubicació aprovada de la base de dades no acredita que es permeti aquesta comunicació separada.

Inspeccioneu tot el recorregut

Dibuixeu el recorregut abans d’afegir-hi dades confidencials. Indiqueu el servei i el compte reals a cada pas. Una etiqueta de producte com ara «enterprise» no és un diagrama de flux de dades.

Registreu el contracte i la configuració aplicables. Comproveu els subencarregats del tractament, el comportament d’eliminació, les condicions d’entrenament dels models i les transferències internacionals quan sigui pertinent. Demaneu als responsables de privacitat i seguretat que resolguin les incerteses.

Els requisits del GDPR depenen del context del tractament. Entre les disposicions rellevants hi ha la minimització de dades, els acords amb encarregats del tractament, la seguretat i l’avaluació d’impacte. La confidencialitat empresarial també cobreix informació que no és personal, com el codi font o els plans comercials. Llegiu el reglament.

Comenceu amb una dada de prova fictícia útil

Un exemple segur també necessita una estructura realista. Substituïu noms, identificadors i números de compte. Conserveu les condicions que van causar el defecte: un camp absent, una data poc habitual o una descripció llarga.

No etiqueteu com a «sintètic» un registre copiat de producció després de canviar-ne un sol nom. Els camps restants poden identificar una persona o revelar una transacció. Creeu un registre nou a partir de l’esquema i de la condició que provoca la fallada.

Manteniu les credencials fora dels prompts i les dades de prova. Si la tasca necessita un secret, utilitzeu el mecanisme de secrets aprovat amb accés limitat. Una instrucció com ara «manteniu això privat» no imposa un límit tècnic.

Verifiqueu abans d’ampliar l’ús

Escriviu una decisió breu d’ús permès: categories de dades, configuració aprovada del servei, accions permeses i responsable. Incloeu una caducitat o una condició que obligui a revisar-la. Un connector nou, una ruta diferent cap al model o una configuració de registres d’activitat poden canviar la decisió.

Si la informació arriba a un destinatari no aprovat, atureu-ne qualsevol comunicació addicional i seguiu el procés d’incidents. Registreu què s’ha compartit i on. Eviteu copiar el material sensible en més tiquets o xats.

L’objectiu pràctic és un ús controlat. Les dades fictícies faciliten una exploració ràpida. Els límits de tractament verificats permeten el pas següent cap als fluxos de treball de l’empresa. Ni una demostració ben presentada ni una regió de núvol responen totes les preguntes necessàries.