jumpstart-mode 1.1.13 → 1.1.14

package/.github/skills/privacy-by-design-for-ai/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: privacy-by-design-for-ai
+description: Produce a DPIA-style privacy review for AI data flows covering data minimization, purpose limitation, lawful basis, retention, redaction, consent, regional residency, sub-processor management, training-data exclusion, log hygiene, and rights fulfillment across prompts, retrievals, model calls, tool I/O, outputs, traces, and eval datasets. Use this whenever the user needs a DPIA, privacy review, data protection assessment, PIA, GDPR compliance check, or privacy-by-design analysis for an AI system, even when phrased as "is this GDPR compliant," "do we need a DPIA," "what about privacy," or "can we process this data."
+argument-hint: Paste the AI use case, data flows (prompts, retrievals, tool calls, outputs, logs), data subjects, regulatory regimes, and data residency constraints.
+---
+
+# Privacy by Design for AI
+
+## Positioning
+
+Use this skill to run a structured DPIA-style privacy review through the lens of AI-specific data flows — prompts, RAG retrievals, tool calls, outputs, traces, evals, and fine-tuning corpora — so the Pod ships a system that meets privacy obligations by design rather than after the fact.
+
+## When To Use This
+
+- The user is building an AI system that processes personal data or regulated data.
+- A DPIA, PIA, or privacy-by-design review is required by regulation, client policy, or governance board.
+- Phrased as "is this GDPR compliant," "do we need a DPIA," "privacy review," or "data protection."
+
+## When Not To Use This Alone
+
+- For data classification (which categories are present), use `../data-classification-quickscan/SKILL.md`.
+- For full RAI assessment, pair with `../responsible-ai-impact-assessment/SKILL.md`.
+- For security controls, pair with `../agent-governance/SKILL.md`.
+
+## Required Inputs
+
+- AI use case and processing purposes,
+- data subjects (customers, employees, public, minors),
+- data flows: prompts, retrievals, tool I/O, outputs, logs, traces, evals, fine-tuning,
+- data residency constraints (where subjects are, where processing happens),
+- legal basis relied upon (consent, legitimate interest, contract, legal obligation),
+- sub-processors including model provider(s),
+- retention requirements per flow,
+- data subject rights approach (access, erasure, portability, objection, restriction).
+
+## DPIA Sections (AI-Adapted)
+
+1. **Processing description** — what personal data, why, which AI flows.
+2. **Necessity and proportionality** — is AI processing necessary for the purpose; is there a less-invasive alternative.
+3. **Lawful basis** — per data subject category and processing activity.
+4. **Data minimization in AI context** — do prompts include only what is needed; do logs retain only what is justified.
+5. **Purpose limitation** — is data used only for stated purpose; training-data exclusion; secondary use.
+6. **Retention** — per flow stage (prompts, chunks, outputs, traces, evals).
+7. **Residency and transfer** — model deployment region, cross-border safeguards (SCCs, adequacy).
+8. **Sub-processors** — model providers as sub-processors; DPA coverage; breach notice.
+9. **Security** — encryption, access control, isolation, audit.
+10. **Transparency** — is the data subject informed that AI processes their data; disclosure UX.
+11. **Data subject rights** — how access, erasure, objection, portability are fulfilled through the AI pipeline.
+12. **Risks and mitigations** — residual risks with likelihood and severity scoring.
+
+See [references/privacy-by-design-guide.md](./references/privacy-by-design-guide.md) for AI-specific considerations per section.
+
+## Workflow
+
+1. Map all AI data flows that carry personal data.
+2. For each flow, identify the data subjects, categories, volumes, and retention.
+3. Walk each DPIA section. Capture finding, evidence, risk, mitigation.
+4. Score residual risk (likelihood × impact).
+5. Identify controls in place and gaps.
+6. Produce the assessment using [templates/privacy-by-design-template.md](./templates/privacy-by-design-template.md).
+7. Recommend DPO / legal sign-off and consultation with supervisory authority where high residual risk remains.
+
+## Output Mode
+
+Default artifact:
+
+- Executive summary (residual risk posture, top three gaps, must-do actions).
+- Processing description and AI data-flow map.
+- Necessity and proportionality analysis.
+- Lawful basis per activity.
+- Minimization, retention, and residency analysis.
+- Sub-processor and DPA register.
+- Data subject rights fulfillment plan.
+- Risk register with mitigations.
+- Recommended sign-offs and reviews.
+- Disclaimer: not legal advice.
+
+## Working Rules
+
+1. Treat every AI pipeline stage (prompts, RAG, tools, logs, evals, fine-tuning) as a processing activity.
+2. Do not assume "enterprise tier = no privacy concern." Enterprise-tier exclusions cover training, not processing.
+3. Erasure obligations extend to embedding indices, cached prompts, and eval datasets.
+4. Treat model outputs that echo personal data as a data flow.
+5. Recommend legal / DPO sign-off; do not present this as a binding legal opinion.

package/.github/skills/privacy-by-design-for-ai/evals/evals.json

@@ -0,0 +1,32 @@
+{
+  "skill_name": "privacy-by-design-for-ai",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Run a DPIA on a planned EU customer-support copilot. Inputs are customer chat (potentially special-category data), retrieved knowledge base, and CRM lookups. Vendor is Azure OpenAI EU region. Tell us where we have privacy risk and the controls to install before launch.",
+      "expected_output": "A DPIA covering data flows, lawful basis, minimization, retention, redaction, residency, sub-processors, training-data exclusion, rights, and a risk register.",
+      "expectations": [
+        "Enumerates every data flow including prompts, retrieval, tool I/O, model call, output, traces, memory, and eval set.",
+        "Names lawful basis per category and addresses special-category data conditions where applicable.",
+        "Specifies redaction at ingest, retention per class, and erasure cascade including embeddings and traces.",
+        "Confirms training-data exclusion with vendor evidence and BYOK/customer-managed keys.",
+        "Pins residency and identifies any transfer mechanism (SCCs/IDTAs) needed.",
+        "Lists sub-processors with DPA review.",
+        "Produces a risk register with mitigations and owners."
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "We're storing every prompt, response, and retrieved chunk in a Snowflake table for analytics. EU users included. What's the privacy posture and what should we change?",
+      "expected_output": "A diagnosis and a remediation plan focused on minimization, redaction, retention, and rights compliance.",
+      "expectations": [
+        "Diagnoses raw retention as a minimization, retention, and erasure-risk failure.",
+        "Recommends redaction at ingest with PII regex/classifier rather than post-cleanup.",
+        "Recommends typed retention by data class with auto-purge.",
+        "Recommends restricted access with audit and break-glass for raw content.",
+        "Addresses erasure cascade including embeddings, summaries, and analytics aggregates.",
+        "Calls out region/residency, sub-processor inventory, and lawful-basis re-justification for the analytics purpose."
+      ]
+    }
+  ]
+}

package/.github/skills/privacy-by-design-for-ai/examples/example-eu-employee-assistant.md

@@ -0,0 +1,53 @@
+# Example: EU Employee Assistant DPIA (excerpt)
+
+## 1. Description
+EU-wide employee assistant (24 countries, ~30k employees) answering HR policy and benefits questions in Teams. Indexes HR policy library and benefits PDFs. No employee personal-data lookups in scope.
+
+## 2. Data flows (excerpt)
+| Flow | Personal data | Lawful basis | Purpose |
+|---|---|---|---|
+| Prompt | Name (from auth), question text (may contain personal context) | Legitimate interest (employee support) | Answer policy questions |
+| Retrieval | none | n/a | Ground answers |
+| Model call (Azure OpenAI EU) | Prompt + system | Legitimate interest | Generate answer |
+| Output | none extra | Legitimate interest | Deliver answer |
+| Traces (redacted) | hashed user ID, redacted text | Legitimate interest | Operate service |
+| Eval set | de-identified questions | Legitimate interest | Quality assurance |
+| Memory | none in scope | n/a | n/a |
+
+## 3. Lawful basis
+- Legitimate interest with LIA on file. Works council notified per local rules.
+
+## 4. Minimization
+- Names not stored beyond auth context; question text is redacted before persistence.
+
+## 5. Retention
+| Data | Retention | Disposal |
+|---|---|---|
+| Redacted traces | 30d | Auto-purge |
+| Raw traces (restricted) | 7d | Auto-purge |
+| Eval set | until model retired | Manual review on retirement |
+| HITL reviewer queue | 90d | Auto-purge |
+
+## 6. Redaction
+- PII regex + multilingual classifier on inputs and outputs at ingest before persistence.
+
+## 7. Residency and transfers
+- Azure OpenAI Sweden Central; storage in EU; no transfer outside EEA.
+- BYOK with customer-managed keys.
+
+## 8. Training-data exclusion
+- Azure OpenAI default no-training; documented via product page snapshot and DPA reference.
+
+## 9. Rights
+- Access via existing IT self-service (no extra personal data captured).
+- Erasure: redacted traces are non-identifying; raw traces purge in 7d; eval samples reviewed yearly for de-identification fidelity.
+
+## 10. Top risks
+| Risk | Likelihood | Severity | Mitigation |
+|---|---|---|---|
+| Question text contains personal disclosure | Medium | Medium | Redaction at ingest; user-facing notice |
+| Cross-region transfer if vendor reroutes | Low | High | Region pin + monitoring + alert |
+| Sub-processor change without notice | Medium | Medium | Vendor DPA notice clause + quarterly review |
+
+## 11. Sign-off
+- DPO, IT engineering lead, HR sponsor, dated.

package/.github/skills/privacy-by-design-for-ai/references/privacy-by-design-guide.md

@@ -0,0 +1,95 @@
+# Privacy by Design Guide for AI
+
+AI-specific considerations for each DPIA section. Use as an elicitation and analysis aid.
+
+## 1. Processing description — AI-specific flows
+
+Every AI system has processing stages invisible to traditional DPIAs:
+- **Prompt construction**: user input + system context + retrieved chunks — all carry data.
+- **Retrieval**: embedding queries that may encode PII in vector space; returned chunks from corpus.
+- **Model call**: full prompt sent to model provider (sub-processor boundary).
+- **Tool I/O**: agent may call external systems with personal data as parameters.
+- **Output**: model response may echo, summarize, or infer personal data.
+- **Logs and traces**: operational logs that capture full prompts, responses, tool calls.
+- **Eval datasets**: samples used to measure quality — often slices of production data.
+- **Fine-tuning corpus**: if used, a long-lived copy of potentially personal data in a model.
+
+## 2. Necessity and proportionality
+
+- Is the AI processing necessary for the stated purpose, or could the purpose be achieved with less data?
+- Does the prompt include the minimum personal data needed, or is context "dumped in"?
+- Is the model the least-invasive technology that achieves the purpose?
+- Are alternatives (rule-based, structured retrieval, anonymized) viable?
+
+## 3. Lawful basis — common AI patterns
+
+| Processing activity | Common lawful basis | Risk notes |
+|---|---|---|
+| RAG retrieval (internal docs) | Legitimate interest (employer context) | DPIA needed if profiling |
+| Customer support copilot | Contract performance / legitimate interest | Consent if recording calls |
+| HR / recruitment AI | Legitimate interest + DPIA mandatory | High-risk under EU AI Act |
+| Fine-tuning on customer data | Requires explicit consent or strong LI | Model providers may require separate basis |
+| Logging prompts for debugging | Legitimate interest | Retention must be minimized |
+
+## 4. Data minimization in AI context
+
+- Strip PII from prompts where the task does not need it (e.g., summarize without names).
+- Redact or tokenize before retrieval indexing where possible.
+- Use entity masking / de-identification in eval datasets.
+- Limit context window content to relevant chunks, not full documents.
+- Avoid logging full prompts when a hash + metadata suffices for debugging.
+
+## 5. Purpose limitation
+
+- Enterprise-tier model providers (Azure OpenAI, Anthropic API) do not train on inputs — confirm contractually.
+- Custom fine-tunes may inadvertently create purpose creep if reused across clients or use cases.
+- Eval sets drawn from production must be scoped to the purpose; not reused for marketing analytics.
+- Secondary use (e.g., using support conversations to train a sales model) requires separate basis.
+
+## 6. Retention — per AI pipeline stage
+
+| Stage | Typical retention | Notes |
+|---|---|---|
+| User prompt (live) | Session only | Persist only if explicitly needed |
+| User prompt (logged) | 30-90 days | Minimized or redacted |
+| Retrieved chunks | Real-time only | Sourced from persisted index |
+| Model response | Session or 30 days | May contain echoed PII |
+| Tool call I/O | Per integration policy | May include PII as parameters |
+| Traces / telemetry | 30-90 days | Redact PII or aggregate |
+| Eval samples | Duration of eval set lifecycle | Refreshed and aged out |
+| Fine-tune corpus | Model lifetime | Erasure = retrain or unlearn |
+| Embeddings index | Until source is deleted | Deletion must cascade |
+
+## 7. Residency and transfer
+
+- Choose model deployment region to match data-subject region.
+- Confirm sub-processor (model provider) processing occurs in declared region.
+- SCCs required for transfers outside EEA unless adequacy decision applies.
+- Watch for "global endpoints" that silently route to other regions.
+- Embedding-generation and reranking calls may route differently than chat completions.
+
+## 8. Sub-processors
+
+- Model providers (Azure OpenAI, Anthropic, Google) are sub-processors.
+- Vector DB providers (if managed SaaS) are sub-processors.
+- Observability platforms (if prompts flow through) are sub-processors.
+- Confirm DPA coverage, breach notice SLA, and sub-processor change notification for each.
+
+## 9. Data subject rights in AI pipelines
+
+| Right | AI-specific challenge | Design approach |
+|---|---|---|
+| Access | What data does the AI hold about me? | Trace retrieval index + logs for subject ID |
+| Erasure | Delete from prompts, indexes, evals, fine-tunes | Cascade deletion; embedding reindex; retrain if fine-tuned |
+| Portability | Export structured personal data the AI holds | Export from retrieval store; logs are typically not portable |
+| Objection | Opt out of AI processing | Feature flag / routing to non-AI path |
+| Restriction | Continue storing but stop processing | Quarantine in index; exclude from retrieval |
+| Not subject to automated decision | AI makes no solely automated decision with legal effect | Ensure HITL for consequential decisions |
+
+## 10. Common mistakes
+
+- Treating the model provider tier as a full privacy solution. Enterprise tier excludes training, not processing.
+- Assuming logs are not personal data. If prompts carry PII, logs carry PII.
+- Forgetting that embeddings are derived personal data and erasure must cascade.
+- Running evals on production data without a separate privacy basis.
+- Not disclosing AI processing to data subjects when the AI touches their data.

package/.github/skills/privacy-by-design-for-ai/references/privacy-control-catalog.md

@@ -0,0 +1,53 @@
+# Privacy Control Catalog
+
+## Lawful basis (GDPR Art. 6)
+- Consent — explicit, granular, revocable.
+- Contract — necessary for service.
+- Legal obligation.
+- Vital interests.
+- Public task.
+- Legitimate interest — requires balancing test (LIA).
+
+For special category data (Art. 9), one of nine additional conditions also required.
+
+## Data flows to enumerate
+- User input → prompt
+- Retrieval corpus → context
+- Tool I/O → both directions
+- Model provider → training data exclusion?
+- Output → user, downstream systems
+- Traces, logs, eval datasets, memory stores
+
+## Controls per flow
+- Minimization — collect only what is needed; drop fields per layer.
+- Purpose limitation — document the purpose; reject reuse without re-basis.
+- Retention — typed retention per data class; auto-purge.
+- Redaction — at ingest, not after; PII regex + classifier.
+- Pseudonymization — hash IDs in logs; reversible only via audited break-glass.
+- Encryption — in transit and at rest; CMK/BYOK where supported.
+- Residency — region pinning; sub-processor inventory; transfer mechanism (SCCs / IDTAs).
+- Sub-processor management — DPA, audit, breach notification SLA.
+- Training-data exclusion — confirm provider does not train on tenant data; capture in writing.
+- Consent surface — for personalization, secondary purposes, recording.
+- Rights — access, rectification, erasure, portability; cascade to embeddings, summaries, memory.
+
+## Special considerations
+- Children's data: COPPA, GDPR Art. 8.
+- HR data: works council / co-determination in EU.
+- Health: HIPAA / GDPR Art. 9.
+- Cross-border: SCCs, IDTAs, adequacy.
+- Schrems II: re-evaluate US data flows; BYOK + region.
+- UK: UK GDPR + DPA 2018 + IDTA.
+- US state laws: CPRA, VCDPA, CTDPA, CPA, UCPA, etc. — opt-out for sale/share/profile.
+- China PIPL: explicit consent, data localization considerations.
+
+## Frameworks to align with
+- ICO DPIA template, CNIL PIA, ENISA AI guidance, NIST Privacy Framework, ISO 27701.
+
+## Reuse and training data exclusion (LLM-specific)
+- Confirm vendor opt-out: Azure OpenAI default no-training; OpenAI API enterprise; Anthropic enterprise; AWS Bedrock; Vertex.
+- Document via vendor DPA + product page reference + tenant config screenshot.
+
+## Eval and red-team data
+- De-identify production samples before they enter eval set.
+- Treat synthetic data as PII-free only after audit.

package/.github/skills/privacy-by-design-for-ai/templates/dpia-template.md

@@ -0,0 +1,66 @@
+# Privacy DPIA — `<system>`
+
+## 1. Description
+- Use case:
+- Data subjects (employees, customers, patients, minors):
+- Volume:
+
+## 2. Data flows
+| Flow | Personal data | Special category? | Source | Destination | Lawful basis | Purpose |
+|---|---|---|---|---|---|---|
+| Prompt | | | | | | |
+| Retrieval | | | | | | |
+| Tool I/O | | | | | | |
+| Model call | | | | | | |
+| Output | | | | | | |
+| Traces / logs | | | | | | |
+| Memory | | | | | | |
+| Eval set | | | | | | |
+
+## 3. Lawful basis and conditions
+- Per category, lawful basis named.
+- Special category condition (if any).
+- Legitimate-interest balancing test attached if used.
+
+## 4. Minimization and purpose
+- Fields collected and rationale.
+- Fields dropped at each layer.
+- Purposes; secondary use restrictions.
+
+## 5. Retention
+| Data | Class | Retention | Disposal |
+|---|---|---|---|
+
+## 6. Redaction and pseudonymization
+- At ingest:
+- In logs:
+- In memory writes:
+- In eval set creation:
+
+## 7. Residency, transfers, sub-processors
+- Regions:
+- Transfer mechanism:
+- Sub-processor inventory link:
+- Vendor DPAs:
+
+## 8. Training-data exclusion
+- Vendor:
+- Mechanism (default, opt-out, contract):
+- Evidence:
+
+## 9. Rights fulfillment
+- Access path:
+- Rectification:
+- Erasure cascade (corpus, embeddings, memory, traces, eval):
+- Portability:
+- Restriction / objection:
+
+## 10. Risks and mitigations
+| Risk | Likelihood | Severity | Mitigation | Owner |
+|---|---|---|---|---|
+
+## 11. Sign-off
+- DPO:
+- Engineering owner:
+- Sponsor:
+- Date:

package/.github/skills/privacy-by-design-for-ai/templates/privacy-by-design-template.md

@@ -0,0 +1,89 @@
+# Privacy by Design Assessment: <Use Case>
+
+**Owner:** <name>
+**Date:** <YYYY-MM-DD>
+**Status:** Draft / DPO reviewed / Legal signed-off
+**Disclaimer:** This is a structured privacy review, not a legal opinion. Recommend DPO and legal sign-off.
+
+## Executive summary
+
+- Residual risk posture: Low / Medium / High.
+- Top three privacy gaps.
+- Must-do actions before launch.
+
+## System description and AI data-flow map
+
+```mermaid
+flowchart LR
+    User -->|prompt| Agent
+    Agent -->|query| VectorDB[(RAG Index)]
+    VectorDB -->|chunks| Agent
+    Agent -->|API call| Model[Model Provider]
+    Model -->|response| Agent
+    Agent -->|tool call| System[(Backend)]
+    Agent -->|output| User
+    Agent -->|traces| Logs[(Observability)]
+```
+
+## Processing activities
+
+| # | Activity | Data subjects | Personal data categories | Lawful basis | Retention | Residency |
+|---|---|---|---|---|---|---|
+| 1 | Prompt processing | | | | | |
+| 2 | RAG retrieval | | | | | |
+| 3 | Model inference | | | | | |
+| 4 | Tool I/O | | | | | |
+| 5 | Output delivery | | | | | |
+| 6 | Logging / tracing | | | | | |
+| 7 | Eval sampling | | | | | |
+
+## Necessity and proportionality
+
+- Is AI processing necessary for the purpose? <yes/no, rationale>
+- Is there a less-invasive alternative? <considered and rejected because...>
+- Does the prompt include minimum required personal data? <yes/no, gaps>
+
+## Data minimization analysis
+
+| Flow | Current state | Minimization action | Status |
+|---|---|---|---|
+| Prompts | | redact / mask / scope | |
+| Retrieved chunks | | filter / scope | |
+| Logs | | redact / hash / sample | |
+| Eval datasets | | anonymize / subset | |
+
+## Sub-processor register
+
+| Sub-processor | Role | DPA in place | Breach notice SLA | Residency | Training exclusion confirmed |
+|---|---|---|---|---|---|
+| | Model provider | | | | |
+| | Vector DB | | | | |
+| | Observability | | | | |
+
+## Data subject rights fulfillment
+
+| Right | Mechanism | Complexity | Status |
+|---|---|---|---|
+| Access | | | |
+| Erasure | | | |
+| Portability | | | |
+| Objection / opt-out | | | |
+| Restriction | | | |
+| Not subject to automated decision | | | |
+
+## Risk register
+
+| # | Risk | Likelihood | Impact | Residual risk | Mitigation | Owner |
+|---|---|---|---|---|---|---|
+| 1 | | H/M/L | H/M/L | H/M/L | | |
+
+## Recommended sign-offs
+
+- DPO: <required / recommended / N/A>
+- Legal: <required / recommended>
+- Security: <required / recommended>
+- Supervisory authority consultation: <required if high residual risk / not required>
+
+## Open questions
+
+- <question> — <owner> — <by date>