Shadow AI? Dai forza al tuo team.
Nelle aziende le app nascono ovunque. Un reparto ha un problema, qualcuno apre un agente AI e in pochi giorni c'è un'app per gli appuntamenti, il budget o le richieste d'acquisto. È shadow IT, e con l'AI corre più veloce di qualsiasi piano.
Bloccarla non funziona, e spegne le idee migliori. Pyrite fa il contrario: dà al team un modo sicuro per costruire, e all'IT un posto solo dove queste app vivono, con accessi, dati e backup sotto controllo.
«Non serve fermare chi costruisce. Serve dargli un posto dove farlo bene.»
Pyrite per le aziendeDall'idea del reparto all'app di tutti.
Cinque tappe, dall'idea all'app in produzione. Accanto a ciascuna, cosa c'è già nell'alpha 0.7.7.
Il reparto ha un problema.
Chi ci lavora lo conosce meglio di tutti: gli appuntamenti da tenere in un'unica lista, un budget da far convalidare, le richieste d'acquisto da approvare.
Uno standard per costruire. Portabile e open source.
Abbiamo scritto una skill per gli agenti AI. Il reparto, o un consulente, la dà all'agente che preferisce, e l'agente costruisce un'app PocketBase normale, già sicura, con una scheda app.json che dichiara tipo, accesso e ruoli.
Un pacchetto compatibile.
Uno zip con la scheda, le pagine e, per le app con dati, hook e migrazioni: le cartelle di un normale progetto PocketBase. I dati veri e gli account di prova restano fuori.
pacchetto zip per «Carica app»L'IT controlla e approva.
L'IT guarda la scheda e il codice e decide chi può entrare. Se l'app l'ha caricata un Admin, resta ferma finché un Proprietario non la approva.
disponibile controllo automatico del codice: dimostrativoPoi è un'app come le altre.
Accessi, stato, consumi, backup e archiviazione dalla stessa console, nello stesso modo per tutte le app.
disponibileLe regole le decidi tu. Il motore le fa rispettare.
Accessi, ruoli e dati di tutte le app dei reparti si governano in un punto solo. Il motore applica le regole a ogni richiesta, per ogni app.
- 03.1Chi entra lo decidi tu
- Accessi granulari, app per app, a una persona o a un gruppo, da una rubrica unica. Ogni richiesta passa dal motore: un accesso tolto vale subito, su tutte le app.
- 03.2Ruoli dentro ogni app
- Ogni app dichiara i suoi ruoli, dal più al meno potente, e il ruolo base di chi entra la prima volta. Cosa vede e modifica ogni ruolo lo decidono le regole sui record, lato server.
- 03.3Quattro livelli per amministrare
- Proprietario, Admin Persone, Admin App e Utente. Chi amministra vede solo le sue persone o le sue app, e le app che carica un Admin restano ferme finché un Proprietario non le approva. Con le unità un solo motore serve più clienti, e ognuno vede solo le sue cose. Nella console quello che nessuna regola permette è negato.
- 03.4Sessioni sotto controllo
- Le chiavi della console stanno solo in memoria; la sessione si chiude da sola dopo 30 minuti senza uso, non dura mai più di 12 ore e decade se la persona viene disattivata o cambia livello. Si può aggiungere la doppia autenticazione, con un codice dal telefono. Il cookie del portale non arriva mai alle app.
- 03.5Identità bloccate
- Nome, email e password vengono dalla rubrica: un'app non crea utenti e nessuno cambia il proprio ruolo. Il token usato nell'app deve appartenere alla persona della sessione.
- 03.6Nessun amministratore nascosto
- Ogni app ha un amministratore tecnico con una password casuale che usa solo il motore: le chiamate da amministratore sulle porte delle app vengono respinte. La registrazione libera è chiusa.
- 03.7Ogni app nel suo recinto
- Processo, chiave e porta interna propri. Gli script non avviano programmi, leggono solo la cartella dell'app, scrivono solo nei suoi dati e non possono toccare la scheda. Non chiamano il motore né un'altra app. Il recinto è una difesa dentro il programma, non un muro: gli script di clienti diversi sullo stesso motore vanno bene se li scrive o li controlla chi lo gestisce.
- 03.8Accessi da rivedere
- Persone attive per giorno e per app, ultima attività e accessi inutilizzati da 30 giorni. Gli eventi del motore stanno in uno storico che dalla console nessuno può cancellare; di serie si tiene un anno.
- 03.9Dati recuperabili, uscite ordinate
- Ogni ripristino salva prima i dati attuali; un'app archiviata si cancella solo dopo aver verificato la copia. I dati stanno sul tuo server.
I dettagli, compreso quello che il motore non controlla, sono in sicurezza e note operative.
Aggiornamenti atomici. Tutto o niente.
Quando un'app cambia non si toccano file a mano sul server. La nuova versione arriva come pacchetto, il motore la analizza e la prova accanto a quella in uso, e solo se tutto passa la sostituisce in un colpo solo.
- 04.1Prepari il pacchetto
- La nuova versione è uno zip nello stesso formato della prima installazione: scheda, pagine, hook e migrazioni. Chi l'ha costruita non deve toccare il server.
- 04.2Il motore lo analizza e lo prova
- Controlli del pacchetto e del codice, come l'analisi delle immagini dei container, migrazioni provate su una copia dei dati e un avvio di prova con controllo di salute.
- 04.3Si cambia in blocco, o niente
- Se ogni controllo passa, il motore fa un backup e scambia la versione in un colpo solo. Se qualcosa non va, l'aggiornamento si ferma e resta la versione di prima, intatta.
Lo stesso principio vale per il motore: prima di ogni suo aggiornamento salva una copia del registro, da cui si può ripartire.
Sui tuoi server. Senza altro da installare.
Pyrite gira su Windows, in rete locale, dove le aziende piccole e medie hanno già i loro server: un eseguibile e una cartella, niente da installare intorno. Le persone entrano con un solo account, e la rubrica collegata ad Active Directory ed Entra ID è il prossimo passo.