· Davide Padeletti · Insights · 6 min read

Il nostro prodotto non usa l'AI. È una decisione, non una mancanza.

Costruiamo sistemi di intelligenza artificiale per i nostri clienti. Eppure nel nostro prodotto, proprio dove tutti si aspetterebbero un modello, abbiamo messo un algoritmo deterministico di poche decine di righe. Ecco perché.

Costruiamo sistemi di intelligenza artificiale per i nostri clienti. Eppure nel nostro prodotto, proprio dove tutti si aspetterebbero un modello, abbiamo messo un algoritmo deterministico di poche decine di righe. Ecco perché.

In questo progetto c’era un punto ovvio in cui mettere un modello. È proprio lì che abbiamo deciso di non metterlo.

TrovaStorage è il marketplace del self storage a cui stiamo lavorando. Nella fase pilota, quando ancora si chiamava Metroquadro, chiedeva all’operatore di pubblicare il proprio deposito unità per unità, così chi cercava un magazzino poteva vederne l’interno vero e non la solita foto della facciata. Il primo compito dell’operatore però era anche il più noioso: prima di affittare qualsiasi cosa doveva disegnare la planimetria, cioè la sagoma del capannone, i corridoi e i box che voleva ricavarne.

Era il posto perfetto per una demo a effetto. Carichi le misure, scrivi «disegnami la planimetria migliore» e in pochi secondi sullo schermo compare qualcosa di plausibile. Nel 2026 nessuno chiede più nemmeno come funzioni. Noi abbiamo scelto di non farlo.

Che cosa abbiamo messo al posto del modello

Al suo posto c’è un algoritmo che dispone i box in righe. È deterministico, sono poche decine di righe di Python e non fa nessuna chiamata di rete. Il commento in cima al codice dice chiaramente cosa vuole essere e, soprattutto, cosa non vuole essere:

«Un punto di partenza che il venditore poi modifica, non un ottimizzatore. Nessuna casualità: lo stesso input produce sempre lo stesso layout.»

Si inseriscono la sagoma, la larghezza del corridoio e il mix di unità che si vuole, e i box vengono messi in fila nell’ordine richiesto. Quello che non entra non sparisce: torna indietro come elenco esplicito, raggruppato per misura (tre unità da sei metri quadri non ci stanno). Non è un dettaglio gestito con eleganza, è metà del valore della funzione.

Non è un algoritmo furbo, lo ammettiamo. Ma il problema non chiedeva furbizia, chiedeva prevedibilità.

Perché quello era il punto sbagliato

Le ragioni sono tre, e sono tutte più noiose dell’idea di un modello linguistico che disegna capannoni.

La bozza esiste per essere modificata. L’operatore la riceve e ci lavora subito: trascina, ruota, sposta il pilastro dove sta davvero, allarga il corridoio perché deve passarci il muletto. Se ogni volta che la rigenera ottenesse un risultato diverso, la bozza smetterebbe di essere un punto di partenza. Diventerebbe un oracolo, qualcosa da consultare invece che una base su cui costruire. In un contesto così la riproducibilità non è un vezzo tecnico, è la condizione perché lo strumento si possa usare.

Il risultato va spiegato a chi paga l’affitto. Prima o poi qualcuno chiederà all’operatore: «Perché in questo corridoio ci stanno sei box e non sette?». La risposta deve essere una regola, cioè la larghezza, la tolleranza, il passaggio minimo da lasciare libero. Non può essere un imbarazzato «l’ha proposto il sistema».

In questo mestiere l’errore è geometrico e definitivo. Un box sovrapposto a un pilastro non è una risposta un po’ peggiore delle altre. È un metro quadro che non esiste, affittato a qualcuno che ha in mano un contratto. Nessuna soglia di confidenza rende accettabile un risultato del genere.

Il criterio, ridotto all’osso

L’intelligenza artificiale dà il meglio quando l’input è vario e sbagliare costa poco. Un assistente che riscrive la descrizione di un annuncio è l’esempio perfetto: gli si può dare qualunque testo e, nel peggiore dei casi, l’errore costa una rilettura. Lo stesso vale per un sistema che estrae dati da documenti tutti diversi tra loro.

Qui succede il contrario. L’input sono tre numeri e una lista (metri, larghezza del corridoio, mix di unità): niente di ambiguo, niente testo libero, niente da interpretare. E l’errore, come abbiamo visto, costa un contratto.

Nel nostro documento di prodotto l’ottimizzatore di layout resta comunque tra le idee per dopo l’MVP, con una nota che vale come regola generale: prima un risolutore di vincoli, il machine learning solo se serve davvero. Lasciare la porta aperta non vuol dire averla già attraversata.

Dove i vincoli li abbiamo messi sul serio

In questo prodotto la certezza non arriva dalla potenza del modello, ma dai vincoli, a patto di metterli dove nessuno può aggirarli.

Le due regole geometriche sono semplici: nessun box sovrapposto a un altro e niente che esca dalla sagoma. Valgono sia nel browser sia sul server. Il controllo nel browser è una cortesia per chi disegna, quello sul server è quello che conta.

Allo stesso modo, le doppie prenotazioni sono impossibili perché lo impone il database, non perché il codice stia attento. Un vincolo di esclusione su Postgres rifiuta due prenotazioni sovrapposte sulla stessa unità, qualunque cosa faccia l’applicazione e anche con molte richieste in contemporanea. Se due clienti cliccano nello stesso istante, uno dei due riceve un errore gestito con un messaggio chiaro. Due contratti sullo stesso box non possono esistere.

La parte che di solito non si racconta

Questa storia ha un finale a nostre spese, ed è successo proprio su questo sito.

Il chatbot che risponde alle domande sul sito è un sistema RAG. Interrogato su TrovaStorage, ha spiegato tranquillamente che il prodotto offre «un editor con vincoli intelligenti». Eppure la scheda che gli avevamo dato noi diceva nero su bianco che dentro non c’è nessuna componente di intelligenza artificiale.

La colpa non era del modello, ma di come avevamo spezzato il testo: in blocchi di lunghezza fissa, senza tener conto delle sezioni. La precisazione stava in fondo alla scheda, quindi nel secondo blocco. Alla domanda sull’editor la ricerca semantica restituiva solo il primo. Il modello ha ricevuto l’affermazione senza il limite che la accompagnava e ha riempito il buco con l’aggettivo più a portata di mano.

La correzione è stata editoriale, non architetturale: abbiamo spostato la precisazione nello stesso blocco dell’affermazione a cui si riferisce.

Da quel giorno ci portiamo dietro questo principio: un modello non sa quello che non gli abbiamo dato, e quel vuoto non resta vuoto. Viene riempito con qualcosa di verosimile, spesso proprio con la parola che volevamo evitare.

A che punto siamo

Il pilota è finito e TrovaStorage è online su trovastorage.it. È l’elenco indipendente dei centri di self storage in Italia, gratuito per chi cerca, in cui ogni operatore gestisce la scheda del proprio centro e riceve le richieste.

Le funzioni del pilota di cui parla questo articolo (planimetria, vista isometrica, prenotazione) oggi non sono attive. Il criterio che ci ha guidati, invece, è rimasto lo stesso. Come funziona TrovaStorage oggi lo trovi nella pagina del prodotto.


Hai un problema e non sei sicuro che serva un modello per risolverlo? Scrivici. A volte la risposta onesta è no, ma vale comunque la pena parlarne.