GDPR, AI Act e Lavoro: Architetture di Compliance per SaaS e Startup

Fonti normative e giurisprudenziali: Regolamento (UE) 2016/679 (GDPR) · Regolamento (UE) 2024/1689 (AI Act) · Linee guida EDPB su modelli AI e protezione dei dati · Provvedimento Garante Privacy italiano — Telemetria IoT, gennaio 2026 · Sanzione CNIL — Time Doctor, 2025 · Legge 23 settembre 2025, n. 132 (Legge italiana sull'IA) · Art. 4 Legge 300/1970 (Statuto dei Lavoratori)

Il panorama regolatorio europeo ha attraversato una trasformazione strutturale che nessuna organizzazione tech può permettersi di ignorare. L'AI Act è pienamente in vigore, il Garante Privacy italiano e la CNIL francese hanno dimostrato un attivismo sanzionatorio senza precedenti, e gli investitori istituzionali scrutinano la governance algoritmica con la stessa attenzione dedicata ai bilanci. Per approfondire il quadro generale dell'AI Act, si veda la guida completa all'AI Act e l'analisi strategica per aziende italiane.

Il presente articolo analizza tre aree ad alto rischio operativo: l'uso dell'AI generativa sui dati dei clienti, la preparazione della data room per il fundraising, e il monitoraggio dei dipendenti con sistemi digitali e IoT. Per ciascuna, vengono forniti riferimenti giurisprudenziali aggiornati, tabelle comparative e indicazioni operative scalabili.

1. AI Generativa e Dati dei Clienti: Le Linee Rosse per SaaS e Agenzie

Il rischio invisibile nei flussi di lavoro quotidiani

La domanda che ogni responsabile legale e ogni CTO dovrebbe porre ai propri team è semplice e diretta: i dipendenti stanno incollando dati reali dei clienti in ChatGPT, Claude o Gemini? La risposta, nella maggior parte delle organizzazioni, è affermativa. Studi di settore stimano che quasi la metà dei dipendenti delle grandi imprese utilizza l'AI generativa nel lavoro quotidiano e che, in circa il 77% dei casi, i dati elaborati appartengono all'azienda o ai suoi clienti.

Quando un operatore copia e incolla informazioni relative a un cliente nell'interfaccia web di un LLM in versione gratuita o consumer, si verificano contestualmente più violazioni del GDPR. L'operazione configura un trasferimento di dati personali verso un titolare autonomo situato, nella grande maggioranza dei casi, al di fuori dello Spazio Economico Europeo, in contrasto con l'Art. 44 e seguenti del GDPR. Affinché tale trasferimento sia lecito per scopi professionali, sono inderogabili un Data Processing Agreement idoneo e una Transfer Impact Assessment preventiva. Se l'azienda agisce come Responsabile del Trattamento (Art. 28 GDPR) per conto di un cliente Titolare, la trasmissione a un sub-responsabile non autorizzato costituisce un data breach autonomo, sia contrattuale che normativo.

La posizione dell'EDPB: i dati non "transitano", vengono assorbiti

L'EDPB chiarisce un punto tecnico-giuridico fondamentale: le informazioni personali immesse nei Large Language Model non si limitano a transitare sui server del fornitore. Esse rischiano di rimanere permanentemente assorbite nei parametri matematici e nei pesi neurali del modello, diventando potenzialmente estraibili durante interrogazioni future di altri utenti. Un modello AI può essere considerato effettivamente anonimo, e quindi sottratto all'ambito del GDPR, soltanto quando la probabilità di estrarre i dati personali sottostanti sia matematicamente insignificante: una soglia che la semplice pseudonimizzazione non raggiunge.

Questo punto merita attenzione pratica. Molte organizzazioni sostituiscono i nomi dei clienti con codici alfanumerici prima di inviare dataset agli LLM tramite API, ritenendo di uscire dal perimetro del GDPR. La supposizione è errata. Se l'azienda o un potenziale attaccante possiede la chiave di decodifica, i dati rimangono a tutti gli effetti dati personali. Il trasferimento di dati pseudonimizzati verso LLM extra-UE richiede comunque un DPA, una TIA e una base giuridica documentata.

Provider o Deployer: una distinzione che vale milioni di euro

L'AI Act introduce una distinzione giuridica che le startup SaaS devono interiorizzare prima di qualsiasi altra cosa. Il Provider è il soggetto che sviluppa o commissiona un sistema AI per immetterlo sul mercato con il proprio nome; su di lui gravano gli obblighi più pesanti, tra cui la documentazione tecnica, la marcatura CE e la gestione del rischio per l'intero ciclo di vita. Il Deployer è la persona fisica o giuridica che utilizza un sistema AI di terze parti nell'ambito di una attività professionale.

Lo scenario più frequente nel mercato attuale è quello di una startup SaaS che integra le API di un modello linguistico di terze parti (GPT-4, Claude, Gemini) per offrire funzionalità avanzate ai propri utenti. In questa architettura, l'azienda assume il ruolo di Deployer e, in contesti di forte personalizzazione, di Downstream Provider. L'errore più pericoloso è credere che la responsabilità sia interamente del fornitore originario della tecnologia: l'Art. 26 dell'AI Act è categorico nel sancire obblighi non trasferibili a carico del Deployer.

Cosa impone l'Art. 26 AI Act al Deployer

Il Deployer di un sistema AI deve adempiere a obblighi concreti e documentabili:

• Rispettare le istruzioni d'uso del fornitore: qualsiasi deviazione dal perimetro di utilizzo prescritto costituisce una violazione diretta imputabile all'azienda utilizzatrice, non al vendor
• Designare un responsabile della supervisione umana con competenze tecniche effettive, non solo nominalmente, con autorità per interrompere il sistema in caso di anomalie
• Garantire la qualità dei dati di input: i dati immessi nel sistema devono essere pertinenti, esatti e sufficientemente rappresentativi per evitare output distorti o discriminatori
• Conservare i log di sistema per almeno sei mesi, fornendo una traccia del funzionamento e degli interventi umani
• Sospendere il sistema e notificare le autorità in caso di incidente grave o rischio inatteso
• Integrare la DPIA con la documentazione tecnica fornita dal Provider (Art. 26, par. 9): questo crea un collegamento obbligatorio tra compliance GDPR e compliance AI Act che molte aziende non hanno ancora implementato

Checklist operativa: sei azioni prioritarie

Per un utilizzo lecito dell'AI generativa sui dati dei clienti, le organizzazioni devono adottare le seguenti misure nell'ordine indicato:

1. Blocco immediato degli LLM consumer. Le versioni gratuite o base dei principali LLM devono essere bloccate a livello di firewall aziendale per qualsiasi uso professionale. La migrazione verso versioni Enterprise (ChatGPT Enterprise, Microsoft Copilot, o modelli in cloud privato) garantisce contrattualmente l'esclusione del riutilizzo dei dati per l'addestramento.

2. Revisione contrattuale con clausole AI. I DPA esistenti devono essere integrati con appendici specifiche sull'AI che esplicitino i limiti del trattamento, il divieto di addestramento sui dati del cliente, le SCC per trasferimenti extra-UE e i criteri della TIA.

3. Implementazione di sistemi DLP. I sistemi di Data Loss Prevention analizzano i prompt in uscita e bloccano l'invio accidentale di PII, dati finanziari o segreti industriali prima che raggiungano i server del fornitore AI.

4. Linee guida interne documentate. Una policy scritta deve stabilire quali tipologie di dati possono essere elaborate da sistemi esterni e quali pratiche sono vietate, come l'upload di file CSV con anagrafiche non filtrate.

5. Aggiornamento della DPIA. Come prescritto dall'AI Act, la Valutazione d'Impatto deve essere aggiornata incorporando la documentazione tecnica del fornitore del modello, unificando le due procedure valutative.

6. Retention dei log per sei mesi. I sistemi IT devono essere configurati per conservare i log operativi per il periodo minimo richiesto dall'AI Act, bilanciando questo vincolo con il principio GDPR di minimizzazione della conservazione.

Tabella: Architetture AI e Livelli di Rischio Legale

Le sanzioni già comminate dimostrano il rischio reale

Le autorità europee non stanno soltanto emanando linee guida: stanno irrogando sanzioni significative. Il Garante Privacy italiano ha comminato 5 milioni di euro a LUKA Inc. (Replika) per assenza di verifica dell'età, mancanza di basi giuridiche e trasparenza insufficiente. Un'altra vicenda ha visto il Garante italiano comminare inizialmente 15 milioni di euro a OpenAI per l'elaborazione illegittima di dati personali, caso poi entrato in una fase più complessa legata alla competenza territoriale a seguito dello stabilimento di OpenAI in Irlanda. Questi precedenti indicano con chiarezza che la negligenza nella gestione dell'AI generativa non rimane impunita.

2. Data Room 2.0: GDPR e AI Act nella Due Diligence delle Startup

Perché i VC ora chiedono governance algoritmica

Il fallimento o il rallentamento di round di investimento (Seed, Serie A e B) è sempre più spesso imputabile all'incapacità dei team fondatori di documentare con precisione la provenienza dei dati di addestramento e l'architettura tecnica dei propri sistemi AI. Per un approfondimento sul tema della due diligence tradizionale, si veda la guida alla GDPR due diligence startup.

Gli investitori istituzionali sanno che le sanzioni previste dall'AI Act possono raggiungere i 35 milioni di euro o il 7% del fatturato annuo globale. Non possono permettersi di investire in architetture che potrebbero essere bloccate dalle autorità o soggette a sanzioni capaci di annientare la liquidità della società partecipata. Il fondo moderno non si accontenta di una certificazione ISO 27001 o di una privacy policy ben redatta: richiede evidenze solide di una governance algoritmica matura. Per capire come strutturare l'adeguamento complessivo, si veda anche la guida agli adempimenti GDPR per startup.

I tre documenti chiave che definiscono la Data Room 2.0

Inventario Architetturale AI e Classificazione del Rischio. Il primo documento che gli investitori vogliono vedere è la mappatura di ogni componente software basato su AI, classificato secondo le categorie dell'AI Act: Rischio Inaccettabile (pratiche vietate dal febbraio 2025), Alto Rischio, Modelli GPAI, Rischio Limitato, Rischio Minimo. Se la valutazione rivela che un algoritmo della startup ricade nelle pratiche vietate, come la manipolazione subliminale, il social scoring o lo scraping di volti dal web, il fondo interrompe immediatamente l'operazione.

DPIA e Fundamental Rights Impact Assessment (FRIA). Per i sistemi ad alto rischio, la documentazione richiede non solo la tradizionale Valutazione d'Impatto sulla Protezione dei Dati, ma anche la FRIA: un documento che esamina l'impatto dell'algoritmo su un ampio spettro di diritti fondamentali. La FRIA deve rispondere a cinque interrogativi specifici: quali diritti sono potenzialmente intaccati; come il sistema potrebbe compromettere dignità, uguaglianza o accesso a rimedi legali; quali sono le conseguenze di una decisione automatizzata errata; chi assume la responsabilità finale; quali meccanismi concreti permettono all'interessato di contestare la decisione.

Documentazione Tecnica AI Act e Governance dei Dataset. Per i sistemi ad alto rischio o per i modelli GPAI, la data room deve presentare specifiche progettuali dettagliate, Model Cards, architetture dei database, metodologie di addestramento e report sulle metriche di accuratezza, robustezza e resilienza contro attacchi quali il data poisoning e il model evasion. La provenienza legale dei dati di addestramento, completa di basi giuridiche e licenze copyright, è un parametro di vulnerabilità critica che gli investitori esaminano con i propri legali.

Tabella: Data Room 2020 vs. Data Room 2026

Le 10 domande che i VC pongono in due diligence

Durante le sessioni di Q&A avanzate, i general partner dei fondi sottopongono il team fondatore a un interrogatorio tecnico serrato. Queste sono le domande che non devono cogliere impreparati:

1. Classificazione del rischio. Sotto quale categoria AI Act ricadono i modelli sviluppati o integrati, e qual è la metodologia giuridica utilizzata per giungervi?
2. Origine dei dati di addestramento. Quali sono le basi giuridiche e le licenze copyright che legittimano l'uso di dati personali o protetti nei dataset di training?
3. Posizione nella filiera. L'azienda opera come Provider o come Deployer, e si è assunta formalmente gli oneri legali corrispondenti?
4. Supervisione umana. Se gli algoritmi influenzano decisioni con impatto sulle persone, come viene garantita e documentata la supervisione umana effettiva (human-in-the-loop)?
5. Contratti con i fornitori LLM. I contratti con OpenAI, Anthropic o altri fornitori includono garanzie che impediscono il riutilizzo dei dati della piattaforma per l'addestramento dei modelli fondazionali?
6. Test anti-bias. Esistono report statistici sui test eseguiti per rilevare e mitigare distorsioni algoritmiche sugli attributi protetti (sesso, etnia, età)?
7. Infrastruttura di logging. I log delle interazioni con i modelli ad alto rischio vengono conservati per almeno sei mesi, come richiesto dalla normativa?
8. Istruzioni per i clienti B2B. I clienti enterprise ricevono istruzioni d'uso sufficientemente dettagliate da consentire loro di adempiere agli obblighi da Deployer?
9. Resilienza informatica. L'architettura è stata testata contro vulnerabilità specifiche dell'AI, in primo luogo le iniezioni di dati malevoli e il model evasion?
10. AI Literacy del personale. Il team che sviluppa, mantiene e supervisiona i modelli possiede il livello di alfabetizzazione sull'intelligenza artificiale reso obbligatorio dall'Art. 4 dell'AI Act?

La roadmap a 6-12 mesi per l'investor readiness

Presentarsi a un round di investimento senza incappare in blocchi documentali richiede pianificazione anticipata. Nei sei-dodici mesi precedenti all'apertura formale del round, la direzione deve:

• 12 mesi prima: avviare l'inventariazione di ogni componente AI in uso o in sviluppo, sia interno che integrato via API; sospendere immediatamente qualsiasi funzionalità che ricada nelle pratiche vietate dall'AI Act
• 6-9 mesi prima: allocare il budget per la conduzione delle DPIA e FRIA; avviare la stesura della documentazione tecnica; formalizzare le responsabilità di supervisione umana e istituire un Comitato Etico AI
• 3-6 mesi prima: inviare i Vendor Security Questionnaires ai fornitori AI; aggiornare la privacy policy pubblica con sezioni dedicate alla trasparenza delle elaborazioni e alla spiegabilità delle decisioni automatizzate (conformità agli Artt. 13, 14 e 22 GDPR)
• 1-3 mesi prima: completare la data room con tutti i documenti AI-ready; effettuare un audit interno di pre-due diligence per identificare e colmare i gap residui

3. Monitoraggio Dipendenti con AI, IoT e Software: Il Confine tra Efficienza e Sanzioni

Il quadro normativo: Art. 4 Statuto dei Lavoratori e GDPR

L'ordinamento italiano pone un perimetro molto definito al controllo a distanza dei lavoratori. L'Art. 4 della Legge 300/1970 (Statuto dei Lavoratori) prescrive che gli impianti audiovisivi e tutti gli strumenti tecnologici da cui derivi anche solo la potenzialità tecnica di esercitare un controllo a distanza sulle azioni dei lavoratori, compresi sensori IoT, cruscotti analitici basati su AI e tracker GPS, possano essere installati soltanto per comprovate esigenze organizzative, produttive, di sicurezza o di tutela del patrimonio aziendale.

L'aspetto che si rivela fatale per la maggior parte delle startup è quello procedurale: l'installazione di tali sistemi è tassativamente subordinata al previo accordo con le Rappresentanze Sindacali Aziendali (RSA o RSU), oppure, in assenza di rappresentanze interne, all'autorizzazione preventiva della sede territoriale dell'Ispettorato Nazionale del Lavoro (INL). Il Garante Privacy agisce come ulteriore organo di deterrenza, imponendo non solo sanzioni pecuniarie ma anche ingiunzioni di disattivazione immediata dei sistemi e cancellazione dei database accumulati illecitamente.

I casi giurisprudenziali che tracciano il confine

Il caso della telemetria IoT sulle automobili aziendali (Garante, gennaio 2026). Il Garante italiano ha inflitto una multa di 120.000 euro a una società multinazionale del settore agricolo che, per disposizione della propria capogruppo svizzera, aveva installato dispositivi di telemetria sulle autovetture aziendali di cinque dipendenti. Il sistema raccoglieva in modo continuativo dati sui tempi di percorrenza, le distanze, il carburante consumato e lo "stile di guida" di ciascun conducente, convogliandoli in un algoritmo che generava un punteggio mensile per valutarne il comportamento e irrogare eventuali misure disciplinari.

Il Garante ha ravvisato un monitoraggio eccessivamente penetrante e ininterrotto, in violazione dell'Art. 4 dello Statuto dei Lavoratori. Le aggravanti hanno moltiplicato la gravità della condotta: i dati profilati venivano conservati per tredici mesi, l'informativa ai lavoratori era generica e ometteva la base giuridica del trattamento, e i dati erano accessibili al personale di altre società del gruppo, concretizzando circolazioni illecite transfrontaliere.

Il caso Time Doctor e il keylogger silenzioso (CNIL, 2025). L'autorità garante francese ha irrogato una sanzione di 40.000 euro a una società immobiliare che imponeva ai propri dipendenti remoti l'uso del software Time Doctor. La versione "silenziosa" dell'applicativo, installata all'insaputa dei lavoratori, registrava ogni battuta sulla tastiera, analizzava l'attività del mouse per determinare i momenti di inattività, acquisiva screenshot ogni tre-quindici minuti e estraeva la cronologia integrale dei siti visitati, classificandoli in indici di produttività.

La CNIL ha stabilito che un sistema di controllo permanente, automatizzato e dotato di funzioni di keylogging è strutturalmente sproporzionato rispetto a qualsiasi legittimo interesse aziendale. Ha inoltre sanzionato l'azienda per la violazione degli Artt. 12 e 13 del GDPR, respingendo la difesa secondo cui l'informativa era stata fornita oralmente: una comunicazione verbale priva di tracciabilità certificabile non ha valore alcuno in sede ispettiva.

Il caso della retention dei metadati email (Garante, 2025/2026). Il Garante italiano ha notificato ordinanze ingiunzione di 20.000 e 25.000 euro a una pubblica amministrazione regionale che conservava i metadati delle email dei dipendenti per novanta giorni e i log di navigazione internet per un anno intero. Le linee d'indirizzo del Garante fissano a ventuno giorni il limite massimo di retention per i metadati legati alla posta elettronica, salvo accordo sindacale specifico. Trattenere queste tracce per periodi più lunghi equivale a un monitoraggio indiretto a distanza che consente di ricostruire le relazioni, le abitudini e le tempistiche lavorative del dipendente.

Le quattro categorie di strumenti ad alto rischio

1. Sistemi di Fleet Management e telemetria avanzata. Il GPS per fini logistici è tecnicamente legittimo, ma non deve trasmodare in una mappatura degli spostamenti extra-lavorativi. L'algoritmo non deve mai sintetizzare metriche comportamentali per generare punteggi di merito, specie se utilizzati per misure disciplinari senza basi negoziali solide.

2. Software di Employee Monitoring. I dispositivi che abilitano la registrazione remota dello schermo o incorporano funzioni di keylogging espongono la forza lavoro al rischio di acquisizione coatta di comunicazioni private, documenti sanitari o credenziali di accesso. Tali soluzioni configurano un'interferenza grave con il diritto alla vita privata sul luogo di lavoro, tutelato con il massimo rigore dalla giurisprudenza europea.

3. Sensoristica IoT negli ambienti fisici. Braccialetti elettronici traccianti, sistemi di videosorveglianza con riconoscimento biometrico e sensori ultra-wideband per il calcolo delle pause o la mappatura delle interazioni tra colleghi si spingono sul confine dell'illecito penale se adottati al di fuori della dialettica sindacale.

4. AI per l'analisi delle performance. Gli applicativi che estrapolano il tempo trascorso su specifici task, la latenza di risposta alle email o il tono vocale durante le chiamate per inferire produttività e comportamenti non solo azionano la macchina sanzionatoria del GDPR: trasformano il sistema in una tecnologia ad "Alto Rischio" ai sensi dell'Allegato III dell'AI Act. Questo inquadramento impone al Deployer di notificare formalmente i lavoratori coinvolti e i loro rappresentanti sindacali prima che il sistema influenzi le valutazioni (Art. 26, par. 7 AI Act).

L'obbligo di DPIA e il test di proporzionalità

Ogni volta che un'azienda intende implementare metodologie di sorveglianza sistemica su scala generalizzata, o nuove tecnologie che incidono significativamente sull'autonomia dei lavoratori, sorge l'obbligo di condurre una DPIA ai sensi dell'Art. 35 GDPR, con il contributo tecnico del DPO. Il documento non può essere un esercizio compilativo: deve dimostrare che le finalità organizzative dichiarate non avrebbero potuto essere raggiunte con mezzi meno lesivi. Alternative da valutare includono: obiettivi basati sul risultato anziché sulla presenza al terminale; cruscotti aggregati e anonimi che impediscono l'identificazione del singolo; dialogo continuo con le linee manageriali. Per un approfondimento sulla figura del DPO e il suo ruolo, si veda la sezione dedicata al DPO esterno.

Costruire la trasparenza prima che sia troppo tardi

Per evitare vertenze sindacali e ispezioni delle autorità, le aziende devono strutturare i propri processi attorno a una trasparenza documentabile. Il confronto preventivo con le RSA/RSU ai sensi dell'Art. 4 dello Statuto dei Lavoratori non è una perdita di tempo manageriale: è lo scudo legale primario dell'imprenditore.

A livello documentale, le organizzazioni devono abbandonare le comunicazioni orali o inserite frettolosamente nei contratti di assunzione. È imperativo redigere un disciplinare informatico e una policy di assegnazione degli asset aziendali, accessibili in modo permanente sulla intranet, che specifichino con precisione: i limiti temporali di conservazione dei metadati; i soggetti con accesso ai log di sistema; le basi giuridiche del trattamento; le circostanze straordinarie in cui la direzione può esercitare ispezioni sui terminali o sulle comunicazioni.

L'infrastruttura tecnologica deve incorporare la Privacy by Design sin dalla sua progettazione. I reparti IT devono disabilitare nativamente qualsiasi funzione analitica sovrabbondante abilitata per impostazione predefinita dai fornitori di software. Nessun algoritmo deve operare rilevazioni di keystroke fuori dall'orario di lavoro; nessun dispositivo deve acquisire screenshot seriali; la disattivazione dei moduli di keylogging deve essere garantita contrattualmente dal vendor e verificata da penetration tester indipendenti.

Compliance come Vantaggio Competitivo: La Raccomandazione Finale

Il quadro normativo europeo esige una trasformazione culturale, non semplicemente legale, all'interno dei consigli di amministrazione e dei reparti di ingegneria. L'idea che l'adozione accelerata dell'AI o il monitoraggio pervasivo dei lavoratori possa prescindere da un rigoroso controllo giuridico si è rivelata economicamente fatale per numerose organizzazioni.

Le organizzazioni che strutturano la compliance come un processo continuo, non come un adempimento una-tantum, ottengono vantaggi concreti e misurabili. Per le startup B2B, la documentazione privacy strutturata accelera il procurement dei clienti enterprise, che richiedono sistematicamente la compilazione di questionari di sicurezza prima di finalizzare un contratto. Per le aziende in fase di fundraising, una data room AI-ready trasforma un potenziale punto di blocco in un segnale di maturità operativa che accelera la closing. Per le organizzazioni che gestiscono team distribuiti, un framework di monitoraggio trasparente e proporzionato preserva la fiducia interna e previene le vertenze sindacali.

La raccomandazione operativa è l'istituzione di audit tecnologici strutturati e ricorrenti, capaci di mappare i flussi di informazione tra modelli on-premise, API di terze parti e dispositivi dislocati sul territorio aziendale. La revisione sistematica dei Data Processing Agreement e l'elevazione della Privacy by Design a principio fondante dell'ingegneria del software sono le leve con cui le organizzazioni possono sterilizzare le esposizioni legali ed elevare la conformità a vantaggio competitivo duraturo. Per un percorso di adeguamento personalizzato alle specifiche caratteristiche della propria architettura tecnologica, si consulti la pagina del servizio di consulenza AI Act.

Il presente articolo ha finalità informative generali ed è aggiornato al 26 maggio 2026. I provvedimenti sanzionatori citati (Garante telemetria 120.000 euro, gennaio 2026; CNIL Time Doctor 40.000 euro; Garante email metadati 20.000 e 25.000 euro; Garante Replika 5 milioni di euro; sanzione OpenAI 15 milioni di euro) fanno riferimento a decisioni pubblicate dalle rispettive autorità. Le scadenze e gli obblighi normativi dell'AI Act sono soggetti a possibili variazioni; si raccomanda di verificare gli aggiornamenti ufficiali pubblicati dalla Commissione Europea e dall'AI Office UE. Per supporto specifico alla propria situazione, contatta lo studio.