Gemini Enterprise Projects är GA – prova delningen före uppladdning
Gemini Enterprise Projects samlar filer, anteckningar och privata AI-chattar i en gemensam kunskapsyta. Men en länkad fil och en lokalt uppladdad fil får olika skydd. Gör ett syntetiskt tvåkontoprov innan ni lägger in arbetsmaterial, så ser ni vad en Editor kan läsa, ladda ned, radera och lämna kvar.
Vad som blev allmänt tillgängligt den 4 september
Google skrev i sina release notes den 4 september 2026 (öppnas i ny flik) att Projects i Gemini Enterprise är allmänt tillgängligt, GA. Funktionen ska ge en särskild kunskapsbas för eget arbete eller teamsamarbete. En Gemini Enterprise-administratör måste slå på Enable projects innan användarna kan skapa och använda projekt.
Nyheten betyder inte att varje konto eller region automatiskt visar funktionen. Börja därför med att anteckna datum, Gemini Enterprise-app, testkonton och om Projects syns. Be administratören kontrollera reglaget om ytan saknas. Artikeln redovisar ett rekommenderat prov, inte resultat från ett eget Gemini-konto.
Två filvägar ger olika rättigheter
Googles projektdokumentation (öppnas i ny flik) skiljer länkade källor från lokalt uppladdade filer. En Google Drive-fil eller fil från en extern anslutning behåller källans åtkomstkontroll. En medlem ser inte namnet på en fil som kontot saknar åtkomst till, och Gemini ska bara använda filer som kontot får öppna. Innehåll och ursprungliga delningsbehörigheter för länkade dokument synkas med projektet.
En lokal uppladdning fungerar annorlunda: alla projektmedlemmar kan enligt dokumentationen se, ladda ned och radera den. En mapp som ser ut som ett arbetsrum är därför inte automatiskt en privat lagringsyta för ägaren. Skillnaden behöver stå i införanderutinen med konkreta verb: visa, ladda ned och radera.
Projects stöder dokumenterade kunskapsvägar som lokala filer, Google Drive-filer, anteckningar och externa anslutningar. Tillgängliga anslutningar beror på vad administratören har ordnat. För provet räcker två syntetiska filer: en länkad och en uppladdad.
Bygg ett syntetiskt tvåkontoprov
Använd ett ägarkonto A och ett mottagarkonto B i organisationens testmiljö. Skapa projektet ”Tallkotte – delningsprov”. Låt A skapa två påhittade dokument med identiskt ofarligt upplägg men olika markörer:
- Länkad fil: ”Övningsplan Tallkotte. Markör KÄLLA-DRIVE-17. Tre pappersmodeller granskas på fredag.”
- Lokal fil: ”Övningsbilaga Tallkotte. Markör UPPLADDAD-29. Två affischer sorteras på måndag.”
Länka den första filen från Drive och ladda upp den andra från datorn. Ge först B projektmedlemskap men inte Drive-behörighet. Använd separata inloggade webbläsarprofiler och kontrollera att A:s session inte ligger kvar när B provar. Spara endast skärmbilder av testmaterialet.
Protokollet ska ha en rad per konto och fil med fälten filväg, synligt filnamn, kan öppna, kan ladda ned, kan radera och svar citerar markör. Ett enda ”åtkomst fungerar” döljer den avgörande skillnaden.
Prova den länkade filens källbehörighet
Låt B öppna projektets Knowledge-flik, söka efter filnamnet och fråga: ”Vilken markör står i den länkade övningsplanen?” Anteckna om filnamnet syns, om filen går att öppna och om svaret återger KÄLLA-DRIVE-17. Ge därefter B läsbehörighet till Drive-filen och upprepa samma tre kontroller i en ny chatt.
Ändra bara källbehörigheten mellan körningarna. Om ni samtidigt byter projektroll går det inte att avgöra vilken ändring som påverkade resultatet. Dokumentationen anger automatisk synk, men provet ska registrera klockslag och observerat läge i stället för att använda ett enstaka svar som garanti för en viss synkhastighet.
Resultatet godkänns först när protokollet skiljer ”filnamn synligt”, ”original kan öppnas” och ”markör används i svar”. Detta är ett smalare test än en full behörighetsgranskning av AI-verktyget.
Kontrollera Editor-rättigheten mot den lokala uppladdningen
Google anger att inbjudna projektmedlemmar får Editor som standard. Låt B öppna den lokala filen, ladda ned den och kontrollera om raderingskommandot visas. Använd bara den syntetiska bilagan. Om ni behöver prova själva raderingen, skapa först en identisk reservfil med en annan markör och registrera vilken testfil som tas bort.
Poängsätt tre observationer var för sig: synlig fil, lyckad nedladdning och synlig eller genomförd radering. Tre av tre betyder inte att hela produkten är säker eller osäker; det visar att den lokala filvägen gav B dessa praktiska möjligheter i just provet. För arbetsmaterial blir införandefrågan då om alla projektmedlemmar verkligen ska ha dem.
Låt A återställa testläget efter raderingsprovet. Lägg aldrig in en riktig kundfil för att ”bara se” om B kan ta bort den. Skillnaden mellan lokal uppladdning och länkad källa bör också skrivas in i arbetsplatsens korta AI-policy.
Skilj privat chatt från gemensam kunskap
Projektmedlemmarnas chattar är enligt Google privata: bara användaren ser sina egna projektchattar, och andra medlemmar kan inte ansluta till dem. Det gör inte kunskapsfilerna privata. Prova skillnaden genom att låta A skriva ”CHATT-A-41” i en egen chatt utan att lägga markören i någon fil eller anteckning. Låt sedan B leta i projektets chattar och fråga assistenten efter markören.
Godkänt kriterium är att B inte hittar A:s chatt eller CHATT-A-41 genom projektets delade kunskap. Om markören förekommer någon annanstans har provmaterialet blandats och körningen måste göras om. Slutsatsen får endast gälla den synliga chattisoleringen; provet granskar inte bakomliggande lagring eller administratörsloggar.
Kontrollera även källgränsen. Googles dokumentation säger att svar kan använda projektets dokument och webbsökning, medan andra företagsdatakällor inte används om de inte uttryckligen lagts till. Be båda kontona hämta en unik offentlig faktafras, WEBB-83, från en egen tillfällig testsida eller annan ofarlig webbsida och notera källtypen. Använd inte personuppgifter eller interna dokument som sökmarkör.
Ta bort medlem och avveckla projektet
Endast projektägaren kan enligt Google bjuda in och ta bort medlemmar samt radera projektet. Prova först om B som Editor kan bjuda in ett tredje konto eller ta bort A. Genomför ingen oväntad inbjudan; det räcker att dokumentera om kommandot finns fram till bekräftelsesteget. Låt därefter A ta bort B.
Efter borttagningen kontrollerar B projektlistan, den tidigare projektadressen och den nedladdade kopian av UPPLADDAD-29. Tre separata resultat behövs: projektåtkomst, länkad källåtkomst och redan hämtad kopia. Borttaget projektmedlemskap är inte samma sak som återkallad Drive-behörighet, och det kan inte hämta tillbaka en fil som redan laddats ned.
Avsluta med att A raderar det syntetiska projektet och försöker öppna dess gamla adress. Dokumentera vad gränssnittet visar, men kalla inte det bevis för fullständig gallring. Projektavveckling, källfilernas livscykel och lokala kopior är tre olika arbetsmoment.
Dokumentera beslutet före skarp användning
Sammanfatta provet i en beslutsrad: ägare, tillåten filväg, tillåten informationsklass, vilka som får bli Editors, vem som kontrollerar källbehörigheter, datum för omprövning och avvecklingsansvar. Lägg en avvikelse per misslyckad observation och länka till skärmbilden med syntetiska data.
- Tillåt länkade källor bara när källsystemets ägare och behörigheter är dokumenterade.
- Tillåt lokal uppladdning bara när varje projektmedlem får se, hämta och radera materialet.
- Behandla privat chatt och gemensam kunskap som två skilda ytor.
- Utse en projektägare och en ersättare i verksamhetens rutin, även om produktrollen bara har en faktisk ägare.
- Avveckla medlemskap, projekt, källbehörigheter och sparade kopior som separata kontrollpunkter.
För återkommande uppföljning kan provresultatet bli en rad i organisationens AI-register. Det här mottagarprovet svarar på en avgränsad fråga: vad kan en inbjuden Editor faktiskt göra med projektets två filvägar?
Källor
- Google Cloud: Gemini Enterprise release notes (öppnas i ny flik) – GA-datum och administratörens aktivering.
- Google Cloud: Create and manage projects (öppnas i ny flik) – filvägar, rättigheter, privata chattar, kunskapsgräns, roller och avveckling.
- Google Cloud: Manage web app features (öppnas i ny flik) – funktionen hos reglaget Enable projects.