Assess the real institutional workflow, not only the product
Separate dissertations, coursework, draft assessments, published writing and voluntary pre-checks. Files may contain names, student identifiers, health information, interview responses, unpublished research, trade secrets and third-party data. Filenames, accounts, IP addresses, logs and reports may also be personal data.
Map the path from upload through processing and result delivery to archiving and deletion. Include the learning platform, identity provider, support function, subprocessors, backups and comparison repository. A hosting location alone does not establish who can access data, which transfer mechanism applies or whether the provider processes content for its own purposes.
Distinguish institutional responsibility, processing and provider purposes
Determine whether the provider follows documented instructions exclusively or pursues separate purposes. Product improvement, abuse monitoring, support and building a comparison corpus may create different role questions. A contract headed “data processing” does not settle the issue; features, settings and actual use must match it.
Inventory subprocessors, processing locations and change mechanisms. Establish how the institution learns about new recipients and can respond. Transfers outside the European Economic Area need a distinct, current assessment of the relevant mechanism and risk. Do not claim GDPR compliance from a badge, server country or provider label.
Assign internal permissions for uploads, report access, support cases, repository settings and deletion control. Role-based accounts and audit records are more inspectable than shared credentials. A support ticket should not automatically include a student’s complete paper.
Decide analysis and continuing comparison use separately
A one-off similarity check and inclusion in a future comparison corpus are distinct purposes. Record whether retention is the default, which organisations may later see matches, whether fingerprints or full text remain, and how exclusion operates technically. Include drafts, revisions and accidental uploads in the analysis.
An interface deletion button is not evidence that every copy disappeared. Consider primary storage, index, report, logs, support copies and backups. Test the defined deletion procedure using synthetic or specifically authorised material. Record what can actually be verified and do not extrapolate to hidden systems.
Give students a clear notice covering controller, purpose, categories, recipients, storage, rights and contact. Repository inclusion should not be buried in a long tool guide. Where a choice is promised, the technical and organisational process must honour it.
Connect procurement, pilot and continuing oversight
Before contracting, request inspectable answers, configuration guidance, a current subprocessor list, security evidence, deletion design and incident route. Privacy review is not a one-off questionnaire. Product releases, new AI features and repository changes can alter the assessment. Define change review and exit, including return and deletion of data.
A pilot uses synthetic or expressly authorised files. Test permissions, result access, support, deletion and logging. A successful upload proves neither complete deletion nor the legal suitability of production use. Technical operation and institutional approval remain separate gates.
The higher education practice hub connects institutional reviews. The AI-detector procurement matrix adds quality and governance controls. The one foundation connection is academic writing and evidence.
Approval check for actual operation
- Data categories and paths are fully inventoried.
- Every purpose has an assessed basis and responsible role.
- Analysis and repository inclusion are described separately.
- Subprocessors and transfers are current.
- Deletion includes named storage layers and a control.
- The privacy notice reflects real configuration.
- Material changes trigger renewed institutional review.
Keep the evidence current
The approval record should identify the tested product version, enabled functions, recipients, deletion route, test date and accountable role. A new integration, storage location, subcontractor or repository function triggers review. Any unverified part of the deletion chain remains an explicit limitation, not an assumed safeguard. This record supports a decision about one deployment at one time; it is not a general privacy seal for the product.