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

1. Inventory: what personal/regulated data exists, where, and which code processes it (a data-flow sketch pays for itself at DPIA time).
2. Scan: automated PII detection over data, logs and history; review hits.
3. Check the code-shaped obligations above; file findings as issues with severity (rseng-version-control-review).
4. Prepare documentation: processing inventory, retention map, AI Act tier assessment draft, gaps list.
5. 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):

• https://eur-lex.europa.eu/eli/reg/2016/679/oj - GDPR, official text
• https://eur-lex.europa.eu/eli/reg/2024/1689/oj - EU AI Act, official text
• https://artificialintelligenceact.eu - AI Act explorer and compliance resources
• https://www.edpb.europa.eu - European Data Protection Board guidance
• https://gdpr.eu - GDPR explainers and checklists
• https://github.com/data-privacy-stack/presidio - PII detection tooling

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