Definizione di GPAI secondo l'AI Act

L'Articolo 3 dell'AI Act definisce un modello General Purpose AI come:

• Capace di eseguire output generativo: crea testo, immagini, audio, codice, dati nuovi
• Funziona per un vasto range di task: non specializzato in un singolo dominio; può essere adattato a downstream task distinti
• Può essere utilizzato da downstream provider: il provider GPAI non è l'utilizzatore finale (es. Meta distribuisce LLaMA; Ollama distribuisce modelli open-source)

Modelli che rientrano in GPAI: LLM come LLaMA 3.1, Llama 2, Mistral, Qwen (ma NON modelli chiusi come alcuni provider commerciali); modelli vision come CLIP, DINOv2; modelli multimodali. Modelli NON GPAI: task-specific classifier (sentiment analysis addestrato su dataset singolo), modelli di forecasting specializzati, small language models ≤1B parametri (sconsigliato ma non obbligatorio).

Obblighi tecnici per i provider GPAI

Se sei un provider GPAI (ossia distribuisci il modello ad altri), devi rispettare 5 categorie di obblighi:

1. Documentazione tecnica completa

Devi mantenere e fornire documentazione che descriva:

• Capacità e limitazioni del modello (accuracy, benchmark pubblici)
• Dati di addestramento (fonti, dimensione, lingue, bias noti)
• Architettura e training procedures
• Threshold di rifiuto (quando il modello non risponde, se implementato)
• Meccanismi di testing e monitoring
• Guida per l'utilizzo responsabile

Questa documentazione deve essere mantenuta per tutta la durata del ciclo di vita del modello e resa disponibile a autorità di supervisione previa richiesta.

2. Risk assessment e mitigation

Prima di qualsiasi deployment o major release, devi eseguire un risk assessment formale che identifichi:

• Rischi di sicurezza: jailbreak, prompt injection, evasione di safety measures
• Rischi di bias: discriminazione verso gruppi protetti, sterotipizzazione
• Rischi di privacy: data leakage, memorizzazione di PII nei parametri
• Rischi di abuso: uso per deepfake, spam, disinformazione
• Rischi di environmental impact: consumo energetico dell'addestramento

Per ogni rischio, devi documentare la probabilità, la severità, e le contromisure implementate. Non basta dire "rischio identified"; devi dimostrare azione concreta (es. red-teaming, fine-tuning su safety, testing ricorsivo).

3. Transparency e notifiche

Devi:

• Comunicare chiaramente quando un output è generato da AI GPAI
• Notificare immediatamente le autorità di qualsiasi incidente di sicurezza grave (es. jailbreak massivo, data breach)
• Mantenere un modello card pubblico (formato standard) con metadata chiave
• Fornire API per il content flagging (ove applicabile, es. CSAM detection)

La trasparenza non significa "dire che è un LLM"; significa descrivere funzionalità, limitazioni, e rischi in modo verificabile.

4. Testing e monitoring continuativo

Devi implementare:

• Pre-deployment testing: benchmark su safety, bias, jailbreak resistance (>1000 test case); red-teaming da provider terzi
• Monitoring runtime: tracciare metriche di utilizzo (es. % di prompt rifiutati, latency); anomaly detection
• Post-incident analysis: ogni abuse report va investigato, categorizzato, e usato per migliorare training
• Periodic re-evaluation: almeno annualmente, ri-eseguire risk assessment su dati nuovi

Monitorare non è opzionale; non puoi semplicemente rilasciare e sparire. Devi mantenere dashboard, alert, e team pronto a respond.

Conformità pratica: scenari comuni

Scenario 1: Ollama on-prem (provider di infrastruttura)

Se usi Ollama on-prem sul tuo VPS (es. llama3.1:8b), sei formalmente sia provider GPAI che user GPAI:

• Come provider: se distribuisci Ollama come tool a downstream users (es. clienti, team interno), devi rispettare gli obblighi di documentazione e risk assessment
• Come user: il modello base (llama3.1) è mantenuto da Meta/Ollama project; tu eri responsabile della deployment architecture, fallback strategy, e monitoring

In pratica: documenta la tua architettura Ollama, fai red-testing del modello, implementa fallback (es. degraded mode con risposta fixed se Ollama down), e traccia accessi/output per compliance audit.

Scenario 2: API esterna (downstream user/provider)

Se integri una API GPAI commerciale nel tuo servizio:

• Responsibility split: il provider API è responsabile del modello; tu sei responsabile della corretta integrazione, fallback, e disclosure agli end-user
• Tu devi: documentare quale GPAI usi, come la chiami, quali output dai all'utente, e come verifichi correttezza
• Liability: se l'API causa danno (es. discriminazione), entrambi (provider + downstream) potete essere ritenuti responsabili se il downstream (tu) non ha implementato mitigazioni

Nota: l'AI Act proibisce "downstream" abuse; se integri un GPAI in un servizio che ne vieta l'uso (es. generazione di deepfake), sei tu responsabile di enforcement.

Scenario 3: Fine-tuning e domain adaptation

Se fai fine-tuning di un GPAI su un dataset proprietario (es. fine-tuning LLaMA su dataset medico), diventi GPAI provider per quella variante:

• Devi ripetere risk assessment sul modello fine-tuned (il fine-tuning può introdurre bias nuovi)
• Devi documentare dataset di fine-tuning (fonte, filtering, quali PII rimossi)
• Devi monitorare il modello fine-tuned come se fosse "nuovo" (anche se di fatto è un'adattamento)

Roadmap obblighi 2026-2027

Cronologia delle scadenze secondo AI Act:

• 02 Feb 2025: AI Act entra in vigore (proibisce sistemi AI ad alto rischio, ma GPAI obblighi ancora non attivi)
• Q2 2025: EU pubblica linee guida dettagliate per GPAI compliance (European Commission)
• Q3 2025 - Q4 2026: Periodo di "soft enforcement": conformità incoraggiata ma non sanzionata; molte aziende avvieranno audit interno
• 01 Jan 2027: GPAI obblighi pienamente attivi; inizio enforcement da parte di autorità nazionali (AGCOM, CNIL, BfDI, ecc.)
• 2027-2028: Prime sanzioni su provider non conformi (probabile: precedenti amministrative, poi possibili sanzioni pecuniarie)

Azione consigliata: entro Q3 2026, completa il tuo risk assessment e documentazione. Non aspettare il 01 Jan 2027.

Rischi di non-conformità

Le sanzioni dell'AI Act sono severe:

• Violazione di obblighi GPAI: fino a 30 milioni EUR o 6% del fatturato globale annuale (scegli il massimo)
• Non disclosure di incidenti di sicurezza: fino a 20 milioni EUR o 4% fatturato
• Mancanza di risk assessment: fino a 40 milioni EUR o 8% fatturato (se categorizzato come "high-risk")
• Divieto di operare nell'EU: per recidivia grave, le autorità possono proibire il provider di operare in territorio UE

Oltre alle sanzioni, ci sono rischi reputazionali: media coverage di non-conformità, loss of customer trust, esclusione da tender pubblici.

Best practices di implementazione

1. Governance interna

Istituisci un "AI Governance Board" con responsabilità su:

• Approvazione di nuovi modelli GPAI (risk assessment sign-off)
• Incident response (breach, abuse report, anomaly detection)
• Audit periodici (almeno annuale) su compliance
• Training del team su AI safety e responsible use

2. Documentazione tecnica completa

Mantieni un "Model Card" per ogni GPAI che usi/distribuisci:

{
  "model_id": "llama3.1-8b",
  "provider": "Meta",
  "version": "3.1",
  "release_date": "2024-07-23",
  "capabilities": {
    "tasks": ["text-generation", "instruction-following", "summarization"],
    "languages": ["English", "Italian", "German", "French", "+70"],
    "max_input_tokens": 8192,
    "output_modality": "text"
  },
  "training": {
    "data_sources": "Public web data, research papers, code repositories",
    "training_compute": "~1-2M GPU-hours (estimated)",
    "fine_tuning": false,
    "known_limitations": [
      "Lack of real-time knowledge (training cutoff Sept 2024)",
      "Potential hallucinations on niche topics",
      "Bias toward English-centric perspectives"
    ]
  },
  "risk_assessment": {
    "last_updated": "2026-06-15T10:30:00Z",
    "security_score": 7.2,
    "bias_score": 5.8,
    "safety_measures": [
      "Post-training safety alignment",
      "Instruction following with refusal patterns",
      "Rate limiting (120 req/min per user)",
      "Content filtering for prohibited uses"
    ]
  },
  "monitoring": {
    "enabled": true,
    "metrics_tracked": ["response_latency", "error_rate", "abuse_reports", "user_satisfaction"],
    "incident_response_sla": "24 hours for critical, 72 hours for medium"
  }
}

3. Risk assessment e mitigation

Esegui red-teaming formale almeno una volta all'anno. Ecco un template di checklist:

# GPAI Risk Assessment Checklist

## Security Risks
- [ ] Tested jailbreak resistance (>100 known jailbreak techniques)
- [ ] Prompt injection vulnerability assessment
- [ ] Model inversion attack testing
- [ ] Denial of service (rate limiting, timeout configured)
- [ ] Data leakage from training set (memorization testing)

## Bias and Fairness
- [ ] Tested on demographic fairness benchmarks (BOLD, WinoBias)
- [ ] Assessed stereotyping risk (gender, race, religion)
- [ ] Reviewed for hate speech/discrimination potential
- [ ] Documented known limitations for protected groups

## Privacy
- [ ] Scanned training data for PII (SSN, email, phone)
- [ ] Tested for direct memorization of training examples
- [ ] Compliance with GDPR right-to-be-forgotten
- [ ] Data minimization: only necessary data retained

## Transparency
- [ ] Clear disclosure: "This is AI-generated"
- [ ] Limitations communicated to users
- [ ] Model card publicly available
- [ ] User can provide feedback on outputs

## Operational
- [ ] Fallback strategy documented (what if AI down?)
- [ ] Monitoring and alerting in production
- [ ] Incident response procedure documented
- [ ] Team trained on responsible use

4. Audit trail e logging

Mantieni un audit log completo di tutti gli accessi e output GPAI:

CREATE TABLE gpai_audit_log (
  id BIGINT PRIMARY KEY,
  timestamp TIMESTAMP NOT NULL,
  user_id VARCHAR(255) NOT NULL,
  model_id VARCHAR(255) NOT NULL,
  prompt_hash VARCHAR(64) NOT NULL,  -- Hash per privacy
  response_length INT NOT NULL,
  latency_ms INT NOT NULL,
  error_code VARCHAR(50),
  flagged_as_abuse BOOLEAN DEFAULT false,
  investigation_status VARCHAR(50),  -- null, open, resolved
  investigator_notes TEXT
);

CREATE INDEX idx_user_timestamp ON gpai_audit_log(user_id, timestamp);
CREATE INDEX idx_model_timestamp ON gpai_audit_log(model_id, timestamp);
CREATE INDEX idx_flagged ON gpai_audit_log(flagged_as_abuse, timestamp);

5. Training data provenance

Per ogni fine-tuning o domain adaptation, documenta la provenienza dei dati:

{
  "fine_tuning_session": {
    "id": "ft_20260614_001",
    "base_model": "llama3.1-8b",
    "training_data": {
      "source": "Internal support tickets 2024-2025",
      "num_examples": 5000,
      "preprocessing": [
        "Removed PII (emails, phone numbers)",
        "Anonymized customer names",
        "Filtered offensive language",
        "Removed duplicate conversations"
      ],
      "distribution": {
        "bug_reports": 45,
        "feature_requests": 30,
        "billing_inquiries": 15,
        "other": 10
      }
    },
    "quality_checks": [
      {
        "check": "PII detection",
        "passed": 4992,
        "failed": 8,
        "resolution": "Manually reviewed and redacted"
      },
      {
        "check": "Bias assessment",
        "metric": "Demographic parity difference",
        "threshold": 0.1,
        "result": 0.06,
        "status": "PASS"
      }
    ]
  }
}

6. Fallback strategy

Implementa un failover esplicito se il GPAI non è disponibile:

class GPAIService:
    def __init__(self, ollama_url, fallback_response):
        self.ollama_url = ollama_url
        self.fallback_response = fallback_response
        self.health_check_interval = 30  # seconds
        self.max_retries = 3

    def query_with_fallback(self, prompt, user_id):
        try:
            # Check service health
            if not self.is_healthy():
                return self.fallback_response, "FALLBACK_DEGRADED_MODE"

            # Primary: Ollama local
            response = self.query_ollama(prompt)
            return response, "SUCCESS"

        except TimeoutError:
            # Log incident for compliance audit
            self.log_incident("TIMEOUT", user_id, prompt)
            return self.fallback_response, "FALLBACK_TIMEOUT"

        except Exception as e:
            # Any other error: fallback + alert
            self.log_incident("ERROR", user_id, str(e))
            self.alert_team(f"GPAI service error: {e}")
            return self.fallback_response, f"FALLBACK_{type(e).__name__}"

    def is_healthy(self):
        try:
            response = requests.get(f"{self.ollama_url}/api/tags", timeout=2)
            return response.status_code == 200
        except:
            return False

7. Monitoring e alerting

Configura dashboard per tracciare metriche critiche:

{
  "monitoring_config": {
    "metrics": [
      {
        "name": "gpai_response_latency_ms",
        "alert_threshold": 5000,
        "alert_type": "warning"
      },
      {
        "name": "gpai_error_rate_percent",
        "alert_threshold": 5,
        "alert_type": "critical"
      },
      {
        "name": "gpai_abuse_reports_per_hour",
        "alert_threshold": 10,
        "alert_type": "critical"
      },
      {
        "name": "gpai_prompt_rejection_rate",
        "alert_threshold": 20,
        "alert_type": "warning"
      }
    ],
    "dashboards": [
      {
        "name": "GPAI Compliance",
        "refresh_interval": "5m",
        "widgets": [
          "Error trend (24h)",
          "User satisfaction (avg rating)",
          "Abuse reports (open investigations)",
          "Service uptime (SLA tracking)"
        ]
      }
    ]
  }
}

8. Response handling e versioning

Ogni response GPAI va versioned e tracciato:

CREATE TABLE gpai_responses (
  id UUID PRIMARY KEY,
  user_id VARCHAR(255) NOT NULL,
  model_id VARCHAR(255) NOT NULL,
  model_version VARCHAR(50) NOT NULL,
  prompt TEXT NOT NULL,
  response TEXT NOT NULL,
  generated_at TIMESTAMP NOT NULL,
  confidence_score FLOAT,

  -- Compliance tracking
  flagged_for_review BOOLEAN DEFAULT false,
  compliance_check_passed BOOLEAN,
  compliance_check_timestamp TIMESTAMP,

  FOREIGN KEY (model_id) REFERENCES gpai_models(id)
);

-- Index for compliance audits
CREATE INDEX idx_compliance_review ON gpai_responses(flagged_for_review, generated_at);
CREATE INDEX idx_model_version ON gpai_responses(model_id, model_version);

Configurazione Ollama per GPAI compliance

Se usi Ollama on-prem, ecco una configurazione di esempio che implementa alcuni requirement GPAI:

{
  "ollama_instance": {
    "host": "127.0.0.1",
    "port": 11434,
    "model": "llama3.1:8b",
    "compliance_mode": true,
    "settings": {
      "num_predict": 512,
      "top_k": 40,
      "top_p": 0.9,
      "temperature": 0.7,
      "repeat_penalty": 1.1,
      "num_gqa": 8
    },
    "safety_features": {
      "rate_limit": {
        "enabled": true,
        "requests_per_minute": 120,
        "per_user": true
      },
      "content_filtering": {
        "enabled": true,
        "filter_harmful_content": true,
        "filter_pii": true
      },
      "prompt_logging": {
        "enabled": true,
        "log_path": "/var/log/ollama/compliance.log",
        "retention_days": 365
      },
      "response_validation": {
        "max_response_length": 4096,
        "timeout_seconds": 30,
        "fallback_response": "I'm unable to respond to that request right now. Please try again later."
      }
    },
    "monitoring": {
      "health_check_interval": 30,
      "metrics_export": true,
      "prometheus_port": 9090
    }
  }
}

FAQ

D: Il mio modello ha solo 500M parametri. È ancora GPAI?

R: No, in genere. Modelli <1B parametri sono considerati small language models (SLM) e esclusi dagli obblighi GPAI. Tuttavia, se il tuo SLM è capace di svolgere vaste gamma di task e ha generazione autonoma, potrebbe comunque rientrare in GPAI a discrezione dell'autorità. Non è una regola rigida; devi fare auto-valutazione documentata.

D: Se uso un modello proprietario (API esterna), sono responsabile della compliance?

R: Dipende. Il provider del modello è responsabile della conformità del modello stesso. Tu sei responsabile di: (1) usarlo correttamente (non per abusi), (2) implementare fallback se non disponibile, (3) comunicare chiaramente agli end-user che è AI-generated, (4) avere contratti che dichiarino la compliance del provider. Se il provider non è EU-based, i tuoi obblighi sono ancora validi se offrì servizio a cittadini EU.

D: Posso usare fine-tuning per evitare obblighi GPAI?

R: No. Fine-tuning non cambio il fatto che il modello è GPAI. Anzi, il fine-tuning introduce nuove responsabilità: devi ripetere risk assessment, documentare dati training, monitorare il modello fine-tuned. Fine-tuning richiede MORE compliance work, non meno.

D: Quali autorità nazionali applicheranno l'AI Act in Italia?

R: In Italia: Garante della Privacy (per aspetti GDPR), AGCOM (Autorità per le Garanzie nelle Comunicazioni), e MISE (Ministero dello Sviluppo Economico) hanno responsabilità condivisa. A livello EU: 27 national authorities + European Artificial Intelligence Board. Se operi in EU, puoi essere soggetto a ispezione da qualsiasi autorità nazionale.

D: Devo pagare per audit terzi di compliance GPAI?

R: Non obbligatorio, ma altamente raccomandato. Se fai auto-audit e autorità scopre gap, la responsabilità è tua. Un audit terzo da certified body offre protezzione legale (due diligence dimostrata). Costo tipico: 5K-50K EUR dipende da complessità e numero di modelli.