Jak decydujecie, co trafia do słownika?

Hasło zasługuje na wpis, kiedy pojawia się w realnej pracy: w ankiecie od klienta, w znalezisku z audytu, w teście bezpieczeństwa albo przy klasyfikacji pod EU AI Act. Jeśli nigdy nie musieliśmy czegoś klientowi tłumaczyć, tego tu nie ma, choćby było popularne w materiałach dostawców.

Czy możemy użyć tych definicji we własnej dokumentacji?

Tak. Są pisane tak, żeby dało się je cytować w politykach wewnętrznych, specyfikacjach i ankietach dla dostawców. Wskazanie dfzoo AI Institute jako źródła jest mile widziane, ale nie jest wymagane.

Czy wersja polska i angielska opisują te same pojęcia?

Tak, ten sam zestaw haseł, ale każda wersja jest pisana natywnie, a nie tłumaczona. Wersja polska zachowuje angielskie rzeczowniki inżynierskie, których polskie zespoły faktycznie używają w rozmowie, bo wymyślanie polskich odpowiedników pogarsza użyteczność tekstu, zamiast ją poprawiać.

Jak często aktualizujecie słownik?

Wtedy, kiedy zmienia się praktyka, czyli w tej dziedzinie kilka razy w roku. Hasła regulacyjne sprawdzamy przed publikacją wobec tekstu źródłowego i weryfikujemy ponownie, gdy pojawiają się wytyczne.

Słownik pojęć AI: terminy, które padają w projektach AI, wyjaśnione po ludzku

Prompt injection (wstrzyknięcie instrukcji): Atak, w którym tekst docierający do modelu jest tak spreparowany, żeby nadpisać instrukcje nadane przez twórcę aplikacji. Bezpośredni prompt injection pochodzi od użytkownika piszącego w interfejsie, a pośredni jest ukryty w treści, którą model czyta samodzielnie: na stronie WWW, w dokumencie, w mailu albo w komentarzu w kodzie. Wariant pośredni jest trudniejszy, bo atakujący w ogóle nie dotyka interfejsu. Powiązana usługa: Security Review
Jailbreak (obejście zabezpieczeń modelu): Prompt zaprojektowany tak, żeby model ominął własne zachowania bezpieczeństwa i wygenerował treść, której normalnie by odmówił. Jailbreak celuje w wyrównanie samego modelu, a prompt injection w instrukcje aplikacji. W praktyce oba się przenikają i testuje się je w jednym ćwiczeniu. Powiązana usługa: Security Review
Guardrails (zabezpieczenia wokół modelu): Mechanizmy kontrolne otaczające model i ograniczające to, co do niego wchodzi i co z niego wychodzi: filtrowanie wejścia, walidacja wyjścia, kontrola dopuszczalnych tematów, wymuszanie schematu, limity uprawnień i tempa wywołań narzędzi. Guardrails to inżynieria, a nie promptowanie, i to ta warstwa działa dalej, kiedy prompt zawiedzie. System, którego jedynym zabezpieczeniem jest zdanie w system prompcie, nie ma zabezpieczeń. Powiązana usługa: Security Review
RAG (generowanie wspomagane wyszukiwaniem): Architektura, w której aplikacja najpierw wyszukuje istotne dokumenty lub rekordy i wkłada je do kontekstu modelu, zamiast polegać na tym, co model zapamiętał w treningu. To standardowy sposób osadzenia odpowiedzi we własnych danych i utrzymania ich aktualności bez ponownego trenowania. Większość awarii RAG to awarie wyszukiwania, a nie modelu. Powiązana usługa: AI-Powered Custom Development
RAG poisoning (zatruwanie bazy wiedzy): Umieszczenie złośliwej lub mylącej treści w bazie wiedzy, z której korzysta system RAG, tak żeby model powtórzył ją jako informację zaufaną. To atak na łańcuch dostaw kontekstu, a nie na kod, i działa dlatego, że pobrany tekst zwykle nie niesie informacji o pochodzeniu. Obroną są kontrola tego, co trafia do bazy, jawne wskazywanie źródeł i traktowanie pobranej treści jak danych niezaufanych. Powiązana usługa: AI Quality Evaluation
MCP (Model Context Protocol): Otwarty protokół standaryzujący sposób, w jaki model łączy się z zewnętrznymi narzędziami, źródłami danych i usługami, dzięki czemu jedna integracja działa w wielu klientach. Ogranicza ilość doraźnego kodu spinającego i czyni możliwości agenta możliwymi do przejrzenia. Koncentruje też ryzyko: serwer MCP jest granicą uprawnień i zasługuje na taki sam przegląd jak każda inna usługa uprzywilejowana. Powiązana usługa: Agentic AI Readiness
Agent: System, w którym model sam decyduje, jakie działania podjąć, wywołuje narzędzia, obserwuje wynik i kontynuuje, aż osiągnie cel albo natrafi na limit. Od zwykłego wywołania modelu odróżnia go autonomia w doborze kolejnych kroków. Wszystko, co czyni agenty użytecznymi, czyli trwałość, dostęp do narzędzi i iteracja, sprawia zarazem, że ich awarie trudniej ograniczyć. Powiązana usługa: Agentic AI Readiness
Tool calling (wywoływanie narzędzi): Mechanizm, w którym model prosi o wykonanie zdefiniowanej funkcji, na przykład wyszukiwania, zapytania do bazy albo wywołania API, i dostaje wynik z powrotem do kontekstu. To nie model uruchamia kod, tylko Wasza aplikacja, więc granica bezpieczeństwa leży po Waszej stronie. Każda definicja narzędzia jest decyzją o nadaniu uprawnień i powinna być zawężona tak bardzo, jak pozwala na to zadanie. Powiązana usługa: Agentic AI Readiness
Agentowy przepływ pracy (agentic workflow): Proces biznesowy lub inżynierski, w którym jeden lub kilka agentów prowadzi wielokrokową pracę w wielu systemach, a ludzie wyznaczają cele i weryfikują efekty, zamiast wykonywać każdy krok. Warto go budować tam, gdzie proces jest wysokowolumenowy, mocno regułowy i rozrzucony po narzędziach, których nigdy nie zintegrowano. Nie warto tam, gdzie deterministyczny skrypt zrobi to samo taniej. Powiązana usługa: Automatyzacja procesów
LLM observability (obserwowalność systemów LLM): Praktyka instrumentowania aplikacji opartej o LLM tak, żeby dało się zobaczyć, co faktycznie zrobiła: pełne ślady żądań, prompty i odpowiedzi, wywołania narzędzi, latencję, zużycie tokenów, koszt i sygnały jakości. Zwykły monitoring aplikacyjny tego nie pokrywa, bo żądanie może zakończyć się technicznym sukcesem i być merytorycznie błędne. Bez observability nie da się zdebugować regresji jakości, można ją tylko zgadywać. Powiązana usługa: LLM Observability
Eval / pipeline ewaluacyjny: Zautomatyzowany zestaw testów zachowania modelu: wyselekcjonowany zbiór wejść z oczekiwanymi właściwościami, oceniany przy każdej zmianie promptu, modelu lub wyszukiwania. To odpowiednik testów regresyjnych dla AI i jedyny wiarygodny sposób, żeby wiedzieć, czy zmiana cokolwiek poprawiła. Zespoły, które pomijają evals, wydają na wyczucie i dowiadują się od użytkowników. Powiązana usługa: LLM Observability
Drift (dryf jakości): Stopniowe rozjeżdżanie się tego, co system robił kiedyś, z tym, co robi teraz, wywołane zmianą danych wejściowych, aktualizacją modelu, edycją promptów albo bazą wiedzy, która poszła dalej. Dryf jest domyślnie cichy: nic się nie wywala, odpowiedzi po prostu robią się gorsze. Wykrycie wymaga stabilnego zbioru ewaluacyjnego i punktu odniesienia, do którego konsekwentnie się mierzy. Powiązana usługa: LLM Observability
Halucynacja: Odpowiedź płynna, pewna siebie i nieprawdziwa: zmyślony cytat, nieistniejące API, wymyślona liczba. To nie błąd do załatania, tylko właściwość sposobu, w jaki te modele generują tekst, więc się nią zarządza, a nie ją usuwa: osadzenie w pobranych źródłach, walidacja wyjścia, wymóg wskazania źródła i przegląd przez człowieka tam, gdzie koszt pomyłki jest wysoki. Powiązana usługa: AI Code Evaluation
Red teaming (testy adwersarialne): Ustrukturyzowane testowanie adwersarialne, w którym ludzie celowo próbują doprowadzić system AI do niewłaściwego zachowania: wycieku danych, obejścia reguł, nadużycia narzędzi, wygenerowania szkodliwej treści. Różni się od ewaluacji tym, że celem jest złamanie systemu, a nie zmierzenie go na oczekiwanych wejściach. Efektem jest zestaw odtwarzalnych ścieżek ataku z istotnością i rekomendowanymi zabezpieczeniami.
AI code review: Automatyczny przegląd zmian w kodzie wykonywany przez model, zwykle wpięty w pull requesty i łączony ze statyczną analizą. Daje ciągłe pokrycie i szybką informację zwrotną na każdej zmianie, także tej, której nikt nie przeczytałby uważnie. To nie to samo co niezależny audyt, który bada cały system i jest podpisany przez człowieka. Powiązana usługa: AI Code Evaluation
Kod generowany przez AI: Kod powstały w całości lub częściowo przy udziale asystenta lub agenta, od uzupełnionej linii po cały moduł. Psuje się w charakterystyczny sposób: wiarygodna logika, której nigdy nie wykonano, zduplikowane implementacje tej samej reguły, obsługa błędów wyglądająca na kompletną i testy sprawdzające implementację zamiast wymagania. Nie chodzi o to, żeby go unikać, tylko żeby recenzować go pod kątem defektów, które realnie wytwarza. Powiązana usługa: AI Code Evaluation
Bramka jakości (quality gate): Jawny, zautomatyzowany warunek, który zmiana musi spełnić, zanim zostanie zmergowana lub wydana: przechodzące testy, progi pokrycia, brak nierozwiązanych krytycznych znalezisk, wymagane akceptacje. Bramka jest realna tylko wtedy, gdy blokuje, a jej nadpisanie zostawia ślad kto i dlaczego. Dla kodu generowanego przez AI bramka zastępuje założenie, że człowiek przeczytał każdą linijkę. Powiązana usługa: Production Readiness
Gotowość produkcyjna (production readiness): Zestaw warunków, które system musi spełnić, zanim zaczną od niego zależeć prawdziwi użytkownicy: monitoring i alerty, które realnie wychwycą awarię, przetestowana ścieżka wycofania, runbooki, imiennie wskazany dyżurny i znane limity pod obciążeniem. Dla funkcji AI dochodzą evals, guardrails, sufity kosztowe i zachowanie awaryjne, gdy dostawca modelu jest niedostępny. Gotowość to lista, którą ktoś podpisuje, a nie poczucie, że działa. Powiązana usługa: Production Readiness
Klasy ryzyka wg EU AI Act: EU AI Act dzieli systemy AI na poziomy o różnych obowiązkach: ryzyko niedopuszczalne (praktyki zakazane), wysokie (rozbudowane wymogi dokumentacji, jakości danych, logowania, nadzoru człowieka i oceny zgodności), ograniczone (głównie obowiązki informacyjne, na przykład ujawnienie, że rozmawia się z AI) oraz minimalne (bez szczególnych obowiązków). Klasyfikacja zależy od przeznaczenia i kontekstu użycia, a nie od technologii. Błędna klasa jest najdroższą pomyłką w całym procesie zgodności, w obie strony. Powiązana usługa: EU AI Act Technical Compliance
System AI wysokiego ryzyka: Wedle EU AI Act system, którego awaria może istotnie wpłynąć na zdrowie, bezpieczeństwo lub prawa podstawowe. Typowe przykłady to AI w rekrutacji, scoringu kredytowym, edukacji, usługach kluczowych, egzekwowaniu prawa i infrastrukturze krytycznej. Takie systemy niosą najcięższe obowiązki: zarządzanie ryzykiem, nadzór nad danymi, dokumentację techniczną, automatyczne logowanie, nadzór człowieka oraz wymogi dokładności i odporności. Większość z nich to obowiązki inżynierskie, dlatego sama opinia prawna ich nie zamyka. Powiązana usługa: EU AI Act Technical Compliance
Kompetencje w zakresie AI (AI literacy): Wymóg, by osoby uczestniczące w obsłudze lub użytkowaniu systemów AI rozumiały wystarczająco, jak te systemy działają, czego potrafią i czego nie potrafią oraz jakie niosą ryzyka, proporcjonalnie do roli. To obowiązek organizacyjny wynikający z EU AI Act, a nie dobra praktyka. W praktyce oznacza szkolenia dopasowane do ról plus zapis, kto, z czego i kiedy został przeszkolony. Powiązana usługa: Programy szkoleń AI
Nadzór człowieka (human oversight): Zaprojektowanie systemu AI tak, żeby kompetentna osoba mogła zrozumieć jego wynik, zainterweniować, nadpisać go albo zatrzymać system. To wymaganie architektoniczne, a nie zapis w polityce: ta osoba potrzebuje informacji, interfejsu, uprawnienia i czasu na reakcję. Przycisk akceptacji pod wynikiem, którego nikt nie potrafi zinterpretować, nadzorem nie jest. Powiązana usługa: Podstawy nadzoru nad AI
Karta modelu (model card): Krótki, ustrukturyzowany dokument opisujący model lub funkcję AI: przeznaczenie, znane ograniczenia, ogólny opis danych treningowych lub źródeł osadzenia, wyniki ewaluacji oraz warunki, w których nie należy z niego korzystać. Dzięki niej zespoły integrujące komponent wiedzą, co wolno z nim zrobić. Dla systemów regulowanych stanowi też element dokumentacji technicznej. Powiązana usługa: Podstawy nadzoru nad AI
System prompt (instrukcja systemowa): Zestaw instrukcji, który aplikacja podaje modelowi przed jakimkolwiek wejściem użytkownika, definiując rolę, ograniczenia, ton i format odpowiedzi. To konfiguracja aplikacji i powinna być wersjonowana, recenzowana i testowana jak każda inna ścieżka w kodzie. Traktowanie jej jako granicy bezpieczeństwa jest błędem: system prompt to wskazówka, nie egzekwowanie. Powiązana usługa: Wdrożenie narzędzi
Token: Jednostka, którą model czyta i wytwarza, mniej więcej krótkie słowo lub jego fragment, zależnie od języka i tokenizatora. Tokeny są jednocześnie jednostką rozliczeniową i jednostką pojemności, więc konstrukcja promptu ma bezpośredni, mierzalny koszt. Polski i inne języki fleksyjne zużywają zwykle więcej tokenów niż angielski na ten sam tekst, co ma znaczenie przy modelowaniu kosztu. Powiązana usługa: Optymalizacja kosztów i modeli
Okno kontekstowe (context window): Maksymalna liczba tokenów, które model może wziąć pod uwagę naraz, obejmująca system prompt, historię rozmowy, pobrane dokumenty i odpowiedź. Kiedy okno się zapełnia, coś trzeba usunąć albo streścić, a to, co zostanie usunięte, decyduje o tym, co model zapomni. Duże okno nie zastępuje decyzji o tym, co w ogóle powinno trafić do kontekstu. Powiązana usługa: AI-Powered Custom Development
Fine-tuning (dostrajanie modelu): Dalsze trenowanie istniejącego modelu na własnych przykładach, żeby przyjął określony format, styl albo wąskie zachowanie zadaniowe. Zmienia sposób odpowiadania, a nie zasób faktów, do których model ma dostęp, bo od tego jest wyszukiwanie. Ma sens, gdy prompty i RAG zostały wyczerpane, a Wy macie dość spójnych i dobrze opisanych przykładów, żeby uzasadnić koszt utrzymania. Powiązana usługa: AI-Powered Custom Development
Koszt na żądanie (cost per request): Pełny koszt modelu przy obsłudze jednej akcji użytkownika, wliczając ponowienia, wywołania narzędzi, pobrany kontekst oraz wywołania ewaluacyjne i moderacyjne na tej ścieżce. To jedyna miara kosztu, która pozwala połączyć wydatek u dostawcy z decyzjami produktowymi i z ceną, którą pobieracie. Zespoły patrzące na miesięczną fakturę zamiast na koszt na żądanie dowiadują się o regresji z około trzydziestodniowym opóźnieniem. Powiązana usługa: Optymalizacja kosztów i modeli
Latencja P95: Czas odpowiedzi, poniżej którego mieści się 95 procent żądań, czyli jedno na dwadzieścia jest wolniejsze. To uczciwa liczba dla doświadczenia użytkownika, bo średnia ukrywa ogon rozkładu, w którym ludzie faktycznie porzucają zadanie. Przy funkcjach LLM ogon budują długie generacje, ponowienia i wolne wywołania narzędzi, więc mierzy się go od końca do końca, a nie na pojedynczym wywołaniu dostawcy. Powiązana usługa: Telemetria i Analytics
Vendor lock-in (uzależnienie od dostawcy): Koszt zejścia z dostawcy modelu lub platformy AI, tworzony przez API specyficzne dla dostawcy, prompty dostrojone do jednej rodziny modeli, własnościowe osadzenia i dane, których nie da się wyeksportować. Pewne przywiązanie bywa rozsądną ceną za tempo, a błędem jest nie wiedzieć, ile kosztuje wyjście. Praktycznie łagodzi się to warstwą abstrakcji na granicy dostawcy, przenośnymi zbiorami ewaluacyjnymi i okresowym testem, czy drugi dostawca nadal działa. Powiązana usługa: Utrzymanie aplikacji
ISO 9001: Międzynarodowa norma systemów zarządzania jakością: udokumentowane procesy, przypisane odpowiedzialności, zapisy i ciągłe doskonalenie, weryfikowane przez zewnętrzną jednostkę certyfikującą. W kontekście współpracy oznacza, że sposób prowadzenia projektów, czyli ustalanie zakresu, przeglądy, rezultaty i działania korygujące, jest udokumentowanym i audytowanym procesem, a nie nieformalnym zwyczajem. Nie mówi nic o jakości konkretnego modelu, mówi o tym, jak kontrolowana jest praca wokół niego. Powiązana usługa: Podstawy nadzoru nad AI

Słownik pojęć AI: terminy, które padają w projektach AI, wyjaśnione po ludzku

Pytania, które zadają zespoły.

Porozmawiaj z inżynierem.