578 lines
18 KiB
Markdown
578 lines
18 KiB
Markdown
# CE EU AI-Cloud Sovereignty Policy — Handoff for Claude Code
|
|
|
|
**Version:** 1.0
|
|
**Date:** 2026-06-27
|
|
**Scope:** Cervello Elettrico (CE) commitment to EU AI and Cloud sovereignty through voluntary regulatory contribution
|
|
**For:** Claude Code @workbench — all infrastructure, deployment, and documentation work
|
|
|
|
---
|
|
|
|
## I. CORE COMMITMENT
|
|
|
|
CE operates under a **community service mandate** to strengthen EU AI-Cloud sovereignty. This is not a marketing position or regulatory compliance checkbox. It is a **foundational design principle** that shapes every system we build.
|
|
|
|
**Core Statement:**
|
|
|
|
> We are not vendors trying to minimize compliance cost. We are practitioner-researchers demonstrating how local AI, privacy-first infrastructure, and sovereign computing serve EU citizens and SMEs. Every technical decision is made with the knowledge that it will inform EU policy and provide evidence for better regulation.
|
|
|
|
**Practical meaning:** Contribution is **built into systems**, not taped on post-deployment.
|
|
|
|
---
|
|
|
|
## II. THE POLICY FRAMEWORK
|
|
|
|
### A. Three Commitments
|
|
|
|
1. **Letter AND Spirit of Regulation**
|
|
- Exceed minimum compliance
|
|
- Anticipate stricter future requirements
|
|
- Log more than legally required today
|
|
|
|
2. **Forward-Thinking Compliance**
|
|
- Build for the regulation coming, not just the one we have
|
|
- Establish audit trails now (years of history before auditors ask)
|
|
- Design flexibility to adapt to unknown future rules
|
|
|
|
3. **Voluntary Contribution to EU Policymakers**
|
|
- Submit evidence and recommendations to EU Commission
|
|
- Publish findings (Codeberg/public repos)
|
|
- Participate in stakeholder consultations
|
|
- Build regulatory-ready documentation at each phase
|
|
|
|
### B. Guiding Principle: Sovereignty ≠ Isolation
|
|
|
|
Local AI deployment means:
|
|
- **Private by design** (data stays on-premises or Aruba/EU only)
|
|
- **Transparent by design** (full audit trail, nothing hidden)
|
|
- **Auditable by design** (regulators can inspect exactly how it works)
|
|
- **Economically viable** (SME-affordable, not enterprise-only)
|
|
|
|
---
|
|
|
|
## III. TECHNICAL ARCHITECTURE FOR CONTRIBUTION
|
|
|
|
### A. Logging Standard (Exceeds Legal Minimum)
|
|
|
|
All deployments must use this logging structure. Logs are designed to answer regulatory questions, not just operational ones.
|
|
|
|
#### Inference Logging (`/srv/ai-logs/inference/`)
|
|
|
|
**Format:** JSONL (one JSON object per line), machine + human readable
|
|
|
|
```json
|
|
{
|
|
"timestamp": "2026-06-27T14:22:33Z",
|
|
"request_id": "req-abc123def456",
|
|
|
|
"model_info": {
|
|
"name": "mistral:7b",
|
|
"version": "Q4_K_M",
|
|
"quantization": "Q4_K_M",
|
|
"source": "ollama",
|
|
"local_endpoint": "http://localhost:11434"
|
|
},
|
|
|
|
"inference": {
|
|
"input_tokens": 142,
|
|
"output_tokens": 87,
|
|
"temperature": 0.7,
|
|
"top_p": 0.95,
|
|
"inference_time_ms": 1840
|
|
},
|
|
|
|
"safety_filtering": {
|
|
"filter_applied": "content_policy_v1",
|
|
"filter_triggered": false,
|
|
"rejected_reason": null,
|
|
"confidence_score": 0.89
|
|
},
|
|
|
|
"system_state": {
|
|
"gpu_utilization_percent": 94,
|
|
"gpu_memory_mb": 8192,
|
|
"gpu_temp_celsius": 68,
|
|
"gpu_power_watts": 165,
|
|
"cpu_utilization_percent": 22,
|
|
"ambient_temp_celsius": 34
|
|
},
|
|
|
|
"data_provenance": {
|
|
"input_source": "user_query",
|
|
"input_language": "it",
|
|
"training_data_used": false,
|
|
"user_pii_present": false,
|
|
"model_trained_on_public_data": true
|
|
},
|
|
|
|
"regulatory_context": {
|
|
"eu_ai_act_category": "general_purpose_ai",
|
|
"nist_ai_impact_level": "moderate",
|
|
"data_lineage_preserved": true,
|
|
"audit_trail_intact": true
|
|
}
|
|
}
|
|
```
|
|
|
|
**Why these fields:**
|
|
- `inference_time_ms` + `gpu_power_watts` = efficiency data (for environmental regs)
|
|
- `safety_filtering` = demonstrates responsible deployment (AI Act Article 50)
|
|
- `data_provenance` = proves we're not using private/training data (AI Act transparency)
|
|
- `regulatory_context` = shows we understand classification framework
|
|
|
|
**Retention:** Keep daily logs for 5 years minimum. Archive older logs but never delete.
|
|
|
|
#### System Health Logging (`/srv/ai-logs/system-health/`)
|
|
|
|
```json
|
|
{
|
|
"timestamp": "2026-06-27T14:00:00Z",
|
|
"hostname": "bigboy",
|
|
"uptime_seconds": 864000,
|
|
|
|
"thermal": {
|
|
"gpu_temp_celsius": 68,
|
|
"gpu_max_temp_celsius": 71,
|
|
"cpu_temp_celsius": 52,
|
|
"ambient_celsius": 34,
|
|
"throttling_event": false
|
|
},
|
|
|
|
"power": {
|
|
"total_system_watts": 185,
|
|
"gpu_power_watts": 165,
|
|
"cpu_power_watts": 20,
|
|
"daily_energy_kwh": 4.44
|
|
},
|
|
|
|
"inference_rate": {
|
|
"inferences_per_hour": 42,
|
|
"avg_queue_depth": 1.2,
|
|
"avg_latency_ms": 1840,
|
|
"error_rate_percent": 0.0
|
|
},
|
|
|
|
"storage": {
|
|
"root_used_percent": 45,
|
|
"rag_library_used_percent": 38,
|
|
"logs_used_percent": 22,
|
|
"backup_health": "good"
|
|
},
|
|
|
|
"regulatory_notes": "System operating within safe thermal envelope. No throttling detected. All metrics nominal."
|
|
}
|
|
```
|
|
|
|
#### Safety Decision Logging (`/srv/ai-logs/safety-decisions/`)
|
|
|
|
```json
|
|
{
|
|
"timestamp": "2026-06-27T14:22:33Z",
|
|
"decision_type": "content_filter_activation",
|
|
"severity": "info",
|
|
|
|
"context": {
|
|
"model": "mistral:7b",
|
|
"request_id": "req-abc123def456",
|
|
"input_language": "it"
|
|
},
|
|
|
|
"filter": {
|
|
"name": "content_policy_v1",
|
|
"category_detected": "potential_harm",
|
|
"confidence_percent": 65,
|
|
"action_taken": "flagged_for_human_review"
|
|
},
|
|
|
|
"evidence": {
|
|
"triggering_tokens": ["harmful", "instruction"],
|
|
"full_input_hash": "sha256:abc...",
|
|
"model_output_hash": "sha256:xyz..."
|
|
},
|
|
|
|
"regulatory_relevance": {
|
|
"ai_act_article": "35",
|
|
"demonstrates": "adequate_safety_measures",
|
|
"shows_responsible_deployment": true
|
|
}
|
|
}
|
|
```
|
|
|
|
---
|
|
|
|
### B. Documentation Standard (Built for Policy Input)
|
|
|
|
**Every major technical work produces TWO documents:**
|
|
|
|
#### 1. Technical Documentation
|
|
- **Audience:** Engineers, future maintainers, CE team
|
|
- **Content:** "Here's what we did and how it works"
|
|
- **Format:** Markdown, code examples, step-by-step
|
|
- **File:** `phase-N-technical.md`
|
|
|
|
#### 2. Regulatory Notes Document
|
|
- **Audience:** EU regulators, researchers, policy makers
|
|
- **Content:** "Here's what this means for policy and sovereignty"
|
|
- **Format:** Clear language, specific evidence, policy implications
|
|
- **File:** `phase-N-regulatory-notes.md`
|
|
|
|
**Example Structure (Phase 4: GPU Driver):**
|
|
|
|
**Technical:**
|
|
```markdown
|
|
# Phase 4: NVIDIA GPU Driver Installation
|
|
|
|
## Hardware
|
|
- GPU: ASUS Dual RTX 5060 Ti OC 16GB (Blackwell sm_120)
|
|
- Driver requirement: 555.42+
|
|
- Kernel: 6.12.0-211.7.3.el10_2 (AlmaLinux 10.2)
|
|
|
|
## Steps
|
|
1. Verify BIOS Secure Boot OFF
|
|
2. Install nvidia-driver-555
|
|
3. Verify with nvidia-smi
|
|
4. Test with ollama
|
|
```
|
|
|
|
**Regulatory Notes:**
|
|
```markdown
|
|
# Phase 4: GPU Deployment — Policy Implications
|
|
|
|
## Why Blackwell Hardware Matters for EU Sovereignty
|
|
- Blackwell (sm_120) is newest architecture as of June 2026
|
|
- Older GPUs (RTX 3090, RTX 4090) cannot run latest models efficiently
|
|
- Hardware refresh cycle: 3-4 years for SMEs running current AI
|
|
|
|
## Policy Finding: Hardware Cost is the Real Barrier
|
|
If EU mandates local AI for SME compliance:
|
|
- **Not software cost** (Ollama, AlmaLinux, Open WebUI all free/open)
|
|
- **Hardware amortization** is the blocker
|
|
- RTX 5060 Ti 16GB @ €280 is affordable; A100 @ €15K is not
|
|
|
|
## Recommendation to EU Policymakers
|
|
1. Consider device trade-in programs for AI hardware
|
|
2. Support refurbished GPU tier (RTX 4090, RTX 5090) for budget SMEs
|
|
3. Require drivers to remain available for 5+ years (currently NVIDIA: 3 years max)
|
|
|
|
## Evidence Generated
|
|
- Driver compatibility matrix: which GPUs work with which kernels
|
|
- Thermal efficiency data: Blackwell power consumption vs. RTX 3090
|
|
- Cost-to-TFLOPS ratio: quantified hardware budget reality for SMEs
|
|
```
|
|
|
|
---
|
|
|
|
### C. Public Repository Structure (Sovereignty-Ready)
|
|
|
|
**Repository:** `ceos/bigboy-regulatory-contribution` (public)
|
|
|
|
```
|
|
bigboy-regulatory-contribution/
|
|
├── README.md
|
|
│ # "We deployed local AI in Brianza.
|
|
│ # Here's how. Here's what we learned."
|
|
│
|
|
├── CONTRIBUTION-STATEMENT.md
|
|
│ # "We're sharing this because EU policy needs
|
|
│ # evidence from practitioners, not just vendors."
|
|
│
|
|
├── phases/
|
|
│ ├── phase-04-gpu-driver/
|
|
│ │ ├── technical.md
|
|
│ │ ├── regulatory-notes.md
|
|
│ │ └── evidence/
|
|
│ │ ├── driver-compatibility-matrix.csv
|
|
│ │ ├── thermal-efficiency-data.json
|
|
│ │ └── cost-analysis.md
|
|
│ │
|
|
│ ├── phase-11-thermal-baseline/
|
|
│ │ ├── technical.md
|
|
│ │ ├── regulatory-notes.md
|
|
│ │ └── evidence/
|
|
│ │ ├── baseline-metrics.csv
|
|
│ │ ├── efficiency-analysis.md
|
|
│ │ └── environmental-impact.md
|
|
│ │
|
|
│ └── phase-14-observation/
|
|
│ ├── technical.md
|
|
│ ├── regulatory-notes.md
|
|
│ └── evidence/
|
|
│ ├── operational-metrics.csv
|
|
│ ├── safety-filter-analysis.md
|
|
│ ├── incident-log-analysis.md
|
|
│ └── policy-recommendations.md
|
|
│
|
|
├── EU-SUBMISSION/
|
|
│ ├── ai-office-submission.md
|
|
│ │ # Formal input to EU AI Office
|
|
│ ├── anssi-security-input.md
|
|
│ │ # NIS2 & cybersecurity evidence
|
|
│ └── agid-italy-submission.md
|
|
│ # Italian digital agency
|
|
│
|
|
└── LICENSE.md
|
|
# "This work is public domain (CC0).
|
|
# EU policymakers may use it freely."
|
|
```
|
|
|
|
**All PII/credentials/internal IPs removed. Everything else public.**
|
|
|
|
---
|
|
|
|
## IV. CONTRIBUTION WORKFLOW (BUILT INTO PHASE 14)
|
|
|
|
### A. Timeline
|
|
|
|
| Week | Task | Output |
|
|
|------|------|--------|
|
|
| **W1** | Data collection & metric generation | Raw CSVs, logs, system state snapshots |
|
|
| **W2** | Preliminary analysis | Trend graphs, anomaly reports, incident summary |
|
|
| **W3** | Draft regulatory input | Policy-notes documents, recommendations |
|
|
| **W4** | Submit & publish | Formal EU submissions + Codeberg push |
|
|
|
|
### B. Submission Targets (Formal & Official)
|
|
|
|
1. **AI Office** → https://ai-act-service-desk.ec.europa.eu/
|
|
- Subject: "SME Local AI Deployment Case Study: Evidence for AI Act Implementation"
|
|
- Attach: phase-14-observation regulatory-notes.md + metrics
|
|
|
|
2. **ANSSI (Italy)** → Cybersecurity feedback
|
|
- Contact: Via ACN (Italy's competent authority)
|
|
- Subject: "NIS2 Compliance Evidence: Local AI Deployment"
|
|
- Attach: Security posture, incident logs
|
|
|
|
3. **Agenzie per l'Italia Digitale (AgID)** → Digital transformation input
|
|
- Subject: "Case Study: Sovereign Local AI for Italian SMEs"
|
|
- Attach: Full deployment narrative, cost analysis
|
|
|
|
4. **Codeberg Public Repo** → Open access to researchers & policy community
|
|
- Push all technical + regulatory documentation
|
|
- Tag with `policy-input`, `eu-ai-act`, `nis2`, `sovereignty`
|
|
|
|
### C. Documentation Requirements for Each Submission
|
|
|
|
**For AI Office:**
|
|
```
|
|
├── Executive Summary (1 page)
|
|
├── Technical Overview (2-3 pages)
|
|
├── Regulatory Evidence (metrics, logs, analysis)
|
|
├── Policy Recommendations (specific to AI Act implementation)
|
|
└── Contact Info (john@cervelloelettrico.it)
|
|
```
|
|
|
|
**For ANSSI:**
|
|
```
|
|
├── Security Posture Summary
|
|
├── Incident Analysis (if any)
|
|
├── Compliance with NIS2 Article 21 measures
|
|
├── Risk Assessment Results
|
|
└── Recommendations for cloud provider security standards
|
|
```
|
|
|
|
**For Public Codeberg:**
|
|
```
|
|
├── Full technical documentation
|
|
├── Regulatory notes (all phases)
|
|
├── Raw data (metrics, logs, evidence)
|
|
├── Discussion of findings
|
|
└── Invitation for others to contribute similar case studies
|
|
```
|
|
|
|
---
|
|
|
|
## V. DECISION-MAKING FRAMEWORK (FOR CODE)
|
|
|
|
When working on any CE infrastructure or deployment decision, apply this framework:
|
|
|
|
### Question 1: Does this serve EU sovereignty?
|
|
- **Yes** → Consider it
|
|
- **No** → Reconsider or reject
|
|
- **Unknown** → Research, consult with John
|
|
|
|
### Question 2: Can we document and share this learning?
|
|
- **Yes** → Proceed; build logging/docs alongside code
|
|
- **No** → Simplify or redesign until shareable
|
|
- **Constraint** → If it can't be documented for regulators, question its necessity
|
|
|
|
### Question 3: Does this anticipate future regulation?
|
|
- **Yes** → Prioritize; log more than necessary
|
|
- **Somewhat** → Proceed with extra logging
|
|
- **No** → Still proceed, but don't add speculative logging
|
|
|
|
### Question 4: Will this become evidence?
|
|
- **Yes** → Make it reproducible, measurable, auditable
|
|
- **Maybe** → Log it anyway
|
|
- **No** → Still track it operationally, but lower priority on regulatory evidence
|
|
|
|
---
|
|
|
|
## VI. OPERATIONAL PRINCIPLES
|
|
|
|
### A. Logging is Not Optional
|
|
|
|
Every system (jahnet, BigBoy, Pi fleet, N100) produces structured logs at the rates shown above. This is as important as backups.
|
|
|
|
### B. Documentation Happens During Work, Not After
|
|
|
|
When coding Phase N:
|
|
- Write technical docs as you code (parallel, not sequential)
|
|
- Draft regulatory notes as you discover findings
|
|
- Don't wait for Phase 14 to decide what's policy-relevant
|
|
|
|
### C. Public Repos Are Contribution Channels, Not PR
|
|
|
|
Do not:
|
|
- Sanitize language to "look good"
|
|
- Omit negative findings ("this didn't work")
|
|
- Hide uncertainties
|
|
|
|
Do:
|
|
- Be honest about what succeeded and what failed
|
|
- Explain why choices were made
|
|
- Show the evidence clearly
|
|
- Recommend policy changes based on real constraints
|
|
|
|
### D. Contribution Doesn't Wait for Perfection
|
|
|
|
If Phase 11 reveals something unexpected (high thermal spike, filter false positives), document it immediately. Regulators learn from real problems, not polished case studies.
|
|
|
|
---
|
|
|
|
## VII. INTEGRATION WITH BIGBOY DEPLOYMENT
|
|
|
|
### Phase 0: Foundation
|
|
- ✓ Logging architecture (see Section III.A)
|
|
- ✓ Repository structure (see Section III.C)
|
|
- ✓ Documentation template (see Section III.B)
|
|
|
|
### Phases 1-13: Build with Contribution in Mind
|
|
- Each phase produces: technical.md + regulatory-notes.md
|
|
- Logs are structured per Section III.A standards
|
|
- Every decision is logged (not just errors)
|
|
|
|
### Phase 14: Observation + Submission
|
|
- Week 1-2: Collect metrics per Section III.A
|
|
- Week 3: Draft regulatory input per Section IV
|
|
- Week 4: Submit to targets per Section IV.B
|
|
|
|
### Post-Deployment: Sustained Contribution
|
|
- Monthly: Review logs for policy-relevant findings
|
|
- Quarterly: Publish updates to Codeberg
|
|
- As regulations evolve: Add new logging fields, document how we adapted
|
|
|
|
---
|
|
|
|
## VIII. WHAT CODE SHOULD KNOW
|
|
|
|
1. **You are not building a product. You are demonstrating a capability.**
|
|
- Every line of code is potential evidence for policy
|
|
- Logging is as important as functionality
|
|
|
|
2. **Simplicity is better than cleverness.**
|
|
- If a choice makes logs harder to understand, don't do it
|
|
- If it can't be documented for regulators, reconsider it
|
|
|
|
3. **Transparency is the default.**
|
|
- Assume everything (technical docs + logs) will be public
|
|
- No "internal notes" hidden from regulators
|
|
- Even failed experiments are valuable evidence
|
|
|
|
4. **John (the OHIOD) makes final calls.**
|
|
- Code surfaces options, evidence, recommendations
|
|
- John decides direction, guided by this policy
|
|
- Contribution framework is non-negotiable; implementation details are flexible
|
|
|
|
5. **This isn't extra work. It's the work.**
|
|
- Building without contribution is incomplete
|
|
- Logging is operational necessity, not compliance overhead
|
|
- Documentation is design input, not bureaucracy
|
|
|
|
---
|
|
|
|
## IX. SUCCESS METRICS (FOR THIS POLICY)
|
|
|
|
**Not measured by:**
|
|
- How fast deployment happens
|
|
- How many features are implemented
|
|
- How low costs are
|
|
|
|
**Measured by:**
|
|
- **Audit trail completeness** — Can a regulator trace every decision?
|
|
- **Documentation quality** — Can policy researchers understand our approach?
|
|
- **Contribution impact** — Did our evidence influence EU guidance?
|
|
- **Reproducibility** — Can another SME build the same system using our docs?
|
|
- **Honesty** — Did we document failures as clearly as successes?
|
|
|
|
---
|
|
|
|
## X. CODEBERG PUBLICATION STANDARDS
|
|
|
|
When pushing to `ceos/bigboy-regulatory-contribution`:
|
|
|
|
1. **No credentials, PIIs, or internal IPs**
|
|
- Generic hostnames: `hostname` not `bigboy`
|
|
- Generic IPs: `192.168.X.X` not `192.168.0.240`
|
|
- No API keys, SSH keys, or secrets
|
|
|
|
2. **All technical details public**
|
|
- Kernel versions, driver choices, hardware specs ✓
|
|
- Thermal baselines, power consumption, inference latency ✓
|
|
- Cost analysis, ROI calculations ✓
|
|
- "Secret sauce" that's proprietary? Don't include it (not relevant to policy anyway)
|
|
|
|
3. **Licensing: CC0 (Public Domain)**
|
|
- EU policymakers may use freely
|
|
- Other SMEs may fork and adapt
|
|
- No attribution required (though welcome)
|
|
|
|
4. **Invitation to Community**
|
|
```markdown
|
|
# Contributing Similar Case Studies
|
|
|
|
If you've deployed local AI in your region, please contribute:
|
|
- Your technical documentation
|
|
- Your regulatory notes
|
|
- Your evidence and metrics
|
|
|
|
This repository is for practitioners sharing real experience
|
|
with EU policymakers. The more voices, the better the policy.
|
|
```
|
|
|
|
---
|
|
|
|
## XI. CONTACT & ESCALATION
|
|
|
|
**For Code guidance on policy questions:**
|
|
- Unclear if something is contribution-worthy? Ask John
|
|
- Uncertain how to log something? Reference Section III.A or ask
|
|
- Not sure if a design choice serves sovereignty? Escalate to John
|
|
|
|
**For formal submission decisions:**
|
|
- John makes all final calls on what/when/how to submit to EU
|
|
- Code drafts recommendations; John decides
|
|
|
|
---
|
|
|
|
## XII. VERSION HISTORY
|
|
|
|
| Version | Date | Changes |
|
|
|---------|------|---------|
|
|
| 1.0 | 2026-06-27 | Initial handoff document, BigBoy-focused, ready for Phase 1 implementation |
|
|
|
|
---
|
|
|
|
## XIII. CLOSING STATEMENT
|
|
|
|
This policy exists because **CE believes EU AI-Cloud sovereignty is a public good, and practitioners have a responsibility to strengthen it.**
|
|
|
|
We are not trying to influence policy for profit. We are trying to influence policy because it matters, and we have evidence that regulators need to see.
|
|
|
|
Every line of code, every log entry, every documented decision is a contribution to something larger than BigBoy. It's a contribution to the European project of building technology that serves people, not platforms.
|
|
|
|
That's the commitment this handoff document represents.
|
|
|
|
---
|
|
|
|
**Prepared by:** John A. Hoeven, Cervello Elettrico
|
|
**For:** Claude Code @workbench, all future deployments
|
|
**Scope:** CE infrastructure, BigBoy primary case study, scalable to all CE systems
|
|
**Status:** Active policy framework, not provisional
|