Notebook AI w Data 360 – bezpieczny RAG dla zespołów
- 5 maja 2026
Przygotowanie do jednego spotkania handlowego potrafi dziś oznaczać przeszukiwanie raportów 10-K, transkryptów rozmów i wewnętrznych PDF-ów rozrzuconych poza CRM.
Notebook AI w Data 360 ma ten etap skrócić do rozmowy z własnym zasobem dokumentów, bez kopiowania wrażliwych plików do publicznych narzędzi AI. Dla admina i architekta kluczowe jest jednak nie samo UI, ale to, że za funkcją stoi pełny pipeline dla danych nieustrukturyzowanych. To zmienia sposób myślenia o RAG w Salesforce – z eksperymentu na pojedynczych plikach w model, który można objąć governance, uprawnieniami i później podłączyć do agentów.
Notebook AI działa jako interfejs dla nowego silnika danych nieustrukturyzowanych w Data 360. Gdy użytkownik zadaje pytanie, mechanizm RAG najpierw pobiera właściwe fragmenty z podłączonych dokumentów, a dopiero potem generuje odpowiedź osadzoną w tych materiałach. W praktyce oznacza to mniej zgadywania przez model i większą kontrolę nad tym, skąd pochodzi odpowiedź.
Za tym podejściem stoją dwa elementy architektury. Pierwszy to Unstructured Data Lake Objects, czyli kontenery przechowujące tekst wyodrębniony z PDF-ów, transkryptów i innych dokumentów. Drugi to Vector Search Index, który dzieli duże pliki na mniejsze fragmenty i indeksuje je tak, by system mógł szybko wskazać właściwy akapit do odpowiedzi. To właśnie ten indeks jest faktycznym „mózgiem” rozwiązania.
Dla praktyka Salesforce ważna jest jedna konsekwencja: nie należy traktować Notebook AI jako kolejnej funkcji do ręcznego uploadu dokumentów. Model enterprise polega na zbudowaniu trwałego połączenia między zewnętrznym repozytorium a Data 360, a następnie wielokrotnym użyciu raz przygotowanego indeksu. Ten sam kierunek widać też szerzej w architekturze platformy, gdzie rośnie znaczenie warstw danych i AI-ready API, o czym pisaliśmy przy analizie Headless 360 dla architektów Salesforce.
Najmocniejszy argument za Notebook AI nie dotyczy wygody, tylko kontroli. W scenariuszu z SharePoint Salesforce nie kopiuje bezrefleksyjnie tysięcy plików do storage CRM. Zamiast tego korzysta z bezpiecznych konektorów API i federacji, by odczytywać tekst z zewnętrznego repozytorium. To istotna różnica dla organizacji, które chcą używać GenAI bez otwierania nowego kanału wycieku danych.
Drugi filar to respektowanie istniejących uprawnień po stronie systemu źródłowego. Jeśli handlowiec nie ma dostępu do poufnego folderu M&A w SharePoint, Notebook AI nie powinien użyć jego zawartości do wygenerowania odpowiedzi. Ten model jest znacznie bliższy realnym wymaganiom enterprise niż lokalne uploady plików do okna czatu, bo nie wymusza pobierania dokumentów na desktop i nie obchodzi polityk dostępu.
Z perspektywy orgów to temat szerszy niż samo AI. Integracje zewnętrzne, uprawnienia i granice odpowiedzialności między Salesforce a repozytorium dokumentów trzeba potraktować jak element architektury bezpieczeństwa, nie tylko konfigurację konektora. Ten sam wzorzec ostrożności wraca przy analizie ryzyk związanych z integracjami zewnętrznymi i wyciekami danych.
Pokazany proof of concept opiera się na Microsoft SharePoint jako zewnętrznym vaultcie dokumentów. Przed konfiguracją po stronie Salesforce potrzebna jest rejestracja aplikacji w Azure Entra ID z uprawnieniem Sites.Read.All. To ogranicza dostęp do plików do zakresu jawnie autoryzowanego przez organizację i pozwala utrzymać granice bezpieczeństwa już na wejściu.
Po stronie Data 360 trzeba najpierw upewnić się, że funkcje dla danych nieustrukturyzowanych i sam Notebook AI są aktywne w Feature Managerze. Część przełączników może być jeszcze opisana jako beta, więc brak odpowiednich opcji w interfejsie nie musi oznaczać błędu konfiguracji użytkownika. Następnie tworzy się połączenie przez natywny konektor Microsoft SharePoint Unstructured Data. Praktyczna przeszkoda jest prosta, ale irytująca: konektor wymaga dokładnego SharePoint Site ID, którego standardowy interfejs Microsoftu nie eksponuje wprost.
Kolejny ważny moment to ingest. Standardowe Data Streams służą wyłącznie do danych strukturalnych – wierszy i kolumn. PDF-ów nie należy więc przepychać przez klasyczny stream. Właściwa ścieżka to utworzenie Unstructured Data Lake Object, wskazanie konkretnego folderu z dokumentami i ograniczenie zakresu crawlowania tylko do potrzebnego obszaru. Potem mapuje się DLO do Unstructured Data Model Object i włącza opcję Enable Unstructured Content Harmonization. To ten checkbox uruchamia faktyczne otwieranie plików, dzielenie tekstu na fragmenty i budowę indeksu wyszukiwania.
Na końcu trzeba uzbroić się w cierpliwość. Przetwarzanie dużych dokumentów wymaga czasu obliczeniowego, więc zanim workspace w Notebook AI zacznie odpowiadać poprawnie, status DLO i indeksu musi przejść na Active. W pokazanym scenariuszu oznacza to zwykle od 5 do 15 minut. Dopiero wtedy można dodać DMO do Resource Library i zadawać pytania obejmujące wiele dokumentów jednocześnie – na przykład porównać ryzyka konkurencyjne z raportów Apple i Google oraz zestawić je z wewnętrznym opisem projektu.
To właśnie tutaj widać przewagę podejścia enterprise nad lokalnym uploadem plików: budujesz pipeline raz, synchronizujesz foldery automatycznie i korzystasz z tych samych danych w kolejnych procesach. Według zapowiedzi ten sam indeks można później wykorzystać także w Agentforce, co dobrze łączy się z szerszym kierunkiem rozwoju opisanym w naszym tekście o praktycznych konsekwencjach wdrożeń Agentforce.
Najważniejszy wniosek jest prosty: warto patrzeć na Notebook AI nie jak na nowy interfejs do rozmowy z dokumentami, ale jak na kontrolowany sposób włączenia danych nieustrukturyzowanych do architektury CRM. Jeśli organizacja już trzyma wiedzę w SharePoint lub podobnym repozytorium, Data 360 daje ścieżkę do użycia jej w AI bez obchodzenia polityk bezpieczeństwa. Pytanie brzmi nie czy da się to uruchomić, ale które procesy w twoim orgu najbardziej skorzystają na indeksie wiedzy gotowym do użycia także poza samym oknem czatu.