Best Practices Automotive (IT)

Raccomandazioni operative, di progettazione e di conformità per sviluppatori e team che costruiscono applicazioni AI/RAG/agent sul dominio automotive.

---

Citare sempre la fonte normativa per i limiti di emissione

Quando si indicano valori di emissione (CO2 g/km, NOx mg/km, PN #/km), citare sempre il Regolamento specifico (es. Reg. UE 715/2007, Allegato I) e il ciclo di misurazione (WLTP, RDE). Non indicare numeri senza fonte attributabile: i limiti variano per categoria di veicolo, versione di Euro e data di applicazione.

Usare VIN come identificatore univoco dei veicoli

In qualsiasi schema dati automotive, usare il VIN (ISO 3779:2009, 17 caratteri) come chiave primaria o identificatore di riferimento dei veicoli individuali. Non usare targa, telaio proprietario o codici interni come surrogati del VIN nei sistemi di tracciabilità.

Separare gli artefatti di omologazione dalla scheda commerciale del veicolo

I dati di omologazione (COC, tipo approvato, varianti, versioni) hanno un ciclo di vita normativo separato dai dati commerciali (listino, accessori, colori). Modellare questi due insiemi in entità distinte per evitare accoppiamento non necessario.

Gestire il contesto temporale delle normative (versioning normativo)

Le normative automotive hanno date di applicazione: un veicolo omologato nel 2020 è conforme a Euro 6d-temp, non a Euro 7. Nei modelli dati e nelle query RAG, includere sempre la data di riferimento o la versione normativa applicabile per evitare risposte non contestuali.

Validare i dati JSONL di eval con contesti non vuoti

Nei golden eval set automotive, ogni riga deve avere il campo contexts non vuoto. Domande su normative senza contesto di recupero producono risposte non verificabili (AI hallucination risk alto per questo dominio). Applicare una validazione automatica pre-commit.

Distinguere emissioni tailpipe da emissioni well-to-wheel nei prompt AI

I modelli AI tendono a confondere emissioni "zero" dei BEV al tubo di scarico con zero emissioni totali. Nei system prompt e nelle istruzioni Copilot/GPT, specificare esplicitamente che "zero emissioni" si riferisce alle emissioni tailpipe WLTP e non al ciclo well-to-wheel.

Applicare la classificazione ASIL prima di implementare logiche safety-critical

Per qualsiasi applicazione che interagisca con sistemi safety-critical del veicolo (freni, sterzo, ADAS), effettuare l'analisi ASIL (ISO 26262) prima dello sviluppo. Non implementare funzionalità ASIL C/D con linguaggi o framework non certificati.

Usare il modello di eventi al passato per i domain events automotive

Nominare gli eventi di dominio al participio passato (VeicoloOmologato, RichiamoEmesso, EmissioneMisurata) in linea con il pattern DDD Event Sourcing. Questo rende inequivocabile che l'evento rappresenta qualcosa già accaduto e non un comando.

I dati di posizione GPS e diagnostica OBD dei veicoli sono dati personali quando associabili a un conducente identificabile. Applicare il principio di privacy by design (Art. 25 GDPR): minimizzare i dati raccolti, anonimizzare quando possibile, definire retention policy chiare.

Versionare i corpus RAG quando cambiano le normative

I corpus RAG automotive devono essere revisionati quando entrano in vigore nuove normative (es. transizione Euro 6 → Euro 7, nuovi Regolamenti UNECE). Aggiungere un campo normative_version ai metadati dei chunk per filtrare i contenuti obsoleti nelle pipeline RAG.

Usare CCS2 come standard di ricarica di default per l'Europa

Nelle applicazioni che gestiscono infrastrutture di ricarica per il mercato europeo, usare CCS2 (IEC 62196-3) come standard di default. CHAdeMO è in declino nell'UE; NACS è predominante in Nord America. Il Regolamento AFIR (UE 2023/1804) promuove CCS2 sulla rete TEN-T.

Non mischiare dati WLTP e NEDC negli stessi dataset

I valori di autonomia e CO2 misurati con WLTP e NEDC non sono comparabili direttamente. Etichettare sempre i dati con il ciclo di misurazione nel metadato. Nei modelli di regressione ML per la stima dell'autonomia, usare solo dati omogenei.