A profile encodes requirements in the message so that every party can see and check them. Selecting one does not by itself establish legal compliance, nor decide which law applies to your system.
The profile catalogue
GDPR-STANDARD
The baseline for personal data, applied when no other profile is declared. Retention and residency are left to the operator’s policy. Cites GDPR Art. 5, 5(2), 6, 9, 17, 30, 33 and 34.
EU-AI-ACT-HIGH-RISK
For systems in the high-risk categories of Annex III. Nothing executes until a person approves, and every action is recorded. Cites AI Act Art. 9, 12, 13, 14, 15, 17, 18, 19, 26(6) and Annex III.
EU-AI-ACT-LIMITED-RISK
For interactions with transparency obligations, such as telling people they are dealing with an AI system. No approval gate, but an audit record is kept. Cites AI Act Art. 50(1) to 50(4).
MIFID-II
For investment workflows such as trade requests. Approval before execution, five-year record keeping, EU residency, and explainability required. Cites MiFID II Art. 16(7), Delegated Regulation (EU) 2017/565 Art. 72, 74 and 75, DORA Art. 17 and 19, PSD2 Art. 97 and GDPR Art. 6(1)(b).
DORA
For ICT operations in financial entities: incident handling, resilience and third-party risk. Human review within 24 hours. Cites DORA Art. 5, 6, 11, 17, 18, 19 and 28.
DSA-VLOP
For content moderation and systemic-risk workflows on very large platforms. Human review within 24 hours and two-year records. Cites DSA Art. 15, 34, 35, 37, 38, 40 and 42.
PAC-AGRICULTURE
For agricultural subsidy administration. Actions run, then a person reviews them; records are kept for three years in the EU. Cites Regulation (EU) 2021/2116 Art. 47, 54, 59 and 60.
No profile matches. Try “AI”, “financial” or “EU”.
The compliance fields
| Field | Meaning |
|---|---|
profile | The profile identifier, such as MIFID-II. |
retention_days | How long audit evidence must be kept. |
data_residency | Where the data may be processed, such as EU. |
human_oversight | When a person must review: before, after, within 24 hours, or not required. |
audit_required | Whether an audit record must be produced. |
pii_involved | Whether the message carries personal data. |
legal_basis | The GDPR legal basis for processing, such as contract. |
explainability_required | Whether the action must come with an explanation. |
ai_system_classification | The AI Act risk classification of the system. |
Apply requirements before signing
Name the profile, resolve its defaults together with your own policy, validate the completed envelope, and then sign it. The receiver evaluates the same requirements independently.
In Python, that is compliance={"profile": "MIFID-II"} on the constructor followed by apply_profile. See the quickstart.
Evaluate the whole workflow
- Who decides which requirements apply to a given message?
- Which checks does the receiver perform before acting?
- Where is human approval enforced, and how is the reviewer authenticated?
- How are retention, erasure and audit evidence managed over time?
- Which deployment assumptions, such as data location, need separate evidence?
Beyond the EU
The mechanism is jurisdiction-agnostic: a profile is a JSON object of rules. The same structure can express HIPAA, SOX, SOC 2, LGPD, PIPL, APPI, POPIA, PDPA, CCPA, the NIST AI RMF or ISO/IEC 42001. Propose a profile through the contribution process.