Dlaczego firma nie potrzebuje od razu Big Data, żeby rozmawiać z danymi

System łączący agenta AI z bazą Microsoft SQL Server pozwala zadawać pytania o dane naturalnym językiem, generować odpowiedzi w locie i omijać barierę, która przez lata oddzielała biznes od tabel, zapytań i raportów BI.

Skrót dla tych, którzy chcą od razu sedna

Klasyczne systemy BI odpowiadają na pytania, które ktoś przewidział wcześniej. Hurtownie Big Data mają sens wtedy, gdy skala, rozproszenie i wolumen danych naprawdę tego wymagają. W wielu firmach problem jest prostszy: dane już są w SQL-u, tylko mało kto potrafi je szybko odpytywać bez wsparcia technicznego.

Opisany projekt idzie inną drogą. Nie buduje od razu hurtowni danych, tylko prywatną warstwę rozmowy nad istniejącą bazą Microsoft SQL Server. Użytkownik pyta w OpenWebUI, Dify prowadzi agenta, agent korzysta z narzędzia SQL, a baza pozostaje w prywatnej sieci dostępnej przez Tailscale.

To case study nie jest o „magicznej sztucznej inteligencji”. Jest o bardzo praktycznym układzie: kontrolowany dostęp do danych, opisany schemat bazy, ograniczone uprawnienia, logowanie zapytań i interfejs rozmowy, który pozwala biznesowi zadawać pytania bez znajomości SQL.

Problem: firma ma dane, ale nie ma rozmowy z danymi

W teorii dane w firmie są uporządkowane. Są tabele, klucze, relacje, statusy, daty, kontrahenci, faktury, produkty, zamówienia i historia zmian. W praktyce dla wielu osób biznesowych baza SQL jest czarną skrzynką. Wiedza istnieje, ale dostęp do niej przechodzi przez wąskie gardło: analityka, programistę, raport cykliczny albo panel BI, który trzeba najpierw zaprojektować.

To oznacza, że proste pytanie potrafi zamienić się w proces. Ktoś chce wiedzieć, które produkty sprzedają się gorzej niż miesiąc temu. Ktoś inny pyta, u których klientów rośnie ryzyko odejścia. Zarząd potrzebuje odpowiedzi „tu i teraz”, ale system raportowy pokazuje tylko to, co zostało przygotowane wcześniej.

Właśnie w tym miejscu pojawia się luka między danymi a decyzją. SQL jest świetny dla osób technicznych, ale nie jest naturalnym językiem pracy dla handlowca, kierownika operacyjnego czy właściciela firmy. BI jest wygodne, kiedy pytania są powtarzalne, ale gorzej radzi sobie z eksploracją: „sprawdźmy jeszcze ten wariant”, „a co jeśli wykluczymy anulowane zamówienia”, „pokaż tylko klientów z segmentu premium”.

Najważniejsza zmiana: agent AI nie zastępuje bazy danych. On staje się warstwą rozmowy nad bazą, tłumacząc naturalny język na kontrolowane zapytania i czytelne odpowiedzi.

Dlaczego nie zawsze trzeba zaczynać od Big Data albo klasycznego BI

Big Data i BI są potrzebne, ale nie są odpowiedzią na każdy przypadek. Jeżeli firma ma dane w relacyjnej bazie, a główne pytania dotyczą filtrowania, agregacji, porównań, trendów i wyciągania rekordów, to pierwszym problemem zwykle nie jest brak hurtowni. Problemem jest brak prostego sposobu zadawania pytań.

Klasyczne BI dobrze działa tam, gdzie mamy powtarzalne metryki, KPI i stabilne dashboardy. Agent AI wnosi coś innego: elastyczność. Użytkownik nie musi wiedzieć, w której tabeli jest dana kolumna ani jak połączyć klientów z transakcjami. Może zacząć od intencji.

Podejście	Najlepsze do	Ograniczenie
Raporty BI	Powtarzalne dashboardy, KPI, kontroling, raportowanie zarządcze.	Trzeba przewidzieć pytania i przygotować widoki z wyprzedzeniem.
Big Data	Bardzo duże wolumeny, wiele źródeł, strumienie zdarzeń, analityka na skalę.	Wysoki koszt wdrożenia, utrzymania i modelowania danych.
AI + SQL	Szybkie pytania ad hoc, eksploracja danych, praca operacyjna, wsparcie analityków.	Wymaga dobrego opisu schematu, kontroli uprawnień i walidacji zapytań.

Cel techniczny projektu

Celem nie było zbudowanie kolejnego dashboardu. Celem było uruchomienie prywatnego środowiska, w którym osoba nietechniczna może zadać pytanie o dane, a agent AI potrafi przełożyć tę intencję na bezpieczne zapytanie do bazy SQL.

W praktyce projekt musiał spełnić kilka warunków jednocześnie: baza nie może być publiczna, panel administracyjny nie może wisieć w internecie, użytkownik ma korzystać z prostego interfejsu rozmowy, a agent ma działać w trybie narzędziowym, nie jako model zgadujący odpowiedź z pamięci.

Co miało działać po wdrożeniu

• Dostęp do środowiska tylko przez Tailscale.
• Coolify jako panel do zarządzania kontenerami.
• Dify uruchomione z trybem agentowym i narzędziami.
• Microsoft SQL Server dostępny w prywatnej sieci Docker.
• OpenWebUI podłączone do Dify przez endpoint kompatybilny z OpenAI.

Czego celowo unikamy

• Publicznego wystawiania portu MSSQL.
• Publicznego panelu Coolify po zakończeniu bootstrapu.
• Ręcznego pisania SQL przez użytkownika biznesowego.
• Budowania hurtowni danych przed sprawdzeniem wartości pilotażu.
• Udawania, że model zna dane bez połączenia z realną bazą.

Architektura: prywatny system do rozmowy z bazą SQL

W założeniach projektowych całość stoi na serwerze Hetzner z Ubuntu 24. Publiczny internet jest potrzebny tylko na etapie bootstrapu. Docelowo dostęp do paneli, aplikacji i usług odbywa się przez Tailscale, czyli prywatną sieć opartą o WireGuard. To ważne, bo baza danych nie powinna być wystawiona publicznie tylko dlatego, że ma z niej korzystać agent AI.

Najprostszy opis architektury wygląda tak:

• Użytkownik zadaje pytanie naturalnym językiem.
• OpenWebUI pełni rolę interfejsu rozmowy.
• Dify prowadzi agenta i wybiera narzędzie SQL.
• Microsoft SQL Server pozostaje źródłem danych.
• Odpowiedź wraca do użytkownika jako wynik z krótkim wyjaśnieniem.

Coolify pełni rolę menedżera kontenerów. W jednej prywatnej sieci Docker pracują usługi: Dify, OpenWebUI, Microsoft SQL Server, Redis, PostgreSQL, Qdrant i plugin daemon. Kluczowe jest to, że Dify łączy się z MSSQL po nazwie kontenera w wewnętrznym DNS, a nie przez publiczny adres IP.

Rola komponentów: co robi każda warstwa

W takim projekcie łatwo wrzucić kilka nazw technologii do jednego worka. Technicznie każda z nich pełni inną funkcję i dopiero połączenie tych funkcji daje sensowny system.

Komponent	Rola w systemie	Dlaczego jest ważny
Hetzner VPS	Maszyna, na której działa środowisko kontenerowe.	Daje kontrolę nad infrastrukturą bez budowania dużej platformy chmurowej.
Tailscale	Prywatna sieć dostępu do paneli i usług.	Ogranicza ekspozycję publiczną i pozwala zamknąć porty po bootstrapie.
Coolify	Panel do zarządzania kontenerami i usługami.	Ułatwia utrzymanie Dify, OpenWebUI, MSSQL i usług pomocniczych.
Dify	Warstwa orkiestracji agenta, promptów i narzędzi.	To tutaj model dostaje narzędzie SQL i reguły pracy z bazą.
OpenWebUI	Interfejs rozmowy dla użytkownika końcowego.	Ukrywa techniczną złożoność i pozwala pracować naturalnym językiem.
Microsoft SQL Server	Źródło danych biznesowych.	System pracuje na istniejących danych, a nie na ręcznie przygotowanych eksportach.

Co zostało wdrożone: od serwera do agenta

1. Hetzner i podstawowe utwardzenie serwera

Pierwszy etap to aktualizacja systemu, minimalny firewall i przygotowanie VPS-a. Publiczny SSH jest potrzebny tylko na start. Po włączeniu Tailscale powinien zostać zamknięty, a ruch przychodzący ograniczony do interfejsu prywatnej sieci. Dzięki temu serwer przestaje być klasycznym publicznym panelem administracyjnym, a staje się prywatnym węzłem w tailnecie.

2. Tailscale jako jedyna brama dostępu

Tailscale zmienia charakter wdrożenia. Zamiast wystawiać Coolify, OpenWebUI, Dify i MSSQL do internetu, system jest dostępny tylko dla urządzeń w tailnecie. To prosta decyzja, która ogranicza powierzchnię ataku i zmniejsza liczbę problemów operacyjnych.

3. Coolify jako panel dla kontenerów

Coolify pozwala zarządzać aplikacjami Dockerowymi bez ręcznego utrzymywania całego stosu komend. Po instalacji również nie powinien być zostawiony publicznie na porcie administracyjnym. Dostęp przez adres Tailscale jest wystarczający.

4. Microsoft SQL Server jako źródło prawdy

Baza MSSQL trzyma dane, które agent ma odpytywać. Ważne jest, aby nie mapować portu 1433 publicznie, jeżeli nie ma takiej konieczności. Dify powinien widzieć bazę przez prywatną sieć kontenerów. Z punktu widzenia bezpieczeństwa agent powinien używać osobnego użytkownika technicznego z ograniczonymi uprawnieniami.

5. Dify w trybie agentowym

Dify odpowiada za logikę agenta: przyjmuje intencję użytkownika, wybiera narzędzie, buduje zapytanie, interpretuje wynik i oddaje odpowiedź w formie zrozumiałej dla człowieka. To tutaj pojawia się największa wartość: agent może korzystać z narzędzia SQL, ale użytkownik nie musi pisać SQL-a. Dify jest też miejscem, w którym można dopisać instrukcje systemowe, ograniczenia i opis schematu danych.

6. OpenWebUI jako front dla biznesu

OpenWebUI łączy się z Dify przez endpoint kompatybilny z OpenAI V1. Dla użytkownika końcowego wygląda to jak rozmowa z asystentem. Pod spodem asystent ma jednak dostęp do narzędzia, które pozwala mu odpytywać konkretną bazę.

Jak agent rozumie bazę, skoro nie zna jej z góry

Model językowy nie powinien zgadywać struktury bazy. Jeżeli użytkownik pyta o „aktywnych klientów”, agent musi wiedzieć, czy aktywność oznacza logowanie, zamówienie, płatność, kontakt handlowy czy brak zaległości. To nie jest problem modelu, tylko problem słownika danych.

Dlatego wdrożenie AI + SQL powinno zawierać warstwę kontekstu: opis tabel, relacji, kolumn, statusów, filtrów i definicji metryk. Bez tego agent może wygenerować SQL poprawny składniowo, ale błędny biznesowo.

Minimalny kontekst dla agenta

• Lista tabel, które wolno odpytywać.
• Opis znaczenia najważniejszych kolumn.
• Relacje między klientami, zamówieniami, fakturami i produktami.
• Definicje pojęć biznesowych: aktywny klient, churn, opóźnienie, marża.
• Reguły filtrowania danych testowych, anulowanych i archiwalnych.

Przykład reguły biznesowej

Aktywny klient to klient, który złożył co najmniej jedno nieanulowane zamówienie w ostatnich 90 dniach albo ma otwartą umowę abonamentową. Sam fakt istnienia rekordu w tabeli klientów nie oznacza aktywności.

Taka definicja powinna trafić do instrukcji agenta, bo bez niej model może potraktować „aktywny” zbyt potocznie.

Jak wygląda pytanie do danych w praktyce

Użytkownik nie pyta bazy: SELECT … GROUP BY … Użytkownik pyta tak, jak zapytałby analityka:

• „Które produkty miały największy spadek sprzedaży w ostatnich 30 dniach?”
• „Pokaż klientów, którzy nie zamawiali od 60 dni, ale wcześniej byli aktywni.”
• „Porównaj przychody z tego tygodnia do poprzedniego i wskaż największe różnice.”
• „Znajdź faktury po terminie i pogrupuj je według handlowca.”

Agent zamienia pytanie na plan: rozpoznaje encje, wybiera tabele, tworzy zapytanie, wykonuje je przez narzędzie SQL, a potem opisuje wynik. Dobra implementacja nie kończy się na „oto tabela”. Powinna też powiedzieć, jak rozumie wynik, co jest najważniejsze i gdzie warto dopytać.

Przepływ jednego pytania

• Użytkownik zadaje pytanie w OpenWebUI.
• Dify przekazuje intencję do agenta.
• Agent sprawdza dostępny kontekst bazy.
• Agent generuje zapytanie do narzędzia SQL.
• MSSQL zwraca wynik.
• Agent tłumaczy wynik człowiekowi.

Przykład end-to-end: od pytania do odpowiedzi

Najłatwiej ocenić wartość takiego systemu na jednym konkretnym przebiegu. Poniższy przykład jest uproszczony i oparty na fikcyjnych nazwach tabel, ale pokazuje właściwy mechanizm: użytkownik zadaje pytanie biznesowe, agent buduje kontrolowane zapytanie, a odpowiedź wraca w formie zrozumiałej dla człowieka.

Pytanie użytkownika

„Pokaż 5 produktów z największym spadkiem sprzedaży w ostatnich 30 dniach względem poprzednich 30 dni. Pomiń anulowane zamówienia.”

Przykładowy SQL wygenerowany przez agenta

WITH sales AS (
  SELECT
    p.product_name,
    SUM(CASE
      WHEN o.order_date >= DATEADD(DAY, -30, CAST(GETDATE() AS date))
      THEN oi.quantity * oi.unit_price ELSE 0
    END) AS current_period,
    SUM(CASE
      WHEN o.order_date >= DATEADD(DAY, -60, CAST(GETDATE() AS date))
       AND o.order_date < DATEADD(DAY, -30, CAST(GETDATE() AS date))
      THEN oi.quantity * oi.unit_price ELSE 0
    END) AS previous_period
  FROM orders o JOIN order_items oi ON oi.order_id = o.id
  JOIN products p ON p.id = oi.product_id
  WHERE o.status <> 'cancelled'
    AND o.order_date >= DATEADD(DAY, -60, CAST(GETDATE() AS date))
  GROUP BY p.product_name
)
SELECT TOP (5)
  product_name,
  current_period,
  previous_period,
  current_period - previous_period AS change_value
FROM sales
WHERE previous_period > 0
ORDER BY change_value ASC;

Odpowiedź widoczna dla użytkownika

Agent nie powinien kończyć pracy na samej tabeli. Dobra odpowiedź mówi, co zostało policzone, jakie filtry zastosowano i gdzie warto dopytać. Przykładowo: „Największy spadek sprzedaży widać w produktach A, B i C. Wynik porównuje ostatnie 30 dni z poprzednimi 30 dniami i pomija anulowane zamówienia. W dwóch produktach spadła liczba transakcji, a w jednym spadła średnia wartość zamówienia, więc warto osobno sprawdzić dostępność magazynową i aktywność handlowców.”

W środowisku produkcyjnym taki SQL powinien być logowany razem z pytaniem użytkownika, czasem wykonania i liczbą zwróconych rekordów. Dzięki temu można później sprawdzić, czy agent liczy metryki zgodnie z definicją biznesową.

Guardrails: co trzeba dopracować, żeby to było użyteczne

Samo podłączenie modelu do bazy nie wystarcza. Największa różnica między prototypem a narzędziem produkcyjnym leży w ograniczeniach, kontekście i walidacji. Agent AI musi mieć swobodę zadawania pytań do danych, ale nie może mieć swobody robienia wszystkiego.

Obszar	Co trzeba ustalić	Dlaczego to ważne
Uprawnienia	Czy agent ma tylko odczyt, jakie tabele widzi, czy może wykonywać kosztowne zapytania.	Model nie powinien mieć większych praw niż realny użytkownik biznesowy.
Opis schematu	Nazwy tabel, relacje, znaczenie kolumn, słownik statusów i definicje metryk.	Bez tego agent może zbudować poprawny technicznie, ale błędny biznesowo wynik.
Limity	Maksymalna liczba rekordów, timeouty, zakaz pełnych skanów bez filtra.	Chroni bazę przed przypadkowym przeciążeniem.
Audyt	Log pytania, wygenerowanego SQL-a, czasu wykonania i odpowiedzi.	Pozwala sprawdzić, co agent zrobił i poprawić reguły.
Prompt injection	Instrukcje użytkownika i dane zwrócone z bazy nie mogą nadpisywać reguł systemowych agenta.	Chroni przed sytuacją, w której model wykonuje polecenie ukryte w treści rekordu albo w pytaniu.
Zakres danych	Allowlista tabel, kolumn i widoków oraz blokada danych wrażliwych poza zakresem pilotażu.	Ogranicza ryzyko przypadkowego ujawnienia danych, których użytkownik nie powinien zobaczyć.

Najbezpieczniejszy start to tryb read-only, ograniczony zakres tabel i zestaw testowych pytań. Dopiero po przejściu testów można rozszerzać uprawnienia, dodawać nowe źródła danych i automatyzacje.

Lista kontrolna

• Osobny użytkownik bazy dla agenta.
• Dostęp wyłącznie do tabel potrzebnych w pilotażu.
• Domyślnie tylko odczyt danych.
• Limit liczby zwracanych rekordów.
• Timeout dla zapytań kosztownych obliczeniowo.
• Logowanie pytania użytkownika i wygenerowanego SQL-a.
• Blokada operacji modyfikujących dane.
• Allowlista tabel i kolumn dostępnych dla agenta.
• Odrzucanie instrukcji, które próbują zmienić reguły systemowe lub ominąć ograniczenia.
• Lista pytań testowych porównywana z ręcznymi wynikami SQL.

Bezpieczeństwo: dlaczego prywatna sieć jest częścią produktu

W tym projekcie bezpieczeństwo nie jest dodatkiem na końcu. Jest elementem architektury. Publiczne porty dla Coolify, OpenWebUI, Dify i MSSQL po wdrożeniu powinny być zamknięte, a dostęp powinien iść przez Tailscale. To szczególnie ważne w systemie, który ma łączyć model AI z danymi klienta.

CrowdSec może mieć sens jako dodatkowy monitoring logów i wykrywanie prób brute-force, ale jeżeli ruch nie jest publiczny, jego rola jest pomocnicza. Największa korzyść daje ograniczenie ekspozycji: mniej publicznych usług, mniej punktów wejścia, mniej rzeczy do pilnowania.

W klasycznym wdrożeniu panel aplikacji często trafia za publiczny reverse proxy, baza ma mapowany port, a ochrona opiera się na hasłach i konfiguracji firewalla. Tutaj priorytet jest inny: usługi administracyjne i baza danych mają być niewidoczne z publicznego internetu. Tailscale staje się bramą, a nie dodatkiem.

Element	Publicznie	Docelowo
Coolify	Potrzebny na czas instalacji lub konfiguracji.	Dostęp tylko przez Tailscale.
MSSQL	Nie powinien być wystawiony publicznie.	Dostęp tylko w prywatnej sieci kontenerów.
OpenWebUI	Nie musi być publiczne w pilotażu.	Dostęp dla użytkowników z tailnetu.
SSH	Tylko bootstrap.	Administracja przez prywatny adres Tailscale.

Testy akceptacyjne: po czym poznajemy, że system działa

W technicznym case study warto jasno oddzielić „zainstalowaliśmy kontenery” od „system spełnia cel”. Działające wdrożenie nie oznacza tylko zielonych statusów w Dockerze. Oznacza, że cały przepływ od użytkownika do bazy i z powrotem jest kontrolowany, powtarzalny i możliwy do sprawdzenia.

System można uznać za działający, kiedy

• Użytkownik łączy się z tailnetem i widzi prywatne środowisko.
• Coolify jest dostępny przez adres Tailscale, nie przez publiczny port.
• OpenWebUI łączy się z Dify przez endpoint kompatybilny z OpenAI.
• Dify działa w trybie agentowym i ma skonfigurowane narzędzie SQL.
• Dify widzi MSSQL przez nazwę kontenera lub prywatną sieć, nie przez publiczny adres.
• Agent odpowiada na zestaw pytań testowych zgodnie z ręcznie sprawdzonym SQL-em.
• Baza nie jest dostępna z publicznego internetu.
• W logach można odtworzyć pytanie użytkownika, zapytanie SQL i odpowiedź.

Najważniejszy test jest prosty: osoba nietechniczna zadaje pytanie biznesowe, system wykonuje prawidłowe zapytanie do bazy, a odpowiedź jest zrozumiała bez czytania SQL-a. Jeżeli to działa na realnych pytaniach, pilotaż ma sens.

Stan po wdrożeniu: co realnie dostaje firma

Po poprawnym uruchomieniu użytkownik łączy się z Tailscale, wchodzi do OpenWebUI i rozmawia z agentem. Agent przez Dify korzysta z narzędzia SQL i odpytuje Microsoft SQL Server w prywatnej sieci kontenerów. To nie jest jeszcze pełna platforma analityczna klasy enterprise, ale jest bardzo praktyczny most między bazą danych a codziennymi pytaniami biznesowymi.

Największa wartość pojawia się w trzech miejscach

• Szybkość odpowiedzi. Pytanie ad hoc nie musi czekać na nowy dashboard.
• Dostępność danych. Osoby nietechniczne mogą samodzielnie eksplorować informacje.
• Mniejsze wejście na start. Firma może sprawdzić wartość AI nad danymi zanim zainwestuje w cięższą architekturę BI lub Big Data.

Ograniczenia: czego ten system nie obiecuje

Dobre case study techniczne powinno pokazywać także granice rozwiązania. AI + SQL nie sprawia, że dane automatycznie stają się poprawne, spójne i dobrze opisane. Jeżeli w bazie są błędne statusy, niejasne definicje albo historyczne wyjątki, agent może je tylko odziedziczyć.

Ryzyko	Co może pójść źle	Jak ograniczyć problem
Niejasne pytanie	Użytkownik pyta o „najlepszych klientów”, ale nie definiuje kryterium.	Agent powinien dopytać albo użyć opisanej definicji biznesowej.
Słaby opis schematu	Model wybiera tabelę o podobnej nazwie, ale innym znaczeniu.	Trzeba przygotować słownik tabel, kolumn i relacji.
Kosztowne zapytanie	Agent generuje szeroki skan dużej tabeli.	Limity, timeouty, zakres dat i domyślne ograniczenia wyników.
Nadmierne zaufanie	Użytkownik traktuje odpowiedź jako audytowany raport finansowy.	Wyraźne oznaczenie trybu eksploracyjnego i walidacja kluczowych decyzji.

FAQ: najczęstsze pytania o AI + SQL

Czy agent AI zastępuje analityka danych?

Nie. Dobrze wdrożony agent przejmuje część powtarzalnych pytań i eksploracji, ale analityk nadal jest potrzebny do modelowania danych, definicji metryk, kontroli jakości i interpretacji trudniejszych wyników.

Czy użytkownik naprawdę nie musi znać SQL?

Nie musi znać składni SQL, ale system musi znać strukturę bazy. To różnica. Użytkownik pyta naturalnym językiem, a agent korzysta z opisu schematu i narzędzia SQL, żeby wykonać pracę techniczną pod spodem.

Czy to jest alternatywa dla BI?

To jest alternatywa dla części zastosowań BI, szczególnie tam, gdzie chodzi o pytania ad hoc i szybkie rozpoznanie sytuacji. Nie zastępuje stabilnych, audytowanych dashboardów finansowych, ale może ograniczyć liczbę raportów tworzonych tylko po to, żeby odpowiedzieć na jednorazowe pytanie.

Czy takie rozwiązanie nadaje się do danych klienta?

Tak, pod warunkiem że wdrożenie jest prywatne, uprawnienia są ograniczone, dostęp jest kontrolowany, a zapytania są logowane. W opisanej architekturze ważną rolę pełni Tailscale i brak publicznego wystawiania bazy MSSQL.

Czy agent powinien mieć dostęp do całej bazy?

Nie na starcie. Najrozsądniej zacząć od ograniczonego zakresu tabel i użytkownika tylko do odczytu. Dopiero po walidacji pytań testowych można rozszerzać zakres danych, które agent widzi.

Czy odpowiedzi agenta można traktować jak raport finansowy?

Na etapie pilotażu raczej nie. To warstwa eksploracyjna i operacyjna. Raporty finansowe, compliance i decyzje wysokiego ryzyka powinny mieć osobną walidację, wersjonowane definicje metryk i kontrolę człowieka.

Od czego zacząć pierwszy test?

Najlepiej od jednej bazy, jednego procesu i kilkunastu prawdziwych pytań biznesowych. Potem trzeba sprawdzić, czy agent wybiera dobre tabele, czy wyniki są zgodne z ręcznym SQL-em i czy odpowiedzi są zrozumiałe dla użytkowników.

Co dalej: roadmapa po pilotażu

Najrozsądniejszy kolejny krok to wersja pilotażowa na prawdziwych, ale ograniczonych danych klienta. Nie chodzi o to, żeby od razu budować wielką platformę danych. Chodzi o sprawdzenie, czy ludzie w firmie potrafią szybciej podejmować decyzje, kiedy zamiast prosić o raport, mogą po prostu zapytać dane.

Kolejne kroki

• Przygotować słownik tabel, kolumn, relacji i pojęć biznesowych.
• Wybrać pierwszy proces: sprzedaż, faktury, magazyn, obsługę klienta albo operacje.
• Zebrać 20-30 realnych pytań, które użytkownicy zadają analitykom.
• Porównać odpowiedzi agenta z ręcznie przygotowanymi zapytaniami SQL.
• Dodać role użytkowników i zakresy dostępu do danych.
• Rozważyć integrację z n8n lub Make dla cyklicznych alertów i automatyzacji.

Kontakt w sprawie wdrożenia

Kontakt do Kordiana, Administratora wdrożenia po stronie AIPORT.pl, który zaprojektował, skonfigurował oraz sprawdził w działaniu u klienta opisane rozwiązanie. W sprawie konsultacji, pilotażu lub uruchomienia podobnego systemu można pisać na adres: kordian@aiport.pl.

Właśnie tu AI + SQL ma największy sens: jako lekka, bezpieczna i praktyczna warstwa rozmowy nad tym, co firma już posiada. Nie zastępuje całej analityki, ale może radykalnie skrócić drogę od pytania do pierwszej sensownej odpowiedzi.