A UK university is adding a Claude-based assistant that drafts formative feedback on student essays against a marking rubric. The current integration sends each essay with the student's full record: name, student number, date of birth, disability adjustments and prior grades. The data protection officer cites the UK GDPR data minimisation principle and requires that each request carry only the personal data needed to produce rubric feedback, while tutors must still see each piece of feedback against the right student. Which change best meets that requirement?
- AKeep the full record in each request and add a system prompt telling the model to ignore every field except the essay.
- BSend only the essay text and rubric with an opaque submission ID, and re-link feedback to the student on the server side. Correct
- CKeep the full record in each request but encrypt it end to end and cut the retention of request logs to seven days.
- DSend the essay with a hashed student number, date of birth and prior grades, so the model can personalise its feedback.
Why A is wrong: Telling the model to ignore fields can stop them shaping the feedback, which is tempting, but the personal data is still transmitted and processed, so it does nothing for minimisation, which concerns what is collected and sent.
Why B is correct: Correct: rubric feedback needs only the essay and the rubric, so the request carries no other personal data, and the university's own system holds the mapping from submission ID to student so tutors still see the feedback in the right place.
Why C is wrong: Encryption and shorter retention are sound security and storage-limitation measures, but they protect data that should not be sent in the first place, so the minimisation requirement on each request is still unmet.
Why D is wrong: Hashing the student number looks like pseudonymisation, but date of birth and prior grades are not needed to apply a marking rubric, and personalisation was not the stated purpose, so excess personal data is still sent.