Regulatory compliance for research code and data
Regulation reaches research software the moment code touches
personal data or ships an AI system. An agent cannot certify
compliance - that is a legal judgment owned by the institution's
data protection officer (DPO), ethics board and legal office - but
it CAN do the engineering half: find the personal data, check the
code against the obligations that have code-shaped answers, prepare
the documentation reviewers need, and flag exactly what requires a
human decision. State that division of labor explicitly whenever
this skill is used. Not legal advice.
GDPR: what an agent can check in code and data
Personal data discovery first - obligations attach to data you HAVE:
- Scan datasets, logs, configs and repo history for personal data:
names, emails, identifiers, IP addresses, free-text fields that
smuggle PII, geolocation precise enough to identify. Automated PII
detection (Presidio-class tools) finds the bulk; manual review
covers domain-specific identifiers (patient codes, student IDs).
Repository history counts - committed-then-deleted data is still
there (rseng-security's leak response applies).
- Check the code paths, not just the files: what gets logged
(debug logging of request payloads is a classic leak), what lands
in error reports and caches, what third-party services receive
(telemetry, cloud APIs) - each is a processing activity.
Obligations with code-shaped answers:
- Minimization: collect and keep only fields the research question
needs; challenge every column (rseng-data-management's data
dictionary makes this reviewable).
- Pseudonymization vs anonymization - keep the distinction sharp:
pseudonymized data (key exists somewhere) is still personal data
under GDPR; true anonymization is hard, and removing names is not
it (re-identification via quasi-identifiers is the standard
failure). Treat "anonymized" claims as claims to verify with the
data steward, not labels to accept.
- Retention: implement it - deletion jobs, dated cohorts, expiry in
the pipeline - a retention policy without code is a wish.
- Data-subject rights: for anything service-shaped, access/export/
erasure must be executable; check that erasure reaches backups,
caches, derived datasets and trained artifacts, or documents why
it cannot.
- Security of processing: encryption in transit and at rest,
access control, and the sensitive-data handling rules already in
rseng-data-management and rseng-security.
- DPIA triggers: large-scale processing of special categories
(health, biometrics, ethnicity...), systematic monitoring, new
technologies on vulnerable groups - when the project matches,
prepare the processing inventory and route to the DPO; do not
improvise the assessment.
EU AI Act: research software that is or contains AI
- Locate the project honestly on the map: the Act regulates by risk
tier (prohibited practices, high-risk uses, transparency-tier,
minimal). Annex-listed high-risk areas (health, education,
employment, law enforcement...) matter the moment research
prototypes head toward deployment.
- The scientific-research carve-out: AI developed and used SOLELY
for scientific research and development is outside the Act's
scope - but the exemption ends where real-world deployment
begins. A model handed to a hospital, a public demo, a spin-off:
each crosses the line and the obligations arrive. Flag the
transition explicitly; it is the single most important thing for
a research team to notice in time.
- Obligations an agent can prepare for when in or near scope:
technical documentation and logging capability, training-data
documentation and governance (dataset provenance -
rseng-data-management, rseng-fair-ml), accuracy/robustness
testing evidence (rseng-testing), transparency notices for
AI-interacting users, and human-oversight hooks. The project's
aidecl.yaml (rseng-ai-declaration) is a natural seed for the
documentation trail.
- General-purpose model obligations (training-data summaries,
copyright policy) sit with model providers - relevant when the
research project IS training and releasing such models.
Other regimes, same method
The pattern generalizes: identify regulated material (US HIPAA for
health data, sectoral and national laws, export controls on some
domains), find where code touches it, check the code-shaped
obligations, document, and route judgment calls to the responsible
office. When the user's jurisdiction is known, name the regime;
when not, ask - jurisdiction changes the answer.
The compliance check, as a workflow
- Inventory: what personal/regulated data exists, where, and which
code processes it (a data-flow sketch pays for itself at DPIA
time).
- Scan: automated PII detection over data, logs and history;
review hits.
- Check the code-shaped obligations above; file findings as issues
with severity (rseng-version-control-review).
- Prepare documentation: processing inventory, retention map, AI
Act tier assessment draft, gaps list.
- Route: DPO/ethics/legal for judgments; record their decisions in
the repository (rseng-documentation) and revisit at each release
(rseng-publishing-releasing) - compliance drifts like code does.
Working with this skill
This skill is source-independent: its authority is the regulations
themselves and the official guidance linked below. It engineers the
checkable half and routes the rest; rseng-data-management owns
sensitive-data storage practice, rseng-security owns the protective
controls, rseng-ai-declaration owns AI-use disclosure.
Learn more (verified):
Related skills
Check whether any of these applies before moving on:
- rseng-ai-declaration - seeds AI Act documentation trail
- rseng-archiving - publishing datasets triggers obligations
- rseng-data-management - sensitive-data storage and stewardship
- rseng-fair-ml - training-data documentation duties
- rseng-security - encryption, access control, leak response
- rseng-testing - robustness evidence for AI Act
1---2name: rseng-regulatory-compliance3description: Covers checking research code and data against data-protection and AI regulation: GDPR obligations in code (personal data discovery, minimization, pseudonymization vs anonymization, retention, data-subject rights, DPIA triggers), the EU AI Act (risk tiers, research carve-out, transparency duties), and similar regimes. Use PROACTIVELY when person-level or sensitive data is evident in the project, and when a project processes personal or sensitive data, trains or ships AI/ML systems, when the user asks about GDPR, the AI Act, DPIAs, consent or anonymization, or before publishing datasets or models derived from people. (Secrets hygiene and protective controls: rseng-security; sensitive-data stewardship: rseng-data-management; AI-use disclosure: rseng-ai-declaration.)4license: CC-BY-4.05---67# Regulatory compliance for research code and data89Regulation reaches research software the moment code touches10personal data or ships an AI system. An agent cannot certify11compliance - that is a legal judgment owned by the institution's12data protection officer (DPO), ethics board and legal office - but13it CAN do the engineering half: find the personal data, check the14code against the obligations that have code-shaped answers, prepare15the documentation reviewers need, and flag exactly what requires a16human decision. State that division of labor explicitly whenever17this skill is used. Not legal advice.1819## GDPR: what an agent can check in code and data2021Personal data discovery first - obligations attach to data you HAVE:2223- Scan datasets, logs, configs and repo history for personal data:24 names, emails, identifiers, IP addresses, free-text fields that25 smuggle PII, geolocation precise enough to identify. Automated PII26 detection (Presidio-class tools) finds the bulk; manual review27 covers domain-specific identifiers (patient codes, student IDs).28 Repository history counts - committed-then-deleted data is still29 there (rseng-security's leak response applies).30- Check the code paths, not just the files: what gets logged31 (debug logging of request payloads is a classic leak), what lands32 in error reports and caches, what third-party services receive33 (telemetry, cloud APIs) - each is a processing activity.3435Obligations with code-shaped answers:3637- Minimization: collect and keep only fields the research question38 needs; challenge every column (rseng-data-management's data39 dictionary makes this reviewable).40- Pseudonymization vs anonymization - keep the distinction sharp:41 pseudonymized data (key exists somewhere) is still personal data42 under GDPR; true anonymization is hard, and removing names is not43 it (re-identification via quasi-identifiers is the standard44 failure). Treat "anonymized" claims as claims to verify with the45 data steward, not labels to accept.46- Retention: implement it - deletion jobs, dated cohorts, expiry in47 the pipeline - a retention policy without code is a wish.48- Data-subject rights: for anything service-shaped, access/export/49 erasure must be executable; check that erasure reaches backups,50 caches, derived datasets and trained artifacts, or documents why51 it cannot.52- Security of processing: encryption in transit and at rest,53 access control, and the sensitive-data handling rules already in54 rseng-data-management and rseng-security.55- DPIA triggers: large-scale processing of special categories56 (health, biometrics, ethnicity...), systematic monitoring, new57 technologies on vulnerable groups - when the project matches,58 prepare the processing inventory and route to the DPO; do not59 improvise the assessment.6061## EU AI Act: research software that is or contains AI6263- Locate the project honestly on the map: the Act regulates by risk64 tier (prohibited practices, high-risk uses, transparency-tier,65 minimal). Annex-listed high-risk areas (health, education,66 employment, law enforcement...) matter the moment research67 prototypes head toward deployment.68- The scientific-research carve-out: AI developed and used SOLELY69 for scientific research and development is outside the Act's70 scope - but the exemption ends where real-world deployment71 begins. A model handed to a hospital, a public demo, a spin-off:72 each crosses the line and the obligations arrive. Flag the73 transition explicitly; it is the single most important thing for74 a research team to notice in time.75- Obligations an agent can prepare for when in or near scope:76 technical documentation and logging capability, training-data77 documentation and governance (dataset provenance -78 rseng-data-management, rseng-fair-ml), accuracy/robustness79 testing evidence (rseng-testing), transparency notices for80 AI-interacting users, and human-oversight hooks. The project's81 aidecl.yaml (rseng-ai-declaration) is a natural seed for the82 documentation trail.83- General-purpose model obligations (training-data summaries,84 copyright policy) sit with model providers - relevant when the85 research project IS training and releasing such models.8687## Other regimes, same method8889The pattern generalizes: identify regulated material (US HIPAA for90health data, sectoral and national laws, export controls on some91domains), find where code touches it, check the code-shaped92obligations, document, and route judgment calls to the responsible93office. When the user's jurisdiction is known, name the regime;94when not, ask - jurisdiction changes the answer.9596## The compliance check, as a workflow97981. Inventory: what personal/regulated data exists, where, and which99 code processes it (a data-flow sketch pays for itself at DPIA100 time).1012. Scan: automated PII detection over data, logs and history;102 review hits.1033. Check the code-shaped obligations above; file findings as issues104 with severity (rseng-version-control-review).1054. Prepare documentation: processing inventory, retention map, AI106 Act tier assessment draft, gaps list.1075. Route: DPO/ethics/legal for judgments; record their decisions in108 the repository (rseng-documentation) and revisit at each release109 (rseng-publishing-releasing) - compliance drifts like code does.110111## Working with this skill112113This skill is source-independent: its authority is the regulations114themselves and the official guidance linked below. It engineers the115checkable half and routes the rest; rseng-data-management owns116sensitive-data storage practice, rseng-security owns the protective117controls, rseng-ai-declaration owns AI-use disclosure.118119Learn more (verified):120 - https://eur-lex.europa.eu/eli/reg/2016/679/oj - GDPR, official121 text122 - https://eur-lex.europa.eu/eli/reg/2024/1689/oj - EU AI Act,123 official text124 - https://artificialintelligenceact.eu - AI Act explorer and125 compliance resources126 - https://www.edpb.europa.eu - European Data Protection Board127 guidance128 - https://gdpr.eu - GDPR explainers and checklists129 - https://github.com/data-privacy-stack/presidio - PII detection tooling130131<!-- related-skills:begin -->132133## Related skills134135Check whether any of these applies before moving on:136137- rseng-ai-declaration - seeds AI Act documentation trail138- rseng-archiving - publishing datasets triggers obligations139- rseng-data-management - sensitive-data storage and stewardship140- rseng-fair-ml - training-data documentation duties141- rseng-security - encryption, access control, leak response142- rseng-testing - robustness evidence for AI Act143144<!-- related-skills:end -->
fdiblen