ARC
Prezzi
Discord
Parli con un tecnicoInizi gratis
Inizi gratis
ARCdi FenxLabsCollective Intelligence

Piattaforma

  • Come funziona
  • Routing e governance su misura
  • Casi d’uso
  • Architetture di esempio

Deployment

  • Hosted Platform
  • Managed Service
  • Self-hosted Licence
  • Per gli ISV
  • Apra il portale

Servizi

  • Valutazione e pianificazione
  • Architettura e integrazione
  • Model Adaptation
  • Preparazione all’EU AI Act
  • Esercizio in Managed Service

Risorse

  • Simulatore di costi
  • Confronti gli approcci
  • Prezzi
  • FAQ
  • Trasparenza
  • Come iniziare
  • Community Discord

Note legali

  • Informativa sulla privacy
  • Termini e condizioni
  • Sub-responsabili del trattamento
  • Accessibilità

Per privati

  • FenxChat

FenxLabs. KvK 91762782.

Herengracht 320, 1016 CE Amsterdam, Netherlands

+31 85 060 5273contact@fenxlabs.ai

© 2026 FenxLabs. Tutti i diritti riservati.

Decida dove vive la policy

Quattro cose separano un piano di controllo da un gateway, da uno stack di IA in cloud o da uno sviluppo interno: il suo confine di rete, i modelli che già gestisce, i suoi dati, e dove viene presa la tariffa.

Parli con un tecnicoInizi gratis

Quattro domande che separano gli approcci

Dove gira FenxARC™, che cosa può raggiungere e come viene pagata FenxLabs: ogni approccio risponde in modo diverso. Le rivolga tutte e quattro alla sua rosa di candidati.

Il router gira dentro la sua rete?

La gestione delle richieste di ARC gira dentro la sua VPC, sul suo hardware o in un ambiente air-gapped. I percorsi interni possono restare dentro la sua rete; un percorso esterno approvato riceve comunque il contesto che gli serve.

Self-hosted Licence. La Hosted Platform gira sull’infrastruttura di FenxLabs.

Instrada verso i modelli che già gestisce?

Scoring antifrode, previsione della domanda, classificazione documentale. I modelli di machine learning e deep learning che già fa girare diventano destinazioni di routing accanto ai suoi modelli linguistici.

Self-hosted Licence.

La sua archiviazione vettoriale sta dietro?

Colleghi l’archiviazione vettoriale direttamente al router. Sta fra i modelli e i dati, e un modello arriva soltanto a ciò che ha il permesso di vedere.

Self-hosted Licence.

Dove prende la sua tariffa il fornitore?

L’inferenza resta un rapporto diretto fra lei e i suoi fornitori, alle tariffe che praticano loro. Noi non ci prendiamo alcun margine.

FenxLabs non rivende inferenza e non ha alcun rapporto commerciale con i produttori di modelli. Il router non ha alcuna ragione commerciale per preferire una destinazione a un’altra.

Tre di queste quattro appartengono alla Self-hosted Licence. Dove gira ARC è una decisione, che cosa applica ne è un’altra.

Scelga dove gira ARCEsplori la Self-hosted LicenceDove FenxLabs applica la sua commissione

ARC governa il livello dei modelli, non tutto lo stack

ARC governa il modo in cui utenti, applicazioni e agenti accedono a modelli, strumenti e fonti di dati approvate. Non governa il ragionamento di un agente, la sua pianificazione, la logica applicativa, il runtime o la responsabilità di business.

Le applicazioni tengono i loro flussi. I fornitori continuano a servire inferenza. ARC valuta ogni richiesta governata rispetto all’elenco attivo, applica le sue regole di ammissibilità e riservatezza, poi ordina ciò che le supera.

Un elenco raccoglie i modelli, gli strumenti e le regole approvati per un team o per un caso d’uso.

Veda come viene gestita una richiesta
Cinque approcci

Scelga un approccio di esercizio

Ciò che li separa è dove vive la regola che governa, e chi risponde del fatto che sia giusta.

Dove ciascuno dei cinque approcci colloca l’endpoint, la policy, l’approvazione per team, il trattamento della riservatezza e il rapporto con il fornitore, e chi ne risponde.
Che cosa serveIntegrazioni dirette con i fornitoriSDK dei fornitori, chiamati dal suo codicePiattaforma di IA in cloudPer esempio AWS Bedrock, Azure AIGateway o routerPer esempio LiteLLM, Portkey, HeliconeSviluppo internoARC
Un endpoint davanti a ogni modello○Lo costruisce leiOgni fornitore viene integrato a parte, dentro l’applicazione.◐Varia col prodottoDentro i servizi propri di quel cloud e gli endpoint collegati.●InclusoUn percorso di richiesta comune è la ragione d’essere della categoria.○Lo costruisce leiL’endpoint lo scrive lei e lo tiene funzionante lei.●InclusoUn URL di base compatibile con OpenAI per tutto ciò che è nell’elenco.
Policy che vive fuori dal codice dell’applicazione○Lo costruisce leiLe regole stanno dentro ogni carico che chiama un fornitore.◐Varia col prodottoDi solito divisa fra servizi cloud e configurazione dell’applicazione.◐Varia col prodottoQuanta policy tiene il gateway varia da prodotto a prodotto.○Lo costruisce leiQuello che costruisce il suo team, e che tiene aggiornato quando i modelli cambiano.●InclusoElenchi, etichette definite dal cliente e policy di routing, al livello dei modelli.
Un insieme approvato diverso per ogni team○Lo costruisce leiLo applica chi scrive ciascuna integrazione.◐Varia col prodottoDipende da come quella piattaforma modella multi-tenancy e accessi.◐Varia col prodottoDipende dal prodotto e da quanto si spinge il suo modello di policy.○Lo costruisce leiSta a lei progettarlo, e sta a lei tenerlo allineato quando i team cambiano.●InclusoUn elenco porta i modelli, gli strumenti e le policy approvati per quel team.
Riservatezza risolta prima di scegliere il modello○Lo costruisce leiQuello che ogni applicazione controlla prima di uscire.◐Varia col prodottoDipende dai servizi che stanno davanti alla chiamata al modello.◐Varia col prodottoDipende dal fatto che il prodotto valuti la policy prima di instradare.○Lo costruisce leiSta a lei definirla, e sta a lei dimostrarla a un revisore.●InclusoLe sue classi decidono l’ammissibilità, e l’ordinamento mette in fila solo ciò che resta.
I suoi conti e le sue tariffe con i fornitori●InclusoContratta direttamente con ogni fornitore.◐Varia col prodottoI costi dei modelli di solito arrivano sul conto cloud.◐Varia col prodottoChe la fatturazione del fornitore passi in trasparenza varia da prodotto a prodotto.●InclusoContratta direttamente con ogni fornitore.●InclusoL’inferenza resta fra lei e i suoi fornitori, alle loro tariffe.
Legga il dettaglioVeda come viene gestita una richiesta
Approcci da confrontare

Ne scelga uno o due. Le risposte compaiono qui sotto, un criterio alla volta.

Un endpoint davanti a ogni modello

Integrazioni dirette con i fornitori · SDK dei fornitori, chiamati dal suo codice
○Lo costruisce leiOgni fornitore viene integrato a parte, dentro l’applicazione.
Piattaforma di IA in cloud · Per esempio AWS Bedrock, Azure AI
◐Varia col prodottoDentro i servizi propri di quel cloud e gli endpoint collegati.
Gateway o router · Per esempio LiteLLM, Portkey, Helicone
●InclusoUn percorso di richiesta comune è la ragione d’essere della categoria.
Sviluppo interno
○Lo costruisce leiL’endpoint lo scrive lei e lo tiene funzionante lei.
ARC
●InclusoUn URL di base compatibile con OpenAI per tutto ciò che è nell’elenco.

Policy che vive fuori dal codice dell’applicazione

Integrazioni dirette con i fornitori · SDK dei fornitori, chiamati dal suo codice
○Lo costruisce leiLe regole stanno dentro ogni carico che chiama un fornitore.
Piattaforma di IA in cloud · Per esempio AWS Bedrock, Azure AI
◐Varia col prodottoDi solito divisa fra servizi cloud e configurazione dell’applicazione.
Gateway o router · Per esempio LiteLLM, Portkey, Helicone
◐Varia col prodottoQuanta policy tiene il gateway varia da prodotto a prodotto.
Sviluppo interno
○Lo costruisce leiQuello che costruisce il suo team, e che tiene aggiornato quando i modelli cambiano.
ARC
●InclusoElenchi, etichette definite dal cliente e policy di routing, al livello dei modelli.

Un insieme approvato diverso per ogni team

Integrazioni dirette con i fornitori · SDK dei fornitori, chiamati dal suo codice
○Lo costruisce leiLo applica chi scrive ciascuna integrazione.
Piattaforma di IA in cloud · Per esempio AWS Bedrock, Azure AI
◐Varia col prodottoDipende da come quella piattaforma modella multi-tenancy e accessi.
Gateway o router · Per esempio LiteLLM, Portkey, Helicone
◐Varia col prodottoDipende dal prodotto e da quanto si spinge il suo modello di policy.
Sviluppo interno
○Lo costruisce leiSta a lei progettarlo, e sta a lei tenerlo allineato quando i team cambiano.
ARC
●InclusoUn elenco porta i modelli, gli strumenti e le policy approvati per quel team.

Riservatezza risolta prima di scegliere il modello

Integrazioni dirette con i fornitori · SDK dei fornitori, chiamati dal suo codice
○Lo costruisce leiQuello che ogni applicazione controlla prima di uscire.
Piattaforma di IA in cloud · Per esempio AWS Bedrock, Azure AI
◐Varia col prodottoDipende dai servizi che stanno davanti alla chiamata al modello.
Gateway o router · Per esempio LiteLLM, Portkey, Helicone
◐Varia col prodottoDipende dal fatto che il prodotto valuti la policy prima di instradare.
Sviluppo interno
○Lo costruisce leiSta a lei definirla, e sta a lei dimostrarla a un revisore.
ARC
●InclusoLe sue classi decidono l’ammissibilità, e l’ordinamento mette in fila solo ciò che resta.

I suoi conti e le sue tariffe con i fornitori

Integrazioni dirette con i fornitori · SDK dei fornitori, chiamati dal suo codice
●InclusoContratta direttamente con ogni fornitore.
Piattaforma di IA in cloud · Per esempio AWS Bedrock, Azure AI
◐Varia col prodottoI costi dei modelli di solito arrivano sul conto cloud.
Gateway o router · Per esempio LiteLLM, Portkey, Helicone
◐Varia col prodottoChe la fatturazione del fornitore passi in trasparenza varia da prodotto a prodotto.
Sviluppo interno
●InclusoContratta direttamente con ogni fornitore.
ARC
●InclusoL’inferenza resta fra lei e i suoi fornitori, alle loro tariffe.
Legga il dettaglio
Veda come viene gestita una richiesta
«Incluso» significa che l’approccio lo fornisce. «Lo costruisce lei» significa che lo lascia al suo team. «Varia col prodotto» significa che dentro quella categoria cambia davvero, ed è una domanda da portare alla sua rosa di candidati più che una a cui questa pagina possa rispondere.

Gli stessi cinque, per esteso

A che cosa è adatto, dove vive la policy, la scelta del modello, il carico per il team e il compromesso principale, per ciascuno dei cinque approcci.
DomandaIntegrazioni dirette con i fornitoriSDK dei fornitori, chiamati dal suo codicePiattaforma di IA in cloudPer esempio AWS Bedrock, Azure AIGateway o routerPer esempio LiteLLM, Portkey, HeliconeSviluppo internoARC
Adatto soprattutto aUn piccolo numero di carichi stabili legati a un solo fornitore.Organizzazioni che standardizzano con decisione su un solo modello cloud.Team che hanno bisogno soprattutto di un endpoint comune, di astrazione dei fornitori e di controlli sul traffico.Team con requisiti insoliti e la capacità di farsi carico di un piano di controllo come prodotto.Organizzazioni che vogliono una scelta governata fra modelli, strumenti, fornitori e ambienti.
Dove vive la policyOgni applicazione, o ogni configurazione di fornitore.Servizi cloud più configurazione dell’applicazione.Configurazione del gateway e logica dell’applicazione.Il suo codice e il suo ambiente di esercizio.Elenchi, etichette definite dal cliente e policy di routing al livello dei modelli.
Scelta del modelloLimitata al fornitore collegato e alla logica propria dell’applicazione.Dipende dalla piattaforma e dagli endpoint collegati a essa.Dipende dal routing del gateway e dai fornitori supportati.Quello che il suo team integra e tiene funzionante.I modelli e gli strumenti approvati nell’elenco attivo.
Carico per il teamIntegrazioni e policy mantenute dentro ogni carico di lavoro.Governance allineata ai servizi e ai confini di quel cloud.Policy di routing definita, provata e mantenuta dal suo team.Progetto, sicurezza, valutazione, esercizio e cambiamenti, tutto suo.La policy e i rapporti con i fornitori restano suoi. ARC applica quella policy a ogni richiesta governata.
Compromesso principaleSemplice all’inizio. I cambiamenti si moltiplicano man mano che crescono fornitori e team.Integrazione ampia con la piattaforma, con decisioni plasmate da quella piattaforma.Connettività utile. La profondità di governance e le opzioni di deployment variano da prodotto a prodotto.Massima personalizzazione, contro un carico permanente di prodotto e di esercizio.Un livello in più da integrare e da governare.
Legga il dettaglioVeda come viene gestita una richiesta
Approcci da confrontare, in dettaglio

Ne scelga uno o due. Le risposte compaiono qui sotto, un criterio alla volta.

Adatto soprattutto a

Integrazioni dirette con i fornitori · SDK dei fornitori, chiamati dal suo codice
Un piccolo numero di carichi stabili legati a un solo fornitore.
Piattaforma di IA in cloud · Per esempio AWS Bedrock, Azure AI
Organizzazioni che standardizzano con decisione su un solo modello cloud.
Gateway o router · Per esempio LiteLLM, Portkey, Helicone
Team che hanno bisogno soprattutto di un endpoint comune, di astrazione dei fornitori e di controlli sul traffico.
Sviluppo interno
Team con requisiti insoliti e la capacità di farsi carico di un piano di controllo come prodotto.
ARC
Organizzazioni che vogliono una scelta governata fra modelli, strumenti, fornitori e ambienti.

Dove vive la policy

Integrazioni dirette con i fornitori · SDK dei fornitori, chiamati dal suo codice
Ogni applicazione, o ogni configurazione di fornitore.
Piattaforma di IA in cloud · Per esempio AWS Bedrock, Azure AI
Servizi cloud più configurazione dell’applicazione.
Gateway o router · Per esempio LiteLLM, Portkey, Helicone
Configurazione del gateway e logica dell’applicazione.
Sviluppo interno
Il suo codice e il suo ambiente di esercizio.
ARC
Elenchi, etichette definite dal cliente e policy di routing al livello dei modelli.

Scelta del modello

Integrazioni dirette con i fornitori · SDK dei fornitori, chiamati dal suo codice
Limitata al fornitore collegato e alla logica propria dell’applicazione.
Piattaforma di IA in cloud · Per esempio AWS Bedrock, Azure AI
Dipende dalla piattaforma e dagli endpoint collegati a essa.
Gateway o router · Per esempio LiteLLM, Portkey, Helicone
Dipende dal routing del gateway e dai fornitori supportati.
Sviluppo interno
Quello che il suo team integra e tiene funzionante.
ARC
I modelli e gli strumenti approvati nell’elenco attivo.

Carico per il team

Integrazioni dirette con i fornitori · SDK dei fornitori, chiamati dal suo codice
Integrazioni e policy mantenute dentro ogni carico di lavoro.
Piattaforma di IA in cloud · Per esempio AWS Bedrock, Azure AI
Governance allineata ai servizi e ai confini di quel cloud.
Gateway o router · Per esempio LiteLLM, Portkey, Helicone
Policy di routing definita, provata e mantenuta dal suo team.
Sviluppo interno
Progetto, sicurezza, valutazione, esercizio e cambiamenti, tutto suo.
ARC
La policy e i rapporti con i fornitori restano suoi. ARC applica quella policy a ogni richiesta governata.

Compromesso principale

Integrazioni dirette con i fornitori · SDK dei fornitori, chiamati dal suo codice
Semplice all’inizio. I cambiamenti si moltiplicano man mano che crescono fornitori e team.
Piattaforma di IA in cloud · Per esempio AWS Bedrock, Azure AI
Integrazione ampia con la piattaforma, con decisioni plasmate da quella piattaforma.
Gateway o router · Per esempio LiteLLM, Portkey, Helicone
Connettività utile. La profondità di governance e le opzioni di deployment variano da prodotto a prodotto.
Sviluppo interno
Massima personalizzazione, contro un carico permanente di prodotto e di esercizio.
ARC
Un livello in più da integrare e da governare.
Legga il dettaglio
Veda come viene gestita una richiesta
Le funzionalità variano da prodotto a prodotto e cambiano nel tempo. Usi questo per scegliere un approccio, poi verifichi i requisiti precisi durante la valutazione.

L’ammissibilità viene prima dell’ordinamento, quindi niente nel passaggio di ordinamento può raggiungere una destinazione che la policy ha escluso.

Veda come viene gestita una richiesta

Da chiedere prima di impegnarsi

Queste domande separano un approccio di esercizio da un elenco di funzioni. Le rivolga a ogni opzione della rosa, ARC compreso.

  • Possiamo governare modelli e strumenti con la stessa policy di richiesta?
  • Ogni team può avere il suo insieme approvato senza fissarlo dentro ogni applicazione?
  • Possiamo tenere i nostri rapporti e le nostre tariffe dirette con i fornitori?
  • Lo stesso modello di policy può girare hosted, managed o self-hosted?
  • Che cosa dovrà costruire, provare e gestire il nostro team dopo la prima integrazione?

ARC non serve per ogni carico di lavoro

Un fornitore, un modello e controlli a livello di applicazione possono coprire tutto ciò che riesce a prevedere. Un secondo livello di controllo sarebbe allora un costo senza ritorno.

  • Un carico e un fornitore. Non c’è ancora niente fra cui instradare.
  • Tracciamento, valutazione e versionamento dei prompt. Compri uno strumento fatto per quello.
  • Un percorso cambia quali destinazioni approvate girano. Non rende migliore nessun modello.

ARC è fatto per il caso in cui categorie di carico, scelta dei modelli, trattamento della riservatezza, policy di accesso e confini di deployment devono variare da team a team senza riscrivere ogni carico di lavoro.

Dove si colloca ARC in ambienti realiScelga dove gira ARCQuanto costaIntegri ARC nel suo software

Confronti ARC con il suo approccio attuale

Porti un carico di lavoro e un vincolo. Le diremo se il routing cambia qualcosa per lei.

Parli con un tecnicoInizi gratis