[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AECWN40NE0EWPRAA64FSYT":3,"skill-same:01M6AECWN40NE0EWPRAA64FSYT":93},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":28,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M6AECWN40NE0EWPRAA64FSYT","ai-bias-special-category",null,"Assesses AI bias risks for GDPR Art. 9 special category data and AI Act Art. 10 data governance. Covers fairness metrics, bias detection methods, mitigation strategies, and documentation requirements for protected characteristics. Keywords: AI bias, special category, fairness metrics, discrimination, Art. 9, Art. 10.","mukul975\u002FPrivacy-Data-Protection-Skills","mukul975","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42860185?v=4","01M6ADEQR8T5M4EEG6C67BQCWF","Mahipal","01M6ADNKWX1HF4Q5DKEXT5M774",336,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fplugins\u002Fprivacy-skills-complete\u002Fskills\u002Fai-bias-special-category\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38],"ai bias special category","documentation","governance","data governance","metrics","gdpr","privacy","data","special category data","detection","2026-11-10 10:12:30",false,"---\nname: ai-bias-special-category\ndescription: >-\n  Assesses AI bias risks for GDPR Art. 9 special category data and AI Act\n  Art. 10 data governance. Covers fairness metrics, bias detection methods,\n  mitigation strategies, and documentation requirements for protected\n  characteristics. Keywords: AI bias, special category, fairness metrics,\n  discrimination, Art. 9, Art. 10.\nlicense: Apache-2.0\nmetadata:\n  author: mukul975\n  version: \"1.0\"\n  domain: privacy\n  subdomain: ai-privacy-governance\n  tags: \"ai-bias, special-category, fairness-metrics, discrimination, art-9, data-governance\"\n---\n\n# AI Bias Assessment for Special Category Data\n\n## Overview\n\nAI systems can amplify, perpetuate, or introduce bias against protected groups defined by GDPR Art. 9 special categories (race, ethnicity, political opinion, religion, trade union membership, genetic data, biometric data, health, sexual orientation) and by EU equality law (gender, age, disability). The AI Act Art. 10 requires data governance practices for training data that address bias, while Art. 5 prohibits AI-based social scoring. This skill provides the methodology for detecting, measuring, and mitigating bias in AI systems that process or infer special category data, with documentation requirements meeting both GDPR and AI Act obligations.\n\n## Art. 9 Special Categories and AI Bias\n\n### Direct Processing of Special Category Data\n\nWhen AI systems directly process Art. 9 data:\n\n| Category | AI Bias Risk | Example |\n|----------|-------------|---------|\n| Racial or ethnic origin | Discrimination in hiring, credit, policing | CV screening penalising names associated with ethnic minorities |\n| Political opinions | Political profiling, content suppression | News recommendation amplifying or suppressing political viewpoints |\n| Religious beliefs | Service denial, discriminatory targeting | Insurance pricing varying by religious affiliation |\n| Trade union membership | Employment discrimination | Performance scoring penalising union activity |\n| Genetic data | Genetic discrimination in insurance\u002Femployment | Health insurance pricing based on genetic predisposition |\n| Biometric data | Differential accuracy across demographics | Facial recognition with higher error rates for darker skin tones |\n| Health data | Health-based discrimination | Hiring algorithms penalising disability or mental health history |\n| Sexual orientation | Discrimination, outing | Content recommendation inadvertently revealing sexual orientation |\n\n### Proxy Inference of Special Categories\n\nAI models frequently infer Art. 9 data from non-sensitive features:\n\n| Proxy Feature | Inferred Category | Mechanism |\n|---------------|-------------------|-----------|\n| Postcode\u002Fzip code | Race\u002Fethnicity, income | Residential segregation patterns |\n| First\u002Flast name | Race\u002Fethnicity, religion | Name-ethnicity correlations |\n| Browsing history | Political opinion, religion, health | Content consumption patterns |\n| Purchase history | Health status, religion | Medication purchases, dietary products |\n| Language patterns | National origin, education | Dialect, vocabulary, grammar patterns |\n| Device\u002Fapp usage | Age, income, disability | Accessibility features, device type |\n\nEDPB position: inferring Art. 9 data from non-sensitive inputs constitutes processing of special category data — the same protections apply.\n\n## Fairness Metrics\n\n### Group Fairness Metrics\n\n| Metric | Definition | When to Use |\n|--------|-----------|-------------|\n| Demographic parity | P(positive outcome | group A) = P(positive outcome | group B) | When equal selection rates are desired regardless of qualification |\n| Equalized odds | TPR and FPR equal across groups | When accuracy should be equal across groups |\n| Equal opportunity | TPR equal across groups (relaxed equalized odds) | When true positive detection should be equal |\n| Calibration | P(Y=1 | score=s, group=A) = P(Y=1 | score=s, group=B) | When scores should mean the same thing across groups |\n| Predictive parity | PPV equal across groups | When positive predictions should be equally reliable |\n\n### Individual Fairness Metrics\n\n| Metric | Definition |\n|--------|-----------|\n| Consistency | Similar individuals receive similar outcomes |\n| Counterfactual fairness | Outcome would be the same if protected attribute were different |\n| Causal fairness | No causal path from protected attribute to outcome |\n\n### Metric Selection Guidance\n\n| Decision Context | Recommended Metric | Justification |\n|-----------------|-------------------|---------------|\n| Hiring\u002Fadmissions | Equalized odds or equal opportunity | Equal detection of qualified candidates across groups |\n| Credit scoring | Calibration | Score should mean the same probability regardless of group |\n| Criminal risk | Equalized odds | Both FPR and TPR should be equal to avoid disproportionate impact |\n| Healthcare | Equal opportunity + calibration | Equal detection of conditions; equal meaning of risk scores |\n| Content moderation | Demographic parity | Content removal should not disproportionately affect groups |\n\nNote: Mathematical impossibility results show that demographic parity, equalized odds, and calibration cannot all be satisfied simultaneously when base rates differ across groups. Document the trade-off explicitly.\n\n## Bias Detection Methodology\n\n### Phase 1: Data Audit\n\n1. Profile training data demographics against target population\n2. Identify underrepresented groups that may have lower model performance\n3. Check for historical bias in labelled data (e.g., biased hiring decisions used as ground truth)\n4. Identify label noise differential across groups\n5. Assess feature distributions across groups for proxy discrimination potential\n\n### Phase 2: Model Testing\n\n1. Evaluate model performance disaggregated by protected groups\n2. Compute selected fairness metrics for each protected group pair\n3. Run counterfactual testing: change protected attributes, observe output changes\n4. Test for intersectional bias (combinations of protected attributes)\n5. Evaluate model performance on edge cases and adversarial examples per group\n\n### Phase 3: Output Analysis\n\n1. Analyse decision distribution across groups\n2. Identify threshold effects that disproportionately impact specific groups\n3. Test for feedback loop amplification over time\n4. Assess output explanation fairness (are explanations equally informative across groups?)\n\n## Bias Mitigation Strategies\n\n### Pre-processing (Data-Level)\n\n| Strategy | Description | Trade-off |\n|----------|-------------|-----------|\n| Resampling | Over-sample underrepresented groups, under-sample overrepresented | May reduce data diversity or introduce duplicates |\n| Reweighting | Assign higher weights to underrepresented group samples | Computationally simple; may not address structural bias |\n| Relabelling | Correct historically biased labels | Requires domain expertise; may be subjective |\n| Fair representation learning | Learn latent representation that removes protected attribute information | May lose legitimate correlations |\n\n### In-processing (Algorithm-Level)\n\n| Strategy | Description | Trade-off |\n|----------|-------------|-----------|\n| Adversarial debiasing | Train adversary to predict protected attribute from model; penalise success | Accuracy-fairness trade-off; requires protected attribute data |\n| Fairness constraints | Add fairness metric as training constraint | May reduce overall accuracy; constraint satisfaction varies |\n| Regularisation | Add fairness-related regularisation term to loss function | Balances accuracy and fairness; requires tuning |\n| Causal modelling | Use causal graph to block discriminatory paths | Requires causal knowledge; complex to implement |\n\n### Post-processing (Output-Level)\n\n| Strategy | Description | Trade-off |\n|----------|-------------|-----------|\n| Threshold adjustment | Different decision thresholds per group to equalise metrics | May be perceived as unfair; legally complex |\n| Score calibration | Calibrate scores per group | Requires sufficient group data; may reduce discrimination |\n| Reject option | Abstain from decision for borderline cases across groups | Reduces coverage; requires human fallback |\n\n## AI Act Art. 10 Data Governance\n\nArt. 10 requires for high-risk AI training data:\n\n| Requirement | Implementation |\n|-------------|---------------|\n| Relevant data | Training data must be relevant to the intended purpose |\n| Sufficiently representative | Data must represent the population the system will be deployed on |\n| Free of errors | Data quality assessment and cleaning processes |\n| Complete | Sufficient coverage of deployment scenarios |\n| Appropriate statistical properties | Distribution analysis including demographic representation |\n| Bias examination | Examine training data for possible biases, especially related to Art. 10(2)(f) |\n\nArt. 10(5): Processing of special category data for bias detection is permitted for high-risk AI if:\n- Strictly necessary for bias monitoring, detection, and correction\n- Subject to appropriate safeguards (pseudonymisation, access controls)\n- Data is not used for other purposes\n- Deleted after bias assessment unless retention is required for compliance documentation\n\n## Documentation Requirements\n\n### Bias Assessment Report\n\n| Section | Content |\n|---------|---------|\n| System description | Model, purpose, affected groups |\n| Protected attributes assessed | Art. 9 categories + equality law characteristics |\n| Fairness metrics selected | With justification for selection |\n| Data audit results | Training data demographics, representation gaps |\n| Model testing results | Per-group performance, fairness metrics, counterfactual results |\n| Bias findings | Identified disparities with severity assessment |\n| Mitigation measures | Applied strategies with effectiveness evidence |\n| Residual bias | Remaining disparities after mitigation |\n| Trade-off documentation | Accuracy-fairness trade-offs, metric impossibility acknowledgement |\n| Ongoing monitoring plan | Post-deployment fairness monitoring |\n\n## Enforcement Precedents\n\n- **Dutch Tax Authority (SyRI, 2020)**: Court struck down algorithmic fraud detection for discriminatory profiling — system disproportionately targeted residents of low-income, immigrant-background neighbourhoods.\n- **Italian DPA v. Deliveroo (2021)**: Algorithmic worker management found to discriminate based on protected characteristics — Art. 22 and equality law violations.\n- **Austrian DPA v. AMS Algorithm (2020)**: Austrian employment service algorithm that scored job seekers lower based on gender, age, disability, and citizenship — DPA found processing unlawful.\n- **AEPD guidance (2021)**: Spanish DPA issued guidance on algorithmic discrimination, emphasising DPIA requirement for AI systems processing protected characteristics.\n- **CNIL (2024)**: AI bias assessment framework published requiring fairness testing for high-impact AI systems.\n\n## Integration Points\n\n- **ai-dpia**: Bias assessment feeds into DPIA risk assessment for discrimination harms\n- **ai-automated-decisions**: Biased automated decisions trigger Art. 22 and equality law violations\n- **ai-training-lawfulness**: Art. 10(5) processing of special category data for bias detection requires documentation\n- **ai-transparency-reqs**: Bias findings should be disclosed in model cards and transparency documentation\n- **ai-act-high-risk-docs**: Art. 10 data governance documentation is part of conformity assessment\n","# AI Bias Assessment for Special Category Data\n\n## Overview\n\nAI systems can amplify, perpetuate, or introduce bias against protected groups defined by GDPR Art. 9 special categories (race, ethnicity, political opinion, religion, trade union membership, genetic data, biometric data, health, sexual orientation) and by EU equality law (gender, age, disability). The AI Act Art. 10 requires data governance practices for training data that address bias, while Art. 5 prohibits AI-based social scoring. This skill provides the methodology for detecting, measuring, and mitigating bias in AI systems that process or infer special category data, with documentation requirements meeting both GDPR and AI Act obligations.\n\n## Art. 9 Special Categories and AI Bias\n\n### Direct Processing of Special Category Data\n\nWhen AI systems directly process Art. 9 data:\n\n| Category | AI Bias Risk | Example |\n|----------|-------------|---------|\n| Racial or ethnic origin | Discrimination in hiring, credit, policing | CV screening penalising names associated with ethnic minorities |\n| Political opinions | Political profiling, content suppression | News recommendation amplifying or suppressing political viewpoints |\n| Religious beliefs | Service denial, discriminatory targeting | Insurance pricing varying by religious affiliation |\n| Trade union membership | Employment discrimination | Performance scoring penalising union activity |\n| Genetic data | Genetic discrimination in insurance\u002Femployment | Health insurance pricing based on genetic predisposition |\n| Biometric data | Differential accuracy across demographics | Facial recognition with higher error rates for darker skin tones |\n| Health data | Health-based discrimination | Hiring algorithms penalising disability or mental health history |\n| Sexual orientation | Discrimination, outing | Content recommendation inadvertently revealing sexual orientation |\n\n### Proxy Inference of Special Categories\n\nAI models frequently infer Art. 9 data from non-sensitive features:\n\n| Proxy Feature | Inferred Category | Mechanism |\n|---------------|-------------------|-----------|\n| Postcode\u002Fzip code | Race\u002Fethnicity, income | Residential segregation patterns |\n| First\u002Flast name | Race\u002Fethnicity, religion | Name-ethnicity correlations |\n| Browsing history | Political opinion, religion, health | Content consumption patterns |\n| Purchase history | Health status, religion | Medication purchases, dietary products |\n| Language patterns | National origin, education | Dialect, vocabulary, grammar patterns |\n| Device\u002Fapp usage | Age, income, disability | Accessibility features, device type |\n\nEDPB position: inferring Art. 9 data from non-sensitive inputs constitutes processing of special category data — the same protections apply.\n\n## Fairness Metrics\n\n### Group Fairness Metrics\n\n| Metric | Definition | When to Use |\n|--------|-----------|-------------|\n| Demographic parity | P(positive outcome | group A) = P(positive outcome | group B) | When equal selection rates are desired regardless of qualification |\n| Equalized odds | TPR and FPR equal across groups | When accuracy should be equal across groups |\n| Equal opportunity | TPR equal across groups (relaxed equalized odds) | When true positive detection should be equal |\n| Calibration | P(Y=1 | score=s, group=A) = P(Y=1 | score=s, group=B) | When scores should mean the same thing across groups |\n| Predictive parity | PPV equal across groups | When positive predictions should be equally reliable |\n\n### Individual Fairness Metrics\n\n| Metric | Definition |\n|--------|-----------|\n| Consistency | Similar individuals receive similar outcomes |\n| Counterfactual fairness | Outcome would be the same if protected attribute were different |\n| Causal fairness | No causal path from protected attribute to outcome |\n\n### Metric Selection Guidance\n\n| Decision Context | Recommended Metric | Justification |\n|-----------------|-------------------|---------------|\n| Hiring\u002Fadmissions | Equalized odds or equal opportunity | Equal detection of qualified candidates across groups |\n| Credit scoring | Calibration | Score should mean the same probability regardless of group |\n| Criminal risk | Equalized odds | Both FPR and TPR should be equal to avoid disproportionate impact |\n| Healthcare | Equal opportunity + calibration | Equal detection of conditions; equal meaning of risk scores |\n| Content moderation | Demographic parity | Content removal should not disproportionately affect groups |\n\nNote: Mathematical impossibility results show that demographic parity, equalized odds, and calibration cannot all be satisfied simultaneously when base rates differ across groups. Document the trade-off explicitly.\n\n## Bias Detection Methodology\n\n### Phase 1: Data Audit\n\n1. Profile training data demographics against target population\n2. Identify underrepresented groups that may have lower model performance\n3. Check for historical bias in labelled data (e.g., biased hiring decisions used as ground truth)\n4. Identify label noise differential across groups\n5. Assess feature distributions across groups for proxy discrimination potential\n\n### Phase 2: Model Testing\n\n1. Evaluate model performance disaggregated by protected groups\n2. Compute selected fairness metrics for each protected group pair\n3. Run counterfactual testing: change protected attributes, observe output changes\n4. Test for intersectional bias (combinations of protected attributes)\n5. Evaluate model performance on edge cases and adversarial examples per group\n\n### Phase 3: Output Analysis\n\n1. Analyse decision distribution across groups\n2. Identify threshold effects that disproportionately impact specific groups\n3. Test for feedback loop amplification over time\n4. Assess output explanation fairness (are explanations equally informative across groups?)\n\n## Bias Mitigation Strategies\n\n### Pre-processing (Data-Level)\n\n| Strategy | Description | Trade-off |\n|----------|-------------|-----------|\n| Resampling | Over-sample underrepresented groups, under-sample overrepresented | May reduce data diversity or introduce duplicates |\n| Reweighting | Assign higher weights to underrepresented group samples | Computationally simple; may not address structural bias |\n| Relabelling | Correct historically biased labels | Requires domain expertise; may be subjective |\n| Fair representation learning | Learn latent representation that removes protected attribute information | May lose legitimate correlations |\n\n### In-processing (Algorithm-Level)\n\n| Strategy | Description | Trade-off |\n|----------|-------------|-----------|\n| Adversarial debiasing | Train adversary to predict protected attribute from model; penalise success | Accuracy-fairness trade-off; requires protected attribute data |\n| Fairness constraints | Add fairness metric as training constraint | May reduce overall accuracy; constraint satisfaction varies |\n| Regularisation | Add fairness-related regularisation term to loss function | Balances accuracy and fairness; requires tuning |\n| Causal modelling | Use causal graph to block discriminatory paths | Requires causal knowledge; complex to implement |\n\n### Post-processing (Output-Level)\n\n| Strategy | Description | Trade-off |\n|----------|-------------|-----------|\n| Threshold adjustment | Different decision thresholds per group to equalise metrics | May be perceived as unfair; legally complex |\n| Score calibration | Calibrate scores per group | Requires sufficient group data; may reduce discrimination |\n| Reject option | Abstain from decision for borderline cases across groups | Reduces coverage; requires human fallback |\n\n## AI Act Art. 10 Data Governance\n\nArt. 10 requires for high-risk AI training data:\n\n| Requirement | Implementation |\n|-------------|---------------|\n| Relevant data | Training data must be relevant to the intended purpose |\n| Sufficiently representative | Data must represent the population the system will be deployed on |\n| Free of errors | Data quality assessment and cleaning processes |\n| Complete | Sufficient coverage of deployment scenarios |\n| Appropriate statistical properties | Distribution analysis including demographic representation |\n| Bias examination | Examine training data for possible biases, especially related to Art. 10(2)(f) |\n\nArt. 10(5): Processing of special category data for bias detection is permitted for high-risk AI if:\n- Strictly necessary for bias monitoring, detection, and correction\n- Subject to appropriate safeguards (pseudonymisation, access controls)\n- Data is not used for other purposes\n- Deleted after bias assessment unless retention is required for compliance documentation\n\n## Documentation Requirements\n\n### Bias Assessment Report\n\n| Section | Content |\n|---------|---------|\n| System description | Model, purpose, affected groups |\n| Protected attributes assessed | Art. 9 categories + equality law characteristics |\n| Fairness metrics selected | With justification for selection |\n| Data audit results | Training data demographics, representation gaps |\n| Model testing results | Per-group performance, fairness metrics, counterfactual results |\n| Bias findings | Identified disparities with severity assessment |\n| Mitigation measures | Applied strategies with effectiveness evidence |\n| Residual bias | Remaining disparities after mitigation |\n| Trade-off documentation | Accuracy-fairness trade-offs, metric impossibility acknowledgement |\n| Ongoing monitoring plan | Post-deployment fairness monitoring |\n\n## Enforcement Precedents\n\n- **Dutch Tax Authority (SyRI, 2020)**: Court struck down algorithmic fraud detection for discriminatory profiling — system disproportionately targeted residents of low-income, immigrant-background neighbourhoods.\n- **Italian DPA v. Deliveroo (2021)**: Algorithmic worker management found to discriminate based on protected characteristics — Art. 22 and equality law violations.\n- **Austrian DPA v. AMS Algorithm (2020)**: Austrian employment service algorithm that scored job seekers lower based on gender, age, disability, and citizenship — DPA found processing unlawful.\n- **AEPD guidance (2021)**: Spanish DPA issued guidance on algorithmic discrimination, emphasising DPIA requirement for AI systems processing protected characteristics.\n- **CNIL (2024)**: AI bias assessment framework published requiring fairness testing for high-impact AI systems.\n\n## Integration Points\n\n- **ai-dpia**: Bias assessment feeds into DPIA risk assessment for discrimination harms\n- **ai-automated-decisions**: Biased automated decisions trigger Art. 22 and equality law violations\n- **ai-training-lawfulness**: Art. 10(5) processing of special category data for bias detection requires documentation\n- **ai-transparency-reqs**: Bias findings should be disclosed in model cards and transparency documentation\n- **ai-act-high-risk-docs**: Art. 10 data governance documentation is part of conformity assessment\n",{"name":5,"license":15,"metadata":44,"description":7},{"tags":45,"author":9,"domain":35,"version":46,"subdomain":47},"ai-bias, special-category, fairness-metrics, discrimination, art-9, data-governance","1.0","ai-privacy-governance","main","9b2ef9eae161c00a17241d42a388571321b33e9f","plugins\u002Fprivacy-skills-complete\u002Fskills\u002Fai-bias-special-category",67,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills","https:\u002F\u002Fgithub.com\u002Fmukul975","Mahipal.engineer","🔐 Cybersecurity | 💻 Dev | 📷 Street Photographer\r\n🎓 MSc | 📚 Research & AI Security","2026-03-17 04:06:52",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add mukul975\u002FPrivacy-Data-Protection-Skills --skill ai-bias-special-category",{"tool":63,"command":64},"bunx","bunx skills add mukul975\u002FPrivacy-Data-Protection-Skills --skill ai-bias-special-category",{"tool":66,"command":67},"pnpm","pnpm dlx skills add mukul975\u002FPrivacy-Data-Protection-Skills --skill ai-bias-special-category","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fplugins\u002Fprivacy-skills-complete\u002Fskills\u002Fai-bias-special-category\u002FSKILL.md",true,[71,77,83,87],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":76},"assets\u002Ftemplate.md","ASSET","资产文件",1380,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fplugins\u002Fprivacy-skills-complete\u002Fskills\u002Fai-bias-special-category\u002Fassets\u002Ftemplate.md",{"path":78,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Fstandards.md","REFERENCE","参考文档",2632,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fplugins\u002Fprivacy-skills-complete\u002Fskills\u002Fai-bias-special-category\u002Freferences\u002Fstandards.md",{"path":84,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":85,"sourceHtmlUrl":86},"references\u002Fworkflows.md",3601,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fplugins\u002Fprivacy-skills-complete\u002Fskills\u002Fai-bias-special-category\u002Freferences\u002Fworkflows.md",{"path":88,"resourceType":89,"resourceTypeDesc":90,"sizeBytes":91,"sourceHtmlUrl":92},"scripts\u002Fprocess.py","SCRIPT","脚本",11031,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fplugins\u002Fprivacy-skills-complete\u002Fskills\u002Fai-bias-special-category\u002Fscripts\u002Fprocess.py",[94,118,132,145,162,175],{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":109,"publishedAt":39},"01M6AG6K8R3XW10ENWH2FH18RH","workplace-email-privacy","Implements email and internet monitoring compliance in the workplace per Barbulescu v Romania (ECHR Grand Chamber), EDPB guidance, and national labour law. Covers acceptable use policies, legitimate expectation of privacy, proportionality testing, and content vs metadata monitoring. Keywords: email monitoring, Barbulescu, workplace privacy, internet monitoring, acceptable use policy, ECHR, proportionality.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fprivacy\u002Fworkplace-email-privacy\u002FSKILL.md",[100,103,106],{"categoryNo":101,"categoryName":102,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000005","邮件与沟通",{"categoryNo":104,"categoryName":105,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":107,"categoryName":108,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000037","律师与法务",[110,111,35,112,113,36,114,115,116,117],"email","workplace email privacy","compliance","content","policy","testing","monitoring","metadata",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":126,"publishedAt":39},"01M6AG6FRCBJY7D061BJZMNV49","whistleblower-data","Implements data protection compliance for whistleblowing systems under EU Directive 2019\u002F1937 and GDPR. Covers anonymous reporting channels, identity protection for whistleblowers and accused persons, retention limits, access restrictions, and retaliation prevention. Addresses national transpositions and DPA guidance. Keywords: whistleblower, Directive 2019\u002F1937, anonymous reporting, identity protection, retaliation, retention, reporting channel.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fprivacy\u002Fwhistleblower-data\u002FSKILL.md",[124,125],{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},{"categoryNo":107,"categoryName":108,"taxonomyType":26,"taxonomyTypeDesc":27},[36,127,128,129,112,130,34,35,131],"whistleblower data","identity","reporting","data protection","prevention",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":139,"publishedAt":39},"01M6AG6CJP0PW3X65HC7VP9SR9","vendor-termination-data","Vendor termination data return and deletion procedures per GDPR Article 28(3)(g). Covers data extraction formats, deletion certification requirements, transition planning, residual data handling, and post-termination verification.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fprivacy\u002Fvendor-termination-data\u002FSKILL.md",[138],{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[36,140,141,142,143,34,35,144],"vendor termination data","planning","verification","extraction","certification",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":152,"publishedAt":39},"01M6AG69E277DXZB2NF6KV17ZA","vendor-risk-scoring","Vendor privacy risk tiering methodology for processor management. Covers scoring factors including data volume, sensitivity, transfer locations, certifications, breach history, and control maturity with weighted risk calculation and tier assignment.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fprivacy\u002Fvendor-risk-scoring\u002FSKILL.md",[151],{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[153,154,155,156,157,158,159,160,35,36,161],"vendor risk scoring","risk","risk scoring","methodology","risk-scoring","assessment","transfer","certifications","processor",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":169,"publishedAt":39},"01M6AG6655ABFKT2BBWHCP4PAT","vendor-privacy-due-diligence","Pre-contract vendor privacy due diligence per GDPR Article 28(1). Covers risk questionnaires, technical controls assessment, certification review, data flow analysis, and documented sufficiency decisions for processor engagement.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fprivacy\u002Fvendor-privacy-due-diligence\u002FSKILL.md",[168],{"categoryNo":107,"categoryName":108,"taxonomyType":26,"taxonomyTypeDesc":27},[35,170,34,171,158,172,173,36,161,154,144,174],"vendor privacy due diligence","review","onboarding","flow","analysis",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":188,"publishedAt":39},"01M6AG62C3VD8SYNGH4N7RHZTE","vendor-privacy-audit","On-site and remote vendor audit procedures per GDPR Article 28(3)(h). Covers audit planning, evidence collection methodologies, finding classification, remediation tracking, and audit report generation for processor compliance verification.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FPrivacy-Data-Protection-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fprivacy\u002Fvendor-privacy-audit\u002FSKILL.md",[181,184,187],{"categoryNo":182,"categoryName":183,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":185,"categoryName":186,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者",{"categoryNo":107,"categoryName":108,"taxonomyType":26,"taxonomyTypeDesc":27},[189,190,35,191,142,192,112,34,193,161,194,195,196,141],"vendor privacy audit","audit","report","audit report","remediation","collection","remediation-tracking","classification"]