Pojęcia

Słownik inżynierii AI: pojęcia z projektów AI wyjaśnione po ludzku

Pojęcia, które padają na rozmowach o zakresie, w raportach z audytu i w ankietach dla dostawców, zdefiniowane tak, jak funkcjonują w zleceniach 23Minds. Tam, gdzie pojęcie łączy się wprost z jedną z praktyk, hasło prowadzi do niej.

W skrócie

Słownik 23Minds definiuje pojęcia z budowy, audytu i utrzymania systemów AI: bezpieczeństwo (prompt injection, jailbreak, guardrails, red teaming), architektura (RAG, MCP, agenci, wywoływanie narzędzi), jakość (ewaluacja, dryf, bramka jakości, gotowość produkcyjna), regulacje z AI Act (klasy ryzyka, system wysokiego ryzyka, kompetencje w zakresie AI, nadzór człowieka) oraz eksploatacja (okno kontekstu, koszt na żądanie, opóźnienie P95, uwiązanie do dostawcy). Definicje są krótkie i nadają się do cytowania w specyfikacji albo ankiecie dla dostawcy, po dopasowaniu do opisywanego systemu. Odzwierciedlają to, jak te pojęcia wyglądają w audytach i wdrożeniach, a nie to, jak reklamują je dostawcy.

Prompt injection: Atak, w którym tekst docierający do modelu jest tak ułożony, żeby nadpisać instrukcje, które dał mu twórca aplikacji. Bezpośrednie wstrzyknięcie promptu przychodzi od użytkownika wpisującego tekst do aplikacji; pośrednie jest ukryte w treści, którą model czyta sam: na stronie, w dokumencie, w mailu albo w komentarzu w kodzie. Pośrednie jest trudniejsze, bo atakujący nigdy nie dotyka interfejsu. Powiązana praktyka: Przegląd bezpieczeństwa kodu pisanego przez AI
Jailbreak: Prompt zaprojektowany tak, żeby model ominął własne zabezpieczenia i wyprodukował wynik, którego normalnie by odmówił. Jailbreak celuje w zachowanie modelu; prompt injection celuje w instrukcje aplikacji. W praktyce oba się przenikają i oba sprawdza się w tym samym ćwiczeniu. Powiązana praktyka: Przegląd bezpieczeństwa kodu pisanego przez AI
Guardrails (zabezpieczenia wokół modelu): Kontrole umieszczone wokół modelu, które ograniczają, co do niego wchodzi i co z niego wychodzi: filtrowanie wejścia, walidacja wyjścia, sprawdzanie dozwolonych tematów, wymuszanie schematu odpowiedzi, limity częstości i uprawnień narzędzi. Działają w kodzie aplikacji, więc pracują dalej, gdy prompt zawiedzie. Sam prompt systemowy nie zapewnia niezawodnej kontroli dostępu ani ochrony przed manipulowaniem instrukcjami. Powiązana praktyka: Przegląd bezpieczeństwa kodu pisanego przez AI
RAG (generowanie wspierane wyszukiwaniem): Architektura, w której aplikacja wyszukuje odpowiednie dokumenty albo rekordy i wkłada je do kontekstu modelu przed odpowiedzią, zamiast polegać na tym, co model zapamiętał w treningu. To standardowy sposób, żeby oprzeć odpowiedzi na własnych danych i utrzymać je aktualne bez ponownego trenowania. Wiele awarii RAG zaczyna się od wyszukiwania, nie od modelu, więc diagnozę zaczyna się od tego, co trafiło do kontekstu. Powiązana praktyka: Budowa oprogramowania z AI
Zatrucie RAG (RAG poisoning): Umieszczenie złośliwej albo mylącej treści w bazie wiedzy, z której korzysta system RAG, tak żeby model powtórzył ją w odpowiedzi jak zaufaną. To atak na łańcuch dostaw kontekstu, a nie kodu. Obrona to kontrola tego, co trafia do bazy, oznaczanie źródeł i traktowanie pobranej treści jak niezaufanego wejścia; samo oznaczenie źródła nie gwarantuje wiarygodności treści. Powiązana praktyka: Ewaluacja jakości działającej AI
MCP (Model Context Protocol): Otwarty protokół, który standaryzuje sposób łączenia modelu z zewnętrznymi narzędziami, źródłami danych i usługami, więc raz napisaną integrację można wykorzystać w wielu klientach. Ogranicza kod integracyjny pisany na zamówienie i pozwala przejrzeć, co agent potrafi. Skupia też ryzyko: serwer MCP jest granicą uprawnień i zasługuje na taki sam przegląd jak każda inna usługa z uprawnieniami.
Agent: System, w którym model decyduje, jakie działania podjąć, wywołuje narzędzia, obserwuje wynik i działa dalej, aż osiągnie cel albo trafi na limit. Od zwykłego wywołania modelu różni go samodzielność w kolejności kroków. Wszystko, co czyni agentów użytecznymi (trwałość, dostęp do narzędzi, iteracja), utrudnia też ograniczenie skutków ich błędów.
Wywoływanie narzędzi (tool calling): Mechanizm, w którym model prosi o wykonanie zdefiniowanej funkcji (wyszukania, zapytania do bazy, wywołania API) i dostaje wynik z powrotem do kontekstu. Model nie uruchamia kodu; robi to wasza aplikacja, więc granica bezpieczeństwa jest wasza. Każda definicja narzędzia jest decyzją o uprawnieniach, a uprawnienia narzędzia powinny obejmować tylko czynności potrzebne do zadania.
Proces z agentami (agentic workflow): Proces biznesowy albo inżynierski, w którym jeden agent albo kilku wykonuje wieloetapową pracę w wielu systemach, a ludzie wyznaczają cele i przeglądają wyniki, zamiast wykonywać każdy krok. Ma sens tam, gdzie kolejne kroki zależą od interpretacji bieżącej sytuacji, na przykład treści dokumentu albo maila. Tam, gdzie kroki są stałe i oparte na regułach, wystarcza zwykła automatyzacja: procedura z właścicielem i obsługą wyjątków. Powiązana praktyka: Automatyzacja procesów
LLM Observability: Zbieranie danych o działaniu aplikacji z modelem językowym tak, żeby dało się zobaczyć, co naprawdę zrobiła: pełne ślady żądań, prompty i odpowiedzi, wywołania narzędzi, opóźnienie, zużycie tokenów, koszt i sygnały jakości. Zwykły monitoring aplikacji tego nie obejmuje, bo żądanie może technicznie się udać i merytorycznie być błędne. Bez tych danych regresję jakości można tylko zgadywać, zamiast ją zdebugować. Powiązana praktyka: LLM Observability
Ewaluacja: Ocena modelu albo całego systemu według określonych kryteriów, na wybranym zestawie wejść z oczekiwanymi właściwościami, prowadzona automatycznie, przez ludzi albo obiema metodami. Uruchamiana przy każdej zmianie promptów, modeli albo wyszukiwania działa jak testy regresyjne dla AI. Zespoły, które jej nie prowadzą, wdrażają bez pomiaru i o regresji dowiadują się od użytkowników. Powiązana praktyka: Ewaluacja jakości działającej AI
Dryf: Zmiana zachowania systemu w czasie bez zmiany kodu ani konfiguracji, wywołana zmienionymi danymi wejściowymi, podmianą modelu u dostawcy albo zmienioną bazą wiedzy. To co innego niż regresja po wdrożeniu własnej zmiany. Dryf jest cichy: nic nie pada, odpowiedzi stopniowo się zmieniają. Wykrycie wymaga stabilnego zestawu ewaluacyjnego i punktu odniesienia, wobec którego dalej się mierzy. Powiązana praktyka: LLM Observability
Halucynacja: Wynik płynny, pewny siebie i błędny: zmyślony cytat, nieistniejące API, sfabrykowana liczba. Wynika z tego, jak modele generują tekst, więc się nim zarządza zamiast usuwać: oparcie odpowiedzi na pobranych źródłach, walidacja wyjścia, wymóg cytowania i przegląd przez człowieka tam, gdzie koszt pomyłki jest wysoki. Powiązana praktyka: Audyt kodu pisanego przez AI
Red teaming: Ustrukturyzowane testy adwersarialne, w których ludzie celowo próbują sprawić, żeby system AI zachował się źle: ujawnił dane, ominął reguły, nadużył narzędzi, wyprodukował szkodliwy wynik. Różni się od ewaluacji tym, że celem jest złamanie systemu, a nie zmierzenie go na oczekiwanych wejściach. Wynik to zestaw odtwarzalnych ścieżek ataku z wagą i zalecanymi kontrolami.
AI code review: Automatyczny przegląd zmian w kodzie przez model, zwykle wpięty w pull requesty i połączony z analizą statyczną. Daje sprawdzanie każdej zmiany i szybką informację zwrotną, także dla zmian, których żaden człowiek nie przeczytałby uważnie. Narzędzie do AI code review to co innego niż audyt kodu pisanego przez AI: audyt obejmuje uzgodniony zakres systemu, jest robiony przez ludzi i kończy się podpisanym raportem; narzędzie i audyt się uzupełniają. Powiązana praktyka: Audyt kodu pisanego przez AI
Kod pisany przez AI: Kod wyprodukowany w całości albo w części przez asystenta kodowania albo agenta, od dokończonej linii po cały moduł. Przegląd takiego kodu zwraca uwagę na kilka typowych problemów: wiarygodną logikę, której nikt nie uruchomił, zduplikowane implementacje jednej reguły, obsługę błędów, która wygląda na kompletną i nie jest, testy sprawdzające implementację zamiast wymagania. Chodzi o to, żeby przeglądać go pod kątem tych problemów, zamiast go unikać. Powiązana praktyka: Audyt kodu pisanego przez AI
Bramka jakości: Jawny, automatyczny warunek, który zmiana musi spełnić, zanim zostanie scalona albo wydana: przechodzące testy, progi pokrycia, brak nierozwiązanych krytycznych ustaleń, wymagane zatwierdzenia. Bramka działa tylko wtedy, gdy blokuje, a jej obejście zostawia zapis, kto to zrobił i dlaczego. Bramka sprawdza warunki, które da się zautomatyzować; zatwierdzenie przez osobę odpowiedzialną pozostaje osobnym warunkiem tam, gdzie zmiana tego wymaga. Powiązana praktyka: Gotowość produkcyjna
Gotowość produkcyjna: Zestaw warunków, które system musi spełnić, zanim użytkownicy zaczną od niego zależeć: monitoring i alerty, które wykryją awarię, przetestowana procedura wycofania, runbooki, osoba odpowiedzialna na dyżurze i określone limity pod obciążeniem. Dla funkcji AI obejmuje też ewaluację, zabezpieczenia, limity kosztów i wariant zapasowy na wypadek niedostępności dostawcy. Gotowość potwierdza lista kontrolna, którą ktoś podpisuje. Powiązana praktyka: Gotowość produkcyjna
Klasy ryzyka w AI Act: W uproszczeniu AI Act rozróżnia: zakazane praktyki (art. 5), systemy wysokiego ryzyka (art. 6 i załączniki I oraz III, z rozbudowanymi wymaganiami co do dokumentacji, jakości danych, logowania, nadzoru człowieka i oceny zgodności), systemy objęte obowiązkami przejrzystości (art. 50, na przykład informowanie, że użytkownik rozmawia z AI) oraz pozostałe systemy, dla których obowiązują ogólne przepisy, w tym o kompetencjach. Klasyfikacja zależy od celu i kontekstu użycia, nie od technologii. Błędna klasa jest kosztowna w obie strony: za wysoka mnoży obowiązki, za niska pomija wymagane. Powiązana praktyka: Zgodność z AI Act po stronie technicznej
System AI wysokiego ryzyka: Według art. 6 AI Act system uznany za wysokiego ryzyka, gdy jest elementem bezpieczeństwa produktu objętego przepisami z załącznika I albo należy do zastosowań z załącznika III, takich jak rekrutacja, ocena zdolności kredytowej, edukacja, dostęp do usług podstawowych, egzekwowanie prawa i infrastruktura krytyczna, z wyjątkami przewidzianymi w rozporządzeniu. Te systemy niosą najcięższe obowiązki: zarządzanie ryzykiem, zarządzanie danymi, dokumentację techniczną, automatyczne logowanie, nadzór człowieka, wymagania co do dokładności i odporności. Większość z nich to obowiązki inżynierskie, dlatego sama porada prawna ich nie zamyka. Powiązana praktyka: Zgodność z AI Act po stronie technicznej
Kompetencje w zakresie AI (AI literacy): Wiedza i umiejętności potrzebne, żeby świadomie korzystać z systemów AI i rozumieć ich możliwości, ograniczenia i ryzyka, w zakresie dopasowanym do roli. Art. 4 AI Act zobowiązuje dostawców i podmioty stosujące do podejmowania środków, które wspierają rozwój tych kompetencji u osób obsługujących i używających systemów AI, z uwzględnieniem ich roli i kontekstu użycia. Od 27 lipca 2026 przepis zastrzega, że nie wymaga zapewnienia określonego poziomu kompetencji u poszczególnych osób. Szkolenia dopasowane do roli i rejestr, kto był szkolony, z czego i kiedy, to sposób realizacji i udokumentowania tego obowiązku, nie jego treść. Powiązana praktyka: Programy szkoleń AI
Nadzór człowieka: Zaprojektowanie systemu AI tak, żeby kompetentna osoba mogła zrozumieć jego wynik, wkroczyć, uchylić go albo go zatrzymać. To wymaganie architektoniczne: ta osoba potrzebuje informacji, interfejsu, umocowania i czasu, żeby działać. Przycisk zatwierdzenia przy wyniku, którego nikt nie umie zinterpretować, nadzorem nie jest. Powiązana praktyka: Zasady korzystania z AI w firmie
Karta modelu (model card): Krótki, ustrukturyzowany dokument opisujący model albo funkcję AI: zamierzone użycie, znane ograniczenia, dane treningowe albo źródłowe na wysokim poziomie, wyniki ewaluacji i warunki, w których nie należy go używać. Pomaga osobom integrującym komponent sprawdzić jego przydatność do ich zastosowania. W systemach regulowanych jest też elementem dokumentacji technicznej. Powiązana praktyka: Zasady korzystania z AI w firmie
Prompt systemowy: Zestaw instrukcji, które aplikacja stawia przed modelem, żeby określić jego rolę, ograniczenia, ton i format odpowiedzi, zanim dotrze jakiekolwiek wejście od użytkownika. To konfiguracja aplikacji i powinna być wersjonowana, przeglądana i testowana jak każda inna ścieżka kodu. Traktowanie go jako granicy bezpieczeństwa to błąd: prompt systemowy to wskazówka, nie wymuszenie.
Token: Jednostka, którą model czyta i pisze: mniej więcej krótkie słowo albo jego fragment, zależnie od języka i tokenizera. Tokeny są jednocześnie jednostką rozliczenia i jednostką pojemności, więc projekt promptu ma bezpośredni, mierzalny koszt. Polski i inne języki fleksyjne zwykle zużywają więcej tokenów niż angielski na ten sam tekst, co ma znaczenie przy liczeniu kosztów. Powiązana praktyka: Optymalizacja kosztów modeli językowych
Okno kontekstu: Maksymalna liczba tokenów, którą model może rozważać naraz, łącznie z promptem systemowym, historią rozmowy, pobranymi dokumentami i odpowiedzią. Gdy okno się zapełnia, coś trzeba wyrzucić albo streścić, a to, co wypada, decyduje o tym, co model zapomina. Duże okno nie zastępuje decyzji, co należy do kontekstu. Powiązana praktyka: Budowa oprogramowania z AI
Dostrajanie (fine-tuning): Dalsze trenowanie istniejącego modelu na własnych przykładach, żeby przyjął konkretny format, styl albo zachowanie w wąskim zadaniu. Dostosowuje model na przykładach, ale nie zapewnia aktualności ani łatwej weryfikacji faktów; od tego jest wyszukiwanie. Warto to robić, gdy promptowanie i wyszukiwanie zostały wyczerpane, a macie dość spójnych, dobrze oznaczonych przykładów, żeby uzasadnić koszt utrzymania. Powiązana praktyka: Budowa oprogramowania z AI
Koszt na żądanie: Łączny koszt wywołań modeli za obsłużenie jednej akcji użytkownika, w uzgodnionych granicach pomiaru: zwykle razem z ponowieniami, wywołaniami narzędzi, pobranym kontekstem i wywołaniami ewaluacji albo moderacji na ścieżce. Pozwala połączyć wydatki u dostawcy z decyzjami produktowymi i z ceną, którą pobieracie. Zespoły, które patrzą tylko na miesięczną fakturę, dowiadują się o regresji kosztów dopiero po zamknięciu okresu rozliczeniowego. Powiązana praktyka: Optymalizacja kosztów modeli językowych
Opóźnienie 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 średnie ukrywają najdłuższe czasy odpowiedzi, przy których ludzie porzucają zadanie. W funkcjach opartych na modelach najdłuższe czasy tworzą długie generacje, ponowienia i wolne wywołania narzędzi, więc mierzy się je od początku do końca, a nie na jednym wywołaniu dostawcy. Powiązana praktyka: Telemetria i analityka produktu
Uwiązanie do dostawcy (vendor lock-in): Koszt odejścia od dostawcy modeli albo platformy AI, tworzony przez API specyficzne dla dostawcy, zachowanie promptów dostrojone do jednej rodziny modeli, własnościowe embeddingi i dane, których nie da się wyeksportować. Pewne sprzężenie jest rozsądną ceną za tempo; błędem jest nie wiedzieć, ile kosztuje wyjście. Praktyczna ochrona to abstrakcja na granicy dostawcy, przenośne zestawy ewaluacyjne i okresowy test, że drugi dostawca wciąż działa. Powiązana praktyka: Utrzymanie aplikacji
ISO 9001: Międzynarodowa norma systemów zarządzania jakością: udokumentowane procesy, określone odpowiedzialności, zapisy i ciągłe doskonalenie. Certyfikacja jest dobrowolna i polega na sprawdzeniu systemu przez zewnętrzną jednostkę certyfikującą. W zleceniach 23Minds objętych zakresem certyfikatu (m.in. tworzenie aplikacji, utrzymanie, szkolenia i doradztwo) sposób prowadzenia projektów jest procesem udokumentowanym i audytowanym. Norma nie mówi nic o jakości konkretnego modelu; mówi, jak kontrolowana jest praca wokół niego. Powiązana praktyka: Zasady korzystania z AI w firmie

FAQ

Pytania przed rozpoczęciem współpracy.

Pojęcie dostaje hasło, gdy pojawia się w prawdziwej pracy: w ankiecie od klienta, w ustaleniu z audytu, w ocenie bezpieczeństwa albo w klasyfikacji pod AI Act. Jeśli nigdy nie musieliśmy go wyjaśniać klientowi, nie ma go tutaj, choćby było częste w materiałach dostawców.

Tak. Są napisane tak, żeby dało się je cytować w politykach wewnętrznych, specyfikacjach i ankietach dla dostawców, po dopasowaniu do opisywanego systemu. Jeśli chcecie podać źródło: Słownik inżynierii AI, 23Minds, 23minds.com.

Tak, ten sam zestaw pojęć, ale każda wersja jest pisana osobno, nie tłumaczona. Polska wersja zostawia angielskie nazwy inżynierskie, których polskie zespoły naprawdę używają w rozmowie, bo wymyślanie lokalnych odpowiedników czyni tekst mniej użytecznym.

Gdy zmienia się praktyka, na której stoi, czyli w tej dziedzinie kilka razy w roku. Hasła regulacyjne sprawdzamy z tekstem źródłowym przed publikacją i ponownie, gdy pojawiają się wytyczne.

Porozmawiajmy o AI w waszej firmie.

Napiszcie, na jakim etapie jesteście z AI. Odpowiedź w ciągu jednego dnia roboczego.

Porozmawiajcie z inżynierem

Szczecin - ul. Wawrzyniaka 6WWarszawaZielona GóraKraków