34 KiB
AI Data Processing - GDPR Compliance Documentation
Document Version: 2.0 Last Updated: February 2026 Classification: Internal / Compliance Parent Document: Platform GDPR Compliance
Table of Contents
- Executive Summary
- Definitions
- Legal Framework
- AI Processing Activities
- Data Minimisation & Anonymisation
- Technical Implementation
- Subprocessor: OpenAI
- Data Subject Rights
- Risk Assessment
- Audit & Monitoring
- Incident Response
- Compliance Checklist
- Contact Information
1. Executive Summary
This document describes how the Monaco Ocean Protection Challenge (MOPC) Platform uses Artificial Intelligence (AI) services while maintaining strict compliance with the General Data Protection Regulation (GDPR) and Monaco Law 1.565 of December 3, 2024.
Key Compliance Measures
| Measure | Implementation |
|---|---|
| Data Minimisation | Only necessary, non-identifying data sent to AI |
| Anonymisation | All personal identifiers stripped before AI processing |
| EU Data Residency | AI processing occurs within EU (Ireland) |
| Zero Data Retention | AI provider does not store data at rest |
| Human Oversight | AI provides recommendations only; humans make final decisions |
| Audit Trail | All AI operations logged for accountability |
Fundamental Principle
No personal data is transmitted to AI services. All data sent to OpenAI is fully anonymised, meaning it cannot be attributed to any identifiable natural person. Anonymised data is not considered personal data under GDPR.
2. Definitions
In addition to the definitions in the Platform GDPR Compliance document, the following AI-specific definitions apply:
| Term | Definition |
|---|---|
| Artificial Intelligence (AI) | Computer systems capable of performing tasks that typically require human intelligence, such as pattern recognition, natural language understanding, and decision-making support. |
| Large Language Model (LLM) | A type of AI model trained on large amounts of text data to understand and generate human language. OpenAI's GPT models are examples of LLMs. |
| AI Service | A component of the Platform that uses AI to process data and provide recommendations or analysis. |
| Anonymised Data | Data that has been processed in such a way that the data subject is not or no longer identifiable. Under GDPR, anonymised data is not personal data. |
| Pseudonymised Data | Data processed so that it can no longer be attributed to a specific data subject without additional information kept separately. Unlike anonymised data, pseudonymised data is still personal data under GDPR. |
| Token | A unit of text processed by an LLM. Approximately 1 token = 4 characters in English. Token usage determines AI processing costs. |
| Zero Data Retention (ZDR) | A configuration where the AI provider does not store input or output data at rest after processing is complete. |
| EU Data Residency | A configuration ensuring that data is processed within the European Union and does not leave EU jurisdiction. |
| Prompt | The text input sent to an AI model, consisting of instructions and data to be processed. |
| Completion | The text output generated by an AI model in response to a prompt. |
3. Legal Framework
3.1 Legal Basis for AI Processing
AI-assisted processing activities are conducted under the following legal bases:
| Activity | Legal Basis | GDPR Article | Justification |
|---|---|---|---|
| AI Project Filtering | Legitimate Interests | Art. 6(1)(f) | Efficient evaluation of large application volumes |
| AI Jury Assignment | Legitimate Interests | Art. 6(1)(f) | Optimal matching of expertise to projects |
| AI Award Eligibility | Legitimate Interests | Art. 6(1)(f) | Consistent application of eligibility criteria |
| AI Mentor Matching | Legitimate Interests | Art. 6(1)(f) | Effective mentor-project pairing |
3.2 Legitimate Interests Assessment
A Legitimate Interests Assessment (LIA) has been conducted for AI processing:
Purpose
To efficiently process and evaluate competition applications using AI-assisted analysis and matching.
Legitimate Interest Identified
- Organisational efficiency: Processing 100+ projects manually is impractical
- Consistency: AI applies criteria uniformly across all applications
- Expertise matching: AI identifies optimal reviewer-project and mentor-project pairings
- Cost-effectiveness: Reduced administrative burden enables focus on substantive evaluation
Necessity
- AI processing is necessary to achieve these interests at scale
- No less intrusive means would achieve the same objectives efficiently
- Human review alone cannot process the volume within required timeframes
Balancing Test
- Risk to data subjects: Minimal to none - data is fully anonymised before AI processing
- Reasonable expectations: Participants expect efficient, fair evaluation processes
- Relationship: Direct relationship through competition participation
- Safeguards in place:
- Full anonymisation (not pseudonymisation)
- EU data residency
- Zero data retention at AI provider
- Human oversight of all AI recommendations
- Right to object and request manual processing
Conclusion
The legitimate interests of the organisation are not overridden by the interests, rights, or freedoms of the data subjects. Processing may proceed with the implemented safeguards.
3.3 Article 22 - Automated Decision-Making
Statement: The Platform's AI processing does not constitute automated decision-making as defined in Article 22 of the GDPR.
Article 22(1) states: "The data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her."
Why Article 22 does not apply:
-
Not solely automated: All AI outputs are recommendations reviewed and approved by human administrators. No decision is made without human involvement.
-
No legal effects: AI recommendations do not directly produce legal effects on data subjects. Humans make the final decisions about project advancement, jury assignments, and award eligibility.
-
No significant effects: The interim recommendations produced by AI do not, by themselves, significantly affect data subjects. Only the final human decisions have such effects.
-
Anonymised data: The data processed by AI is anonymised, meaning Article 22 protections for personal data processing do not apply to the AI processing stage itself.
Safeguards implemented regardless:
- Human review of all AI recommendations before implementation
- Right to request explanation of AI-assisted decisions
- Right to request fully manual processing
- Audit logging of AI recommendations and human decisions
4. AI Processing Activities
4.1 Overview of AI Services
The Platform uses AI for four distinct processing activities:
| Service | Purpose | Input Data | Output |
|---|---|---|---|
| Project Filtering | Evaluate projects against admin-defined criteria | Anonymised project data | Pass/fail recommendations with confidence scores |
| Jury Assignment | Match jury expertise to project topics | Anonymised juror and project data | Assignment suggestions with match scores |
| Award Eligibility | Determine eligibility for special awards | Anonymised project data | Eligibility determinations with reasoning |
| Mentor Matching | Recommend mentors for projects | Anonymised mentor and project data | Ranked mentor recommendations |
4.2 AI Project Filtering
Purpose: Assist administrators in screening projects against specific criteria (e.g., "Projects must have ocean conservation focus", "Exclude projects without descriptions").
Process:
- Administrator defines criteria in plain language
- System anonymises project data (see Section 5)
- Anonymised data sent to AI with criteria
- AI returns recommendations with confidence scores
- Administrator reviews and approves/modifies recommendations
- Results applied to projects
Human Oversight: Administrator reviews all AI recommendations before application. Projects flagged by AI as "uncertain" require manual review.
4.3 AI Jury Assignment
Purpose: Suggest optimal juror-project pairings based on expertise alignment.
Process:
- System anonymises juror expertise tags and project data
- Anonymised data sent to AI with assignment constraints
- AI returns suggested pairings with match scores and reasoning
- Administrator reviews suggestions
- Administrator approves, modifies, or rejects assignments
- Approved assignments created in system
Human Oversight: All assignments require explicit administrator approval. AI suggestions can be partially accepted or entirely rejected.
4.4 AI Award Eligibility
Purpose: Assist in determining which projects meet special award criteria.
Process:
- Award criteria defined (may include rule-based and AI-interpreted criteria)
- System anonymises project data
- Anonymised data sent to AI with criteria
- AI returns eligibility determinations with reasoning
- Administrator reviews determinations
- Final eligibility set by administrator
Human Oversight: Administrator has final authority on all eligibility decisions. AI reasoning is transparent and reviewable.
4.5 AI Mentor Matching
Purpose: Recommend suitable mentors for selected projects based on expertise.
Process:
- System anonymises mentor profiles and project data
- Anonymised data sent to AI
- AI returns ranked mentor recommendations with reasoning
- Administrator reviews recommendations
- Assignments made by administrator or offered to mentors
Human Oversight: Mentor assignments require administrator approval and mentor acceptance.
5. Data Minimisation & Anonymisation
5.1 Principles Applied
The Platform applies the following GDPR principles to AI processing:
| Principle | GDPR Article | Implementation |
|---|---|---|
| Data Minimisation | Art. 5(1)(c) | Only necessary fields sent; descriptions truncated |
| Purpose Limitation | Art. 5(1)(b) | Data used only for specific AI task |
| Storage Limitation | Art. 5(1)(e) | Zero data retention at AI provider |
| Integrity & Confidentiality | Art. 5(1)(f) | TLS encryption; anonymisation |
5.2 What is Sent to AI
The following anonymised data elements may be sent to AI services:
| Data Element | Anonymisation Method | Purpose |
|---|---|---|
| Project ID | Replaced with sequential ID (P1, P2, etc.) | Reference only |
| Project title | PII patterns removed | Content analysis |
| Project description | Truncated (300-500 chars), PII removed | Criteria matching |
| Competition category | Sent as-is (enum value) | Filtering criteria |
| Ocean issue | Sent as-is (enum value) | Topic matching |
| Country | Sent as-is (country name) | Geographic filtering |
| Region/Zone | Sent as-is (zone name) | Regional eligibility |
| Institution | Sent as-is (institution name) | Student project identification |
| Tags | Sent as-is (keywords) | Topic matching |
| Founded year | Year only (not full date) | Age-based filtering |
| Team size | Count only (no member details) | Team requirements |
| File count | Count only (no file content) | Document requirements |
| File types | Type names only | File requirement checks |
| Mentorship preference | Boolean flag | Mentorship filtering |
| Submission source | Enum value | Source filtering |
| Submission date | Date only (no time) | Deadline checks |
| Juror expertise tags | Sent as-is (keywords) | Expertise matching |
| Juror assignment count | Number only | Workload balancing |
5.3 What is NEVER Sent to AI
The following data elements are never transmitted to AI services:
| Data Element | Reason | Alternative |
|---|---|---|
| Personal names | PII - directly identifying | N/A |
| Email addresses | PII - directly identifying | N/A |
| Phone numbers | PII - directly identifying | N/A |
| Physical addresses | PII - directly identifying | Country/region only |
| Team member details | PII - identifying individuals | Team size count only |
| External URLs | Could lead to identifying information | Removed |
| Real database IDs | Could be cross-referenced | Sequential anonymous IDs |
| File contents | May contain PII | File type and count only |
| Internal comments | May contain PII references | N/A |
| Profile photos | Biometric data | N/A |
| IP addresses | PII - indirectly identifying | N/A |
5.4 PII Detection and Removal
Before any data is sent to AI, the following patterns are detected and removed:
Email addresses: [a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}
Phone numbers: Various international formats
URLs: https?://[^\s]+
Social Security: \d{3}-\d{2}-\d{4}
IP addresses: \d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}
Detected patterns are replaced with placeholders (e.g., [email removed], [url removed]).
5.5 Anonymisation vs. Pseudonymisation
Critical distinction:
| Aspect | Pseudonymisation | Anonymisation (Our Approach) |
|---|---|---|
| Definition | Data can be attributed to individual with additional info | Data cannot be attributed to any individual |
| GDPR Status | Still personal data | Not personal data |
| Example | User123 → Real user (with mapping) | P1, P2 → No mapping to individuals |
| Our implementation | ❌ Not used | ✅ Used |
The Platform uses anonymisation, not pseudonymisation. The sequential IDs (P1, P2) used in AI processing cannot be mapped back to individuals by the AI provider or any external party. The mapping exists only within the Platform's secure environment and is used solely to apply AI recommendations to the correct records.
5.6 Validation Before Transmission
Every data payload is validated before transmission to AI:
// Executed before EVERY AI API call
function enforceGDPRCompliance(data: unknown[]): void {
for (const item of data) {
const { valid, violations } = validateNoPersonalData(item);
if (!valid) {
throw new Error(`GDPR compliance check failed: ${violations.join(', ')}`);
}
}
}
If validation fails, the AI operation is aborted and an error is logged. This provides defence-in-depth against accidental PII transmission.
6. Technical Implementation
6.1 Architecture Overview
┌─────────────────────────────────────────────────────────────────┐
│ Platform (Austria, EU) │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ AI Service │───▶│ Anonymiser │───▶│ Validator │ │
│ │ (filtering, │ │ (strip PII, │ │ (verify no │ │
│ │ assignment) │ │ replace IDs)│ │ PII remains)│ │
│ └──────────────┘ └──────────────┘ └──────┬───────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ API Client │ │
│ │ (TLS 1.2+) │ │
│ └──────┬───────┘ │
└─────────────────────────────────────────────────┼───────────────┘
│
│ HTTPS (TLS 1.2+)
│ Anonymised data only
▼
┌─────────────────────────────────────────────────────────────────┐
│ OpenAI (Dublin, Ireland, EU) │
│ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ GPT Model Processing │ │
│ │ │ │
│ │ • EU Data Residency enabled │ │
│ │ • Zero Data Retention (ZDR) │ │
│ │ • Data NOT used for training │ │
│ │ • AES-256 encryption at rest (during processing) │ │
│ │ • SOC 2 Type 2 compliant │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
6.2 Encryption
| Stage | Encryption | Standard |
|---|---|---|
| Data at rest (Platform) | AES-256 | Database encryption |
| Data in transit | TLS 1.2+ | HTTPS to OpenAI API |
| Data at rest (OpenAI) | AES-256 | OpenAI infrastructure |
| Data at rest after processing | N/A | Zero Data Retention |
6.3 Batching Strategy
To optimise efficiency and reduce API calls, data is processed in batches:
| Service | Batch Size | Rationale |
|---|---|---|
| Project Filtering | 20 projects | Balance throughput and cost |
| Jury Assignment | 15 projects | Include all jurors per batch |
| Award Eligibility | 20 projects | Consistent with filtering |
| Mentor Matching | 15 projects | Include all mentors per batch |
Batching reduces the number of API calls and associated costs while maintaining processing efficiency.
6.4 Description Truncation
Project descriptions are truncated to limit data exposure and token consumption:
| Context | Limit | Rationale |
|---|---|---|
| Assignment | 300 characters | Sufficient for topic identification |
| Filtering | 500 characters | More context needed for criteria |
| Eligibility | 400 characters | Balanced approach |
| Mentor Matching | 350 characters | Focus on topic alignment |
Truncation reduces:
- Data exposure (less text transmitted)
- Processing costs (fewer tokens)
- Risk of PII in longer texts
7. Subprocessor: OpenAI
7.1 Subprocessor Details
| Field | Value |
|---|---|
| Legal Entity | OpenAI, Inc. |
| EU Entity | OpenAI Ireland Limited |
| Registered Address | 3180 18th Street, San Francisco, CA 94110, USA |
| EU Processing Location | Dublin, Ireland |
| Role | Data Processor (for anonymised data) |
| Service Used | OpenAI API (Chat Completions) |
7.2 Data Processing Agreement
| Aspect | Status |
|---|---|
| DPA Available | Yes - OpenAI Data Processing Addendum |
| SCCs Included | Yes - EU Standard Contractual Clauses |
| Current Status | Using standard API Terms; DPA execution recommended |
Recommendation: Execute the formal OpenAI Data Processing Addendum for enhanced contractual protection, even though only anonymised data is transmitted.
Reference: OpenAI Data Processing Addendum
7.3 EU Data Residency
OpenAI offers EU data residency for API customers:
| Feature | Details |
|---|---|
| Processing Location | Dublin, Ireland (EU) |
| Configuration | Per-project setting in OpenAI platform |
| Data Flows | Requests processed entirely within EU |
| Availability | Available for API Platform customers |
Status: EU data residency should be configured for all MOPC API projects.
Reference: OpenAI EU Data Residency
7.4 Zero Data Retention
| Aspect | Details |
|---|---|
| Default Retention | 30 days (for abuse monitoring) |
| ZDR Option | Available for eligible endpoints |
| With EU Residency | Automatic ZDR for EU projects |
| Training Data | API data NOT used for training (default) |
With EU data residency enabled, data is processed in-region and not stored at rest on OpenAI's servers.
7.5 Security Certifications
OpenAI maintains the following security certifications:
| Certification | Scope |
|---|---|
| SOC 2 Type 2 | Security, availability, confidentiality |
| ISO/IEC 27001 | Information security management |
| ISO/IEC 27017 | Cloud security controls |
| ISO/IEC 27018 | PII protection in cloud |
| ISO/IEC 27701 | Privacy information management |
7.6 Subprocessor Due Diligence
| Assessment Area | Finding |
|---|---|
| Security posture | Strong - multiple certifications |
| Privacy practices | GDPR-aligned - DPA available |
| Data handling | Configurable - EU residency, ZDR available |
| Training data | Acceptable - API data not used by default |
| Incident response | Documented - breach notification procedures in DPA |
Conclusion: OpenAI is an acceptable subprocessor for anonymised data processing with appropriate configurations enabled.
8. Data Subject Rights
8.1 Rights Applicable to AI Processing
| Right | Applicability | Explanation |
|---|---|---|
| Access | Limited | Anonymised data sent to AI is not personal data |
| Rectification | N/A | Anonymised data cannot be corrected as it's not attributed |
| Erasure | N/A | No personal data stored at AI provider |
| Restriction | Via objection | Can request exclusion from AI processing |
| Portability | N/A | Anonymised AI inputs are not personal data |
| Object | Yes | Can object to AI-assisted processing |
| Automated decisions | N/A | No solely automated decisions made |
8.2 Right to Object to AI Processing
Data subjects may object to having their project data processed by AI systems.
Procedure:
- Submit objection to gdpr@monaco-opc.com
- Objection acknowledged within 72 hours
- Project excluded from AI processing
- Manual review conducted instead
Impact of objection:
- Project will not be processed by AI filtering
- Jury assignment suggestions generated manually or algorithmically
- Award eligibility determined manually
- Mentor matching done manually
- No disadvantage to the data subject
8.3 Right to Explanation
Data subjects may request an explanation of how AI recommendations affected decisions about their project.
Information provided:
- Whether AI was used in processing their application
- What criteria the AI evaluated against
- The AI's recommendation (if approved by human reviewer)
- The human decision that was ultimately made
- The reasoning provided by the human decision-maker
Note: The actual AI model's internal reasoning is not interpretable. Explanations are based on the prompts used, the recommendations output, and the human reviewer's documented rationale.
8.4 Right to Human Review
All AI recommendations are subject to human review before implementation. Data subjects may also request:
- Confirmation that a human reviewed the AI recommendation
- The identity of the human reviewer (role, not personal identity)
- The outcome of the human review
9. Risk Assessment
9.1 Data Protection Impact Assessment Summary
A DPIA has been conducted for AI processing activities. Key findings:
| Risk Category | Risk | Likelihood | Severity | Mitigation | Residual Risk |
|---|---|---|---|---|---|
| PII Exposure | Personal data sent to AI provider | Very Low | Medium | Anonymisation, validation | Very Low |
| Re-identification | AI provider re-identifies individuals | Very Low | Medium | Full anonymisation (not pseudonymisation) | Very Low |
| Data Breach at AI Provider | Breach exposes data | Low | Low | Anonymised data only; ZDR | Very Low |
| Algorithmic Bias | AI recommendations are biased | Medium | Medium | Human oversight, diverse training data | Low |
| Incorrect Recommendations | AI makes errors | Medium | Low | Human review before action | Low |
| Model Training on Data | Data used to train AI | Very Low | Medium | Contractual prohibition; opt-out default | Very Low |
9.2 Risk Mitigation Summary
| Risk | Primary Mitigation | Secondary Mitigation |
|---|---|---|
| PII Exposure | Automated anonymisation | Pre-transmission validation |
| Re-identification | Anonymisation (not pseudonymisation) | No additional data sent |
| Data Breach | Zero data retention | Anonymised data only |
| Algorithmic Bias | Human oversight | Documented criteria |
| Incorrect Recommendations | Mandatory human review | Algorithmic fallback |
| Model Training | Contractual terms | Technical opt-out |
9.3 Residual Risk Statement
After implementation of all mitigation measures, the residual risk of GDPR non-compliance in AI processing is assessed as Very Low. The primary reason is that no personal data is transmitted to the AI provider - only fully anonymised data that cannot be attributed to any identifiable natural person.
10. Audit & Monitoring
10.1 Audit Logging
All AI operations are logged in the AIUsageLog table:
| Field | Purpose |
|---|---|
createdAt |
Timestamp of AI operation |
userId |
Administrator who initiated operation |
action |
Type of AI operation (FILTERING, ASSIGNMENT, etc.) |
entityType |
Related entity type (Round, Award, etc.) |
entityId |
Related entity ID |
model |
AI model used |
promptTokens |
Input tokens consumed |
completionTokens |
Output tokens consumed |
totalTokens |
Total tokens consumed |
estimatedCostUsd |
Estimated cost in USD |
batchSize |
Number of items in batch |
itemsProcessed |
Number of items successfully processed |
status |
SUCCESS, PARTIAL, or ERROR |
errorMessage |
Error details if applicable |
10.2 Monitoring Metrics
| Metric | Alert Threshold | Purpose |
|---|---|---|
| Error rate | >10% in 24 hours | Detect AI service issues |
| Token consumption | >$100/day | Cost control |
| Validation failures | Any | Detect PII leakage attempts |
| Processing time | >30 seconds/batch | Performance monitoring |
10.3 Regular Reviews
| Review | Frequency | Scope |
|---|---|---|
| AI usage audit | Monthly | Token usage, costs, error rates |
| Anonymisation validation | Quarterly | Sample review of AI inputs |
| DPIA review | Annually | Risk reassessment |
| Subprocessor review | Annually | OpenAI compliance status |
10.4 Audit Trail Retention
| Log Type | Retention | Purpose |
|---|---|---|
| AI usage logs | 12 months | Operational monitoring, cost tracking |
| Audit logs | 12 months | Security and compliance |
| Error logs | 30 days | Debugging |
11. Incident Response
11.1 AI-Specific Incident Types
| Incident Type | Description | Response |
|---|---|---|
| PII Transmission | Personal data accidentally sent to AI | Immediate: Disable AI; Investigate; Assess breach |
| Validation Failure | Pre-transmission check fails | Automatic: Block transmission; Log; Alert |
| AI Service Breach | OpenAI reports data breach | Assess impact (likely none - anonymised data); Document |
| Model Misbehaviour | AI produces inappropriate content | Disable AI; Review outputs; Resume with modifications |
11.2 PII Transmission Response Procedure
If personal data is accidentally transmitted to AI:
-
Immediate (0-1 hour):
- Disable all AI processing
- Preserve logs and evidence
- Alert Data Protection Contact
-
Assessment (1-24 hours):
- Determine what data was sent
- Identify affected data subjects
- Assess risk level
- Contact OpenAI if deletion needed
-
Notification (if required):
- Follow breach notification procedure
- APDP notification if risk to data subjects
- Data subject notification if high risk
-
Remediation:
- Fix root cause
- Enhance validation
- Resume AI with additional safeguards
- Document lessons learned
11.3 Contact OpenAI
For urgent data-related issues:
- OpenAI Trust & Safety: Via API dashboard
- DPA-related requests: Via contract terms
12. Compliance Checklist
12.1 Technical Compliance
| Requirement | Status | Evidence |
|---|---|---|
| ✅ Data anonymisation implemented | Complete | anonymization.ts |
| ✅ PII validation before transmission | Complete | validateNoPersonalData() |
| ✅ EU data residency configured | To verify | OpenAI project settings |
| ✅ Zero data retention enabled | To verify | OpenAI project settings |
| ✅ TLS encryption for API calls | Complete | HTTPS enforcement |
| ✅ Audit logging implemented | Complete | AIUsageLog table |
| ✅ Error handling and fallbacks | Complete | Algorithmic fallbacks |
12.2 Organisational Compliance
| Requirement | Status | Evidence |
|---|---|---|
| ✅ Legal basis documented | Complete | This document, Section 3 |
| ✅ DPIA conducted | Complete | This document, Section 9 |
| ✅ Subprocessor due diligence | Complete | This document, Section 7 |
| ⚠️ DPA executed with OpenAI | Recommended | Standard API terms in use |
| ✅ Data subject rights procedures | Complete | Section 8 |
| ✅ Incident response procedures | Complete | Section 11 |
| ✅ Staff awareness | Ongoing | Training programme |
12.3 Documentation Compliance
| Document | Status | Location |
|---|---|---|
| ✅ Platform GDPR compliance | Complete | docs/gdpr/platform-gdpr-compliance.md |
| ✅ AI data processing documentation | Complete | This document |
| ✅ AI system architecture | Complete | docs/architecture/ai-system.md |
| ✅ AI services reference | Complete | docs/architecture/ai-services.md |
| ✅ Processing records (ROPA) | To maintain | As required by Art. 30 |
13. Contact Information
13.1 Data Protection Contact
Email: gdpr@monaco-opc.com
For:
- Data subject rights requests related to AI processing
- Questions about AI data handling
- Reporting AI-related incidents
13.2 Technical Contact
For AI system technical issues, contact the Platform administrators.
13.3 Supervisory Authority
Autorité de Protection des Données Personnelles (APDP) Principality of Monaco
Appendices
Appendix A: Sample Anonymised Data
Example of data sent to AI (actual personal data replaced with anonymised equivalents):
{
"projects": [
{
"project_id": "P1",
"title": "Coral Reef Restoration Initiative",
"description": "Our project focuses on restoring damaged coral reefs using innovative bio-engineering techniques...",
"category": "STARTUP",
"ocean_issue": "HABITAT_RESTORATION",
"country": "Italy",
"region": "Mediterranean",
"institution": null,
"tags": ["coral", "reef", "restoration", "marine biology"],
"founded_year": 2022,
"team_size": 4,
"has_description": true,
"file_count": 3,
"file_types": ["PITCH_DECK", "VIDEO_PITCH"],
"wants_mentorship": true,
"submission_source": "MANUAL",
"submitted_date": "2026-01-15"
}
]
}
Note: No names, emails, phone numbers, URLs, or real IDs are included.
Appendix B: Related Documents
- Platform GDPR Compliance
- AI System Architecture
- AI Services Reference
- AI Configuration Guide
- AI Error Handling
Appendix C: Legal References
- GDPR - Regulation (EU) 2016/679
- Monaco Law 1.565 of December 3, 2024
- OpenAI Data Processing Addendum
- OpenAI EU Data Residency
- OpenAI Enterprise Privacy
Document Control
| Version | Date | Changes |
|---|---|---|
| 1.0 | January 2025 | Initial version |
| 2.0 | February 2026 | Comprehensive revision: Added definitions, expanded legal framework, detailed technical implementation, enhanced risk assessment, added compliance checklist |