Jak AI odpowiada na pytania o dane z własnej bazy SQL firmy bez angażowania informatyka?

AI może czytać dane bezpośrednio z bazy MySQL, PostgreSQL albo MS SQL Server działającej w Twojej firmie i odpowiadać po polsku na pytania o sprzedaż, należności czy stany magazynowe. Robi to przez konto z prawem wyłącznie do odczytu, więc nic nie zmienia i nic nie usuwa. Zadajesz pytanie ludzkim językiem, AI tłumaczy je na zapytanie SQL, pobiera wynik i odpowiada zdaniem z liczbą w kontekście.

Które bazy działają i jak wygląda to połączenie od strony technicznej?

Obsługujemy MySQL, PostgreSQL, MS SQL Server, MariaDB, a w wielu przypadkach też starsze wersje MS SQL sprzed 2016 roku. Połączenie odbywa się przez standardowy sterownik: ODBC albo natywny klient bazy danych. AI dostaje dostęp przez osobne konto bazodanowe założone wyłącznie do tego celu.

To konto ma tylko SELECT. Żadnego INSERT, UPDATE ani DELETE. Jeśli ktoś napisze do AI "usuń te faktury" albo "zmień cenę towaru na 120 zł", AI odpowie, że to nie jest możliwe. Nie dlatego, że model tak skonfigurowano w opcjach. Dlatego, że serwer bazy fizycznie odrzuci każdą próbę zapisu. To zabezpieczenie niezależne od samego modelu językowego.

U jednego z naszych klientów: producenta opakowań foliowych, baza MS SQL Server trzyma historię zamówień od 2014 roku w tabeli ZAM_Naglowek i szczegółach w ZAM_Pozycja. Przez lata tylko kierownik produkcji i jeden zewnętrzny programista wiedzieli, jak wyciągnąć z tego cokolwiek sensownego poza tygodniowym raportem. Teraz każdy kierownik pyta z telefonu i dostaje odpowiedź w kilka sekund.

Co dokładnie wyciągamy: tabele, widoki, słowniki

Przed wdrożeniem robimy mapowanie bazy: przegląd, które tabele i widoki zawierają dane przydatne biznesowo. Nie wszystko. W typowej bazie Subiekta GT jest kilkadziesiąt tabel, ale do codziennych pytań handlowych i finansowych wystarczy kilkanaście:

• dok__Dokument: faktury, zamówienia, WZ-ki, RW-ki. Trzyma nagłówki dokumentów z symbolem, datą wystawienia, identyfikatorem kontrahenta i wartością netto.
• tw__Towar: kartoteka towarów z bieżącymi stanami, cenami zakupu i sprzedaży, grupami towarowymi i symbolami producenta.
• cnt__Kontrahent: baza klientów i dostawców z NIP, bieżącym saldem, limitem kredytowym, domyślnym terminem płatności i adresem.
• dok__PozycjaDokumentu: pozycje dokumentów, czyli co konkretnie trafiło na każdą fakturę albo zamówienie i w jakiej ilości.
• sl__Status: słownik statusów. AI musi wiedzieć, że status o identyfikatorze 3 to "Zrealizowane", a nie "Nowe".

W Comarch Optima nazwy są inne: CDN.Dokumenty, CDN.Kontrahenci, CDN.Towary. W systemach pisanych na zamówienie nazwy bywają całkowicie własne i nieprzewidywalne. W każdym przypadku przygotowujemy opis struktury, tzw. schema description: co trzyma każda tabela, co znaczy każda kolumna, jakie wartości przyjmują pola słownikowe. To jednorazowa praca. Potem AI korzysta z tego opisu przy każdym pytaniu.

Oprócz tabel bezpośrednich udostępniamy też widoki SQL przygotowane przez wdrożeniowca lub przez nas. Na przykład widok v_NaleznosciAktywne może zawierać gotową kolumnę z liczbą dni po terminie płatności. AI nie musi jej liczyć za każdym razem: widok robi to raz, wynik jest zawsze aktualny.

Jak AI tłumaczy pytanie po polsku na SQL i skąd wie, o co chodzi?

Właściciel pisze: "Pokaż mi klientów, którzy nic nie kupili od trzech miesięcy." AI nie szuka w Google ani nie zgaduje. Bierze opis struktury bazy, nazwy tabel i kolumn, typy danych i generuje konkretne zapytanie SQL. Wykonuje je, pobiera wynik i formułuje odpowiedź.

Ta odpowiedź nie brzmi: "47". Brzmi: "47 klientów nie złożyło zamówienia od ponad 90 dni. Największa luka to ABC Transport Sp. z o.o., ostatnia faktura FA/2025/05/341 z 12 maja. Na liście są też trzy firmy z przekroczonym limitem kredytowym." Liczba zawsze idzie z kontekstem.

AI działa w dwóch krokach. Najpierw rozumie intencję pytania: o co naprawdę pyta ta osoba? Potem układa zapytanie bazodanowe. Dzięki temu radzi sobie z niejednoznacznościami. "Sprzedaż za zeszły rok" AI interpretuje jako rok kalendarzowy 2025, nie ostatnie 365 dni. "Kontrahenci z problemami" AI rozumie jako tych z przekroczonym terminem płatności albo przekroczonym limitem kredytowym, bo tak wynika z kontekstu bazy i historii pytań w tej firmie.

Warto też wiedzieć, że każda firma ma trochę inny żargon. U jednego klienta mówi się "odbiorca", u innego "klient", u jeszcze innego "kontrahent". Na etapie wdrożenia opisujemy te synonimy, żeby AI rozumiał słownictwo firmy, a nie tylko nazwy kolumn z bazy.

Pilnujemy też wartości, które wyglądają podejrzanie. Jeśli zapytanie o obrót z klientem zwraca wartość kilkakrotnie wyższą niż w poprzednich miesiącach, AI zaznacza to w odpowiedzi. Typowo wygląda to tak: "Obrót z firmą X w czerwcu wychodzi trzy razy wyżej niż w maju. Sprawdź, czy nie trafiła tam korekta zbiorcza albo dokument z błędną datą."

Jakie pytania zadają firmy po wdrożeniu?

Kilka realnych pytań, które padają regularnie po tym, jak system działa kilka tygodni:

• "Które faktury są po terminie ponad 30 dni?" AI zwraca zestawienie: kontrahent, kwota, liczba dni po terminie, data ostatniego dokumentu. Dane z tabeli rozrachunków albo z widoku należności.
• "Jaki był obrót z firmą X w tym roku i jak to wychodzi rok do roku?" AI liczy z dok__Dokument i odpowiada dwiema liczbami z komentarzem, czy wzrost czy spadek.
• "Który towar najszybciej schodził z magazynu w ostatnich 60 dniach?" AI liczy rotację z pozycji dokumentów i zwraca ranking.
• "Ile zamówień czeka dziś w statusie Do realizacji?" Jedno proste zapytanie, odpowiedź w jednym zdaniu z liczbą.
• "Pokaż mi dostawców, od których nie zamawialiśmy od ponad kwartału." AI sprawdza tabele zamówień zakupu, zwraca listę z datami ostatnich dostaw i wartościami historycznych zamówień.

Pracownicy szybko przestają zadawać ogólne pytania. Zaczynają pytać konkretnie. "Na kiedy mamy zaplanowane dostawy od firmy X w przyszłym tygodniu?" albo "Które pozycje z zamówienia ZAM/2026/10/112 nie mają jeszcze wystawionego WZ?" To jest moment, kiedy wartość systemu staje się oczywista dla całego zespołu.

Co AI nie robi i gdzie trzeba uważać

AI nie modyfikuje żadnych danych. To zdanie pada u każdego klienta przy pierwszej rozmowie i zawsze lepiej powiedzieć to wprost.

Przy starych bazach pisanych 15-20 lat temu bez żadnej dokumentacji zdarzają się tabele z kolumnami o nazwach kol1, kol2, x_val. Tam mapowanie zajmuje więcej czasu, bo trzeba usiąść z kimś, kto te tabele zna, i opisać każdą kolumnę. Bez tego AI generuje błędne zapytania albo łączy ze sobą nie te pola.

Bazy z dużą ilością danych osobowych: kadrowe, medyczne, bazy pacjentów, wymagają osobnej analizy pod kątem RODO przed uruchomieniem. Nie każde pytanie powinno być dostępne dla każdego użytkownika. Decydujemy wtedy, które tabele są w ogóle dostępne i dla kogo w firmie.

AI nie zastąpi też analityka, gdy pytanie wymaga wiedzy, której nie ma w bazie. Jeśli zasady naliczania marży handlowej są w głowach handlowców albo w arkuszu Excela poza systemem, a nie w kolumnie marza tabeli pozycja_zamowienia, AI tego nie wie i nie będzie udawać, że wie.

Od czego zaczynamy, żeby to wdrożyć?

Pierwsze trzy kroki są zawsze podobne. Zaczynamy od audytu: jakie tabele są w bazie, co trzymają, które widoki już istnieją, kto dziś wyciąga z nich dane i w jaki sposób. Zwykle są to dwie, trzy osoby w firmie.

Potem zakładamy osobne konto SQL z prawem SELECT na wybranych tabelach i widokach. Żadnych uprawnień systemowych, żadnych ról administracyjnych. Następnie przygotowujemy opis struktury dla AI: co znaczy każda tabela, każda kolumna, jakie wartości przyjmują pola statusów i typów dokumentów.

Potem testy. Zadajemy kilkadziesiąt pytań biznesowych razem z kimś z firmy i sprawdzamy, czy AI generuje poprawne zapytania i czy wyniki zgadzają się z tym, co firma wie z innych źródeł. Ten etap wymaga zaangażowania kogoś po stronie klienta, bo tylko firma wie, co jest "prawda" w jej własnych danych.

Po uruchomieniu monitorujemy przez kilka tygodni, które pytania AI odpowiada dobrze, a gdzie generuje błędy. Często dodajemy wtedy kolejne tabele albo poprawiamy opis struktur. Z czasem zakres rośnie, bo pracownicy sami zgłaszają, o co chcieliby jeszcze pytać.

Czas od audytu do działającego systemu zależy głównie od stanu dokumentacji bazy i liczby tabel, które chcemy udostępnić. Przy dobrze prowadzonej bazie z opisanymi strukturami jest krótki. Przy starszych systemach bez dokumentacji bywa dłuższy, bo opisanie schematu jest pracą, której nie można pominąć.

Jeśli chcesz sprawdzić, czy Twoja baza nadaje się do takiej integracji, zapraszamy na bezpłatny audyt. Sprawdzimy strukturę, wskażemy, co można podpiąć od razu, a co wymaga wcześniejszego przygotowania. Możesz też zobaczyć, jak to działa u innych, w naszych realnych wdrożeniach.