{"id":54421,"date":"2026-07-01T14:39:10","date_gmt":"2026-07-01T14:39:10","guid":{"rendered":"https:\/\/www.carmatec.com\/?p=54421"},"modified":"2026-07-01T14:41:50","modified_gmt":"2026-07-01T14:41:50","slug":"scalabilita-dellinfrastruttura-di-intelligenza-artificiale-per-la-crescita-aziendale","status":"publish","type":"post","link":"https:\/\/www.carmatec.com\/it_it\/ai-infrastructure-scaling-for-enterprise-growth\/","title":{"rendered":"Come sviluppare pratiche di ingegneria dell'IA scalabili per la crescita aziendale"},"content":{"rendered":"

Un CTO con cui abbiamo parlato di recente aveva undici progetti pilota di IA in corso in tutta l\u2019azienda. Un chatbot nell\u2019assistenza clienti. Uno strumento di sintesi dei documenti nell\u2019ufficio legale. Tre team diversi, che lavoravano in modo indipendente, stavano sviluppando ciascuno la propria versione di una \u201cfunzionalit\u00e0 di ricerca nei nostri documenti interni\u201d. Nessuno di loro comunicava con gli altri. Nessuno di loro disponeva di una dashboard di monitoraggio. Uno di questi progetti era gi\u00e0 stato accantonato dopo che il data scientist che lo aveva sviluppato aveva lasciato l\u2019azienda.<\/span><\/p>\n

Non \u00e8 una storia insolita. \u00c8 piuttosto lo stato attuale dell'IA aziendale.<\/span><\/p>\n

La maggior parte delle aziende ha ormai superato la fase in cui ci si chiedeva se fosse il caso di provare l\u2019IA. Hanno condotto progetti pilota, ne hanno dimostrato il valore in casi specifici e hanno acquisito la convinzione interna che l\u2019IA possa svolgere un lavoro utile. La domanda pi\u00f9 complessa \u00e8 quella che determina effettivamente se l\u2019IA sia redditizia: cosa succede quando deve operare contemporaneamente tra team, sistemi e unit\u00e0 aziendali diversi?.<\/span><\/p>\n

\u00c8 proprio qui che il ridimensionamento dell\u2019infrastruttura di intelligenza artificiale diventa il vero progetto. Non il modello, ma il sistema che ruota attorno al modello.<\/span><\/p>\n

Perch\u00e9 la scalabilit\u00e0 dell'IA risulta difficile nelle aziende<\/h2>\n

I progetti pilota hanno successo proprio perch\u00e9 sono su piccola scala: un solo team, un solo caso d\u2019uso, un solo set di dati e rischi contenuti in caso di malfunzionamenti. Il passaggio a scala pi\u00f9 ampia elimina tutte e quattro queste protezioni in un colpo solo, ed \u00e8 proprio in quel momento che iniziano a emergere i problemi che erano invisibili quando il progetto era ancora in fase pilota.<\/span><\/p>\n

Ci sono alcuni aspetti che tendono a caratterizzare ogni prototipo che fatica a trasformarsi in un sistema di produzione. \u00c8 stato realizzato al di fuori dei normali standard ingegneristici, da un data scientist o da un fornitore che ha agito in fretta, senza revisione del codice n\u00e9 disciplina di implementazione, perch\u00e9 funzionava abbastanza bene da non spingere nessuno a ritoccarlo per renderlo pi\u00f9 solido. La pipeline di dati che lo alimenta \u00e8 stata progettata per un\u2019esportazione una tantum o per l\u2019aggiornamento di una dashboard, non per un modello che necessita ogni singolo giorno di dati freschi e convalidati. I costi del cloud e delle GPU aumentano senza che nessuno li monitori in base al caso d\u2019uso, quindi il reparto finanziario si ritrova con una fattura pi\u00f9 alta senza una risposta chiara su quale team o flusso di lavoro ne sia responsabile.<\/span><\/p>\n

Spesso il monitoraggio \u00e8 del tutto assente. L\u2019accuratezza \u00e8 stata verificata una sola volta, durante la fase di test, e da allora nessuno ci ha pi\u00f9 fatto caso, il che significa che nessuno si accorge quando, sei mesi dopo, i dati di input subiscono una deriva e i risultati peggiorano silenziosamente. La responsabilit\u00e0 tra i team che si occupano di dati, ingegneria, prodotto e business \u00e8 raramente chiara, quindi quando qualcosa non funziona, passano giorni prima che qualcuno si assuma effettivamente la responsabilit\u00e0 di risolvere il problema. Anche la sicurezza e la conformit\u00e0 sono solitamente un ripensamento: i dati sensibili finiscono in un prompt o in un set di dati di ottimizzazione prima che qualcuno si fermi a chiedersi se ci\u00f2 fosse consentito.<\/span><\/p>\n

E, in fondo, di solito non esiste un\u2019architettura riutilizzabile. Ogni nuovo caso d\u2019uso parte da zero, con una nuova pipeline, un nuovo processo di distribuzione, una nuova configurazione di monitoraggio, realizzati da chiunque si occupi di quel particolare progetto.<\/span><\/p>\n

Nulla di tutto ci\u00f2 significa che i modelli in s\u00e9 siano carenti. La maggior parte dei fallimenti dell\u2019IA aziendale non sono dovuti a difetti dei modelli, bens\u00ec a una mancanza di maturit\u00e0 ingegneristica. Il modello fa esattamente ci\u00f2 per cui \u00e8 stato progettato. \u00c8 il sistema che lo circonda, ovvero la parte responsabile di garantire affidabilit\u00e0, sicurezza e controllo dei costi su larga scala, che non \u00e8 mai stato progettato per reggere tale carico.<\/span><\/p>\n

Cosa significa realmente \"ingegneria dell'IA scalabile\"<\/h2>\n

Un'architettura IA scalabile non \u00e8 semplicemente una versione pi\u00f9 grande del prototipo. Si tratta di una categoria diversa di sistema, realizzata con la stessa rigore che ci si aspetterebbe da qualsiasi altro software di produzione.<\/span><\/p>\n

In che modo le aziende possono scalare l'infrastruttura di IA? In pratica, si tratta di una manciata di livelli fondamentali a cui ogni caso d'uso di IA pu\u00f2 collegarsi, invece di dover ricreare una propria versione di ciascuno di essi.<\/span><\/p>\n

Le pipeline di dati devono essere riutilizzabili: logiche di acquisizione, convalida e trasformazione a cui qualsiasi modello o flusso di lavoro possa attingere, anzich\u00e9 uno script una tantum scritto per un singolo progetto. L\u2019implementazione richiede un flusso di lavoro coerente e ripetibile per trasferire un modello dallo sviluppo alla produzione, con fasi di test lungo il percorso. \u00c8 necessario disporre di un vero e proprio livello di API e integrazione, in modo che i risultati dell\u2019IA possano effettivamente raggiungere i sistemi che li utilizzano, che si tratti di un CRM, di un ERP, di un portale interno o di un\u2019app rivolta ai clienti.<\/span><\/p>\n

Il monitoraggio e l'osservabilit\u00e0 sono pi\u00f9 importanti di quanto la maggior parte dei team pensi all'inizio. Non basta sapere che un servizio \u00e8 tecnicamente attivo; occorre avere visibilit\u00e0 su precisione, latenza, costi e deviazioni. \u00c8 inoltre necessario definire un percorso chiaro per la revisione umana, in modo che, quando un modello \u00e8 incerto o errato, qualcuno se ne accorga prima che si trasformi in un incidente di produzione, anzich\u00e9 dopo.<\/span><\/p>\n

Il resto riguarda in gran parte attivit\u00e0 di governance: sicurezza e controllo degli accessi sui dati a cui un modello pu\u00f2 accedere e su chi pu\u00f2 interrogarlo, controllo delle versioni su dati, prompt, modelli e output in modo da poter rispondere alla domanda \u201ccosa \u00e8 cambiato e quando\u201d senza dover tirare a indovinare, visibilit\u00e0 dei costi fino al livello del carico di lavoro e una tracciabilit\u00e0 sufficiente a soddisfare chiunque chieda come sia stato approvato un sistema e quali siano le sue prestazioni.<\/span><\/p>\n

Il ridimensionamento dell'infrastruttura di IA non consiste nell'aggiungere maggiore potenza di calcolo o un cluster di GPU pi\u00f9 grande. Si tratta piuttosto di creare il modello operativo, l'architettura e la governance che consentano all'IA di funzionare in modo affidabile senza che un team di persone debba monitorarla manualmente.<\/span><\/p>\n

L'impatto aziendale di un'ingegneria dell'IA carente<\/h2>\n

Il costo derivante dal tralasciare questo lavoro non si manifesta immediatamente. Tende a emergere dopo sei-dodici mesi, quando ormai porvi rimedio risulta molto costoso.<\/span><\/p>\n

I costi dell\u2019infrastruttura aumentano pi\u00f9 rapidamente del previsto, poich\u00e9 nessuno ha monitorato la spesa in base al carico di lavoro sin dall\u2019inizio. L\u2019implementazione rallenta, poich\u00e9 ogni nuovo caso d\u2019uso deve risolvere gli stessi problemi di integrazione e implementazione gi\u00e0 riscontrati in precedenza. I rischi legati alla conformit\u00e0 e alla sicurezza si accumulano silenziosamente, specialmente ovunque i dati dei clienti o dei dipendenti entrino in contatto con un modello. La fiducia interna nei risultati dell\u2019IA si erode non appena alcune previsioni errate rimangono senza spiegazione, e i team iniziano a duplicare gli sforzi perch\u00e9 manca una base condivisa su cui costruire. Le esperienze rivolte ai clienti o ai dipendenti diventano instabili quando un modello che funzionava bene in fase di test subisce un calo di prestazioni in produzione e nessuno se ne accorge per settimane.<\/span><\/p>\n

Mettendo insieme tutti questi elementi, si ottiene ci\u00f2 che pu\u00f2 essere meglio definito come \u201cdebito tecnico dell\u2019IA\u201d.<\/span><\/p>\n

La gestione del debito tecnico nell\u2019ambito dell\u2019intelligenza artificiale \u00e8 una disciplina diversa dalla gestione del debito in un normale codice sorgente. Non si limita al codice disordinato. Si manifesta sotto forma di modifiche ai prompt non tracciate che alterano silenziosamente il comportamento, set di dati di cui nessuno riesce a risalire alla fonte, integrazioni punto a punto fragili che si interrompono nel momento in cui un sistema a monte cambia, monitoraggio che semplicemente non esiste e soluzioni manuali che andavano bene su scala pilota ma diventano davvero rischiose quando un centinaio di persone dipendono quotidianamente dai risultati. Pi\u00f9 a lungo rimane irrisolto, pi\u00f9 rallenta ogni iniziativa di IA che lo segue.<\/span><\/p>\n

Errori comuni commessi dalle aziende nell'implementazione su larga scala dell'IA<\/h2>\n

Quando veniamo coinvolti per aiutare un\u2019azienda a passare dalla fase pilota alla produzione, ci sono alcuni schemi ricorrenti che si ripetono continuamente.<\/span><\/p>\n

L'errore pi\u00f9 comune \u00e8 quello di considerare un progetto pilota come se fosse gi\u00e0 pronto per la produzione. Non \u00e8 mai stato sottoposto a test di carico, n\u00e9 \u00e8 mai stato verificato dal punto di vista della sicurezza, ed \u00e8 stato spesso realizzato da una sola persona che dava per scontato di essere sempre disponibile a occuparsene. Subito dopo c\u2019\u00e8 la scelta di una piattaforma o di uno strumento prima che qualcuno abbia definito i requisiti operativi: chi \u00e8 responsabile del monitoraggio, chi ne sostiene i costi, come si presenta il piano di rollback. Anche la qualit\u00e0 dei dati e il controllo degli accessi vengono sottovalutati, perch\u00e9 il modello ha funzionato bene in una demo basata su dati puliti e selezionati con cura, e nessuno lo ha sottoposto a test di stress con il set di dati disordinato su cui verrebbe effettivamente eseguito in produzione.<\/span><\/p>\n

Spesso l\u2019MLOps viene ignorato fino a quando i modelli non sono gi\u00e0 stati implementati, il che rende l\u2019integrazione a posteriori del monitoraggio e del controllo delle versioni in un sistema gi\u00e0 operativo molto pi\u00f9 costosa rispetto alla loro integrazione fin dall\u2019inizio. I team sviluppano casi d\u2019uso di IA isolati, senza un\u2019architettura condivisa, per cui ogni gruppo reinventa da s\u00e9 la distribuzione, la registrazione degli eventi e l\u2019integrazione. Il costo per caso d\u2019uso, flusso di lavoro o reparto viene raramente monitorato, quindi quando la direzione finanziaria pone delle domande non c\u2019\u00e8 un modo chiaro per rispondere. La responsabilit\u00e0 per la deriva dei modelli, i guasti o gli aggiornamenti viene raramente assegnata, quindi quando qualcosa non funziona, la prima reazione \u00e8 solitamente \u201cdi chi \u00e8 questo problema?\u201d, invece di seguire un percorso di escalation definito. Inoltre, le modifiche ai prompt o ai modelli vengono implementate senza controllo delle versioni con una frequenza tale che capita spesso che qualcuno risolva un problema e ne crei silenziosamente altri tre, senza alcun modo di tracciare cosa sia effettivamente cambiato.<\/span><\/p>\n

Non si tratta di problemi insoliti. Sono le stesse lacune nella disciplina operativa che si riscontrano in qualsiasi programma software non ancora maturo. L\u2019intelligenza artificiale non fa altro che accelerare il processo e aumentare i costi quando tali lacune non vengono colmate.<\/span><\/p>\n

Migliori pratiche MLOps aziendali per una crescita sostenibile<\/h2>\n

Quali sono le migliori pratiche relative al MLOps aziendale? In sostanza, il MLOps \u00e8 ci\u00f2 che rende sostenibile il ridimensionamento dell\u2019infrastruttura di IA, evitando che si tratti di un progetto una tantum.<\/span><\/p>\n

Il primo passo consiste nel standardizzare lo sviluppo e la distribuzione dei modelli, in modo che ogni team segua lo stesso processo anzich\u00e9 uno proprio. I test e la convalida dovrebbero essere automatizzati prima che qualsiasi cosa raggiunga la produzione, verificando i casi limite e non solo l\u2019accuratezza nei casi medi. Le versioni dei modelli, dei prompt e dei set di dati devono essere monitorate in modo che qualsiasi output possa essere ricondotto esattamente a ci\u00f2 che lo ha generato, e il monitoraggio dovrebbe coprire accuratezza, latenza, deriva e costo, non solo il tempo di attivit\u00e0.<\/span><\/p>\n

I processi di rollback ed escalation devono essere definiti prima che se ne presenti la necessit\u00e0, non inventati durante un incidente. I principi CI\/CD dovrebbero applicarsi ai sistemi di IA allo stesso modo in cui si applicano a qualsiasi altro software di produzione, e l\u2019accesso ai dati dovrebbe essere protetto separatamente negli ambienti di sviluppo, staging e produzione, anzich\u00e9 condividere le stesse autorizzazioni. I controlli di governance devono essere effettuati prima della distribuzione in produzione, in particolare per tutto ci\u00f2 che riguarda i clienti o \u00e8 soggetto a normative, ed \u00e8 pi\u00f9 vantaggioso per i team creare componenti riutilizzabili, un livello di recupero condiviso e una pipeline di distribuzione condivisa, piuttosto che scrivere script isolati per ogni progetto.<\/span><\/p>\n

In realt\u00e0, nulla di tutto ci\u00f2 \u00e8 esclusivo dell\u2019IA. Si tratta della stessa disciplina che, un decennio fa, ha reso affidabili l\u2019infrastruttura cloud e il DevOps, applicata ora a una nuova classe di sistemi che, per caso, sono probabilistici anzich\u00e9 deterministici.<\/span><\/p>\n

Un approccio pratico alla realizzazione di un'architettura di intelligenza artificiale scalabile<\/h2>\n

In che modo le aziende possono passare dalla fase pilota alla produzione con l\u2019IA? Un percorso strutturato tende a dare risultati migliori rispetto al tentativo di risolvere tutto in una volta.<\/span><\/p>\n

Iniziate valutando i casi d\u2019uso esistenti dell\u2019IA e il livello di maturit\u00e0 dell\u2019infrastruttura: cosa \u00e8 effettivamente in esecuzione, chi ne \u00e8 responsabile, come \u00e8 stato realizzato. Da l\u00ec, individuate dove esiste gi\u00e0 un debito tecnico legato all\u2019IA, prompt non monitorati, fonti di dati non documentate e lacune nel monitoraggio, prima che siano questi aspetti a individuarvi di loro iniziativa. Definisci quali carichi di lavoro sono effettivamente critici per l\u2019azienda, perch\u00e9 non tutti i progetti pilota meritano un investimento in produzione e alcuni dovrebbero semplicemente essere dismessi.<\/span><\/p>\n

Una volta chiarito questo punto, occorre costruire le basi condivise per i dati, l\u2019integrazione e la distribuzione su cui si fonderanno i futuri casi d\u2019uso, e implementare MLOps, monitoraggio e governance attorno ad esse, in modo che l\u2019affidabilit\u00e0 e la responsabilit\u00e0 siano parte integrante del sistema anzich\u00e9 un elemento aggiunto a posteriori. L\u2019ottimizzazione dei costi e delle prestazioni viene dopo, ed \u00e8 molto pi\u00f9 semplice una volta che si dispone di una visibilit\u00e0 reale. Solo allora le aziende dovrebbero espandersi gradualmente tra i vari reparti, riutilizzando le basi esistenti invece di ricostruirle per ogni nuovo team che voglia partecipare.<\/span><\/p>\n

Non tutti gli esperimenti di intelligenza artificiale che hanno mostrato risultati promettenti nelle fasi iniziali meritano di essere portati su larga scala. Quelli su cui vale la pena investire combinano un chiaro valore aziendale, prontezza operativa e fattibilit\u00e0 tecnica, e vale la pena essere onesti riguardo a quelli che non soddisfano ancora tali requisiti.<\/span><\/p>\n

A cosa dovrebbero dare la priorit\u00e0 i CTO<\/h2>\n

Cosa distingue un'architettura di IA scalabile da una normale architettura software? Principalmente le dimensioni aggiuntive rappresentate dalla deriva, dalla volatilit\u00e0 dei costi e dai risultati probabilistici, che modificano il significato stesso dell'espressione \u201cpronto per la produzione\u201d.<\/span><\/p>\n

Ci sono alcune priorit\u00e0 che tendono ad assumere maggiore importanza per i responsabili tecnici che devono affrontare questa situazione. Quali carichi di lavoro necessitano realmente di un\u2019architettura di livello produttivo, rispetto a quelli che possono tranquillamente rimanere su scala pilota. Dove i costi dell\u2019infrastruttura sono destinati a crescere pi\u00f9 rapidamente e se \u00e8 possibile avere visibilit\u00e0 su questo aspetto prima che diventi un argomento di discussione con la direzione finanziaria. Cosa dovrebbe essere gestito a livello centrale (pipeline di dati, strumenti di distribuzione, monitoraggio) e cosa invece dovrebbe essere di competenza diretta dei singoli team. Quali controlli di governance sono imprescindibili, in particolare per quanto riguarda l\u2019accesso ai dati e qualsiasi aspetto soggetto a regolamentazione. Come bilanciare la velocit\u00e0 di consegna con l\u2019affidabilit\u00e0 senza ricorrere all\u2019approccio \u201crilascia in fretta, correggi dopo\u201d per qualsiasi aspetto rivolto al cliente. E come evitare di ricostruire da zero le stesse basi di IA per ogni nuovo caso d\u2019uso che si presenta.<\/span><\/p>\n

Prendere le decisioni giuste sin dall\u2019inizio permette di risparmiare mesi di lavoro di rifinitura in seguito. Prendere decisioni sbagliate \u00e8 esattamente ci\u00f2 che porta un\u2019azienda ad avere undici progetti pilota scollegati tra loro e senza un responsabile chiaro per nessuno di essi.<\/span><\/p>\n

Il ruolo di Carmatec<\/h2>\n

Alla Carmatec, il nostro lavoro inizia solitamente con una semplice domanda: cosa deve continuare a funzionare una volta terminata la fase pilota?<\/span><\/p>\n

Abbiamo dedicato 22 anni alla realizzazione e all\u2019ammodernamento di sistemi di produzione per aziende operanti nei settori del fintech, della sanit\u00e0, della logistica e SaaS<\/a>, molto prima che \u201cingegneria delle piattaforme di IA\u201d diventasse una qualifica professionale. \u00c8 proprio questo background che mettiamo oggi al servizio del lavoro nel campo dell\u2019IA: la stessa disciplina ingegneristica, applicata a un nuovo tipo di sistema.<\/span><\/p>\n

In pratica, ci\u00f2 significa che Consulenza in materia di architettura dell'intelligenza artificiale<\/a> per definire quali siano le effettive esigenze della produzione, sviluppo di piattaforme di intelligenza artificiale su misura<\/a>, Implementazione di MLOps<\/a>, E RAG<\/a> oppure sistemi di conoscenza aziendale basati su dati interni reali anzich\u00e9 su un set di dati dimostrativo generico. Significa inoltre Integrazione dell'intelligenza artificiale<\/a> con i sistemi gi\u00e0 in uso nell'azienda, CRM<\/a>, ERP, infrastruttura cloud, perch\u00e9 un sistema di intelligenza artificiale che non si integra con i flussi di lavoro esistenti non viene utilizzato. Supportiamo il nuvola<\/a> E DevOps<\/a> il lavoro che sta alla base, la modernizzazione delle applicazioni che spesso deve avvenire parallelamente e l\u2019ottimizzazione continua una volta che il sistema \u00e8 operativo.<\/span><\/p>\n

Non la consideriamo una trasformazione in s\u00e9. Si tratta di un lavoro di ingegneria, svolto con lo stesso rigore di qualsiasi altro sistema produttivo da cui dipende un\u2019azienda.<\/span><\/p>\n

Conclusione<\/h2>\n

Intelligenza artificiale aziendale<\/a> La crescita non deriva dall'avviare un numero maggiore di progetti pilota. Deriva invece da pratiche ingegneristiche rigorose, da un'architettura che viene riutilizzata anzich\u00e9 ricostruita e da una chiara attribuzione delle responsabilit\u00e0 operative una volta che il prodotto \u00e8 in produzione.<\/span><\/p>\n

Le aziende che traggono un valore reale e duraturo dall\u2019intelligenza artificiale non sono quelle che conducono il maggior numero di esperimenti. Sono invece quelle che hanno creato l\u2019infrastruttura, i meccanismi di governance e i sistemi di monitoraggio necessari per garantire il funzionamento affidabile di un numero pi\u00f9 ristretto di sistemi ad alto valore aggiunto, e che hanno continuato a sviluppare su quelle basi invece di ricominciare da zero ogni volta.<\/span><\/p>\n

\u00c8 proprio questo cambiamento, pi\u00f9 di qualsiasi modello o strumento specifico, a distinguere i \u201cpiloti dell\u2019IA\u201d che rimangono semplici \u201cpiloti\u201d dai sistemi di IA che contribuiscono effettivamente a far progredire l\u2019azienda.<\/span><\/p>\n

Contatta il team di Carmatec<\/a> per valutare il vostro attuale approccio ingegneristico all'intelligenza artificiale e individuare gli aspetti da potenziare prima di procedere a un'ulteriore espansione.<\/span><\/p>","protected":false},"excerpt":{"rendered":"

A CTO we spoke with recently had eleven AI pilots running across the business. A chatbot in customer support. A document summarizer in legal. Three different teams, independently, building their own version of \u201csearch over our internal docs.\u201d None of them talked to each other. None of them had a monitoring dashboard. One had already […]<\/p>\n","protected":false},"author":8,"featured_media":54422,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[71,4],"tags":[],"class_list":["post-54421","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-artificial-intelligence","category-blog"],"_links":{"self":[{"href":"https:\/\/www.carmatec.com\/it_it\/wp-json\/wp\/v2\/posts\/54421","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.carmatec.com\/it_it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.carmatec.com\/it_it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.carmatec.com\/it_it\/wp-json\/wp\/v2\/users\/8"}],"replies":[{"embeddable":true,"href":"https:\/\/www.carmatec.com\/it_it\/wp-json\/wp\/v2\/comments?post=54421"}],"version-history":[{"count":2,"href":"https:\/\/www.carmatec.com\/it_it\/wp-json\/wp\/v2\/posts\/54421\/revisions"}],"predecessor-version":[{"id":54424,"href":"https:\/\/www.carmatec.com\/it_it\/wp-json\/wp\/v2\/posts\/54421\/revisions\/54424"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.carmatec.com\/it_it\/wp-json\/wp\/v2\/media\/54422"}],"wp:attachment":[{"href":"https:\/\/www.carmatec.com\/it_it\/wp-json\/wp\/v2\/media?parent=54421"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.carmatec.com\/it_it\/wp-json\/wp\/v2\/categories?post=54421"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.carmatec.com\/it_it\/wp-json\/wp\/v2\/tags?post=54421"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}