Install
$ agentstack add skill-fdiblen-rseng-agent-skills-rseng-regulatory-compliance ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
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):
- 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
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: fdiblen
- Source: fdiblen/rseng-agent-skills
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.