A municipal birth-certificate counter wants a public chatbot to draft cases from real applicant rows that include names, dates of birth, and addresses. What compliance risk should the tester raise?
Select an answer to reveal the explanation.
Short Explanation
GDPR is a seatbelt rule for personal data, not a ban on the whole car. Feeding real names, birth dates, and addresses into a public chatbot without a lawful basis is the problem. GenAI can still be used when data handling stays compliant.
Full Explanation
Birth-certificate counters handle names, dates of birth, and addresses—classic personal data. Feeding real applicant rows into a public chatbot to draft cases without a lawful basis creates GDPR compliance risk. The regulation constrains personal-data processing; it is not a blanket ban on GenAI in testing when handling is lawful and minimized.
Claiming GDPR forbids every use of GenAI in software testing fails by overbreadth. Claiming low temperature alone violates Regulation (EU) 2016/679 fails because temperature is not a lawful-basis substitute. Claiming synthetic rows always trigger the same fine path as live rows fails because properly non-identifying synthetic data is treated differently from live personal data.
Exam caveat: lawful basis, purpose limitation, and minimization matter; “we used GenAI” is not automatically unlawful, and “we used synthetic data” is not automatically safe if re-identification remains possible.
Operational check: classify whether case-drafting inputs are personal data; use synthetic applicants by default; require legal review before any live row enters an LLM; document the lawful basis and retention period when an exception is approved. Birth-certificate pilots should keep a data-protection impact note that states why synthetic rows were chosen and who approves any temporary live-data exception.