Jak AI odpowiada na pytania o dane w BigQuery i Snowflake bez pisania SQL?

Tak, AI może odpytywać BigQuery i Snowflake na podstawie pytania wpisanego po polsku. Zamienia je na SQL, wysyła zapytanie do hurtowni danych i zwraca wynik w normalnym języku, bez angażowania analityka przy każdym raportowym pytaniu. Firma zachowuje pełną kontrolę: AI dostaje dostęp tylko do odczytu na wybranych tabelach, a uprawnienia do zmiany danych pozostają wyłączone.

Dlaczego firmy trafiają do BigQuery i Snowflake?

BigQuery (Google Cloud) i Snowflake to hurtownie danych w chmurze. Różnią się interfejsem i modelem rozliczeń, ale pełnią tę samą rolę: firma ściąga dane z wielu systemów operacyjnych do jednego miejsca i tam je analizuje. Typowy układ, który widzimy u klientów: zamówienia z trzech sklepów internetowych, faktury z Comarch ERP, stany magazynowe z WMS i dane logistyczne z TMS spływają co noc do Snowflake'a albo BigQuery. Stamtąd analitycy budują raporty dla zarządu.

Problem zaczyna się, gdy firma potrzebuje odpowiedzi szybciej niż za tydzień, kiedy analityk "wrzuci do kolejki". Albo gdy analityk jest jeden, a pytań jest dziesięć dziennie. AI nie zastępuje analityka przy trudnych analizach. Ale zdejmuje z niego rutynę: ile sprzedaliśmy wczoraj, które zamówienia czekają zbyt długo, czy ładowanie z nocy zakończyło się sukcesem.

Jak fizycznie wygląda podłączenie AI do BigQuery i Snowflake?

Obydwa systemy mają otwarte API i producenci niczego tu nie blokują. Połączenie jest standardowe, bez dodatkowych licencji ani wtyczek.

BigQuery udostępnia BigQuery REST API oraz Jobs API. AI łączy się przez konto serwisowe (Service Account) z kluczem w formacie JSON. Temu kontu nadajemy dwie role w Google Cloud IAM: BigQuery Data Viewer (podgląd danych w wybranych datasetach) i BigQuery Job User (uprawnienie do uruchamiania zapytań). Podłączenie wskazuje na projekt i dataset, np. firma_prod.sprzedaz. Żadnej roli powyżej BigQuery Data Viewer AI nie potrzebuje do odczytu.

Snowflake ma Snowflake SQL API dostępne przez HTTPS. Uwierzytelnienie odbywa się albo przez parę kluczy (key-pair authentication), albo przez JWT. Zamiast dawać AI istniejące konto użytkownika, tworzymy osobną rolę, np. AI_READER, z uprawnieniem SELECT tylko na wybranych schematach i tabelach. Rola dostaje dostęp do wirtualnego magazynu obliczeniowego (warehouse) niezbędnego do wykonania zapytania. Nic poza tym.

Co trzeba przygotować, zanim zaczniecie:

• W BigQuery: projekt Google Cloud, dostęp do IAM (rola Owner albo Editor na projekcie), lista datasetów i tabel, które AI ma widzieć
• W Snowflake: dostęp SYSADMIN lub USERADMIN, lista schematów i tabel, pusta rola do skonfigurowania
• W obu przypadkach: schemat tabel przekazany AI jako kontekst, czyli nazwy kolumn, typy danych i przykładowe wartości dla pól słownikowych takich jak status czy kanal

Czego producent nie udostępnia: żaden z tych systemów nie ma wbudowanej warstwy "pytaj po polsku". Tę warstwę buduje AI na podstawie schematu, który jej przekazujecie. Bez schematu AI zgaduje nazwy kolumn i myli się.

Jakie pytania możecie zadać AI zamiast zlecać je analitykowi?

Zacznijmy od konkretnego przykładu. Firma dystrybucyjna, z którą pracowaliśmy, ma w Snowflake tabelę SPRZEDAZ.ZAMOWIENIA z kolumnami: data_zamowienia, kanal (wartości: Allegro, Sklep, Hurt, Amazon), kwota_netto, region, status (Nowe, W realizacji, Zrealizowane, Anulowane). Handlowiec, który chciał wiedzieć, ile sprzedali na Allegro w poprzednim tygodniu i czy to więcej niż tydzień wcześniej, musiał czekać na analityka. Teraz pisze pytanie do AI i dostaje odpowiedź w ciągu kilkudziesięciu sekund.

AI generuje zapytanie SQL, wysyła je przez Snowflake SQL API, odbiera wynik i odpowiada po polsku z liczbami prosto z tabeli. Żadnych liczb z głowy: jeśli baza ma wynik, AI go podaje. Jeśli baza nic nie zwróci, AI mówi, że brak danych.

Typowe pytania, które widujemy u klientów:

• "Które produkty miały najwyższy zwrot w tym miesiącu?" (tabela ZWROTY z kluczem do PRODUKTY)
• "Ile zamówień ze statusem Nowe czeka już ponad 48 godzin?"
• "Porównaj sprzedaż październik do września dla regionu Śląsk."
• "Którzy klienci hurtowi nie złożyli zamówienia od ponad 60 dni?"
• "Jakie były trzy najgorsze dni sprzedażowe w tym kwartale?"
• "Ile paczek wyszło z magazynu Kraków w zeszłym tygodniu?"

Jedno ograniczenie warto znać. AI nie domyśli się reguł biznesowych specyficznych dla Waszej firmy, jeśli ich nie opisaliście. Jeśli "marża" w Waszym przypadku to kwota po rabacie lojalnościowym pomniejszona o koszt zwrotu, trzeba to albo zdefiniować w widoku SQL, albo wyjaśnić AI w kontekście. To nie jest wada tego podejścia: tak po prostu działa każde narzędzie, które nie zna Waszych wewnętrznych definicji.

Jak AI pilnuje harmonogramów ładowania i wysyła alert, gdy coś poszło nie tak?

Hurtownie żyją z regularnych ładowań. Dane spływają z systemów źródłowych według harmonogramu: co noc, co godzinę, po każdej transakcji. Gdy ładowanie się nie powiedzie, firma zwykle dowiaduje się o tym dopiero, gdy ktoś pyta o dane i dostaje stare liczby. Albo gdy analityk to wyłapie następnego dnia.

AI może to sprawdzać automatycznie. W BigQuery statusy zadań są dostępne w widoku systemowym INFORMATION_SCHEMA.JOBS_BY_PROJECT. Kolumna state przyjmuje wartości DONE, RUNNING, PENDING. Zadania zakończone błędem mają state = DONE i niepuste pole error_result. AI rano odpytuje ten widok za ostatnie 24 godziny i raportuje: które zadania zakończyły się błędem, jakie tabele były celem i jak brzmi komunikat błędu.

W Snowflake analogiczne informacje są w INFORMATION_SCHEMA.LOAD_HISTORY (ładowania przez COPY INTO) i INFORMATION_SCHEMA.COPY_HISTORY. Kolumna STATUS przyjmuje wartości Loaded, Load failed, Partially loaded. Przy Snowpipe dochodzi jeszcze widok systemowy SYSTEM$PIPE_STATUS, który pokazuje, czy potok jest aktywny i kiedy ostatnio przetwarzał pliki.

Automat uruchamiany co rano o 7:00 sprawdza te widoki i wysyła podsumowanie na maila albo do Teams. Przykładowa wiadomość: "Ładowanie z ERP z nocy 13.11.2026 zakończyło się błędem na tabeli ZAKUPY_DOSTAWCY. Ostatnie poprawne ładowanie: 12.11.2026, 02:14. Pozostałe cztery ładowania bez błędów." Dział IT dostaje informację, zanim ktokolwiek z zarządu zacznie się zastanawiać, dlaczego raport pokazuje dane sprzed dwóch dni.

Uprawnienia: dlaczego AI dostaje tylko do odczytu na wybranych tabelach?

To ważna rozmowa, którą przeprowadzamy z każdą firmą przed podłączeniem. AI podpięta do hurtowni z pełnymi uprawnieniami mogłaby: kasować tabele, modyfikować dane, skopiować całą bazę na zewnątrz. Żadna z tych rzeczy nie jest potrzebna do odpowiadania na pytania biznesowe.

Reguła, której trzymamy się u klientów: AI dostaje tylko SELECT na wskazanej liście tabel i widoków. Nie na całym datasecie, nie na całej bazie: na konkretnych obiektach, które Wasza firma wybiera na początku.

W BigQuery wygląda to tak: Service Account ma rolę BigQuery Data Viewer nadaną na poziomie konkretnego datasetu, nie projektu. Można ją zawęzić przez IAM Conditions do pojedynczych tabel, jeśli macie mieszane datasety z danymi różnej wrażliwości.

W Snowflake tworzycie rolę AI_READER z uprawnieniami:

• USAGE na bazie danych i schemacie, żeby AI mogło je "zobaczyć"
• SELECT na każdej tabeli lub widoku z listy
• USAGE na jednym małym warehousing do wykonania zapytań

Żadnego INSERT, UPDATE, DELETE, TRUNCATE. Żadnego dostępu do schematów z danymi osobowymi pracowników ani klientów, chyba że firma to świadomie decyduje i obsługuje zgody RODO po swojej stronie.

Jeden z klientów, firma dystrybucyjna z BigQuery, miał na początku obawy, że AI "zobaczy coś, czego nie powinna". Pokazaliśmy konfigurację IAM: AI ma dostęp do dwóch datasetów ze sprzedażą i nic poza tym. Żadnej drogi do danych finansowych ani pracowniczych. Po tym procesie nie było już żadnych wątpliwości ze strony zarządu.

Widoki zamiast surowych tabel: jak uprościć pytania i ukryć dane wrażliwe

Zanim podepniecie AI do tabel, warto zastanowić się nad widokami. VIEW to zapytanie SQL zapisane w bazie, które wygląda jak tabela. Możecie stworzyć widok SPRZEDAZ_TYGODNIOWA, który już liczy sumy, filtruje anulowane zamówienia i dołącza nazwy produktów zamiast ID. AI pyta widok, nie tabelę źródłową, i ryzyko błędnego SQL znacznie spada.

Dodatkowy bonus: widoki mogą ukrywać dane osobowe. Zamiast dawać AI dostęp do tabeli z adresami i numerami telefonów klientów, dajesz widok z ID klienta, regionem i historią zakupów. Dane osobowe zostają po stronie systemu źródłowego. Do analizy biznesowej nie są potrzebne.

Tworzenie widoków to kilka linii SQL, a utrzymanie ich nie obciąża analityka na co dzień. Jeśli tabela źródłowa zmienia strukturę, aktualizujesz widok i AI dalej działa bez modyfikacji po swojej stronie.

Od czego zaczynacie?

Pierwsze pytanie, które zadajemy firmie: jakie pytania zadajecie analitykowi lub sobie nawzajem najczęściej? Nie "jakie raporty chcecie", tylko konkretne zdania wpisywane do Teamsów albo maila. Z tej listy wynika, do których tabel AI potrzebuje dostępu. Zazwyczaj to 5 do 15 tabel lub widoków, nie cała hurtownia.

Kolejne kroki:

• Lista tabel i widoków, na których AI będzie pracować
• Nadanie uprawnień: Service Account w BigQuery albo rola AI_READER w Snowflake
• Przekazanie AI schematu tabel z nazwami kolumn, typami i wartościami słownikowymi
• Testowanie pytań z listy i sprawdzenie, czy SQL generowany przez AI jest poprawny na Waszych danych
• Opcjonalnie: automat monitorowania ładowań uruchamiany codziennie rano i wysyłający podsumowanie do wybranych osób

Pierwsze sensowne odpowiedzi dostajecie zazwyczaj w ciągu kilku dni od podłączenia. Nie potrzebujecie do tego przebudowy hurtowni ani dodatkowych licencji poza tym, co już macie. Jeśli chcecie zobaczyć, jak to wygląda na Waszych tabelach, zacznijcie od 15 minut rozmowy. Mamy też realne wdrożenia u klientów, którzy przeszli przez dokładnie ten sam proces i dziś pytają AI o dane zamiast czekać na raport.