Data protection, the AI provider and governance. For institutions: Feedbacker

For learning technologists, data protection officers and others deciding whether educators may use Feedbacker with students' work. It describes Feedbacker as built, in plain language, and links to where each point is decided in the code and the decision records.

What this page is, and isn't

It is not legal advice, and Feedbacker claims no certification and no compliance with any law or standard. Your institution makes its own assessment, with its data protection officer; this page is meant to support it. Read it with responsible use and known limits.

At a glance

No hosted service. Feedbacker has no accounts and no server of its own. The material stays in folders the educator keeps, on their computer or on storage your institution allows.
Only what the educator approves is sent to the AI, and only when they confirm it. Names and identifiers in the text are replaced on the educator's computer first. Images are reviewed one by one, but not redacted.
Pseudonymised, not anonymised. The key that links each token to a student never leaves the educator's computer, so the work is still personal data and is handled as such.
The AI never gives a mark, and nothing is released without the educator's approval. Feedbacker never sends marks or feedback to students or to your systems.
Every AI contribution is traceable, to the AI, the instructions and what it was sent, and feedback adapted from it is marked as such.
One AI provider today: Anthropic (Claude), reached with the educator's or your institution's own API key.

Who does what

How data protection law labels each party is for your institution to decide with its data protection officer. As Feedbacker is built:

The educator, on your institution's behalf, decides what is sent, and when. They review the pseudonymised text and each image, and confirm each request.
The AI provider processes what is sent, under its own terms and any agreement your institution has with it.
Feedbacker has no server and receives nothing: it is software that runs on the educator's computer. Its author doesn't see students' work, marks or feedback.

Where the material lives

Each piece of work (a moderation, or the marking of a cohort) is a workspace: a folder the educator chooses, on their own disk or on storage your institution allows. Where it is decides who else can reach it.
The app runs in Chrome or Edge and talks only to a small program on the same computer, which holds the API key and checks every request against what may be sent before it leaves. It accepts requests only from that computer, with a token it issues each time it starts.
The pseudonym key, which links each token (for example [STUDENT_A]) to a student's name and platform ID, is kept in the workspace's private folder and is never sent to the AI. On macOS and Linux it is readable only by the educator's user account. On Windows it can't be restricted that way, so keep workspaces on storage only that educator can reach.
In marking, the whole cohort's submissions are imported from the marking platform's bulk download. In moderation, only the sampled submissions are imported; other students' files aren't opened.

What is sent to the AI, and when

Nothing is sent until the educator has reviewed and approved the pseudonymised material and confirmed the request, having seen a worst-case cost. Each request is rebuilt from what is recorded just before it is sent, and must match what was approved, or nothing is sent.

An AI reading (moderation) or proposals (marking): the approved pseudonymised submission, the approved brief (optional), the rubric, and the submission's approved figures (optional). Never anyone's marks or comments.
Feedback drafts (marking): as above but without figures, plus the educator's own levels, marks and comments for that one student, and their approved feedback guide. Never another student's material.
A suggested edit to flagged feedback (marking): the educator's recorded feedback on one criterion, the checks' flags on it, their marking of that criterion, and the rubric. Never the submission.
A suggested verdict and comment on one submission (moderation), when the educator asks: the rubric; the educator's own levels, marks, verdict and comments; the original marker's marks (not their comments); and the AI reading's levels and reasons. Never the submission's text, the brief, the original marker's comments or the AI reading's quoted evidence.
A suggested overall comment on the sample (moderation), when the educator asks: how the sample was chosen (the note the educator wrote, redacted by the rules first) and, for each sampled submission, the original marker's overall mark and the educator's verdict, marks and comment. No rubric, and never the submissions, the brief, the AI reading or the original marker's comments.
Reading a rubric from its image (either), when the educator asks: the image of the rubric, with its instructions and nothing else: no student's material, nothing from the brief. The image's hidden metadata is removed, but what the picture shows is not redacted, so the educator checks it first. It proposes a grid for the educator to check; nothing is saved until they save it.

Everything is sent with Feedbacker's versioned instructions to the AI, which are in the code and can be read there. Never sent: the pseudonym key; the original submission files and their document properties (author and so on); and any other student's material.

Pseudonymisation, and its limits

Replacing names with tokens, while the educator keeps the key, is pseudonymisation. It reduces what the AI is sent, and what is in an export, but it does not make the work anonymous. Feedbacker treats pseudonymised work as personal data, and says so wherever it matters.

Text is extracted on the educator's computer, and the submission document's properties (author and so on) are discarded.
Names, identifiers, emails, links and phone numbers are replaced with consistent tokens. Students' own names come from Turnitin downloads' file names; the educator adds Canvas students' names, and other people's names and organisations, to the rules.
The educator reviews every pseudonymised text, can see what each token replaced, and approves it. Any later change clears the approval, and a text that newer rules would redact further is not sent until it is approved again.
It is rule-based, so it can miss a name nobody listed (a peer, a client, an interviewee) and indirect identifiers (an employer, a project). The educator's review is the safeguard.
It can't see inside images: a screenshot may show a name, an email, a username or a face. The educator reviews each figure and can choose not to send any. Images' hidden metadata (camera details, dates, locations, authors) is removed from those that can be sent, so what the educator reviews is what can be sent.

The AI provider

The terms below are the ones to check, and they are on this page only, because they are yours to confirm and they change.

Anthropic's Claude, through Anthropic's API. Claude Sonnet is used by default. If it declines a request on safety grounds, the same approved request may be sent once to Claude Opus, when that fallback is on (it is by default) and the spend limit allows; both calls are recorded.
Feedbacker's requirement of any provider: it must exclude API inputs and outputs from training by default, and retain data only for a limited period, as its terms state. Check Anthropic's current terms yourself, before first use and whenever they change, including that your agreement covers images of students' work, and where the data is processed and the terms for any transfer.
What the provider may keep: part of a request (the instructions, the rubric, the brief and, when drafting, the feedback guide; never a submission) may be held in its prompt cache for five minutes, to lower the cost of later requests. If the educator sends a run as a batch, the provider keeps the results for 29 days so they can be collected.
The key: your institution's or the educator's own API key, read by the local program from its environment or a file in the educator's home folder. It is never sent to the AI or to the browser, and never logged or exported.
Spend: the educator sees a worst-case estimate before each run, and each run stops at a spend limit (by default, $5).
Only one provider is supported today. Feedbacker is built so that others can be added, each through the same checks.

Records and audit

In the workspace: every request's record (the AI used, the instructions' version, hashes of what was sent and of the approvals it was sent under, token use and cost) and the AI's raw reply. Every proposal, draft and suggestion records where it came from, and feedback adapted from one is recorded as derived from the AI, however much it is changed.
On the educator's computer, outside the workspace: a log with one line per request sent or refused: the time, the AI, a hash of what was sent, the outcome, token use and cost. It holds no text and no names, and entries are removed after 90 days by default.
Exports are pseudonymous. A copy with each student's platform ID in place of their pseudonym is made only when the educator confirms it, each time.

Retention and deletion

When an educator creates a workspace, Feedbacker records how long its material may be kept (90 days by default), for example under your institution's terms. It doesn't yet remind anyone when that has passed: deleting is the educator's action.
Deleting a workspace removes the whole folder, and everything in it, in one action, once its exports have been listed and the workspace's name typed. Bulk downloads the educator saved are theirs to delete.
The provider's own retention is governed by its terms (above).

Security

No hosted endpoint, no accounts, and no shared key: each user runs their own copy with their own key.
The app loads no third-party scripts and may connect only to the local program. To report a vulnerability, use the security policy.

What your institution needs to confirm

Feedbacker can't decide these for you:

That using AI assistance in marking or moderation is acceptable for the assessments concerned, and whether and how students are told.
That your agreement with the AI provider covers students' work, images included, and that its terms on training, retention and transfer meet your requirements.
Who holds the API key: each educator, or your institution.
How long material may be kept, so educators set the retention period correctly, and who deletes it.
Where exports may be kept, and for how long.
That educators understand the review they are responsible for: pseudonymised text, images, and everything released.
Any data protection impact assessment your institution requires.

Data protection, the AI provider and governance.