Definér, hvor dine data må sendes hen

Skeln mellem to datastrømme

Vibe coding er nyttigt til at afprøve en arbejdsgang med fiktive poster. Risikoen ændres, når rigtige virksomhedsoplysninger kommer ind i værktøjet. Det kan ske, før applikationen har brugere.

Der er to forløb at undersøge. Udviklingsforløbet omfatter prompts, kontekst fra repositoryet, vedhæftede filer, værktøjsoutput og diagnoselogs. Applikationsforløbet omfatter brugerforespørgsler, databaser, integrationer, telemetri og backups. Hvert forløb kan have forskellige modtagere og kontroller.

Overvej en fiktiv udgiftsapp. Dens database kører i en godkendt cloudkonto. En udvikler indsætter en rigtig udgiftsanmodning i en assistent for at rette en parser. Anmodningen indeholder medarbejdernavn, kvittering og bankoplysninger. Databasens godkendte placering giver ikke tilladelse til denne særskilte videregivelse.

Undersøg hele vejen

Tegn forløbet, før du tilføjer fortrolige data. Navngiv den faktiske tjeneste og konto på hvert trin. En produktbetegnelse som »enterprise« er ikke et diagram over datastrømme.

Registrér den gældende kontrakt og konfiguration. Kontrollér underdatabehandlere, sletningsadfærd, vilkår for modeltræning og internationale overførsler, hvor det er relevant. Bed de ansvarlige for databeskyttelse og sikkerhed om at afklare usikkerhed.

GDPR-krav afhænger af behandlingens kontekst. Relevante bestemmelser omfatter dataminimering, databehandleraftaler, sikkerhed og konsekvensanalyse. Virksomhedens fortrolighed omfatter også oplysninger, som ikke er persondata, eksempelvis kildekode eller kommercielle planer. Læs forordningen.

Start med brugbare fiktive testdata

Et sikkert eksempel skal stadig have en realistisk struktur. Udskift navne, identifikatorer og kontonumre. Bevar de forhold, der udløste fejlen: et manglende felt, en usædvanlig dato eller en lang beskrivelse.

Kald ikke en kopieret produktionspost »syntetisk«, blot fordi ét navn er ændret. De resterende felter kan identificere en person eller afsløre en transaktion. Byg en ny post ud fra skemaet og fejlforholdene.

Hold adgangsoplysninger ude af prompts og testdata. Hvis opgaven kræver en secret, skal du bruge den godkendte mekanisme med begrænset adgang. Instruktionen »hold dette privat« håndhæver ikke en teknisk grænse.

Kontrollér først, og udvid derefter brugen

Skriv en kort beslutning om tilladt brug: datakategorier, godkendt tjenestekonfiguration, tilladte handlinger og ansvarlig. Medtag udløb eller en betingelse for ny vurdering. En ny connector, modelrute eller logkonfiguration kan ændre beslutningen.

Hvis oplysninger når en ikke-godkendt modtager, skal du stoppe yderligere videregivelse og følge hændelsesprocessen. Registrér, hvad der blev delt, og hvor. Undgå at kopiere det følsomme materiale til flere opgaver eller chats.

Det praktiske mål er kontrolleret brug. Fiktive data støtter hurtig afprøvning. Verificerede behandlingsgrænser støtter næste skridt ind i virksomhedens arbejdsgange. Hverken en flot demo eller en cloudregion besvarer alle nødvendige spørgsmål.