# RS Management - pełne teksty wpisów bloga > Wszystkie opublikowane wpisy w jednym pliku, bez layoutu i nawigacji. > Skrócony opis witryny wraz z cennikiem: https://rsmanagement.ai/llms.txt > English summary of the site: https://rsmanagement.ai/en/llms.txt Wpisów po polsku: 14. Wpisów po angielsku: 14. Wersje językowe są odrębnymi tekstami, nie tłumaczeniami zdanie w zdanie. --- ## Wpisy po polsku (14) ### Kiedy AI poleca firmę, a kiedy jej nie zauważa https://rsmanagement.ai/blog/kiedy-ai-poleca-firme/ Opublikowano: 2026-08-11 | zaktualizowano: 2026-09-02 Boty AI czytają firmowe strony tysiące razy częściej, niż odsyłają odwiedzających. Co z tego wynika, czego nie kupować i jak zmierzyć własną widoczność. Coraz więcej pytań zakupowych nie trafia już do wyszukiwarki. Klient pisze do ChatGPT albo Perplexity zdanie w rodzaju „poleć dobrą firmę, która zrobi mi to i to, w moim mieście, i podaje ceny” i dostaje w odpowiedzi trzy nazwy z uzasadnieniem. Nie widzi dziesięciu niebieskich linków, nie porównuje ich sam, nie wchodzi na dziesięć stron. Dostaje gotową odpowiedź. Jeśli nazwy firmy w niej nie ma, to z punktu widzenia tego klienta firma nie istnieje. To nie jest przewidywanie na przyszły rok. To już się dzieje i widać to w logach serwerów. #### Boty czytają, ale nie odsyłają Najbardziej wymowna liczba w tej dyskusji jest prosta: ile razy bot musi pobrać treść ze stron, zanim jedna osoba trafi na taką stronę z odpowiedzi modelu. W lipcu 2026 boty Anthropic pobierały ok. 1 900 stron na każde wejście, które odesłały, a boty OpenAI ok. 250.[^radar] Rok wcześniej ta sama proporcja dla Anthropic sięgała kilkudziesięciu tysięcy, więc kierunek jest w stronę poprawy, tylko z bardzo wysokiego pułapu. Dwie rzeczy warto przy tych liczbach wiedzieć: zmieniają się z miesiąca na miesiąc, a sam Cloudflare zastrzega, że są prawdopodobnie zawyżone, bo wejścia z aplikacji Claude nie niosą informacji o źródle i nie dają się policzyć. Rząd wielkości zostaje ten sam i to on jest wnioskiem: treść jest czytana masowo, a odwiedzający z tego nie wraca. Klasyczna wyszukiwarka przez dwie dekady działała na zasadzie wymiany, w której obie strony coś dostawały: my treść do zaindeksowania, my w zamian ruch. Kiedy odpowiedź powstaje w oknie czatu, wymiana przestaje być symetryczna. Treść jest nadal potrzebna, kliknięcie już nie. Wniosek dla właściciela firmy jest niewygodny, ale prosty. Nie da się już mierzyć całej widoczności wejściami z organicznych wyników. Część decyzji zakupowych podejmowana jest w miejscu, do którego żadna analityka na stronie nie zagląda. #### Co ogłosił Cloudflare i co z tego naprawdę wynika W tle toczy się spór o pieniądze i warto go rozumieć, żeby nie kupić czegoś przedwcześnie. 1 lipca 2025 Cloudflare, jedna z największych firm obsługujących ruch internetowy, uruchomił pay-per-crawl: mechanizm, w którym właściciel strony może zażądać opłaty od bota AI za pobranie treści, odpowiadając kodem HTTP 402, czyli „wymagana płatność”. Brzmiało to jak początek nowego źródła przychodu dla wydawców. Dokładnie rok później, 1 lipca 2026, Cloudflare sam odstawił ten pomysł na bok i zapowiedział Monetization Gateway: rozliczenie nie za pobranie strony, a za faktyczne użycie treści w odpowiedzi. Na razie to lista oczekujących i dwóch partnerów: Ceramic.ai i You.com. 4 sierpnia 2026 doszły do tego Cloudflare Wallets, czyli portfele w stablecoinach, z których agenci AI mają płacić za dostęp do usług. Kierunek jest sensowny, tylko skala mikroskopijna. Cały rynek takich mikropłatności jest dziś mniejszy niż roczny obrót jednej średniej hurtowni, a pojedyncza transakcja to kilkadziesiąt groszy. Jeśli ktoś proponuje dziś „zarabianie na botach AI” jako usługę dla zwykłej firmy, sprzedaje zapowiedź, nie produkt. Jest jednak druga strona tego samego ogłoszenia, dostępna od razu i bez opłaty. AI Crawl Control działa na każdym planie Cloudflare, w tym na podstawowym, i pokazuje, które boty AI wchodzą na stronę, jak często i po co. To pierwszy pomiar, który warto zrobić, bo zajmuje kwadrans i nie wymaga żadnej decyzji zakupowej. Druga rzecz to wiedzieć, czego nie kupować. Ostatni rok przyniósł modę na plik llms.txt, czyli krótką instrukcję dla modeli językowych, którą umieszcza się na stronie. Przebadano 137 tysięcy stron, które taki plik wdrożyły: 97% z nich nie zanotowało ani jednego zapytania o niego, a wśród tych nielicznych, które coś zanotowały, po plik sięgały głównie narzędzia SEO, a nie modele.[^ahrefs] To nie znaczy, że pomysł jest zły w założeniu. To znaczy, że dzisiaj nie zmienia wyniku i nie jest wart osobnej pozycji na fakturze. Ciekawsza jest druga strona tej samej sprawy. Strona internetowa może wprost powiedzieć botom, czego im wolno, a czego nie, i robi to dziś ledwie kilka procent firm. Większość nie podjęła żadnej decyzji, bo nie wie, że jest do podjęcia. #### Co decyduje, czy model wymieni firmę Nudna prawda: to samo, co od lat wpływa na jakość informacji o firmie w sieci, tylko teraz ma wyższą stawkę. **Dane strukturalne.** Znaczniki schema.org, które opisują wprost, czym jest dana strona: organizacja, usługa, cena, godziny otwarcia, lokalizacja, opinia. Model nie musi ich zgadywać z układu graficznego, dostaje je podane. Dla firmy usługowej z jedną lokalizacją to kilka godzin pracy. **Czytelna strona cennika.** Ceny jako tekst, nie jako grafika ani plik PDF do pobrania. Widełki lepiej niż nic, „skontaktuj się z nami” najgorzej. Pytania zakupowe niemal zawsze zawierają element ceny, a model nie potrafi zacytować liczby, której nie widzi. **Spójność informacji.** Ta sama nazwa firmy, adres, telefon i zakres usług na stronie, w wizytówce Google, w katalogach branżowych i na profilach społecznościowych. Sprzeczne dane to najczęstsza przyczyna tego, że model opisuje firmę ostrożnie albo pomija ją na rzecz konkurenta, którego dane się zgadzają. **Strona czytelna bez JavaScriptu.** Jeśli treść pojawia się dopiero po wykonaniu skryptów w przeglądarce, część botów zobaczy pustą stronę. Prosty test: wyłączyć JavaScript i sprawdzić, co zostaje. **Skan technicznej gotowości.** Narzędzie isitagentready.com wystawia stronie ocenę w czterech kategoriach i wskazuje, co poprawić. Nie jest wyrocznią i nie zastąpi pomiaru rzeczywistej widoczności, ale jako punkt wyjścia nie wymaga ani opłaty, ani rejestracji. #### Metoda 30 pytań Ocena techniczna mówi, czy stronę da się przeczytać. Nie mówi, czy model faktycznie wymienia firmę. To trzeba sprawdzić osobno i da się to zrobić samemu. Metoda jest prosta w opisie i pracochłonna w wykonaniu. Krok pierwszy: lista 30 pytań, które klient wpisuje przed zakupem, we własnej branży. Nie hasła z SEO, tylko całe zdania z intencją, zbudowane wokół trzech wzorców: ile to kosztuje, kto robi to w danym mieście lub regionie, kto ma w tym dobre opinie. W praktyce brzmi to jak „ile kosztuje wdrożenie systemu do obsługi zamówień w hurtowni”, „kto prowadzi szkolenia z AI dla kadry zarządzającej w Trójmieście” albo „która kancelaria zna się na umowach IT”. Dwie trzecie pytań ma nie zawierać nazwy firmy, jedna trzecia ma ją zawierać, żeby sprawdzić, co model mówi o firmie, kiedy już wprost o nią zapytać. Krok drugi: każde pytanie idzie w co najmniej trzech miejscach. ChatGPT, Perplexity i przegląd AI w wynikach Google to sensowne minimum, bo działają na różnych źródłach. Za każdym razem nowa rozmowa, bez zalogowanej historii, która zaburza wynik. Krok trzeci: przy każdej odpowiedzi notujemy trzy rzeczy. Czy firma została wymieniona. Na którym miejscu w kolejności. Które źródło model zacytował. To ostatnie jest najciekawsze, bo zwykle okazuje się, że modele cytują katalog branżowy albo portal z opiniami, a nie stronę firmy. Krok czwarty: liczymy udział. Ile z 30 pytań dało wzmiankę, ile wzmianek było poprawnych merytorycznie, ile razy pojawiła się konkurencja. Ta pierwsza liczba jest wartością bazową. Bez niej każda późniejsza zmiana na stronie jest zgadywaniem. Krok piąty: cały przebieg powtarzamy po sześciu do ośmiu tygodniach, tym samym zestawem pytań. Odpowiedzi modeli są zmienne z natury, więc pojedynczy pomiar mówi mało, a różnica między dwoma pomiarami mówi już dużo. Cały przebieg dla jednej firmy to około jednego dnia pracy, jeśli robić go uczciwie i notować wszystko. Da się skrócić, ale wtedy spada wiarygodność porównania. #### Co zrobić w najbliższym miesiącu Nie ma tu żadnej rewolucji do przegapienia. Jest zmiana proporcji: coraz większa część decyzji zakupowych zapada w rozmowie z modelem, a nie na liście wyników, i większość firm nie wie, co model o nich mówi. Dwie rzeczy w najbliższym miesiącu nie wymagają budżetu, tylko czasu: włączyć podgląd ruchu botów AI i przejść przez 30 pytań własnych klientów. [^radar]: Cloudflare Radar, proporcja pobrań do odesłań dla botów AI: . [^ahrefs]: Ahrefs, analiza 137 tysięcy witryn z plikiem llms.txt: . Jeśli wygodniej mieć to zmierzone i opisane z zewnątrz, robimy takie pomiary w ramach [naszych usług](/uslugi/). Wynik jest zwykle mniej dramatyczny i bardziej konkretny, niż zakłada właściciel firmy przed pierwszym przebiegiem. --- ### Popularne repozytoria AI na GitHubie https://rsmanagement.ai/blog/popularne-repozytoria-ai-na-githubie/ Opublikowano: 2026-08-07 | zaktualizowano: 2026-09-02 Najpopularniejsze projekty AI na GitHubie w sierpniu 2026 i co liczba gwiazdek mówi o dojrzałości, a czego nie mówi. Pytanie na spotkaniach zarządu pada niemal zawsze w tej samej formie: czy to jest już standard rynkowy. Odpowiedź, której wszyscy w pokoju szukają, sprowadza się zwykle do jednej liczby, czyli gwiazdek na GitHubie. Liczba jest publiczna, łatwa do porównania i wygląda na obiektywną, więc trafia do prezentacji i do decyzji o architekturze. Warto rozumieć, co ta liczba faktycznie mierzy. #### Krajobraz w sierpniu 2026 Poniższe wartości to liczby gwiazdek zaokrąglone do pełnych tysięcy.

Skrót MCP w zestawieniu poniżej oznacza Model Context Protocol, otwarty standard podłączania agentów AI do firmowych narzędzi.

Frameworki i platformy agentowe

  1. OpenClaw386 k
  2. AutoGPT186 k
  3. LangChain144 k
  4. browser-use108 k
  5. MCP servers89 k
  6. OpenHands83 k
  7. Cline66 k
  8. CrewAI57 k
  9. LlamaIndex51 k
  10. LangGraph39 k
Gwiazdki w tysiącach. Skala jest wspólna dla wszystkich czterech zestawień, więc długości słupków da się porównywać między kategoriami. 100% szerokości to OpenClaw z 386 tysiącami[^github]; dla odniesienia React ma 247 tysięcy.
Repozytorium serwerów Model Context Protocol, widoczne w pierwszym zestawieniu, stało się faktycznym punktem wymiany integracji między narzędziami.

Uruchamianie modeli na własnej infrastrukturze

  1. Ollama178 k
  2. Transformers163 k
  3. llama.cpp123 k
  4. vLLM88 k
  5. LlamaFactory74 k
  6. Unsloth70 k
  7. LocalAI48 k
  8. SGLang32 k
Gwiazdki w tysiącach, ta sama skala co wyżej.

RAG i wyszukiwanie semantyczne

RAG (retrieval-augmented generation) to wzorzec, w którym system najpierw wyszukuje fragmenty firmowych dokumentów, a dopiero potem dokleja je do polecenia dla modelu.

  1. RAGFlow87 k
  2. Milvus46 k
  3. FAISS41 k
  4. GraphRAG35 k
  5. Qdrant34 k
  6. Chroma29 k
  7. Haystack26 k
  8. Weaviate17 k
Gwiazdki w tysiącach, ta sama skala co wyżej.

Orkiestracja przepływów i interfejsy

  1. n8n200 k
  2. Langflow153 k
  3. Dify152 k
  4. Open WebUI148 k
  5. AnythingLLM64 k
  6. LiteLLM56 k
  7. Flowise55 k
  8. LibreChat42 k
Gwiazdki w tysiącach, ta sama skala co wyżej.
Jedna liczba z tej listy zaburza skalę pozostałych. OpenClaw ma więcej gwiazdek niż React, czyli 247 tysięcy[^github], i doszedł do tego w niespełna osiem miesięcy. Do czołówki całego GitHuba, gdzie zbiory materiałów do nauki programowania przekraczają pół miliona gwiazdek, wciąż mu daleko, a i tak żaden projekt AI nie rósł dotąd tak szybko. #### Co popularność faktycznie mówi Wysoka pozycja niesie kilka informacji o wartości biznesowej. Po pierwsze, dostępność kompetencji. Przy projekcie z sześciocyfrową liczbą gwiazdek łatwiej znaleźć wykonawcę, łatwiej zrekrutować i łatwiej zastąpić osobę, która odchodzi z zespołu. Po drugie, powierzchnia integracji. Popularne biblioteki mają gotowe konektory do systemów, z których organizacja i tak korzysta, co skraca prace integracyjne. Po trzecie, jakość materiałów. Duża społeczność oznacza opisane błędy, przykłady wdrożeniowe i to, że modele językowe znają API (interfejs programistyczny) danego projektu, więc wsparcie AI przy pisaniu kodu jest po prostu skuteczniejsze. Po czwarte, uwaga badaczy bezpieczeństwa. Podatności w szeroko używanych komponentach są znajdowane szybciej. #### Czego popularność nie mówi Tu zaczyna się część, którą łatwo pominąć przy pobieżnej analizie. **Gwiazdka jest zakładką, która nigdy nie znika.** Licznik rośnie i nigdy nie maleje, więc projekt wygaszany może przez lata utrzymywać wysoką pozycję. Microsoft AutoGen ma ponad 60 tysięcy gwiazdek, a ostatnie zmiany w kodzie pochodzą z 15 kwietnia 2026.[^github] README repozytorium informuje wprost o trybie utrzymaniowym i kieruje nowych użytkowników do Microsoft Agent Framework, który zebrał około 13 tysięcy gwiazdek. Organizacja wybierająca komponent po pozycji w rankingu wybrałaby w tym przypadku projekt zamykany, a odrzuciła jego oficjalnego następcę. **Popularność nie mówi nic o licencji.** n8n z 200 tysiącami gwiazdek[^github] jest udostępniony na Sustainable Use License i sam projekt nie określa się mianem open source, ponieważ licencja ogranicza zastosowania komercyjne w sposób niedopuszczalny dla definicji Open Source Initiative. Dify korzysta ze zmodyfikowanej licencji Apache 2.0, która zabrania prowadzenia środowisk wielodostępnych bez osobnej zgody oraz usuwania logotypu z interfejsu. Dla firmy planującej odsprzedaż usługi klientom końcowym to różnica rozstrzygająca, całkowicie niewidoczna w liczbie gwiazdek. **Popularność nie mówi o profilu ryzyka.** OpenClaw zdobył swoją pozycję jako asystent działający na maszynie użytkownika, wykonujący polecenia powłoki i operacje na plikach, sterowany z komunikatorów. Ta charakterystyka jest źródłem zarówno entuzjazmu, jak i poważnych zastrzeżeń w środowiskach z danymi osobowymi lub tajemnicą przedsiębiorstwa. Tempo przyrostu gwiazdek odzwierciedla ciekawość rynku i nie stanowi oceny gotowości korporacyjnej. #### Sześć sygnałów zamiast rankingu Zanim komponent trafi do naszej rekomendacji, przechodzi przez sześć sprawdzeń. Żadne z nich nie wymaga narzędzi ani dostępu poza publicznym repozytorium, a razem zajmują kwadrans. Kolejność nie jest przypadkowa: pierwsze trzy sygnały mówią, czy projekt jeszcze żyje, pozostałe trzy, czy da się na nim bezpiecznie budować. - Data ostatniego commita, a nie ostatniego wydania. Wydanie można wypuścić z materiału przygotowanego dawno temu; commit pokazuje, czy ktoś nad projektem jeszcze siedzi. - Kadencja wydań: regularne wydania co kilka tygodni znaczą coś innego niż trzy wydania w jednym tygodniu i cisza przez pół roku. Nieregularność bywa sygnałem, że projekt trzyma się na jednej osobie. - Koncentracja kontrybutorów: jeśli większość zmian pochodzi od jednego konta, ryzyko przejmuje charakter osobowy: wystarczy zmiana pracy tej osoby. - Tempo zamykania zgłoszeń. Nie liczba otwartych, tylko to, czy zgłoszenia w ogóle dostają odpowiedź. Setka otwartych zgłoszeń przy szybkich reakcjach mówi co innego niż dwadzieścia otwartych i cisza od pół roku. - Zmiana licencji w historii projektu. Jeśli projekt raz już zaostrzył warunki, może to zrobić ponownie, a wtedy trzeba albo zostać na starej wersji bez poprawek, albo przepisać integrację. - Licencja przeczytana, nie zgadnięta. Etykieta „open source” w opisie repozytorium bywa nieścisła, a warunki ograniczające odsprzedaż albo środowiska wielodostępne widać dopiero w treści licencji. Przy dłuższej ocenie dochodzi obecność polityki bezpieczeństwa, a przy projektach z komercyjnym właścicielem pytanie, kto finansuje rozwój. Podmiot komercyjny oznacza zwykle przewidywalną kadencję wydań, a jednocześnie ryzyko zmiany licencji w chwili, w której inwestor zaczyna oczekiwać przychodu. Ten zestaw nie zastępuje testów. Odsiewa natomiast projekty, przy których testowanie byłoby stratą czasu, i robi to zanim ktokolwiek zacznie budować na nich integrację. Sygnały bywają sprzeczne i wtedy rozstrzyga warstwa, w której komponent ma stanąć, o czym niżej. **Popularność nie mówi o dopasowaniu.** Ranking nie zna wolumenu dokumentów, wymagań wobec opóźnień, języka danych ani tego, że dokumenty są w polskim, skanowanym PDF. Projekt najlepszy statystycznie bywa przewymiarowany wobec zadania albo pozbawiony jednej funkcji, która w danym przypadku decyduje o wszystkim. #### Warstwy różnią się kosztem pomyłki Z tego wynika kolejność decyzji. Warstwa serwowania modeli jest stosunkowo tania w wymianie, ponieważ interfejsy są zbliżone do standardu i migracja z jednego silnika na drugi zajmuje dni. Warstwa orkiestracji agentów i przepływów jest najdroższa w wymianie, bo przenika logikę biznesową i przyzwyczajenia zespołu. Tam, gdzie koszt zmiany jest wysoki, wybór ostrożny i sprawdzony zwraca się szybciej niż wybór modny. Tam, gdzie koszt zmiany jest niski, eksperymentowanie z młodszymi projektami jest rozsądne. Ta sama słabość znaczy co innego w zależności od tego, jak drogo kosztowałoby wycofanie się z decyzji. Komponenty open source wchodzące w skład systemu AI podlegają temu samemu reżimowi dokumentacyjnemu co reszta rozwiązania, łącznie z obowiązkami wynikającymi z unijnego aktu o sztucznej inteligencji. [^github]: Publiczne liczniki gwiazdek w repozytoriach: [OpenClaw](https://github.com/openclaw/openclaw), [React](https://github.com/facebook/react), [n8n](https://github.com/n8n-io/n8n), [Dify](https://github.com/langgenius/dify), [Microsoft AutoGen](https://github.com/microsoft/autogen), [Microsoft Agent Framework](https://github.com/microsoft/agent-framework). --- ### AI Act po 2 sierpnia 2026 https://rsmanagement.ai/blog/ai-act-po-2-sierpnia-2026/ Opublikowano: 2026-08-04 Rozporządzenie 2024/1689 po nowelizacji z lipca 2026: co zaczęło obowiązywać 2 sierpnia, co przesunięto na grudzień 2027 i co z tego wynika dla HR. Data 2 sierpnia 2026 przez ponad dwa lata funkcjonowała jako moment pełnego stosowania unijnego rozporządzenia o sztucznej inteligencji. Sześć dni przed tym terminem obraz się zmienił. 27 lipca 2026 weszło w życie rozporządzenie (UE) 2026/1744, opublikowane w Dzienniku Urzędowym 24 lipca, które przesunęło najcięższą część obowiązków o kilkanaście miesięcy. Termin nie zniknął, ale oznacza dziś coś innego, niż zakładała większość planów zgodności pisanych w 2025 roku. Przy klasyfikacji konkretnego systemu warto sięgnąć po wsparcie prawnika. #### Kalendarz, który warto mieć przed oczami Rozporządzenie (UE) 2024/1689 weszło w życie 1 sierpnia 2024 i od początku uruchamiało się etapami, zgodnie z artykułem 113: | Data | Co zaczyna obowiązywać | |---|---| | 1 sierpnia 2024 | Wejście w życie rozporządzenia (UE) 2024/1689 | | 2 lutego 2025 | Zakazane praktyki i obowiązek kompetencji w zakresie AI (rozdz. I i II) | | 2 sierpnia 2025 | Modele ogólnego przeznaczenia, organy nadzoru, kary, poufność | | 2 sierpnia 2026 | Pozostała część rozporządzenia, w tym przejrzystość z art. 50 oraz art. 101 | | 2 grudnia 2026 | Nowe zakazy z art. 5; koniec okresu przejściowego na oznaczanie treści | | 2 grudnia 2027 | Samodzielne systemy wysokiego ryzyka z załącznika III (przesunięte) | | 2 sierpnia 2028 | Systemy wysokiego ryzyka wbudowane w produkty z załącznika I (przesunięte) | - 2 lutego 2025: zakazane praktyki oraz obowiązek kompetencji w zakresie AI (rozdziały I i II). - 2 sierpnia 2025: modele ogólnego przeznaczenia, struktura organów nadzoru, przepisy o karach oraz poufność (rozdział III sekcja 4, rozdziały V, VII i XII poza artykułem 101, a także artykuł 78). - 2 sierpnia 2026: stosowanie pozostałej części rozporządzenia, w tym obowiązki przejrzystości z artykułu 50 oraz artykuł 101, czyli kary dla dostawców modeli ogólnego przeznaczenia. - 2 grudnia 2027: samodzielne systemy wysokiego ryzyka z załącznika III, przesunięte z 2 sierpnia 2026. - 2 sierpnia 2028: systemy wysokiego ryzyka wbudowane w produkty objęte prawodawstwem sektorowym z załącznika I, przesunięte z 2 sierpnia 2027. Nowelizacja dołożyła też dwie daty pośrednie. Od 2 grudnia 2026 zaczną obowiązywać nowe zakazy z artykułu 5, obejmujące generowanie materiałów intymnych bez zgody osoby oraz materiałów przedstawiających seksualne wykorzystywanie dzieci. Ten sam dzień kończy okres przejściowy na oznaczanie treści w formacie odczytywalnym maszynowo dla systemów wprowadzonych do obrotu przed 2 sierpnia 2026. #### Co faktycznie zaczęło obowiązywać 2 sierpnia Zostały obowiązki przejrzystości z artykułu 50 i to one schodzą dziś na poziom operacyjny. Sprowadzają się do kilku sytuacji. Osoba rozmawiająca z systemem AI musi zostać o tym poinformowana. Treści syntetyczne, czyli dźwięk, obraz, wideo i tekst, wymagają oznaczenia w formacie odczytywalnym maszynowo po stronie dostawcy. Systemy rozpoznawania emocji oraz kategoryzacji biometrycznej wymagają poinformowania osób nimi objętych. Materiały typu deepfake oraz teksty publikowane w sprawach interesu publicznego wymagają ujawnienia przez podmiot stosujący, przy czym dla treści poddanych redakcji człowieka przewidziano wyjątki. W praktyce dotyka to wielu firm, które nie uważają się za organizacje technologiczne: chatbot na stronie, asystent w kanale obsługi klienta, grafika lub nagranie wygenerowane do kampanii marketingowej. Przegląd tych punktów styku zajmuje zwykle kilka dni roboczych i jest najtańszym działaniem dostępnym w tym kwartale. #### Kary i odwrócona reguła dla mniejszych firm Artykuł 99 ustawia trzy poziomy sankcji: do 35 mln euro lub 7% światowego rocznego obrotu za naruszenie zakazanych praktyk, do 15 mln euro lub 3% za większość pozostałych naruszeń oraz do 7,5 mln euro lub 1% za podanie nieprawdziwych albo wprowadzających w błąd informacji.[^art99] Wobec przedsiębiorstw stosuje się wartość wyższą z tych dwóch. Tutaj kryje się szczegół, który w rozmowach z zarządami umyka najczęściej. Ustęp 6 tego samego artykułu odwraca regułę dla małych i średnich przedsiębiorstw, w tym startupów: wobec nich stosuje się wartość niższą z dwóch. Lipcowa nowelizacja dodała analogiczny mechanizm dla małych spółek o średniej kapitalizacji. Dla firmy z obrotem rzędu kilkudziesięciu milionów złotych różnica między tymi dwoma sposobami liczenia bywa różnicą między karą dotkliwą a karą kończącą działalność. #### HR jako obszar wysokiego ryzyka Załącznik III w punkcie 4 obejmuje zatrudnienie i zarządzanie pracownikami. Litera a wymienia systemy używane do rekrutacji i selekcji, w szczególności do kierowania ukierunkowanych ogłoszeń o pracę, analizy i filtrowania zgłoszeń oraz oceny kandydatów. Litera b obejmuje systemy wspierające decyzje o warunkach stosunku pracy, awansie i rozwiązaniu umowy, przydzielanie zadań na podstawie zachowania lub cech osobowych, a także monitorowanie i ocenę wyników oraz zachowania pracowników. Narzędzie rankujące życiorysy, model punktujący kandydatów, analiza nagrań z rozmów rekrutacyjnych, system przydzielający zadania na podstawie profilu pracownika: każde z nich mieści się w tym punkcie. Pełne wymogi zaczną obowiązywać 2 grudnia 2027, więc działy HR dostały około szesnastu dodatkowych miesięcy. Ten czas warto zagospodarować, ponieważ prace zajmują więcej, niż wygląda to na starcie. Rozsądna kolejność obejmuje spis wszystkich narzędzi dotykających kandydatów i pracowników, łącznie z funkcjami AI włączonymi w systemie rekrutacyjnym bez odrębnej decyzji zakupowej. Dalej idzie przegląd umów z dostawcami pod kątem dokumentacji, którą będą musieli dostarczyć. Potem projekt nadzoru ludzkiego, czyli wskazanie osoby, która ma kompetencje i mandat do odrzucenia rekomendacji systemu. Na końcu zasady informowania kandydatów i pracowników oraz retencja rejestrów zdarzeń. #### Obowiązki podmiotu stosującego poza HR Artykuł 26 nakłada obowiązki na organizację korzystającą z systemu wysokiego ryzyka, niezależnie od obowiązków dostawcy. Nie da się ich przenieść umową na kogoś innego, co bywa zaskoczeniem po zakupie gotowego narzędzia od uznanego producenta. Rdzeń tych obowiązków jest powtarzalny w każdej branży. Organizacja używa systemu zgodnie z instrukcją dostawcy. Powierza nadzór ludziom o odpowiednich kompetencjach i wsparciu. Monitoruje działanie systemu, a przy podejrzeniu ryzyka dla zdrowia, bezpieczeństwa lub praw podstawowych wstrzymuje jego użycie i informuje dostawcę oraz organ nadzoru. Przechowuje automatycznie generowane rejestry zdarzeń przez okres wskazany w przepisach. Dba o adekwatność danych wejściowych w zakresie, w jakim ma nad nimi kontrolę. Część podmiotów, w tym instytucje publiczne oraz podmioty świadczące określone usługi, przeprowadza dodatkowo ocenę skutków dla praw podstawowych z artykułu 27. #### Polski organ nadzoru rusza jesienią Równolegle domknęła się warstwa krajowa. Ustawa z 3 lipca 2026 o systemach sztucznej inteligencji została podpisana przez prezydenta 24 lipca i ogłoszona w Dzienniku Ustaw 27 lipca 2026, a zasadnicza część jej przepisów wejdzie w życie 11 sierpnia 2026. Powołuje ona Komisję Rozwoju i Bezpieczeństwa Sztucznej Inteligencji (KRiBSI) jako krajowy organ nadzoru rynku i punkt kontaktowy wobec instytucji unijnych. Według zapowiedzi Ministerstwa Cyfryzacji przewodniczący ma zostać powołany w październiku 2026, a Komisja ma rozpocząć działalność w listopadzie. Obowiązki unijne działają niezależnie od gotowości organizacyjnej organu, więc oczekiwanie na jego uruchomienie nie przesuwa żadnego terminu. #### Co zrobić z dodatkowym czasem Przesunięcie terminów jest dobrą wiadomością dla harmonogramów i ryzykowną dla dyscypliny. Z doświadczenia wdrożeniowego wynika, że projekty odłożone bez wyznaczonego właściciela wracają na stół dopiero na kwartał przed terminem, kiedy przestrzeń na negocjacje z dostawcami już się zamknęła. Praktyczny podział pracy wygląda tak: obowiązki przejrzystości z artykułu 50 zamykamy w tym kwartale, ponieważ już obowiązują i są stosunkowo tanie do wdrożenia. Inwentaryzację i klasyfikację systemów pod kątem załącznika III prowadzimy do końca 2026 roku, kiedy decyzje są jeszcze odwracalne. Zapisy umowne z dostawcami renegocjujemy przy najbliższym odnowieniu, a nie w 2027 roku pod presją terminu. Taka kolejność kosztuje niewiele, a usuwa większość ryzyka, które zwykle ujawnia się w ostatnim momencie. [^art99]: Rozporządzenie (UE) 2024/1689, artykuł 99, tekst w Dzienniku Urzędowym: . --- ### Tokeny i okno kontekstu https://rsmanagement.ai/blog/optymalizacja-tokenow-i-kontekstu/ Opublikowano: 2026-07-21 | zaktualizowano: 2026-09-02 Techniki obniżania kosztu rozwiązań AI: pamięć podręczna promptów, streszczanie historii, RAG, routing i limity długości odpowiedzi. Rachunek za AI rzadko rośnie dlatego, że zespół nagle zaczął zadawać więcej pytań. Częściej rośnie dlatego, że każde pytanie z osobna stało się droższe. Modele rozliczają się z tokenów, czyli kawałków tekstu wchodzących do modelu i z niego wychodzących, a większość organizacji nie wie, ile tokenów faktycznie wysyła przy jednym zapytaniu. Bez tej wiedzy optymalizacja sprowadza się do zgadywania. Narzędzie do policzenia tego stoi po stronie dostawcy: Anthropic udostępnia osobną funkcję zliczającą tokeny jeszcze przed wysłaniem zapytania. #### Dlaczego kontekst puchnie sam z siebie Za większość wzrostu odpowiadają trzy mechanizmy. - Rozmowa z modelem jest bezstanowa. Model nie pamięta poprzedniej tury, więc aplikacja przy każdym kolejnym pytaniu wysyła całą dotychczasową historię od nowa. Dziesiąta wiadomość kosztuje wielokrotnie więcej niż pierwsza, choć użytkownik napisał dokładnie tyle samo. - Instrukcje powtarzają się w każdym wywołaniu. Polecenie systemowe z opisem roli, zasadami, przykładami i definicjami narzędzi potrafi mieć kilka tysięcy tokenów i jedzie z każdym zapytaniem, także z tym, które dałoby się obsłużyć jednym zdaniem. - Dokumenty wklejane w całości. Ktoś wrzuca 80-stronicowy regulamin, żeby zapytać o jeden paragraf. Płacimy za 80 stron, i to przy każdym kolejnym pytaniu o ten sam dokument. Okna kontekstu sięgają dziś 1 mln tokenów[^okno], ale za duże okno też trzeba zapłacić. Płaci się za to, co się w nim faktycznie umieści. Te trzy mechanizmy nakładają się na siebie i to jest sedno problemu. Historia rośnie z każdą turą, instrukcja systemowa jedzie przy każdej z nich, a wklejony dokument powiela się razem z historią. Rachunek rośnie więc nie liniowo, tylko szybciej, mimo że zespół zadaje dokładnie tyle samo pytań co miesiąc temu. #### Pamięć podręczna promptu Jeśli duża część promptu jest za każdym razem identyczna, dostawcy pozwalają zapamiętać ją po swojej stronie. W API (interfejs programistyczny) Anthropic odczyt z pamięci podręcznej kosztuje 10% ceny zwykłego wejścia[^cache], a utworzenie wpisu 1,25 raza tej ceny przy pięciominutowym czasie życia albo dwa razy przy godzinnym (stan na sierpień 2026). Przy krótszym wariancie mechanizm wychodzi na zero już przy drugim wywołaniu tego samego prefiksu, przy godzinnym potrzebne są co najmniej trzy. U innych dużych dostawców logika jest zbliżona, choć czas życia wpisu i dopłata za zapis różnią się między platformami, więc każdy cennik trzeba sprawdzić osobno. | Technika | Nakład wdrożenia | Kiedy się zwraca | |---|---|---| | Pamięć podręczna promptu | Godziny | Od drugiego wywołania tego samego prefiksu | | Skrócenie instrukcji systemowej | Godziny | Natychmiast, przy każdym zapytaniu | | Routing zadań do tańszych modeli | Dni | Przy stałym wolumenie rutynowych zadań | | Przetwarzanie wsadowe | Dni | Gdy odpowiedź nie musi być natychmiastowa | | Streszczanie historii rozmowy | Tygodnie | Przy długich sesjach z powracającym kontekstem | Jest przy tym haczyk, który w praktyce psuje więcej wdrożeń niż wszystko inne razem. Dopasowanie działa na prefiksie, znak po znaku. Wystarczy, że na początku promptu systemowego znajdzie się aktualna data, identyfikator sesji albo imię użytkownika, i cała reszta przestaje się zapisywać. Jedna zmiana unieważnia wszystko, co jest za nią. Stąd prosta zasada projektowa: treść stała idzie na początek, treść zmienna na koniec. Dwa ograniczenia warto znać zawczasu. Bardzo krótkie prompty w ogóle nie trafiają do pamięci podręcznej, a próg zależy od modelu i mieści się mniej więcej między 512 a 4096 tokenami. Druga rzecz jest najczęściej mylona: rabat obejmuje wyłącznie wejście. Tokeny wygenerowane przez model kosztują tyle samo co zwykle, więc każda kalkulacja oszczędności rozciągnięta na wyjście jest zawyżona. #### Streszczanie zamiast przewijania historii W dłuższych rozmowach i w agentach, które wykonują po kilkadziesiąt kroków, historia rośnie szybciej niż wartość, jaką niesie. Sensowny wzorzec wygląda tak: kilka ostatnich tur zostaje w oryginale, wcześniejsze zamieniamy na zwięzłe streszczenie, a surowe wyniki wywołań narzędzi usuwamy, gdy przestają być potrzebne. Część dostawców, w tym Anthropic, udostępnia to jako gotową funkcję po swojej stronie, część zespołów pisze własną logikę. Efekt jest ten sam: koszt tury przestaje rosnąć liniowo wraz z długością rozmowy. Kompromis jest jawny. Streszczenie gubi szczegóły, więc trzeba zdecydować, co jest w danym procesie nieutracalne, np. ustalenia z klientem albo numery spraw, i wyłączyć to spod skracania. #### Pobieranie zamiast wklejania Kiedy pytania dotyczą stałego zasobu wiedzy, wklejanie całości przestaje być opłacalne bardzo szybko. Alternatywą jest wyszukiwanie fragmentów i podawanie modelowi tylko tego, co dotyczy pytania. Zwykle nazywa się to RAG, czyli generowanie wspomagane wyszukiwaniem. Przy kilku dokumentach nie ma o czym mówić, po prostu wklejamy. Przy kilkuset dokumentach i regularnym ruchu różnica robi się rzędu wielkości. Warto policzyć próg dla własnego przypadku, zamiast przyjmować cudzy. Zysk nie jest wyłącznie kosztowy: krótszy, trafniejszy kontekst poprawia też jakość odpowiedzi, bo model nie musi szukać igły w stogu siana. #### Routing i sufit na długość odpowiedzi Tokeny wyjściowe są zwykle kilkukrotnie droższe od wejściowych, a modele mają wyraźną skłonność do rozwlekłości, jeśli nikt nie powie im inaczej. Dwa proste ograniczenia działają natychmiast: twardy limit długości odpowiedzi ustawiony w wywołaniu oraz instrukcja opisująca oczekiwaną formę wyniku. Klasyfikacja nie potrzebuje akapitu uzasadnienia, wystarczy etykieta. Do tego dochodzi dobór modelu. Zadania rutynowe, czyli formatowanie, klasyfikacja, krótkie ekstrakcje, nie wymagają modelu flagowego. Jeśli wynik nie jest potrzebny natychmiast, warto sprawdzić kolejkę wsadową: w API Anthropic przetwarzanie asynchroniczne kosztuje połowę ceny standardowej, a większość zleceń kończy się w ciągu godziny. Dla nocnych przeliczeń czy masowego przetwarzania dokumentów to najprostsza oszczędność, jaka istnieje. #### Najpierw pomiar Wszystkie te techniki mają wspólny warunek wstępny. Bez rozbicia kosztu na poszczególne procesy i prompty widać wyłącznie jedną liczbę na fakturze, a ona nie mówi, gdzie szukać. Minimalny zestaw wskaźników to liczba tokenów wejściowych i wyjściowych na wywołanie, udział odczytów z pamięci podręcznej, raportowany w API Anthropic osobnym polem odpowiedzi, oraz koszt w rozbiciu na przypadki użycia. Jeśli udział odczytów z pamięci podręcznej uparcie wynosi 0% mimo poprawnej konfiguracji, prawie zawsze oznacza to, że coś zmiennego wkradło się na początek promptu. #### Gdzie kończy się optymalizacja Dwie granice warto postawić świadomie. Pierwsza jest jakościowa: agresywne skracanie kontekstu obniża trafność odpowiedzi, więc każdą zmianę trzeba weryfikować na zestawie testowym, a nie na wrażeniu. Druga dotyczy danych. Treść trafiająca do pamięci podręcznej jest przechowywana po stronie dostawcy przez czas życia wpisu, co w organizacjach z sektorów regulowanych wymaga uzgodnienia z klasyfikacją informacji i z polityką retencji wynikającą z RODO. Kolejność wdrożenia w większości przypadków wygląda tak samo: najpierw pomiar, potem pamięć podręczna, potem limity długości wyjścia i routing, na końcu przebudowa sposobu podawania wiedzy. Pierwsze dwa kroki bywają najtańsze i najczęściej dają największą część efektu. [^okno]: Anthropic, zestawienie modeli wraz z rozmiarem okna kontekstu: . [^cache]: Anthropic, cennik pamięci podręcznej promptu: odczyt 0,1x, zapis 1,25x przy buforze pięciominutowym i 2x przy godzinnym: . --- ### MCP czy CLI https://rsmanagement.ai/blog/mcp-vs-cli-integracje-agentow/ Opublikowano: 2026-07-07 | zaktualizowano: 2026-09-02 Porównanie protokołu MCP i integracji przez CLI: kiedy standaryzacja się zwraca, kiedy wystarczy skrypt, jak wygląda audyt wywołań i bezpieczeństwo. Kiedy agent AI ma zrobić w firmie coś użytecznego, prędzej czy później musi sięgnąć do systemu, w którym leżą dane: Jiry, SharePointa, hurtowni, systemu ERP (planowanie zasobów przedsiębiorstwa) albo wewnętrznego API (interfejs programistyczny). Sposób tego połączenia bywa traktowany jako szczegół techniczny do rozstrzygnięcia przez zespół. W praktyce decyduje o tym, ile kosztuje utrzymanie integracji, kto może ją wywołać i czy po incydencie da się odtworzyć, co dokładnie agent zrobił. #### Dwa sposoby podłączenia narzędzia Pierwszy to MCP (Model Context Protocol), otwarty protokół opisujący, jak agent odkrywa narzędzia i zasoby udostępnione przez serwer oraz jak je wywołuje. Serwer MCP stoi przed systemem docelowym i mówi wspólnym językiem, a klient, czyli asystent w IDE (edytor kodu), aplikacja czatowa albo własny agent, nie musi uczyć się tego języka od nowa dla każdego systemu. Drugi to wywołanie przez CLI (command line interface), czyli linię poleceń. Agent dostaje prawo uruchomienia konkretnego polecenia lub skryptu, a kontraktem są argumenty, kod wyjścia i format danych wypisany na standardowe wyjście. Cała logika autoryzacji, walidacji i logowania siedzi w kodzie, który zespół napisał sam. Różnica dotyczy poziomu abstrakcji. MCP standaryzuje opis możliwości, negocjację uprawnień i sposób przekazywania wyników. Skrypt zostawia te decyzje konwencji zespołu, co bywa zaletą przy jednej integracji i problemem przy dziesięciu. #### Stan protokołu we wrześniu 2026 9 grudnia 2025 MCP trafił do Agentic AI Foundation, funduszu prowadzonego pod Linux Foundation, współzałożonego przez Anthropic, Block i OpenAI, przy wsparciu Google, Microsoftu, AWS, Cloudflare i Bloomberga. W ogłoszeniu podano ponad 10 tysięcy aktywnych publicznych serwerów MCP[^mcpaaif] i ponad 97 milionów miesięcznych pobrań bibliotek dla Pythona i TypeScriptu. Publiczny rejestr serwerów działa od września 2025. Obowiązująca wersja specyfikacji nosi datę 2026-07-28 i przynosi największą zmianę od startu protokołu: bezstanowy rdzeń bez uzgadniania sesji, negocjację możliwości osobno dla każdego żądania, zaostrzone reguły autoryzacji oraz ramy rozszerzeń. Zmiany łamią zgodność wstecz, a poprzednia wersja nosiła datę 2025-11-25, więc integracja pisana pod starszą specyfikację wymaga przeglądu przed kolejną aktualizacją bibliotek. Dla planowania oznacza to jedno: standard ma dziś twarde poparcie największych dostawców, a jednocześnie porusza się szybko. Integracja pisana pod MCP potrzebuje budżetu nie tylko na pierwsze uruchomienie, ale też na regularne aktualizacje bibliotek i testy zgodności. #### Kiedy MCP się zwraca Standaryzacja opłaca się wtedy, gdy to samo narzędzie ma być wywoływane z kilku miejsc. Jeden serwer obsłuży asystenta w IDE, aplikację czatową i własnego agenta, zamiast trzech osobnych klejów utrzymywanych przez trzy osoby. Drugi mocny przypadek pojawia się, gdy serwer utrzymuje dostawca systemu. Wtedy zgodność z kolejnymi wersjami API przestaje być kosztem zespołu i staje się elementem produktu, za który ktoś inny odpowiada. Trzeci to uwierzytelnianie po stronie serwera. Jeżeli dostęp ma być przyznawany per użytkownik, z odświeżaniem tokenów i wycofywaniem uprawnień, warstwa autoryzacyjna protokołu wykona pracę, którą inaczej trzeba napisać ręcznie i utrzymywać. Czwarty dotyczy zmiennego zestawu narzędzi. Kiedy katalog funkcji rośnie i zmienia się co kilka tygodni, odkrywanie narzędzi w czasie działania jest wygodniejsze niż aktualizowanie promptów przy każdej zmianie. #### Kiedy prostszy skrypt wystarcza Przy jednej integracji obsługiwanej przez jednego klienta serwer MCP dokłada warstwę, która nic nie zwraca. Jeżeli w repozytorium leży już przetestowany skrypt do wystawiania faktur albo aktualizowania zgłoszeń, tańszym rozwiązaniem jest dopuszczenie agenta do jego wywołania niż przepisywanie go na protokół. Skrypt wygrywa też przy operacjach o wysokiej stawce, gdzie chodzi o wąską i sztywną powierzchnię działania. Pięć jawnie zdefiniowanych poleceń bez dynamicznego odkrywania łatwiej przejrzeć na przeglądzie kodu niż serwer wystawiający czterdzieści narzędzi, z których agent wybierze sam. W jednym z wdrożeń przyjęliśmy podział na odczyt i zapis. Odczyt danych idzie przez gotowy serwer MCP dostawcy, bo jest wygodny i nieszkodliwy. Każdy zapis przechodzi przez własny skrypt, z poświadczeniem trzymanym w zmiennych środowiskowych i logiem każdego wywołania. Kompromis polega na utrzymywaniu dwóch mechanizmów zamiast jednego. W zamian operacja zmieniająca stan wymaga jawnej ścieżki i zostawia ślad. #### Koszt kontekstu, o którym rzadko się mówi Definicje narzędzi zajmują miejsce w kontekście modelu. Przy kilkunastu podłączonych serwerach sam katalog potrafi pochłonąć kilkadziesiąt tysięcy tokenów, zanim agent wykona pierwszą użyteczną czynność. W listopadzie 2025 Anthropic opisał wzorzec wywoływania narzędzi MCP z poziomu kodu uruchamianego w odizolowanym środowisku: definicje ładowane na żądanie, dane pośrednie przetwarzane w kodzie, a do modelu trafia gotowy wynik. W opisanym przykładzie zadanie zeszło z ok. 150 tysięcy do ok. 2 tysięcy tokenów.[^mcpkod] To jeden udokumentowany przypadek, więc liczby nie warto przenosić wprost na własne środowisko, ale kierunek jest wymowny. Granica między obydwoma podejściami zaciera się, bo MCP dostarcza opis narzędzi, a wykonanie i tak schodzi do kodu. | Wymiar | MCP | CLI i skrypty | |---|---|---| | Koszt wejścia | Wyższy: serwer, uprawnienia, utrzymanie | Niski: to, co zespół już ma | | Zużycie kontekstu | Katalog narzędzi zajmuje miejsce w prompcie | Zerowe do czasu wywołania | | Odporność na zmiany API | Opis narzędzia w jednym miejscu | Każdy skrypt osobno | | Kto odpowiada za kod | Serwer bywa cudzy | Kod jest nasz i audytowalny | | Kiedy wygrywa | Wiele systemów, częste zmiany | Kilka systemów, stabilne interfejsy | #### Bezpieczeństwo i ślad audytowy 15 kwietnia 2026 badacze opisali klasę ataków nazwaną „Comment and Control”.[^cc] Treść wstrzyknięta w tytuł pull requesta albo w komentarz zgłoszenia przejmowała agentów uruchamianych automatycznie w GitHub Actions, w tym Claude Code Security Review, Gemini CLI Action i GitHub Copilot Agent, i skłaniała je do wyprowadzenia sekretów ze środowiska uruchomieniowego. Producenci wypłacili nagrody za zgłoszenia, bez publicznych identyfikatorów CVE (katalog powszechnie znanych podatności). Wniosek jest niezależny od sposobu połączenia. Agent traktuje wczytaną treść jak zaufany kontekst, a jego uprawnienia stają się uprawnieniami atakującego. Zasięg szkody ograniczają cztery kontrole stosowane razem: lista dozwolonych narzędzi, tożsamość przypisana do każdego wywołania, log zawierający argumenty i wynik oraz akceptacja człowieka przy operacjach nieodwracalnych. Tutaj skrypt ma przewagę, która liczy się w rozmowie z audytem. Log wywołań powstaje sam z siebie, a granica uprawnień jest widoczna wprost w kodzie. Przy MCP audyt trzeba zaprojektować świadomie, bo wywołanie przechodzi przez warstwę, której zespół nie pisał, a serwer bywa cudzy. Rozszerzenia opisane osobno od rdzenia protokołu adresują ten obszar, a to, które z nich obsługuje konkretny klient, sprawdza się przy uzgadnianiu połączenia, nie przy wyborze narzędzia. #### Jak rozstrzygnąć konkretny przypadek Wystarczą cztery pytania. Ilu różnych klientów będzie wywoływać to narzędzie w ciągu najbliższego roku? Czy dostawca systemu utrzymuje serwer MCP, czy trzeba go napisać i utrzymywać samodzielnie? Czy operacja jest odwracalna, a jeśli nie, gdzie stoi punkt akceptacji człowieka? Czy w repozytorium jest już skrypt, który robi to samo i przeszedł przegląd kodu? Najczęstszy błąd polega na traktowaniu tego wyboru jako jednorazowej decyzji dla całej organizacji. Rozsądniej rozstrzygać go osobno dla każdej integracji i zapisywać krótkie uzasadnienie, bo w perspektywie kilku miesięcy zmienią się zarówno wersje protokołu, jak i lista gotowych serwerów, które ktoś utrzymuje za nas. [^mcpaaif]: Model Context Protocol, ogłoszenie o przejściu pod Agentic AI Foundation z 9 grudnia 2025, wraz z podanymi liczbami serwerów i pobrań SDK: . [^mcpkod]: Anthropic, wzorzec wywoływania narzędzi MCP z poziomu kodu: . [^cc]: Cloud Security Alliance, nota badawcza o wykradaniu sekretów przez agentów AI w GitHub Actions: . --- ### Jak poprawić promptowanie https://rsmanagement.ai/blog/jak-poprawic-promptowanie/ Opublikowano: 2026-06-23 Pięć elementów dobrego polecenia dla modelu AI, pary przed i po z zadań biurowych oraz sposób na iterację, gdy pierwsza odpowiedź rozmija się z potrzebą. W zespołach, z którymi pracujemy, różnica między osobą wyciągającą z modelu użyteczne wyniki a osobą sfrustrowaną po trzech próbach rzadko wynika ze znajomości specjalnych sformułowań. Wynika z tego, ile informacji trafia do polecenia i jak są one uporządkowane. Krążące po sieci listy magicznych zwrotów w rodzaju „działaj jak ekspert światowej klasy” zwykle nie zmieniają wyniku, ponieważ nie dodają modelowi żadnej wiedzy o zadaniu. Ma to potwierdzenie w badaniach: na 2 410 pytaniach faktograficznych i 162 rolach wpisanych do polecenia dopisanie samej roli nie poprawiło trafności odpowiedzi wobec wersji bez roli.[^persona] Poniżej praktyka, którą stosujemy w RS Management na co dzień przy dokumentach, analizach i korespondencji. Nie ma w niej trików, są za to konkretne pary przed i po. #### Pięć części dobrego polecenia - **Rola**: kim ma być model i dla kogo pisze. Sformułowanie „analityk finansowy przygotowujący materiał dla zarządu” zawęża słownictwo i poziom szczegółu skuteczniej niż jakikolwiek przymiotnik w rodzaju „profesjonalnie”. - **Kontekst**: to, co model musi wiedzieć, żeby nie zgadywać. Branża, etap projektu, historia relacji, ograniczenia, wcześniejsze ustalenia. Warto trzymać się informacji faktycznie potrzebnych, bo nadmiar materiału potrafi zaszkodzić: praca badawcza z 2023 roku pokazała, że modele dają się rozpraszać nieistotnymi fragmentami kontekstu i częściej mylą się w zadaniach z dodatkowymi, zbędnymi danymi (Shi i in., „Large Language Models Can Be Easily Distracted by Irrelevant Context”, ICML 2023). - **Zadanie**: jedna konkretna czynność wyrażona czasownikiem. „Wypisz ryzyka” oraz „oceń, które ryzyko jest największe” to dwa różne zadania i wychodzą lepiej rozdzielone na dwa kroki. - **Format wyjścia**: długość, struktura, ton, język, układ tabeli. Bez tego model wybiera format samodzielnie i zwykle trafia obok potrzeby. - **Przykład**: jeden albo dwa wzorce tego, jak wygląda dobra odpowiedź. Kolejność tych części ma mniejsze znaczenie niż ich kompletność. Kiedy odpowiedź rozczarowuje, zwykle brakuje jednej z nich, najczęściej formatu wyjścia albo kontekstu. #### Trzy pary z codziennej pracy ##### Notatka po spotkaniu Przed: > Podsumuj te notatki ze spotkania. Po: > Jesteś asystentem kierownika projektu. Poniżej surowe notatki z 90-minutowego statusu z klientem i dwoma dostawcami. Przygotuj podsumowanie dla dyrektora, który nie był na spotkaniu i ma dwie minuty na lekturę. Format: trzy zdania sedna, następnie lista podjętych decyzji, następnie tabela zadań w układzie zadanie / właściciel / termin. Jeśli właściciel albo termin nie padł wprost, wpisz „nieustalone” zamiast uzupełniać własnym domysłem. Ostatnie zdanie usuwa najczęstszy defekt takich podsumowań: uprzejme dopisywanie terminów, których nikt nie ustalił. ##### Odpowiedź na zapowiedź podwyżki Przed: > Napisz maila do dostawcy, że nie zgadzamy się na podwyżkę. Po: > Kontekst: trzy lata współpracy z dostawcą usług serwisowych, umowa ramowa z aneksem rocznym, dostawca zapowiedział podwyżkę stawek o 12% od stycznia i uzasadnia ją kosztami pracy. Zależy nam na utrzymaniu współpracy oraz na rozłożeniu podwyżki na dwa etapy. Napisz odpowiedź do 150 słów, ton rzeczowy i spokojny, bez wykrzykników, zakończoną jednym pytaniem o gotowość do rozmowy o harmonogramie. Poniżej dwa nasze wcześniejsze maile do tego dostawcy, trzymaj się tego tonu. Dwa wklejone maile działają tu mocniej niż jakikolwiek opis stylu. Model dobrze kopiuje wzorzec, słabo odgaduje intencję. ##### Analiza arkusza sprzedaży Przed: > Przeanalizuj te dane sprzedażowe. Po: > Poniżej sprzedaż miesięczna 14 kategorii produktowych za ostatnie 18 miesięcy. Zadanie: wskaż kategorie, w których dynamika rok do roku zmieniła kierunek w ostatnim kwartale. Dla każdej podaj wartość zmiany i miesiąc odwrócenia trendu. Format: tabela z kolumnami kategoria / zmiana rok do roku / miesiąc odwrócenia / krótki komentarz. Nie interpretuj przyczyn. Jeśli dane dla kategorii są niekompletne, wypisz ją osobno pod tabelą. Zdanie „nie interpretuj przyczyn” ma tu znaczenie praktyczne. Model poproszony o analizę bez granic chętnie dopisze wyjaśnienia, których nie da się wyprowadzić z podanych liczb. #### Plan przed wykonaniem Przy zadaniach dłuższych niż jedna strona warto najpierw poprosić o plan: 5 do 7 punktów mówiących, co znajdzie się w kolejnych sekcjach i skąd wezmą się dane. Poprawienie planu zajmuje 2 minuty, poprawienie gotowego ośmiostronicowego dokumentu zajmuje 30 minut. Plan ujawnia też nieporozumienie na starcie, gdy model zrozumiał zadanie inaczej, niż zostało pomyślane. Ten jeden nawyk zmienia więcej niż wszystkie pozostałe punkty tej listy razem wzięte, zwłaszcza przy dokumentach wymagań, ofertach i analizach. #### Iteracja na własnych błędach Typowy odruch po słabej odpowiedzi to poprawienie jej ręcznie. Bardziej opłaca się potraktować każdy defekt jako brakującą instrukcję i dopisać ją do polecenia. Model wypisał ogólniki zamiast liczb, więc do polecenia trafia zdanie o obowiązkowym podaniu wartości liczbowych. Model napisał trzy strony zamiast jednej, więc pojawia się twardy limit słów. Po kilku rundach powstaje polecenie, które daje przewidywalny wynik za pierwszym razem. Te sprawdzone bloki warto zapisywać. U nas leżą w jednym pliku tekstowym, podzielone na kategorie: podsumowania, korespondencja, analiza danych, przegląd dokumentów. Kopiowanie gotowego bloku i podmiana kontekstu zajmują mniej niż 1 minutę, a jakość jest powtarzalna niezależnie od dnia i nastroju. #### Weryfikacja przed wysyłką Wynik pracy modelu wymaga sprawdzenia, zanim trafi dalej. Minimalna lista kontrolna obejmuje liczby, daty, nazwiska i cytaty z dokumentów źródłowych. Pomaga poproszenie modelu o wskazanie, z którego fragmentu źródła pochodzi każde twierdzenie, a następnie sprawdzenie dwóch albo trzech losowych pozycji. Jeśli te wyrywkowe kontrole wypadają dobrze przez 4 tygodnie, można je rozrzedzić. Jeśli wypadają źle, problem zwykle leży w poleceniu, które pozwoliło modelowi wykroczyć poza materiał. Osobna kwestia dotyczy tego, co w ogóle trafia do okna czatu. Dane osobowe w rozumieniu RODO, warunki handlowe i materiały objęte poufnością wymagają narzędzia zaakceptowanego przez organizację oraz świadomości, gdzie te dane są przetwarzane i jak długo przechowywane. Przy danych wrażliwych decyzję warto potwierdzić z osobami odpowiedzialnymi za bezpieczeństwo i zgodność. #### Czego lepszy prompt nie naprawi Struktura polecenia pomaga tylko wtedy, gdy zadanie da się w ogóle wykonać na dostarczonym materiale. Model nie wymyśli danych, których nie dostał. Nie odpowie sensownie na pytanie źle postawione, np. takie, na które sam autor nie umie odpowiedzieć. Nie zastąpi też dostępu do systemów: kiedy potrzebne informacje siedzą w bazie, w systemie kadrowym albo w repozytorium dokumentów, rozwiązaniem staje się integracja z tymi systemami, na przykład przez MCP (Model Context Protocol), standard podłączania modeli do firmowych źródeł danych. Wydłużanie polecenia niczego tu nie zmieni. Praktyczny punkt startowy jest prosty. Wystarczy wybrać trzy zadania powtarzane co tydzień, spisać dla każdego polecenie z pięcioma częściami, przetestować je przez kilka dni i poprawiać po każdym nieudanym wyniku. Po miesiącu takiej pracy różnica w czasie i w jakości jest widoczna bez żadnych pomiarów. [^persona]: Zheng i in., pomiar wpływu roli wpisanej do polecenia na trafność odpowiedzi: . --- ### Modele lokalnie https://rsmanagement.ai/blog/modele-lokalnie-na-czym-uruchamiac/ Opublikowano: 2026-06-09 | zaktualizowano: 2026-09-02 Przegląd progów sprzętowych do uruchamiania modeli AI lokalnie: od laptopa, przez stację z GPU, po pamięć zunifikowaną, wraz z rachunkiem kosztów. Pytanie o lokalne uruchamianie modeli wraca w niemal każdej rozmowie o wdrożeniu AI, zwykle w formie „czy da się to trzymać u nas”. Da się, i to prościej niż jeszcze dwa lata temu. Warto natomiast wiedzieć, na jakim progu sprzętowym kończą się rzeczy proste, a zaczynają kosztowne. #### Cztery progi sprzętowe | Próg | Pamięć | Co się mieści | Do czego wystarcza | |---|---|---|---| | Laptop lub komputer bez karty | 16-32 GB pamięci | modele skwantyzowane 4-14 mld parametrów | klasyfikacja, przepisywanie tekstu, prosta ekstrakcja | | Komputer z kartą graficzną | 24-32 GB pamięci karty | modele 30B lekko skompresowane, 70B mocno | asystent kodu, streszczanie, wyszukiwanie po bazie wiedzy | | Stacja z kartą profesjonalną | 96 GB z korekcją błędów | te same modele, ale w pracy ciągłej | praca całodobowa bez szukania przyczyny rozjeżdżających się wyników | | Pamięć wspólna procesora i karty | 128-512 GB | modele wymagające kilku kart naraz | eksperymenty z największymi modelami otwartymi | **Zwykły laptop albo komputer, 16 do 32 GB pamięci.** Bez dedykowanej karty graficznej mieszczą się tu modele skwantyzowane z pierwszego wiersza tabeli. Działają, generują kilka do kilkunastu tokenów na sekundę na procesorze i nadają się do klasyfikacji, przepisywania tekstu, prostej ekstrakcji danych z dokumentów. OpenAI podaje, że gpt-oss-20b uruchamia się w 16 GB pamięci, co dobrze wyznacza górną granicę tego progu. Do rozmowy z człowiekiem w czasie rzeczywistym takie tempo bywa za wolne, do przetwarzania wsadowego w nocy wystarcza w zupełności. **Komputer z kartą graficzną 24 do 32 GB.** Mocna karta konsumencka daje 32 GB własnej pamięci i jest to pierwszy próg, na którym modele klasy 30B mieszczą się przy lekkiej kompresji, a modele 70B przy mocnej. Tu zaczyna się użyteczna praca: asystent kodu, streszczanie długich dokumentów, obsługa wyszukiwania po firmowej bazie wiedzy. **Stacja robocza z kartą profesjonalną.** Karta profesjonalna daje trzykrotnie więcej pamięci od konsumenckiej i dokłada mechanizm, który sam wykrywa i poprawia przekłamania w pamięci. Różnica nie sprowadza się do samej pojemności: ta korekcja i wsparcie producenta zaczynają mieć znaczenie, gdy maszyna ma pracować całą dobę i nikt nie planuje szukać przyczyny wyników, które raz na jakiś czas wychodzą inaczej. **Maszyny z dużą pamięcią zunifikowaną.** Mac Studio z układem M3 Ultra, wprowadzony w marcu 2025, oferował do 512 GB pamięci współdzielonej przez procesor i układ graficzny, więc mieścił modele wymagające na kartach graficznych kilku sztuk sprzętu. NVIDIA DGX Spark realizuje ten sam pomysł na sprzęcie NVIDII, ze 128 GB pamięci koherentnej w obudowie wielkości książki. #### Czym to uruchamiać Warstwa oprogramowania jest dziś prostsza od sprzętu. Większość ekosystemu wyrosła na llama.cpp i bibliotece ggml, z formatem plików GGUF, w którym publikuje się skompresowane modele. Ollama sprowadza uruchomienie modelu do jednej komendy i wystawia API (interfejs programistyczny) zgodne z OpenAI, dzięki czemu podmiana dostawcy w istniejącej aplikacji ogranicza się do zmiany adresu. LM Studio daje podobne możliwości w interfejsie graficznym, z wbudowaną przeglądarką modeli, i sprawdza się u osób, które nie pracują w terminalu. Do obsługi wielu użytkowników naraz właściwym narzędziem jest vLLM, znacznie lepiej wykorzystujący kartę przy równoległych zapytaniach. Drobna uwaga licencyjna, która bywa istotna w korporacji: llama.cpp, Ollama i vLLM są otwarte, LM Studio pozostaje oprogramowaniem zamkniętym. #### Ile pamięci zajmie model Reguła kciuka wystarczająca do planowania opiera się na jednym przeliczeniu: model w pełnej dokładności zajmuje około dwóch bajtów na parametr, a kompresja dzieli tę wartość, kosztem niewielkiego spadku jakości. | Wariant | Bajty na parametr | Model 30 mld parametrów | |---|---|---| | pełna dokładność | ok. 2 | ok. 60 GB | | ośmiobitowy | ok. 1 | ok. 30 GB | | czterobitowy | ok. 0,5 | ok. 15 GB | Do wyniku z tabeli dochodzi jeszcze pamięć podręczna kontekstu, która rośnie razem z długością promptu. Stąd bierze się typowa pomyłka w planowaniu: model mieści się w karcie na papierze, a przestaje się mieścić po wczytaniu kilkudziesięciu tysięcy tokenów kontekstu. Drugie zaskoczenie dotyczy maszyn z pamięcią zunifikowaną. Pamięci mają dużo, ale przetworzenie długiego promptu przed pierwszym tokenem odpowiedzi trwa na nich zauważalnie dłużej niż na dedykowanej karcie. Przy krótkich zapytaniach różnicy nie widać, przy analizie stustronicowej umowy widać ją aż nadto. #### Prąd, ciepło i serwis Mocna karta graficzna pobiera pod pełnym obciążeniem ok. 575 W, wersja profesjonalna 600 W, a cały komputer potrzebuje zasilacza rzędu 1000 W, czyli mniej więcej tyle co czajnik elektryczny. Maszyna pracująca osiem godzin dziennie przez dwadzieścia dni w miesiącu zużyje ok. 110 kWh. Przy unijnej średniej dla firm, 18,37 euro za 100 kWh, daje to jakieś 20 euro miesięcznie.[^prad] Prąd rzadko rozstrzyga o wyniku rachunku. Większy ciężar mają pozostałe konsekwencje. Sześćset watów oddane do niewielkiego pokoju działa jak grzejnik, który latem podnosi temperaturę o kilka stopni i wymusza chłodzenie. Wentylatory pod obciążeniem są słyszalne przez cały dzień. Ktoś musi aktualizować sterowniki, pilnować wersji modeli i reagować, gdy usługa przestaje odpowiadać w piątek po południu. W mniejszej firmie tym kimś zwykle zostaje osoba mająca już komplet innych obowiązków, i to jest koszt, którego nie widać w cenniku sprzętu. #### Gdzie leży granica wobec API Trzy sytuacje, w których lokalne uruchomienie broni się bez naciągania argumentów: - Dane, które z powodów umownych lub regulacyjnych nie mogą opuścić własnej infrastruktury, przy czym deklaracja dostawcy o regionie przetwarzania i braku retencji często wystarcza i warto to sprawdzić przed zakupem sprzętu. - Wysoki i stały wolumen zadań prostych: klasyfikacja, ekstrakcja pól z dokumentów, generowanie osadzeń. Koszt jednostkowy przy stałym obciążeniu wychodzi lokalnie wyraźnie niżej. - Praca bez łącza albo w sieci odciętej od internetu. W pozostałych przypadkach rachunek zwykle wypada na korzyść API. Przyjmijmy stację roboczą za 25 000 do 40 000 zł amortyzowaną przez trzy lata: wychodzi od 700 do 1 100 zł miesięcznie, zanim ktokolwiek jej użyje, plus prąd, plus czas administracyjny. Jeżeli zespół wydaje dziś na API mniej niż około tysiąca złotych miesięcznie, zakup sprzętu nie zwróci się na samym koszcie, a dodatkowo trzeba pogodzić się z różnicą w jakości. Najlepsze modele o otwartych wagach są dobre, natomiast w zadaniach wymagających długiego wnioskowania wciąż ustępują czołowym modelom dostępnym przez API. #### Rok 2026 przesunął ten rachunek Kalkulację warto zrobić na cenach aktualnych, bo mocno się przesunęły. Ceny pamięci DRAM (pamięć operacyjna) wzrosły w pierwszym kwartale 2026 roku o ok. 90% wobec końca 2025[^dram], ponieważ producenci przekierowali produkcję do centrów danych obsługujących AI. Skutki widać dokładnie w konfiguracjach opisanych powyżej. Skutki widać w cennikach maszyn z dużą pamięcią zunifikowaną: warianty o największej pojemności drożeją albo znikają z oferty, a konfiguracja wyceniona rok temu dziś kosztuje inaczej. Przed decyzją zakupową trzeba sprawdzić aktualny cennik producenta, nie notatkę z poprzedniego kwartału. Rachunek, który w 2025 roku wychodził na korzyść własnego sprzętu, w 2026 często wygląda odwrotnie, więc opieranie się na zapamiętanych cenach prowadzi do złych decyzji. #### Praktyczne podejście Zaczynamy zawsze od najtańszego progu. Ollama albo LM Studio na sprzęcie, który firma już posiada, jeden konkretny proces, dwa tygodnie pomiarów jakości i czasu odpowiedzi. Taki eksperyment kosztuje kilka godzin pracy i rozstrzyga więcej niż tygodnie dyskusji o specyfikacji. Dopiero gdy wiadomo, że model danej klasy faktycznie wykonuje zadanie i że wolumen uzasadnia dedykowaną maszynę, sensowna staje się rozmowa o karcie za kilkanaście tysięcy złotych. Powyższy materiał opisuje praktyczne rozeznanie w kwestiach sprzętowych i kosztowych. [^dram]: Counterpoint Research, wzrost cen pamięci do 90% wobec czwartego kwartału 2025: . [^prad]: Eurostat, ceny energii elektrycznej dla odbiorców innych niż gospodarstwa domowe, druga połowa 2025: . --- ### Jak czytać benchmarki modeli AI bez kupowania marketingu https://rsmanagement.ai/blog/jak-czytac-benchmarki-modeli/ Opublikowano: 2026-05-26 Kontaminacja danych, błędy w zestawach i wariancja między wersjami sprawiają, że rankingi modeli mylą. Praktyczny sposób na własny zestaw testowy. Do rozmów o wyborze modelu AI coraz częściej wchodzi się z wydrukiem rankingu. Ktoś pokazuje tabelę, w której nowy model wyprzedza obecny o kilka p.p., i pyta, czy to wystarczający powód do migracji. Uczciwa odpowiedź wymaga cofnięcia się o krok i sprawdzenia, skąd te p.p. w ogóle pochodzą. Benchmarki mają sens jako narzędzie badawcze. Kłopot zaczyna się wtedy, gdy wynik z laboratorium trafia na slajd sprzedażowy i zaczyna udawać prognozę tego, jak model poradzi sobie z fakturami, umowami albo zgłoszeniami serwisowymi konkretnej firmy. Za większość rozjazdu między jednym a drugim odpowiadają trzy mechanizmy. #### Kontaminacja: model zna klucz Benchmarki publikuje się w internecie. Dane treningowe zbiera się z internetu. Dalszy ciąg tej historii jest przewidywalny: im dłużej zestaw testowy krąży publicznie, tym większa szansa, że model widział już zadania albo ich rozwiązania podczas treningu. Skalę zjawiska dobrze pokazało badanie Scale AI z maja 2024. Zespół przygotował GSM1k, 1205 nowych zadań z matematyki szkolnej[^gsm1k], dopasowanych do popularnego zestawu GSM8K pod względem trudności, liczby kroków i długości treści. Najbardziej przeuczone rodziny modeli traciły na świeżych zadaniach do kilkunastu p.p., modele czołowe znacznie mniej. Wniosek jest umiarkowany: przeuczony model nadal potrafi rozwiązywać nowe zadania, po prostu słabiej, niż obiecywał wynik z publicznego zestawu. Podobna historia rozegrała się na SWE-bench Verified (software engineering benchmark), zestawie 500 zgłoszeń wziętych żywcem z repozytoriów open source, który przez dwa lata pełnił funkcję nieoficjalnej tablicy wyników dla programowania. W lutym 2026 OpenAI opublikowało wyjaśnienie, dlaczego przestaje raportować wyniki na tym zestawie: narastająca kontaminacja oraz wady samych testów sprawiły, że różnice na górze tabeli przestały nieść informację. Jako sensowniejszą alternatywę wskazano SWE-bench Pro, wydany przez Scale AI we wrześniu 2025, gdzie część zadań trzymana jest w puli zamkniętej właśnie po to, żeby dało się wykryć przeuczenie. Przy premierze najlepsze modele schodziły tam poniżej 25% skuteczności.[^swebenchpro] Praktyczny wniosek dla kupującego: data powstania zestawu testowego jest równie ważna, jak wynik. Zestaw z 2021 roku, na którym czołowe modele od dawna ocierają się o sufit skali, mierzy głównie to, jak dobrze materiał został zapamiętany. #### Benchmark mierzy inną umiejętność MMLU (Massive Multitask Language Understanding), przez lata najczęściej cytowany zestaw ogólnej wiedzy, to kilkanaście tysięcy pytań wielokrotnego wyboru z 57 dziedzin. W 2024 roku zespół badawczy przejrzał ręcznie próbkę 5700 pytań i opublikował poprawioną wersję pod nazwą MMLU-Redux.[^mmluredux] Oszacowanie: ok. 6,5% pozycji zawiera błędy, od złego klucza odpowiedzi po pytania niejednoznaczne lub mające kilka poprawnych wariantów. W niektórych działach było dużo gorzej, w wirusologii wadliwa okazała się ponad połowa przejrzanych pozycji. Po odfiltrowaniu błędnych pytań kolejność modeli w rankingu potrafiła się zmienić. Nawet przy idealnym kluczu odpowiedzi zostaje różnica cięższego kalibru. Firmowe zadanie rzadko ma cztery warianty do wyboru. Zwykle wygląda tak: dwadzieścia stron skanu w jakości z 2013 roku, żargon branżowy, wewnętrzne skróty, wymóg wskazania źródła każdej liczby i konsekwencja wyniku widoczna dopiero w księgach. Zdolność wybrania właściwej odpowiedzi z listy koreluje z taką pracą tylko częściowo. | Pułapka | Jak wygląda | Co zrobić przed zakupem | |---|---|---| | Kontaminacja zestawu | Wynik rośnie, a praca nie | Sprawdzić datę powstania zestawu | | Błędy w kluczu odpowiedzi | Ranking zmienia się po korekcie | Zapytać, na której wersji zestawu liczono | | Inna umiejętność niż firmowa | Pytania wielokrotnego wyboru wobec skanu na 20 stron | Zbudować własny zestaw z dokumentów firmy | | Zamknięta pula zadań | Brak możliwości wykrycia przeuczenia | Preferować zestawy z częścią niepubliczną | #### Wariancja: ten sam model, różne wyniki Trzeci mechanizm bywa najbardziej niedoceniany. Wynik benchmarku opisuje nie tylko model, ale całą obudowę wokół niego: prompt systemowy, dostępne narzędzia, liczbę prób, sposób weryfikacji odpowiedzi, limit tokenów. W zadaniach agentowych ta warstwa odpowiada za bardzo dużą część różnicy między publikowanymi wynikami, a bywa opisana jednym zdaniem w przypisie. Do tego dochodzi pytanie, kto wynik zgłosił. Większość pozycji na publicznych tablicach pochodzi od samych dostawców i nigdy nie została niezależnie powtórzona. W kwietniu 2025 badacze z Cohere Labs, AI2 oraz kilku uczelni opublikowali analizę „The Leaderboard Illusion”, w której opisali m.in. praktykę testowania wielu prywatnych wariantów modelu przed publikacją i pokazywania tylko najlepszego z nich. Przed premierą Llamy 4 miało to być 27 wariantów. Organizatorzy areny część zarzutów przyjęli, część zakwestionowali, ale sam mechanizm selekcji wyników pozostaje kłopotem, z którym czytelnik rankingu zostaje sam. Wreszcie modele zmieniają się pod stałą nazwą. Aktualizacja wersji albo zmiana domyślnych parametrów potrafi przesunąć zachowanie na zadaniach brzegowych, a tabela sprzed kwartału opisuje już trochę inny obiekt. #### Własny zestaw testowy bije rankingi Alternatywa jest mniej efektowna i znacznie skuteczniejsza. Budujemy ją tak: - **Skąd przypadki**: trzydzieści do sześćdziesięciu z własnej produkcji, w tym te trudne i brzegowe, na których praca zwykle się zacina. Przypadki idealne mierzą przede wszystkim optymizm autora zestawu. - **Kto definiuje wynik**: osoba, która tę pracę wykonuje na co dzień, a nie zespół techniczny. Bez tego ocena zamienia się w dyskusję o gustach. - **Kiedy spisujemy kryteria**: zanim zobaczymy jakiekolwiek wyniki. Kolejność jest tu kluczowa, bo kryteria dopisywane po fakcie zawsze potwierdzają wybraną wcześniej tezę. - **Ta sama obudowa**: identyczny prompt, te same narzędzia, ta sama liczba prób dla każdego kandydata. Inaczej porównujemy konfiguracje, a nie modele. - **Co mierzymy obok jakości**: koszt i czas odpowiedzi. Model o dwa punkty lepszy i cztery razy droższy rzadko wygrywa w rachunku rocznym. - **Gdzie żyje zestaw**: wyłącznie u nas. Opublikowanie go w repozytorium publicznym rozpoczyna dokładnie ten sam cykl kontaminacji, który psuje benchmarki branżowe. Przygotowanie takiego zestawu zajmuje zwykle od jednego do trzech dni pracy osoby znającej dziedzinę. Kompromis jest oczywisty: pięćdziesiąt przypadków to mała próba, więc różnice rzędu kilku p.p. na niej również nic nie znaczą. Zestaw pewnie odróżnia natomiast sytuację, w której model radzi sobie z naszymi dokumentami, od tej, w której sobie nie radzi. Dokładnie tej informacji publiczny ranking nie dostarczy. #### Cztery pytania przed cytatem Kiedy tabela i tak trafia na spotkanie, warto przepuścić ją przez krótki filtr. Kto zgłosił wynik i czy powtórzył go ktoś niezależny. Kiedy powstał zestaw zadań i czy mógł już trafić do danych treningowych. Czy istnieje pula zamknięta, pozwalająca wykryć przeuczenie. Jak opisana jest obudowa: prompt, narzędzia, liczba prób. Ranking wystarczy, żeby zawęzić listę kandydatów z dwudziestu do trzech. Decyzję o tym, który z tej trójki pójdzie na produkcję, opieramy na własnych danych. [^gsm1k]: Scale AI, „A Careful Examination of Large Language Model Performance on Grade School Arithmetic”, maj 2024: . [^swebenchpro]: Scale AI, SWE-Bench Pro, wrzesień 2025: . [^mmluredux]: Gema i in., „Are We Done with MMLU?”, próbka 5700 pytań, szacowany udział błędów 6,49%: . --- ### Modele komercyjne czy open-source https://rsmanagement.ai/blog/modele-prywatne-vs-open-source/ Opublikowano: 2026-05-12 | zaktualizowano: 2026-09-02 Kiedy wygrywa model komercyjny z API, a kiedy open-source uruchomiony u siebie: poufność danych, koszty przy skali, jakość po polsku i kontrola wersji. Pytanie o modele komercyjne kontra otwarte pojawia się niemal w każdym projekcie wdrożeniowym, zwykle w połowie warsztatu i zwykle w formie ideologicznej. Odpowiedź rzadko jest ideologiczna. Zależy od tego, jakie zadanie ma wykonać model, ile razy dziennie, na czyich danych i kto poniesie konsekwencje, gdy odpowiedź okaże się błędna. #### Trzy kategorie zamiast dwóch W praktyce spotykamy trzy różne modele operacyjne, choć dyskusja toczy się tak, jakby były dwa. Pierwszy to model komercyjny dostępny wyłącznie przez API dostawcy, czyli rodziny GPT, Claude i Gemini. Drugi to model o otwartych wagach uruchamiany u zewnętrznego dostawcy hostingu: wagi są publiczne, ale infrastruktura nadal nie należy do nas. Trzeci to model o otwartych wagach uruchomiony na własnym sprzęcie albo we własnej chmurze prywatnej. | Wymiar | API komercyjne | Otwarte wagi u dostawcy | Otwarte wagi u siebie | |---|---|---|---| | Poufność danych | Zerowa retencja i region UE w umowie | Infrastruktura nadal cudza | Dane nie opuszczają sieci | | Koszt przy niskim wolumenie | Najniższy: płacimy za zużycie | Średni | Najwyższy: sprzęt stoi bezczynnie | | Koszt przy wysokim i stałym wolumenie | Rośnie liniowo | Zależy od umowy | Najniższy przy pełnym wykorzystaniu | | Kontrola wersji modelu | Dostawca może wycofać wariant | Ograniczona | Pełna | | Nakład zespołu | Bliski zeru | Niewielki | Monitoring, utrzymanie, dyżury | Warto też odróżnić „open source” od „open weights”. Większość popularnych modeli otwartych publikuje wagi i architekturę, natomiast pełny zbiór treningowy i kod treningu pozostają zamknięte. W zastosowaniach biznesowych ta różnica ma znaczenie głównie przy audycie pochodzenia danych. #### Poufność danych To najczęstszy powód, dla którego w ogóle rozmawiamy o modelach otwartych, i zarazem argument stawiany najbardziej nieprecyzyjnie. Dostawcy komercyjni oferują dziś umowy o zerowej retencji, wyłączenie danych klienta z treningu oraz wybór regionu przetwarzania w Unii Europejskiej, także pośrednio przez platformy chmurowe. Dla większości danych firmowych to wystarczający poziom ochrony i zdecydowanie krótsza droga niż budowa własnej infrastruktury. Model uruchomiony lokalnie wygrywa tam, gdzie ograniczenie jest twarde: dane objęte tajemnicą zawodową, dokumentacja medyczna, materiał z postępowań, informacje, których zgodnie z polityką bezpieczeństwa nie wolno wypuścić poza własną sieć nawet do zaufanego procesora. W takim przypadku dyskusja o benchmarkach staje się wtórna, bo zmienną decydującą ustala polityka bezpieczeństwa, zanim ktokolwiek spojrzy na wyniki. #### Koszt przy skali Tutaj najczęściej widzimy błąd w rachunku. Modele otwarte nie mają opłat licencyjnych, za to mają koszt eksploatacji. Wynajem pojedynczej karty obliczeniowej klasy H100 kosztuje w wyspecjalizowanych chmurach GPU (procesory kart graficznych) rzędu dwóch do trzech dolarów za godzinę, u dużych dostawców chmury publicznej wyraźnie więcej. Karta pracująca w trybie ciągłym generuje więc koszt rzędu kilku tysięcy złotych miesięcznie za sam sprzęt, zanim doliczymy pracę zespołu, monitoring i procedury utrzymania. Skala sprzętu bywa przy tym mniejsza, niż podpowiada intuicja. OpenAI podaje, że model gpt-oss-120b mieści się na pojedynczej karcie 80 GB, a gpt-oss-20b w 16 GB pamięci, czyli na dobrze wyposażonej stacji roboczej. Oba są publikowane na licencji Apache 2.0. Konsekwencja jest prosta. Przy niskim i nieregularnym wolumenie API wygrywa niemal zawsze, ponieważ płacimy wyłącznie za zużycie. Punkt przełamania pojawia się przy wysokim i przewidywalnym wolumenie zadań powtarzalnych: klasyfikacji zgłoszeń, ekstrakcji pól z dokumentów, wstępnym streszczaniu. Wtedy własna instancja pracuje blisko pełnego wykorzystania i rachunek zaczyna wyglądać inaczej. Zanim ktokolwiek podpisze plan migracji, warto policzyć zmierzony wolumen zapytań z ostatnich trzech miesięcy zamiast jego wyobrażenia. #### Jakość w języku polskim Przewaga modeli komercyjnych była tu przez lata największa i wciąż pozostaje zauważalna przy zadaniach wymagających swobody stylistycznej: redagowaniu pism, obsłudze niuansów rejestru, pracy na tekście prawnym. Dystans jednak wyraźnie się skrócił. Rodzina Qwen3 jest publikowana na licencji Apache 2.0 i deklaruje wsparcie dla 119 języków i dialektów. Mistral, spółka francuska, udostępnia na Apache 2.0 zarówno model flagowy Mistral Large 3, jak i mniejszą serię Ministral 3 w wariantach 14B, 8B i 3B, co daje europejską alternatywę również po stronie jurysdykcji. Osobno warto znać ekosystem polski. Bielik fundacji SpeakLeash, rozwijany przy wsparciu Cyfronetu AGH i publikowany na Apache 2.0, jest trenowany na polskich danych i inaczej dzieli polski tekst na fragmenty rozliczeniowe, przez co ten sam tekst kosztuje mniej niż u modeli trenowanych głównie po angielsku. Wersja 11B ukazała się na początku 2026 roku. Równolegle działa PLLuM, inicjatywa Ministerstwa Cyfryzacji udostępniona publicznie w 2025 roku. Do porównań służy Open PL LLM Leaderboard prowadzony przez SpeakLeash na Hugging Face, oparty na polskich zadaniach NLP (przetwarzanie języka naturalnego). Ranking mierzy klasyfikację, rozumienie tekstu i pytania zamknięte, więc traktujemy go jako wskazówkę o ograniczonym zasięgu; o jakości redakcyjnej mówi niewiele. Rekomendujemy własny zestaw testowy: od 50 do 100 przypadków wziętych z firmy, ocenianych przez osoby, które tę pracę wykonują na co dzień. #### Kontrola nad wersją i ciągłość Ten wymiar bywa niedoceniany, a potrafi przesądzić o wyborze. Dostawca API może wycofać wersję modelu, zmienić jej zachowanie albo zaostrzyć filtry treści, przez co proces, który przeszedł walidację, zacznie zwracać inne wyniki. Model o otwartych wagach pobrany raz działa tak samo za rok, o ile utrzymujemy środowisko. Dla systemów objętych walidacją, audytem lub dokumentacją zgodności ta powtarzalność jest wartością samą w sobie. #### Licencja i odpowiedzialność Licencję otwartego modelu warto przeczytać, zanim ktoś zbuduje na nim produkt, ponieważ nie wszystkie rodziny są równie otwarte. Licencja Llama 4 zawiera klauzulę: „With respect to any multimodal models included in Llama 4, the rights granted under Section 1(a) of the Llama 4 Community License Agreement are not being granted to you if you are an individual domiciled in, or a company with a principal place of business in, the European Union”. Ponieważ cała rodzina Llama 4 jest natywnie multimodalna, dla firmy z siedzibą w Polsce oznacza to barierę prawną niezależną od jakości modelu. Licencja Apache 2.0, na której publikowane są Qwen3, Mistral Large 3 czy gpt-oss, takiego ograniczenia nie zawiera. Druga strona tego samego wymiaru to odpowiedzialność. Kupując API, kupujemy również umowę, poziom usług, kanał wsparcia i podmiot, który odpowiada za działanie usługi. Uruchamiając model otwarty, przejmujemy tę rolę w całości: dostępność, aktualizacje bezpieczeństwa, jakość odpowiedzi i skutki jej braku. Na koniec kontekst regulacyjny. Unijne rozporządzenie o AI przewiduje dla modeli ogólnego przeznaczenia wydawanych na wolnych i otwartych licencjach ograniczone zwolnienie z części obowiązków dokumentacyjnych, pod warunkiem publicznej dostępności wag i architektury oraz braku monetyzacji. Zwolnienie nie obejmuje modeli o ryzyku systemowym, a obowiązki dotyczące polityki praw autorskich i podsumowania danych treningowych pozostają w mocy. Obowiązki podmiotu stosującego model istnieją niezależnie od tego, czy model jest otwarty. #### Rekomendacja W większości organizacji, z którymi pracujemy, wybór kończy się na architekturze mieszanej. Model komercyjny obsługuje zadania wymagające najwyższej jakości językowej i najszerszego kontekstu. Model otwarty, uruchomiony lokalnie, obsługuje wolumen powtarzalny oraz dane, które nie mogą opuścić sieci. Granicę między jednym a drugim wyznaczamy raz, zapisujemy w polityce i przeglądamy kwartalnie, ponieważ obie strony tego rynku zmieniają się szybciej niż roczny cykl budżetowy. --- ### Od POC do produkcji https://rsmanagement.ai/blog/od-poc-do-produkcji/ Opublikowano: 2026-04-28 | zaktualizowano: 2026-09-02 Większość prototypów AI nie dochodzi do wdrożenia. Pięć różnic, które oddzielają POC kończący się demem od tego, który trafia na produkcję. Prototyp działa. Demonstracja przechodzi bez potknięcia, na sali padają dobre pytania, ktoś rzuca, że to zmieni sposób pracy całego działu. Trzy miesiące później nikt nie pamięta, gdzie był ten link. Scenariusz powtarza się na tyle regularnie, że przestaje być pechem pojedynczego zespołu i staje się właściwością sposobu, w jaki prowadzone są prototypy. #### Skala zjawiska W lipcu 2024 Gartner prognozował, że do końca 2025 co najmniej 30% projektów generatywnej AI zostanie porzuconych po fazie POC (proof of concept), czyli prototypu, który ma wyłącznie pokazać, że pomysł da się zrealizować.[^gartner] Jako przyczyny wskazano słabą jakość danych, niewystarczające mechanizmy kontroli ryzyka, rosnące koszty oraz niejasną wartość biznesową. Prognoza nie dostała publicznego rozliczenia, więc traktujemy ją jako opis mechanizmu, nie jako pomiar rynku. Kierunek zgadza się z tym, co widać w projektach: bariera rzadko stoi po stronie modelu. Stoi w miejscach, które w prototypie świadomie pominięto, żeby było szybciej. #### Definicja sukcesu spisana przed startem Najtańsza rzecz, jaką można zrobić dla losu prototypu, zajmuje pół strony i powstaje przed pierwszą linijką kodu. Jedna metryka, próg liczbowy, sposób pomiaru i nazwisko osoby, która ten wynik akceptuje. Zamiast „sprawdzimy, czy AI poradzi sobie z weryfikacją dokumentów”, zapis brzmi: > Na 100 sprawach wylosowanych z ostatniego kwartału ekstrakcja kluczowych pól ma być poprawna w ponad 90%, a średni czas weryfikacji ma spaść z 14 minut do poniżej 5. Bez tego prototyp kończy się dyskusją, czy wynik jest „wystarczająco dobry”, a takiej dyskusji nie da się wygrać, bo każdy uczestnik ma w głowie inny próg. Kompromis jest realny: na starcie często nie wiadomo, jaki próg jest w ogóle osiągalny. W takiej sytuacji warto wpisać próg wstępny razem z datą jego rewizji. Liczba do poprawienia działa lepiej niż brak liczby. #### Dane produkcyjne, nie testowe Prototypy testuje się zwykle na próbce, którą ktoś wcześniej uporządkował: czyste skany, komplet pól, przypadki typowe. Produkcja wygląda inaczej. Skan obrócony o 90 stopni, dwa dokumenty w jednym PDF, dopisek odręczny na marginesie, plik z 2019 roku w nieaktualnym szablonie, pole wypełnione w sposób, którego nie przewidywał żaden formularz. Praktyczna zasada: próbka losowana z realnego strumienia, z zachowaniem ogona dziwnych przypadków. Zestaw wybrany ręcznie przez osobę, która chce pokazać działający wynik, mówi wyłącznie o tym zestawie. Jeżeli dane nie mogą opuścić organizacji, prototyp powstaje w środowisku organizacji. Anonimizacja i uzgodnienie podstawy przetwarzania zajmują tygodnie, więc ten wątek warto uruchomić w pierwszym tygodniu prac. Bywa, że na starcie dostępne są wyłącznie dane syntetyczne. Wtedy pierwszy wynik traktujemy jako sygnał o wykonalności technicznej, a rozmowę o jakości odkładamy do momentu, w którym pojawi się próbka z produkcji. #### Właściciel biznesowy z własnym interesem Sponsor, który „popiera temat”, nie wystarczy. Potrzebny jest właściciel, czyli osoba, której wskaźniki zmienią się, jeśli rozwiązanie zadziała, która przydzieli czas swoich ludzi na testy akceptacyjne i która ma mandat do zmiany procesu. Test jest prosty: czyje liczby w raporcie kwartalnym będą wyglądać inaczej. Jeśli odpowiedź nie pada w ciągu kilku sekund, prototyp nie ma adresata. Dział IT zbuduje rozwiązanie i utrzyma je, natomiast nie odbierze wyniku biznesowego za kogoś, kto tego wyniku nie potrzebuje. Ten punkt tłumaczy sporą część porzuconych prototypów. Powstały z ciekawości technologicznej, w oderwaniu od konkretnego problemu, który ktoś naprawdę chciał rozwiązać. #### Bezpieczeństwo od pierwszego dnia Trzy pytania warto zadać już na starcie prototypu, zamiast odkładać je do momentu przekazania na produkcję. Gdzie trafiają dane i na jakiej umowie. Kto ma dostęp do logów, promptów i wyników. Kto utrzyma to rozwiązanie za 18 miesięcy i z jakiego budżetu. Trzydziestominutowa rozmowa z bezpieczeństwem i działem prawnym w pierwszym tygodniu kosztuje mniej niż odkrycie w ósmym tygodniu, że wybrany dostawca modelu nie przejdzie oceny ryzyka. W organizacjach objętych regulacjami dochodzi do tego klasyfikacja systemu, ocena skutków dla ochrony danych i dokumentacja, która ma przetrwać audyt. Konkretne obowiązki warto potwierdzić z właściwym doradcą. Utrzymanie bywa pomijane jeszcze częściej niż bezpieczeństwo. Wersje modeli się zmieniają, jakość promptów degraduje się przy zmianie danych wejściowych, integracje się psują. Rozsądnie jest założyć stałą roczną pozycję budżetową na utrzymanie, zamiast traktować wdrożenie jako koszt jednorazowy. #### Data decyzji: skalować czy zamknąć Data decyzji powinna być ustalona razem z zakresem prototypu. W praktyce sprawdza się okno sześciu do ośmiu tygodni i trzy możliwe rozstrzygnięcia: skalujemy, poprawiamy jeden konkretny element i powtarzamy pomiar raz, albo zamykamy. Zamknięcie jest normalnym rozstrzygnięciem i warto raportować je jako wynik pomiaru, bez etykiety porażki zespołu. Najgorszy scenariusz to prototyp, który dryfuje przez pół roku, aż wszyscy przestaną o nim mówić. Nikt wtedy niczego się nie uczy, a organizacja zapamiętuje jedynie, że „AI u nas nie działa”. Przy zamknięciu przydaje się jednostronicowa notatka: co sprawdzano, jaki był wynik wobec progu, co zrobilibyśmy inaczej. Trzy takie notatki po roku są warte więcej niż jeden prototyp, który nigdy nie dostał werdyktu. #### Co z tego wynika Wszystkie pięć punktów kosztuje niewiele: kilka rozmów, jedna strona zapisu, jedna próbka danych i wpisana w kalendarz data decyzji. Pominięcie ich skraca start o tydzień i regularnie odbiera wartość trzem kolejnym miesiącom pracy. Warto też zacząć od problemu, zanim wybierze się narzędzie. Jeżeli sukces prototypu nie zmieni żadnej liczby, na której komuś zależy, wynik techniczny pozostanie ciekawostką. [^gartner]: Gartner, prognoza z 29 lipca 2024 o porzucaniu projektów generatywnej AI po fazie proof of concept: . --- ### Chatboty i voiceboty w dużej organizacji https://rsmanagement.ai/blog/chatboty-voiceboty-w-korporacji/ Opublikowano: 2026-04-14 Co decyduje o powodzeniu chatbota i voicebota w dużej firmie: jakość bazy wiedzy, separacja danych, eskalacja do człowieka i utrzymanie treści. Wdrożenie chatbota albo voicebota w dużej organizacji rzadko rozbija się o wybór modelu językowego. Rozbija się o rzeczy, których nie widać na prezentacji: o stan bazy wiedzy, o to, kto ma prawo zobaczyć jaką odpowiedź, o moment przekazania rozmowy człowiekowi i o to, czy ktokolwiek utrzymuje treści pół roku po starcie. Wynika to z samej konstrukcji takich systemów. Standardem jest dziś RAG (retrieval-augmented generation), układ, w którym bot najpierw wyszukuje fragmenty firmowych dokumentów, a dopiero z nich układa odpowiedź. W tym układzie model jest ostatnim ogniwem. Poniżej praktyczne rozeznanie tych wyzwań z perspektywy wdrożeniowej, razem z korzyściami, które w praktyce udaje się osiągnąć. #### Baza wiedzy decyduje o jakości Bot odpowiada tak dobrze, jak dobra jest treść, do której sięga. Typowy stan wyjściowy w dużej firmie wygląda podobnie w każdej branży: procedura istnieje w trzech wersjach w trzech miejscach, zwykle w SharePoincie, w intranecie i w załączniku do maila, jeden z dokumentów pochodzi z 2019 roku i nie ma daty ważności, a najważniejszy wyjątek został uzgodniony mailowo i nie trafił nigdzie indziej. Model nie rozstrzygnie tej sprzeczności za organizację. Wybierze fragment, który najlepiej pasuje do pytania, i sformułuje go pewnym tonem. Dwa działania dają tu największy zwrot. Pierwsze to inwentaryzacja źródeł i wskazanie jednego dokumentu obowiązującego dla każdego obszaru, jeszcze zanim cokolwiek zostanie zaindeksowane. Drugie to zestaw kontrolny pytań, zwykle od 100 do 200, z odpowiedziami zatwierdzonymi przez merytorycznych właścicieli. Uruchamiamy go jak test regresyjny po każdej zmianie treści, promptu albo modelu. Bez takiego zestawu każda zmiana w systemie jest zakładem, a spadek jakości zauważa dopiero klient. #### Separacja danych i uprawnienia W korporacji to samo pytanie może mieć różne poprawne odpowiedzi w zależności od tego, kto je zadaje. Inny zakres dla pracownika centrali, inny dla franczyzobiorcy, jeszcze inny dla klienta zewnętrznego. Filtr uprawnień musi działać na etapie wyszukiwania dokumentów, zanim cokolwiek trafi do modelu. Instrukcja w prompcie w stylu „nie ujawniaj informacji wewnętrznych” jest sugestią, którą da się obejść zwykłym, uprzejmie zadanym pytaniem. Najlepiej widać to na Microsoft 365 Copilot, który z założenia pokazuje wyłącznie treści, do których pytający i tak ma dostęp.[^copilot] Uprawnień więc nie łamie. Ujawnia za to, jak szerokie one były: katalog, który przez lata leżał udostępniony całej organizacji, staje się wyszukiwalny jednym zdaniem po polsku. Bot bywa pierwszym skutecznym audytem uprawnień, jaki firma przeprowadziła, i dowiaduje się o tym po starcie. Praktyczne minimum: osobne indeksy albo twarde filtry po roli, logowanie nie tylko odpowiedzi, ale też fragmentów, które system pobrał, oraz test penetracyjny na próbach wyciągnięcia treści spoza uprawnień. Ten ostatni warto powtarzać, bo zmienia się zarówno model, jak i zawartość bazy. #### Eskalacja do człowieka Przekazanie rozmowy człowiekowi warto traktować jako pełnoprawną funkcję produktu. Projektujemy ją razem z zespołem obsługi i uruchamiać na kilku wyraźnych sygnałach: niska pewność wyszukiwania, dwie nieudane próby odpowiedzi na to samo pytanie, wprost wyrażona prośba rozmówcy, ton wskazujący na reklamację oraz tematy wyłączone regulaminem, np. rozliczenia finansowe, sprawy kadrowe czy bezpieczeństwo. Dwa szczegóły decydują o odbiorze. Konsultant powinien dostać pełny zapis rozmowy i zebrany kontekst, żeby rozmówca nie opowiadał wszystkiego od nowa. Eskalacja nigdy nie może kończyć się ślepą uliczką: poza godzinami pracy bot zakłada zgłoszenie i podaje konkretny termin kontaktu, na przykład do 24 godzin roboczych. #### Mierzenie skuteczności Sam odsetek rozmów zakończonych bez konsultanta jest metryką mylącą, bo rozmowa zakończona nie oznacza sprawy załatwionej. Sensowny zestaw obejmuje: udział spraw zamkniętych w kanale automatycznym wraz z pisemną definicją, powrót rozmówcy do tego samego tematu w ciągu 7 dni, wskaźnik eskalacji z podziałem na przyczyny, udział odpowiedzi „nie wiem” oraz ręczny przegląd próbki rozmów, np. 50 tygodniowo, robiony przez kogoś z pierwszej linii. | Metryka | Co mierzy | Pułapka | |---|---|---| | Sprawy zamknięte w kanale automatycznym | Skuteczność kanału, o ile ma pisemną definicję | Bez definicji każdy liczy inaczej | | Powrót do tematu w ciągu 7 dni | Czy sprawa naprawdę została załatwiona | Rozmowa zakończona to nie sprawa zamknięta | | Wskaźnik eskalacji z podziałem na przyczyny | Gdzie system się potyka | Sam odsetek bez przyczyn nic nie mówi | | Udział odpowiedzi „nie wiem” | Luki w bazie wiedzy | Spadek bywa skutkiem zgadywania, nie wiedzy | | Ręczny przegląd próbki, ok. 50 rozmów tygodniowo | Jakość, której liczby nie widzą | Wymaga czasu kogoś z pierwszej linii | Benchmarki publikowane przez dostawców platform rozrzucone są bardzo szeroko i rzadko podają definicję liczonego wskaźnika, więc porównywanie się z nimi niewiele daje. Znacznie więcej wart jest własny punkt odniesienia zmierzony na kilka tygodni przed uruchomieniem bota. #### Utrzymanie treści To najmniej efektowna część wdrożenia i jednocześnie ta, która decyduje o drugim roku działania. Każdy obszar wiedzy potrzebuje właściciela z imienia i nazwiska, ustalonego rytmu przeglądu, w praktyce raz na 90 dni, i daty ważności na dokumencie. Pierwsza linia potrzebuje jednego kliknięcia, żeby zgłosić złą odpowiedź. Logi bota, uporządkowane w klastry tematyczne, są przy okazji najlepszą listą treści do poprawienia, jaką organizacja może mieć: pokazują, o co ludzie faktycznie pytają, w ich własnych słowach i w ich własnej kolejności. #### Voicebot dokłada własną warstwę problemów Kanał głosowy dziedziczy wszystkie wyzwania czatu i dorzuca kilka swoich. Silnik ASR (automatic speech recognition), który zamienia mowę na tekst, potyka się dokładnie tam, gdzie boli najbardziej: na nazwiskach, adresach, numerach umów i kodach produktów, a polska odmiana dodatkowo utrudnia dopasowanie. Pomagają trzy rzeczy: potwierdzanie danych krytycznych przez literowanie albo klawiaturę telefonu, słownik nazw własnych i kodów podawany silnikowi rozpoznawania oraz tolerancja na rozpoznanie częściowe zamiast wymuszania powtórzeń. Do tego dochodzi możliwość przerwania bota w połowie zdania oraz hałas tła w sklepie czy magazynie. Osobno stoi budżet opóźnienia i tu warto znać punkt odniesienia. W rozmowie między ludźmi przerwa między wypowiedziami ma medianę 100 ms, a średnie dla dziesięciu zbadanych języków rozkładają się od 7 ms dla japońskiego po 469 ms dla duńskiego.[^tury] Bot odpowiadający po sekundzie wypada poza tę skalę w całości i rozmówca to słyszy, nawet jeśli nie umie tego nazwać. Voicebot warto uruchamiać po czacie, na węższym zakresie spraw, kiedy baza wiedzy jest już sprawdzona w łatwiejszym kanale. #### Korzyść leży w wolumenie Wartość rzadko bierze się ze spraw skomplikowanych. Bierze się z wolumenu spraw prostych, a te w każdej organizacji układają się w zaskakująco krótką listę: status zamówienia, reset dostępu, godziny i terminy, gdzie znaleźć dokument, jak wypełnić formularz. Odciążenie pierwszej linii z tego trzonu zwalnia czas na sprawy, w których rozmowa z człowiekiem naprawdę coś wnosi. Druga korzyść to dostępność wieczorem, w nocy i w weekendy, tam, gdzie obsadzenie zmiany przez 24 godziny na dobę i 7 dni w tygodniu byłoby nieopłacalne. Trzecia to spójność. 40 osób na pierwszej linii odpowiada w 40 wariantach, bot odpowiada identycznie za każdym razem. To działa w obie strony i warto powiedzieć to wprost: błąd w treści również powiela się identycznie, w całej skali kanału. Ta sama właściwość, która daje spójność, sprawia jednak, że poprawka wchodzi natychmiast i wszędzie. #### Trzeba powiedzieć, że to AI Od 2 sierpnia 2026 roku zaczynają obowiązywać wymogi przejrzystości z art. 50 rozporządzenia (UE) 2024/1689, znanego jako Akt o sztucznej inteligencji.[^aiact] Systemy przeznaczone do bezpośredniej interakcji z osobami fizycznymi mają być zaprojektowane tak, żeby rozmówca wiedział, że rozmawia ze sztuczną inteligencją, a informacja ma zostać przekazana w sposób jasny i wyraźny najpóźniej w chwili pierwszej interakcji. W praktyce oznacza to jedno zdanie w powitaniu czatu, jedno w powitaniu voicebota oraz wpis w wewnętrznym inwentarzu systemów AI. Konkretny zakres obowiązków warto potwierdzić z doradcą prawnym. #### Kolejność, która się sprawdza Wybieramy jeden obszar o dużym wolumenie i względnie uporządkowanej treści. Budujemy zestaw kontrolny pytań przed pierwszą linią kodu. Ścieżkę eskalacji projektujemy wspólnie z zespołem obsługi, zanim ruszy pierwszy ruch produkcyjny. Mierzymy stan sprzed wdrożenia przez 2 do 4 tygodni, żeby mieć do czego porównać wynik. Na koniec wskazujemy właściciela treści i rezerwujemy mu czas w kalendarzu, bo utrzymanie bazy wiedzy jest pracą ciągłą. Organizacje, które przechodzą tę kolejność rzetelnie, zwykle wdrażają wolniej i wychodzą z tego z systemem, który po roku wciąż odpowiada poprawnie. [^copilot]: Microsoft Learn, architektura ochrony danych w Microsoft 365 Copilot, o dostępie wyłącznie do treści uprawnionych dla pytającego: . [^tury]: Stivers i in., pomiar przerw między wypowiedziami w dziesięciu językach: . [^aiact]: Rozporządzenie (UE) 2024/1689, art. 50 o obowiązkach przejrzystości: . --- ### Unijne rozporządzenie o AI już obowiązuje https://rsmanagement.ai/blog/ai-act-dla-liderow/ Opublikowano: 2026-03-10 | zaktualizowano: 2026-08-04 Unijne rozporządzenie o AI już obowiązuje. Przewodnik dla liderów branż regulowanych: co się zmieniło, kogo dotyczy odpowiedzialność i od czego zacząć. > **Aktualizacja, sierpień 2026.** Od publikacji tego wpisu stan prawny się zmienił: 2 sierpnia 2026 zaczęły obowiązywać obowiązki przejrzystości z art. 50, a rozporządzenie (UE) 2026/1744 przesunęło terminy dla systemów wysokiego ryzyka na 2 grudnia 2027 (załącznik III) i 2 sierpnia 2028 (załącznik I). Aktualny harmonogram i wnioski opisuje wpis [AI Act po 2 sierpnia 2026](/blog/ai-act-po-2-sierpnia-2026/). Poniższy tekst zachowujemy w wersji zaktualizowanej o nowe daty. Jeszcze do niedawna unijne rozporządzenie o sztucznej inteligencji (AI Act) można było traktować jako temat na przyszłość: akt wciąż negocjowany, dopracowywany, „nadchodzący”. Ten etap się skończył. Rozporządzenie (UE) 2024/1689 obowiązuje od sierpnia 2024 roku. Jego wymogi wchodzą w życie etapami, nie jednorazowo. Kilka etapów już minęło. Dla kadry zarządzającej w bankowości, farmacji, energetyce i innych branżach regulowanych pytanie nie brzmi już, czy rozporządzenie ich dotyczy. Brzmi ono: na ile organizacja jest gotowa na obowiązki, które już obowiązują, oraz te, których terminy dopiero nadejdą. W kwestii konkretnych obowiązków warto skonsultować się z doradcą prawnym. #### Co się zmieniło AI Act nie wchodzi w życie jednym ruchem. Obowiązki uruchamiają się etapami, a kalendarz wygląda dziś tak: 1 sierpnia 2024 rozporządzenie weszło w życie; od 2 lutego 2025 obowiązują zakazane praktyki oraz bazowy obowiązek zapewnienia pracownikom odpowiedniej wiedzy o AI (tzw. AI literacy, art. 4); od 2 sierpnia 2025 obowiązki dla modeli AI ogólnego przeznaczenia, przepisy o organach nadzoru i karach; od 2 sierpnia 2026 obowiązki przejrzystości z art. 50, w tym informowanie o interakcji z systemem AI. Terminy dla systemów wysokiego ryzyka rozporządzenie (UE) 2026/1744 przesunęło na 2 grudnia 2027 (zastosowania z załącznika III) oraz 2 sierpnia 2028 (systemy wbudowane w produkty regulowane z załącznika I). Regulatorzy publikują już wytyczne wdrożeniowe, w tym doprecyzowania sposobu klasyfikacji systemu jako wysokiego ryzyka: infrastruktura egzekwowania powstaje już teraz, a przesunięcie terminów jej nie zatrzymało. Sam mechanizm egzekwowania opiera się na strukturze znanej wielu organizacjom z RODO: kary o charakterze warstwowym, liczone jako kwota stała lub procent globalnego rocznego obrotu, w zależności od tego, która wartość jest wyższa, przy czym poważniejsze naruszenia plasują się na surowszym końcu tej skali. Dla małych i średnich przedsiębiorstw oraz startupów pułapem jest wartość niższa z tych dwóch (art. 99 ust. 6). Praktyczny wniosek: część obowiązków nie czeka na przyszły termin. Już obowiązuje. #### Kogo to dotyczy Najczęstsze błędne założenie, z jakim się spotykamy, to przekonanie, że regulacja AI to problem dostawcy technologii. To nieprawda, a przynajmniej nie tylko. AI Act rozróżnia dostawców (podmioty budujące systemy AI) od podmiotów stosujących, czyli organizacji, które używają tych systemów w pracy zawodowej. Obowiązki podmiotu stosującego istnieją niezależnie od obowiązków dostawcy. Nie da się ich przenieść umową na kogoś innego. W praktyce oznacza to, że bank korzystający z modelu firmy trzeciej do oceny zdolności kredytowej, firma farmaceutyczna wykorzystująca AI w procesach jakościowych lub klinicznych oraz firma energetyczna stosująca AI do zarządzania siecią lub majątkiem, każda z nich jest podmiotem stosującym we własnym zakresie. Zakup zgodnego z przepisami narzędzia od renomowanego dostawcy nie zwalnia automatycznie organizacji wdrażającej z własnych obowiązków w zakresie nadzoru, monitorowania, zgłaszania incydentów i zarządzania ryzykiem. Odpowiedzialność spoczywa na tym, kto faktycznie wykorzystuje system, nie tylko na tym, kto go zbudował. #### Co oznacza wysokie ryzyko Rozporządzenie porządkuje systemy AI według kategorii ryzyka, zamiast traktować każdą AI tak samo. W dużym uproszczeniu: część praktyk jest całkowicie zakazana, określony zbiór zastosowań traktowany jest jako wysokiego ryzyka i podlega najbardziej rygorystycznym obowiązkom, kolejny zbiór wiąże się z lżejszymi obowiązkami przejrzystości, a wszystko poza tym mieści się w kategorii minimalnego ryzyka z niewielką liczbą wiążących wymogów. | Kategoria | Czego dotyczy | Ciężar obowiązków | |---|---|---| | Zakazane praktyki | Zastosowania wyłączone z obrotu | Zakaz bezwzględny | | Wysokie ryzyko | Zatrudnienie, zdolność kredytowa, infrastruktura krytyczna | Najcięższy: nadzór, dokumentacja, rejestry | | Obowiązki przejrzystości | Chatboty, treści syntetyczne, deepfake | Poinformowanie i oznaczenie | | Ryzyko minimalne | Wszystko pozostałe | Niewiele wiążących wymogów | To kategoria wysokiego ryzyka ma największe znaczenie dla branż regulowanych, ponieważ zwykle obejmuje systemy wykorzystywane w decyzjach zatrudnieniowych, ocenie zdolności kredytowej, obsłudze infrastruktury krytycznej oraz innych kontekstach, w których działanie systemu AI istotnie wpływa na prawa jednostki lub na obowiązki firmy w zakresie bezpieczeństwa. To, które konkretnie systemy w danej organizacji kwalifikują się jako wysokiego ryzyka i kiedy dokładnie zaczynają ich dotyczyć poszczególne obowiązki, zależy od konkretnego systemu i sposobu jego wykorzystania. Ta klasyfikacja nie jest czynnością opcjonalną. Nie warto przeprowadzać jej nieformalnie. Warto potraktować ją jako formalne, udokumentowane ćwiczenie, najlepiej z udziałem osób technicznych i prawnych. #### Obowiązek, o którym najczęściej się zapomina Artykuł 4 rozporządzenia wprowadza wymóg, który dostaje znacznie mniej uwagi niż kategorie ryzyka: kompetencje w zakresie AI (AI literacy). Organizacje mają obowiązek podjąć działania zapewniające, że pracownicy oraz inne osoby obsługujące systemy AI w ich imieniu mają wystarczający poziom zrozumienia tych systemów, aby korzystać z nich w sposób odpowiedzialny. Ten obowiązek już obowiązuje. Nie ogranicza się wyłącznie do systemów wysokiego ryzyka. To wymóg bazowy, dotyczący całej organizacji. Dla większości firm oznacza to, że kompetencje w zakresie AI nie mogą pozostać nieformalną umiejętnością zdobywaną przy okazji. Powinny stać się udokumentowanym obowiązkiem szkoleniowym, dopasowanym do roli i konkretnego systemu. #### Co robić teraz Nic z powyższego nie wymaga gotowego programu zgodności w przyszłym kwartale. Wymaga punktu wyjścia. Organizacje, które są dziś najdalej w przygotowaniach, to te, które potraktowały ten temat jako pracę operacyjną, nie jako formalność prawną. Rozsądna kolejność działań na start: - Zbudowanie inwentarza wszystkich systemów AI wykorzystywanych w organizacji, łącznie z narzędziami wdrożonymi nieformalnie przez pojedyncze zespoły. - Klasyfikacja każdego systemu według kategorii ryzyka z rozporządzenia, z jasno przypisaną osobą odpowiedzialną za tę decyzję. - Przegląd dokumentacji przejrzystości udostępnianej przez dostawców modeli AI ogólnego przeznaczenia wykorzystywanych produkcyjnie. - Wprowadzenie nawyku dokumentowania decyzji wspieranych przez AI oraz prowadzenia śladów audytowych, zwłaszcza tam, gdzie wynik działania systemu dotyka ludzi, pieniędzy lub bezpieczeństwa. - Uruchomienie programu podnoszącego kompetencje AI dla pracowników mających kontakt z tymi systemami, dopasowanego do ich roli. Żaden z tych kroków nie wymaga czekania na ostateczną opinię prawną. Wymaga własności tematu, działającego inwentarza i gotowości, by traktować zarządzanie AI jako stałą funkcję organizacyjną, nie jednorazowy projekt. #### Co dalej Organizacje, które dobrze poradzą sobie z tym tematem, to nie te, które zaczną działać w pośpiechu, gdy egzekwowanie dotrze do ich branży. To te, które wykorzystały dostępny czas, żeby uporządkować własny stan: przejrzysty inwentarz, obronną klasyfikację i dokumentację, która wytrzyma weryfikację. Aktualny stan prawny po 2 sierpnia 2026, wraz z nowym kalendarzem i wnioskami dla działów HR, opisuje wpis [AI Act po 2 sierpnia 2026](/blog/ai-act-po-2-sierpnia-2026/). RS Management doradza kadrze zarządzającej w bankowości, farmacji, energetyce i innych branżach regulowanych w zakresie ładu AI i gotowości do zgodności z przepisami. Jeśli warto sprawdzić, jak bardzo obecne wykorzystanie AI w organizacji jest narażone na te wymogi, [zapraszamy do rozmowy](/#contact). --- ### Kiedy jeden agent AI przestaje wystarczać https://rsmanagement.ai/blog/roj-agentow-ai/ Opublikowano: 2026-02-26 Dlaczego pojedynczy uniwersalny agent AI traci jakość wraz ze wzrostem zakresu i jak skoordynowany rój wyspecjalizowanych agentów przywraca jakość, kontrolę i rozliczalność. Większość organizacji zaczyna wdrażanie agentów AI od jednego agenta, od którego oczekuje się planowania, tworzenia, weryfikacji, zabezpieczania i dokumentowania, ponieważ takie rozwiązanie jest prostsze do uruchomienia i łatwiejsze do wytłumaczenia zarządowi. Przy niewielkiej skali to działa. Problem pojawia się, gdy zakres rośnie: więcej systemów, więcej plików, więcej decyzji przechodzących przez to samo, wąskie okno kontekstu. To nie jest problem promptów. To problem architektury, a ten ma sprawdzone rozwiązanie: zamiast oczekiwać, że jeden agent zrobi wszystko, buduje się mały zespół wyspecjalizowanych agentów koordynowanych przez orkiestrator. Wzorzec nie jest niszowy. Tak zbudowany jest system badawczy Anthropic, w którym agent prowadzący rozdziela pracę między podagentów.[^anthropic] #### Granice pojedynczego agenta uniwersalnego Agent uniwersalny, który utrzymuje pełny kontekst złożonego środowiska, musi przy każdym zadaniu dzielić uwagę pomiędzy wszystkie jego elementy. Im większy zakres, tym większy kontekst do utrzymania, a jakość zwykle spada w przewidywalny sposób. Nie ratuje tego samo powiększanie okna kontekstu: modele sięgają po informację z początku i z końca podanego tekstu pewniej niż po tę ze środka, a różnica rośnie wraz z długością.[^kontekst] Zadania trwają dłużej. Wyniki stają się niespójne między podobnymi żądaniami. Kontrole, które mają największe znaczenie, takie jak bezpieczeństwo, zgodność z RODO i dokumentacja, są wykonywane tylko wtedy, gdy ktoś o nich pamięta, a nie według stałego harmonogramu. Nie oznacza to, że sam model jest słaby. Oznacza to, że wadliwy jest model operacyjny wokół niego. Ta sama zależność dotyczy zespołów ludzkich: jeden generalista nie zweryfikuje kodu, nie przeprowadzi audytu bezpieczeństwa, nie poprowadzi projektu i nie utrzyma dokumentacji na takim poziomie, jak czworo ludzi zajmujących się tym na pełen etat. #### Podział pracy na wyspecjalizowane role Rozwiązaniem jest podział pracy. Zamiast jednego agenta odpowiedzialnego za wszystko, praca zostaje podzielona na niewielką liczbę ról o ściśle określonym zakresie, każda z jasnym mandatem, zdefiniowanym wejściem i wyjściem oraz własnym standardem jakości. We własnych pracach wdrożeniowych i badawczych stosujemy ten wzorzec w pięciu rolach. Żądanie trafia najpierw do Planisty, który dzieli je na zadania. Dalej pracuje Recenzent, sprawdzający wyłącznie defekty i naruszenia standardów. Audytor bezpieczeństwa i ryzyka ocenia poziom ekspozycji. Rola porządkowa usuwa martwy kod i pilnuje higieny. Rola dokumentacyjna dba, by materiały pisane odpowiadały temu, co faktycznie zostało zbudowane.
Orkiestrator dzieli zadanie na pięć wyspecjalizowanych ról, a ich wyniki schodzą do jednego punktu akceptacji człowieka Orkiestrator Planista dzieli na zadania Recenzent szuka defektów Audytor ocenia ryzyko Porządki usuwa martwy kod Dokumentacja pilnuje opisu Punkt akceptacji człowieka przed decyzją, której nie da się cofnąć
Pięć ról z naszych prac wdrożeniowych i badawczych. Każda ma własne wejście, wyjście i standard jakości, a o kolejności decyduje orkiestrator.
##### Gdzie wzorzec ma zastosowanie poza inżynierią Ta sama logika wykracza daleko poza zespoły inżynierskie. Proces przetwarzania dokumentów można podzielić na ekstrakcję, weryfikację względem reguł i obsługę wyjątków. Asystenta obsługującego klientów można podzielić na rozpoznawanie intencji, eskalację i przegląd treści wrażliwych pod względem zgodności, zanim trafią do klienta. Proces finansowy lub zakupowy można podzielić na przygotowanie, sprawdzenie zgodności z polityką i logowanie na potrzeby audytu. W każdym przypadku zasada jest ta sama: zawężać zakres każdej roli, dopóki jej wynik nie stanie się łatwy do sprawdzenia. #### Orkiestracja, nie autonomia Częstym błędnym odczytaniem tego wzorca jest przekonanie, że oznacza on uruchomienie kilku autonomicznych botów działających niezależnie od siebie. Tak nie jest. Każdy specjalista to zawężony zestaw instrukcji, tryb działania z własnymi ograniczeniami i formatem wyniku, w który przełącza się centralny orkiestrator, zależnie od zadania. To orkiestrator decyduje, co dzieje się dalej i który specjalista się tym zajmie. Nic nie działa bez nadzoru tylko dlatego, że nosi etykietę roli. To rozróżnienie ma największe znaczenie w środowiskach regulowanych, gdzie Akt o sztucznej inteligencji wymaga nadzoru człowieka nad systemami wysokiego ryzyka i samo słowo „autonomiczny” od razu wzbudza czujność.[^nadzor] Dobrze zaprojektowany rój agentów, po angielsku agent swarm, przypomina ustrukturyzowany proces, w którym AI wykonuje kolejne kroki, a nie zbiór niezależnych decydentów. #### Gdzie umieścić punkty akceptacji człowieka Podział pracy na wyspecjalizowane role niesie ze sobą korzyść dla nadzoru nad procesem, którą łatwo przeoczyć: ułatwia umieszczenie punktów przeglądu przez człowieka. Pojedynczy agent, który planuje, buduje i wdraża w jednym przebiegu, daje recenzentowi jeden duży, mieszany wynik do sprawdzenia. Rój agentów wytwarza na każdym etapie węższy, bardziej czytelny wynik, dzięki czemu punkt akceptacji można umieścić dokładnie tam, gdzie decyzja niesie realne konsekwencje: przed wdrożeniem zmiany istotnej dla bezpieczeństwa, przed wysłaniem wiadomości do klienta, przed ostatecznym zatwierdzeniem klasyfikacji dokumentu. Dla zarządów odpowiadających przed radą nadzorczą, regulatorem lub funkcją audytu to często ważniejszy argument niż sama efektywność. Tym samym językiem mówią normy zarządzania AI, z ISO/IEC 42001 na czele: liczy się udokumentowany nadzór, a nie zapewnienie, że system jest bezpieczny. Pytanie rzadko brzmi, czy AI potrafi wykonać pracę. Brzmi raczej, czy ktoś jest w stanie po fakcie wyjaśnić, co zrobiła i dlaczego pozwolono jej kontynuować. #### Koszt i jakość: co się naprawdę zmienia Podzielenie jednego agenta na kilku specjalistów kosztuje więcej, niż podpowiada intuicja. Anthropic podaje, że system wieloagentowy zużywa ok. 15 razy więcej tokenów niż zwykła rozmowa z modelem, a jednocześnie zmierzył 90,2% przewagi takiego układu nad pojedynczym agentem na własnym teście badawczym.[^anthropic] Rachunek wychodzi więc na plus tam, gdzie wynik jest wart tej różnicy, i na minus przy zadaniach, które jeden agent domknie za pierwszym razem. Reszta kosztu przesuwa się wcześniej: w projektowanie ról, przekazywanie zadań między nimi oraz logikę orkiestracji, która to wszystko spina. Ta wcześniejsza inwestycja daje system łatwiejszy do testowania, łatwiejszy do audytu i łatwiejszy do poprawiania rola po roli, bez konieczności przeuczania czy przeformułowywania promptów całego agenta uniwersalnego za każdym razem, gdy zmienia się fragment procesu. Argument jakościowy działa według tej samej logiki, co w każdym wyspecjalizowanym zespole. Recenzent, którego jedynym zadaniem jest wyłapywanie defektów, wyłapuje ich więcej niż generalista wykonujący pięć zadań naraz, po prostu dlatego, że jego uwaga nie jest podzielona. #### Co kosztuje najwięcej przy pierwszym roju Najdroższe okazuje się ustalenie, co dokładnie jedna rola przekazuje drugiej. Koszt modelu i orkiestratora jest przy tym drugorzędny. Dopóki wyjście planisty jest luźnym opisem, reviewer dostaje coś, czego nie da się sprawdzić mechanicznie, i cała korzyść z podziału znika: znowu ktoś czyta wszystko i ocenia na oko. Dlatego pierwszy rój warto budować od formatu przekazania, nie od liczby ról. Trzy rzeczy wystarczą na start: nazwane pole z zakresem zadania, nazwane pole z kryterium akceptacji i miejsce na wynik weryfikacji. Role można dokładać później, format przekazania zmienia się najtrudniej. Druga pułapka jest organizacyjna. Rój z pięcioma rolami i jednym punktem akceptacji człowieka na końcu daje dokładnie to samo co agent uniwersalny, tylko drożej. Punkt akceptacji ma stać tam, gdzie decyzja jest nieodwracalna, a nie tam, gdzie kończy się przebieg. Dla liderów prowadzących AI poza etapem pojedynczego pilotażu pytaniem wartym zadania nie jest, czy dodać kolejne AI, lecz czy obecna architektura udźwignie to, o co organizacja już ją prosi. RS Management projektuje i buduje systemy wieloagentowe dla klientów oraz stosuje tę samą dyscyplinę we własnych operacjach. Jeśli warto sprawdzić, czy systemy AI w organizacji wymagają takiej restrukturyzacji, zapraszamy do rozmowy. [^anthropic]: Anthropic, opis systemu wieloagentowego wraz z pomiarem przewagi nad pojedynczym agentem i zużycia tokenów: . [^kontekst]: Liu i in., pomiar skuteczności modeli w zależności od położenia informacji w kontekście: . [^nadzor]: Rozporządzenie (UE) 2024/1689, art. 14 o nadzorze ze strony człowieka nad systemami wysokiego ryzyka: . --- ### Dobór modelu AI do zadania https://rsmanagement.ai/blog/dobor-modelu-ai-do-zadania/ Opublikowano: 2026-02-25 Ramy decyzyjne: który model AI powinien obsłużyć które zadanie, na podstawie kosztu, opóźnienia i ryzyka, a nie przyzwyczajenia. Każda praca z AI zawiera decyzję, która rzadko jest podejmowana świadomie: który model powinien obsłużyć dane zadanie. Większość organizacji podejmuje tę decyzję raz z automatu i później się nad nią nie zastanawia. Ten jeden nienazwany nawyk w dużej mierze odpowiada zarówno za przepłacanie za AI, jak i za zbędne opóźnienia. Rzecz nie dotyczy jednego dostawcy: cennik Anthropic i cennik OpenAI zbudowane są tak samo, w poziomy o różnej mocy i różnej stawce za token. #### Czym jest routing modeli Routing modeli to praktyka dopasowywania każdego zadania do modelu, którego możliwości, koszt i szybkość odpowiadają temu zadaniu, zamiast kierowania każdego zapytania do najbardziej zaawansowanego dostępnego modelu. To prosty pomysł o dużych konsekwencjach, gdy organizacja korzysta z AI w realnej skali: dziesiątki lub setki zapytań dziennie, w wielu zespołach, narzędziach i procesach. Najczęstszy nawyk polega na utożsamianiu „najlepszego modelu” z „właściwym modelem”. To rzadko to samo. Proszenie modelu klasy Opus o streszczenie statusu projektu albo przeformatowanie tabeli przypomina angażowanie starszego architekta do odpisywania na rutynowe maile: kompetentnie, ale to złe wykorzystanie osądu, czasu i budżetu. #### Gdzie zawodzi „zawsze najlepszy model” Trzy czynniki sprawiają, że domyślne sięganie po model premium jest w praktyce kosztowne. ##### Koszt Warto zobaczyć te stawki obok siebie, bo różnica jest mniejsza, niż sugeruje intuicja, i większa, niż widać na pojedynczym rachunku. Między warstwą najtańszą a flagową jest dokładnie 5 razy.[^cennik] | Klasa modelu | Wejście za 1 mln tokenów | Wyjście za 1 mln tokenów | |---|---:|---:| | Szybka (Claude Haiku 4.5) | 1 USD | 5 USD | | Średnia (Claude Sonnet 5) | 2 USD | 10 USD | | Flagowa (Claude Opus 5) | 5 USD | 25 USD | W skali pojedynczego użytkownika ta różnica jest niezauważalna. W skali zespołu obsługującego tysiące zapytań miesięcznie urasta do pozycji, którą widać w budżecie, w dużej mierze możliwą do uniknięcia przy zadaniach rutynowych. ##### Opóźnienie Większe modele co do zasady odpowiadają wolniej. Tę różnicę łatwo zignorować w pojedynczym oknie czatu, a trudno pominąć w agencie, który wywołuje model dziesiątki razy, aby wykonać jedno zadanie, albo w produkcie skierowanym do klienta, gdzie każda dodatkowa sekunda opóźnienia mierzalnie wpływa na współczynnik dokończenia procesu. ##### Jakość, która nie ma się gdzie ujawnić Przy dobrze zdefiniowanych, jednoznacznych zadaniach dodatkowa moc wnioskowania modelu flagowego nie przekłada się na lepszy wynik. Zadanie jej po prostu nie wymaga, więc dodatkowa inteligencja pozostaje niewykorzystana: opłacona, ale niedostarczona. Brak polityki routingu nie jest wyborem neutralnym. To także polityka, tyle że domyślna i zwykle kosztowna. #### Trzy poziomy zadań Zamiast decydować za każdym razem od nowa, warto kierować się kształtem zadania: - **Zadania rutynowe**: wyszukiwanie informacji, edycje pojedynczego pliku, formatowanie, krótkie statusy, generowanie pierwszej wersji z szablonu. Duży wolumen, niska stawka pojedynczego zadania, łatwa weryfikacja. Miejsce dla modeli klasy Haiku, w tym darmowych warstw tam, gdzie są dostępne. - **Zadania robocze**: wdrożenia obejmujące wiele plików, ustrukturyzowana analiza, redagowanie istotnych fragmentów dokumentu, wnioskowanie rozłożone na kilka kroków. Tu mieści się większość codziennej pracy i tu solidny model średniego poziomu ogólnego przeznaczenia zarabia na swój koszt. - **Zadania strategiczne**: projektowanie systemów, decyzje architektoniczne i nieodwracalne, synteza długiego lub niejednoznacznego kontekstu, wszystko, co niesie ryzyko finansowe, prawne lub wizerunkowe. To niewielki odsetek całego wolumenu i jedyne miejsce, w którym płacenie za wnioskowanie modelu flagowego rzeczywiście się opłaca. Pytanie, które warto zadać przed każdym zadaniem, brzmi nie „który model wydaje się najbezpieczniejszym wyborem”, tylko „ile kosztuje pomyłka w tym konkretnym przypadku” i czy zadanie wymaga głębokiego wnioskowania, czy tylko kompetentnego wykonania. ##### Kiedy routing się nie opłaca Routing ma własny koszt: ktoś musi utrzymywać reguły, obserwować, czy nadal odpowiadają rzeczywistości, i reagować, gdy dostawca wycofa wariant modelu. Ten koszt zwraca się dopiero wtedy, gdy zadania rutynowe stanowią wyraźną większość wolumenu i powtarzają się w rozpoznawalnych kształtach. Przy kilkudziesięciu zapytaniach dziennie, rozrzuconych po różnych zadaniach, oszczędność na modelu jest mniejsza niż czas poświęcony na utrzymanie reguł. W takiej sytuacji uczciwszą decyzją jest jeden model średniego poziomu jako domyślny i świadome sięganie po flagowy tam, gdzie stawka jest wysoka. Próg do sprawdzenia przed wdrożeniem routingu jest prosty: ile zapytań z ostatnich trzech miesięcy da się przypisać do powtarzalnych kształtów zadań. Jeśli odpowiedź brzmi „mniej niż połowa”, routing będzie kosztować więcej, niż przyniesie. | Klasa zadania | Przykłady | Klasa modelu | Koszt pomyłki | |---|---|---|---| | Rutynowe | Formatowanie, krótkie statusy, pierwsza wersja z szablonu | Szybki i tani, także warstwy darmowe | Niski, weryfikacja natychmiastowa | | Robocze | Analiza ustrukturyzowana, redakcja istotnych fragmentów, kilka kroków wnioskowania | Solidny model średniego poziomu | Średni, wychodzi przy przeglądzie | | Strategiczne | Decyzje architektoniczne i nieodwracalne, synteza niejednoznacznego kontekstu | Model flagowy | Wysoki: finansowy, prawny, wizerunkowy | #### Od ręcznego doboru do automatycznych kaskad Gdy trzy poziomy są już zdefiniowane, decyzja o routingu nie musi zależeć od tego, czy ktoś akurat o niej pamięta. Architektura kaskadowa najpierw próbuje wykonać zadanie na szybkim i tanim modelu, sprawdza wynik prostą regułą albo lekką weryfikacją, po czym eskaluje do mocniejszego modelu wyłącznie te przypadki, które tej weryfikacji nie przejdą. Przy stawkach z tabeli wyżej rachunek jest prosty: każdy przypadek eskalowany kosztuje 5 razy tyle, co obsłużony na miejscu, więc kaskada zarabia dopiero wtedy, gdy tani model domyka wyraźną większość ruchu. To wzorzec wart wbudowania w produkcyjne systemy AI: routing przestaje być nawykiem, o który musi dbać jedna osoba, a staje się właściwością samego systemu, stosowaną konsekwentnie niezależnie od tego, czy zapytanie pochodzi od pracownika, narzędzia wewnętrznego czy agenta działającego po stronie klienta. #### Gdzie routing wymaga warstwy nadzoru W środowisku regulowanym koszt i opóźnienie nie są jedynymi zmiennymi. Niektóre zadania powinny za każdym razem działać na tej samej, zwalidowanej konfiguracji modelu niezależnie od ceny, ponieważ spójność i wyjaśnialność liczą się bardziej niż oszczędność: decyzje dotyczące danych osobowych w rozumieniu RODO, ujawnień finansowych lub bezpieczeństwa, albo takie, które trzeba będzie później uzasadnić przed regulatorem lub audytorem. Dla takich zadań routing przestaje być pytaniem o efektywność, a staje się pytaniem o nadzór. Jego miejsce jest w spisanej polityce, poddawanej regularnemu przeglądowi, z człowiekiem w pętli decyzyjnej wszędzie tam, gdzie decyzję trudno cofnąć. #### Jak zbudować własną macierz routingu Praktyczny punkt startowy rzadko wymaga więcej niż czterech kroków: spisać przez kilka tygodni, jakie zadania AI faktycznie wykonują zespoły; podzielić je według stawki i odwracalności, a nie nowości; przypisać każdej kategorii domyślny poziom modelu i zapisać to w dokumencie; oraz ustalić jawne reguły eskalacji dla wyjątków, zamiast zostawiać wybór osobie, która akurat siedzi przy klawiaturze. Ponieważ możliwości i ceny modeli zmieniają się szybko, macierz warto przeglądać raz na kwartał. Polityka routingu ustalona raz i nigdy niepoddana ponownemu przeglądowi zwykle traci aktualność w ciągu kilku miesięcy. RS Management projektuje i wdraża takie systemy routingu, od wstępnego spisu zadań po produkcyjną kaskadę, jako część szerszego doradztwa i wdrożeń AI dla kadry zarządzającej oraz organizacji z branż regulowanych. Jeśli organizacja wydaje na AI więcej, niż wymaga tego wykonywana praca, albo przydałaby się druga, bardziej krytyczna opinia o obecnym sposobie doboru modeli, [zapraszamy do rozmowy](/#contact). [^cennik]: Anthropic, cennik modeli w przeliczeniu na milion tokenów: . --- ## Posts in English (14) ### Does AI Recommend Your Company? https://rsmanagement.ai/en/blog/does-ai-recommend-your-company/ Published: 2026-08-11 | updated: 2026-09-02 AI crawlers read company sites far more often than they send a visitor back. What that means, what not to buy and how to measure your own visibility. A growing share of buying questions never reaches a search engine. A customer types something like "recommend a good company that does this kind of work near me, one that publishes prices" into ChatGPT or Perplexity, and gets three names with reasons. No ten blue links, no comparing them personally, no visits to ten websites. Just a finished answer. If the company's name is not in it, then as far as that customer is concerned, the company does not exist. This is not a forecast for next year. It is already happening, and it shows up in server logs. #### Bots read, but they do not send anyone back The most telling number in this discussion is a simple one: how many times a crawler has to fetch content from websites before a single person lands on one of those sites from a model answer. In July 2026 Anthropic crawlers fetched roughly 1,900 pages for every single visit they sent back, and OpenAI crawlers roughly 250.[^radar] A year earlier the same ratio for Anthropic ran into the tens of thousands, so the direction is improvement, from a very high starting point. Two things are worth knowing about these numbers: they move from month to month, and Cloudflare itself notes they are probably overstated, because visits arriving from the Claude app carry no information about where they came from and cannot be counted. The order of magnitude stays the same and that is the conclusion: the content is read at scale and the visitor does not come back. Classic search operated for two decades on an exchange where both sides gained something: our content to index, our traffic in return. When the answer is assembled inside a chat window, that exchange stops being symmetrical. The content is still needed. The click is not. The conclusion for a business owner is uncomfortable but simple. Visibility can no longer be measured by organic sessions alone. Part of the buying decision now happens in a place no on-site analytics tool can see.
  • 1,900:1crawls per referral, Anthropic bots, July 2026
  • 250:1the same ratio for OpenAI bots
  • 137ksites studied that carry an llms.txt file
  • 97%of them logged not one request for it
#### What Cloudflare announced, and why There is a fight about money going on in the background, and it is worth understanding so you do not buy something too early. On 1 July 2025 Cloudflare, one of the largest companies handling internet traffic, launched pay-per-crawl: a mechanism letting a site owner charge an AI bot for fetching content by responding with HTTP status 402, meaning "payment required." It sounded like the start of a new revenue stream for publishers. Exactly one year later, on 1 July 2026, Cloudflare set that idea aside itself and announced the Monetization Gateway: billing not for fetching a page, but for actual use of the content in an answer. For now it is a waitlist and two partners, Ceramic.ai and You.com. On 4 August 2026 Cloudflare Wallets followed, stablecoin wallets from which AI agents are meant to pay for access to services. The direction makes sense, but the scale is still negligible. The whole market for these micropayments is smaller today than the annual turnover of one mid-sized wholesaler, and a single transaction is worth a few cents. If anyone is currently pitching "earning money from AI crawlers" as a service for an ordinary business, they are selling an announcement, not a product. There is, however, a second side to the same announcement, available right now at no charge. AI Crawl Control works on every Cloudflare plan, including the entry-level one, and shows which AI bots visit a site, how often and for what. That is the first measurement worth taking, because it takes fifteen minutes and requires no purchase. It is also worth knowing what not to buy. The past year brought a fashion for llms.txt, a short set of instructions for language models placed on the site. Across 137,000 sites that had added the file, 97% never logged a single request for it, and among the few that logged anything, most requests came from SEO tools rather than from models.[^ahrefs] That does not mean the idea is wrong in principle. It means it does not change the outcome today and does not deserve its own line on an invoice. The other side of the same question is more interesting. A website can tell crawlers directly what they may and may not do, and only a few percent of companies do so today. Most have made no decision at all, because they do not know there is one to make. #### What decides whether a model names you The boring truth: the same things that have shaped the quality of a company's information online for years, only now the stakes are higher. **Structured data.** Schema.org markup that states plainly what a page is: organisation, service, price, opening hours, location, review. The model does not have to infer it from the visual layout, it is handed the facts. For a single-location service business this is a few hours of work. **A readable pricing page.** Prices as text, not as an image or a downloadable PDF. A range is better than nothing, "contact us" is worst. Buying questions almost always involve price, and a model cannot quote a number it cannot see. **Consistency.** The same company name, address, phone number and service scope on the website, in the Google business profile, in industry directories and on social profiles. Contradictory data is the most common reason a model describes a company cautiously, or skips it in favour of a competitor whose details line up. **A page that reads without JavaScript.** If content only appears after scripts run in the browser, some bots will see an empty page. Simple test: turn JavaScript off and see what is left. **A technical readiness scan.** The tool isitagentready.com scores a site across four categories and points to specific fixes. It is not an oracle and it does not replace measuring actual visibility, but as a starting point it needs neither payment nor signup. #### The 30-question method A technical score tells you whether a site can be read. It does not tell you whether models actually name the company. That has to be checked separately, and it can be done in-house. The method is simple to describe and laborious to run. Step one: write out 30 questions a customer genuinely asks before buying, in your own industry. Not SEO keywords, but full sentences with intent, built around three patterns: what it costs, who does this in a given city or region, who has a good reputation for it. In practice that sounds like "how much does an order management system cost for a wholesaler," "who runs AI training for senior managers in a specific region" or "which law firm knows its way around IT contracts." Two thirds should carry no company name, one third should include it, to see what the model says about the company when asked directly. Step two: ask each question in at least three places. ChatGPT, Perplexity and Google's AI overview are a sensible minimum, because they draw on different sources. Start a fresh conversation each time, with no logged-in history skewing the result. Step three: record three things for every answer. Whether the company was named. In which position. Which source the model cited. The last one is the most revealing, because it usually turns out models cite an industry directory or a review portal rather than the company's own site. Step four: count the share. How many of the 30 questions produced a mention, how many mentions were factually correct, how many times competitors appeared. That first number is your baseline. Without it, every later change to the site is guesswork. Step five: repeat after six to eight weeks with the same set of questions. Model answers vary by nature, so a single measurement says little, while the difference between two measurements says a great deal. A full run for one company takes about a day of work if done honestly, with everything written down. It can be shortened, but the comparison loses credibility when it is. #### What to do in the coming month There is no revolution here to miss. There is a shift in proportion: a growing share of buying decisions is made in conversation with a model rather than on a list of results, and most companies do not know what the model says about them. Two things in the coming month take time rather than budget: turn on a view of AI bot traffic and work through 30 questions your own customers ask. [^radar]: Cloudflare Radar, crawl-to-refer ratios for AI crawlers: . [^ahrefs]: Ahrefs, analysis of 137,000 sites carrying an llms.txt file: . If it is easier to have this measured and written up from the outside, we run such measurements as part of [our services](/en/services/). The result is usually less dramatic and more specific than owners expect before the first run. --- ### Popular AI Repos on GitHub https://rsmanagement.ai/en/blog/popular-ai-repos-on-github/ Published: 2026-08-07 | updated: 2026-09-02 The most popular AI projects on GitHub in August 2026 and what star counts reveal about maturity and what they hide. The question arrives in board meetings in almost identical wording every time: is this the market standard yet. The answer everyone in the room reaches for usually reduces to a single number, the GitHub star count. It is public, easy to compare and looks objective, so it ends up in slide decks and then in architecture decisions. It is worth understanding what that number actually measures. #### The landscape in August 2026 The figures below are star counts rounded to the nearest thousand.

MCP in the charts below stands for Model Context Protocol, the open standard for connecting AI agents to company tools.

Agent frameworks and platforms

  1. OpenClaw386k
  2. AutoGPT186k
  3. LangChain144k
  4. browser-use108k
  5. MCP servers89k
  6. OpenHands83k
  7. Cline66k
  8. CrewAI57k
  9. LlamaIndex51k
  10. LangGraph39k
Stars in thousands. The scale is shared across all four charts, so bar lengths can be compared between categories. Full width is OpenClaw at 386,000; for reference, React stands at 247,000.
The Model Context Protocol servers repository, visible in the first chart, has become the de facto exchange point for integrations between tools.

Running models on your own infrastructure

  1. Ollama178k
  2. Transformers163k
  3. llama.cpp123k
  4. vLLM88k
  5. LlamaFactory74k
  6. Unsloth70k
  7. LocalAI48k
  8. SGLang32k
Stars in thousands, same scale as above.

RAG and semantic search

RAG (retrieval-augmented generation) is the pattern where a system first retrieves passages from company documents and only then attaches them to the prompt.

  1. RAGFlow87k
  2. Milvus46k
  3. FAISS41k
  4. GraphRAG35k
  5. Qdrant34k
  6. Chroma29k
  7. Haystack26k
  8. Weaviate17k
Stars in thousands, same scale as above.

Workflow orchestration and interfaces

  1. n8n200k
  2. Langflow153k
  3. Dify152k
  4. Open WebUI148k
  5. AnythingLLM64k
  6. LiteLLM56k
  7. Flowise55k
  8. LibreChat42k
Stars in thousands, same scale as above.
One figure on that list distorts the scale of everything else. OpenClaw carries more stars than React, which sits at 247,000[^github], and it got there in under eight months. It is still well short of the top of GitHub overall, where learning-resource collections pass half a million stars, and no AI project has grown that fast before. #### What popularity genuinely tells you A high ranking does carry several pieces of information with commercial value. The first is talent supply. With a project in the six-figure star range it is easier to find an implementation partner, easier to hire and easier to replace someone who leaves the team. The second is integration surface. Widely adopted libraries ship connectors to the systems an organisation already runs, which shortens integration work. The third is the quality of supporting material. A large community means documented failure modes, deployment examples, and language models that know the project's API (application programming interface) well enough to make AI-assisted coding meaningfully more productive. The fourth is security attention. Vulnerabilities in heavily used components tend to be found sooner. #### What popularity does not tell you This is the part that gets skipped in a quick review. **A star is a bookmark that never expires.** The counter only goes up, so a project being wound down can hold a high position for years. Microsoft AutoGen carries more than 60,000 stars[^github], and its most recent code change dates from 15 April 2026. The repository README states plainly that it is in maintenance mode and directs new users to Microsoft Agent Framework, which has collected around 13,000 stars[^github]. An organisation picking components by ranking would have chosen the project being retired and passed over its official successor. **Popularity says nothing about the licence.** n8n, at 200,000 stars[^github], is distributed under the Sustainable Use License, and the project itself declines to call this open source because the licence restricts commercial use in ways the Open Source Initiative definition does not allow. Dify uses a modified Apache 2.0 licence that prohibits operating multi-tenant environments without separate written permission, and prohibits removing the logo from the interface. For a company planning to resell a service to end customers, that is a decisive distinction and it is entirely invisible in the star count. **Popularity says nothing about risk profile.** OpenClaw earned its position as an assistant that runs on the user's own machine, executing shell commands and file operations, driven from messaging apps. That characteristic is the source of both the enthusiasm and the serious reservations in environments handling personal data or trade secrets. Star velocity reflects market curiosity and carries no judgment about enterprise readiness. #### Six signals we check instead of the ranking Before a component reaches our recommendation it passes six checks. None of them needs tooling or access beyond the public repository, and together they take a quarter of an hour. The order matters: the first three signals say whether the project is still alive, the other three whether it is safe to build on. - Date of the last code change, and not the last release but the last commit. A release can be cut from material prepared long ago; a commit shows whether anyone is still working on the project. - Release cadence: regular releases every few weeks mean something different from three releases in one week followed by six months of silence. Irregularity often signals a project resting on one person. - Contributor concentration: if most changes come from a single account, the risk becomes personal: that person changing jobs is enough. - Rate at which issues get closed. Not the number open, but whether reports get an answer at all. A hundred open issues with fast replies says something different from twenty open and six months of silence. - Licence changes in the project's history. A project that has tightened its terms once can do it again, and then the choice is staying on an old version without fixes or rewriting the integration. - Licence read, not assumed. The "open source" label in a repository description is sometimes inaccurate, and terms restricting resale or multi-tenant environments only show up in the licence text itself. On a longer assessment, the presence of a security policy comes in, and for projects with a commercial owner the question of who funds development. A commercial entity usually means a predictable release cadence, and at the same time a risk of licence changes at the moment investors start expecting revenue. This set does not replace testing. It does filter out projects where testing would be wasted time, and it does so before anyone starts building an integration on top. Signals sometimes conflict, and then the layer the component is meant for decides, as described below. **Popularity says nothing about fit.** A ranking knows nothing about document volumes, latency requirements, the language of the data or the fact that the documents in question are scanned PDFs in Polish. The statistically strongest project is sometimes oversized for the task, or missing the one capability that decides the case at hand. #### Layers differ in the cost of being wrong That sets the order of decisions. The model serving layer is comparatively cheap to swap, because the interfaces have converged on a near-standard and migrating between engines takes days. The agent and workflow orchestration layer is the most expensive to swap, because it permeates business logic and team habits. Where the cost of change is high, a conservative and well-tested choice pays back faster than a fashionable one. Where the cost of change is low, experimenting with younger projects is entirely reasonable. The same weakness means different things depending on how expensive it would be to reverse the decision. Open source components inside an AI system fall under the same documentation regime as the rest of the solution, including obligations arising from the EU AI Act. [^github]: Public star counters on the repositories: [OpenClaw](https://github.com/openclaw/openclaw), [React](https://github.com/facebook/react), [n8n](https://github.com/n8n-io/n8n), [Dify](https://github.com/langgenius/dify), [Microsoft AutoGen](https://github.com/microsoft/autogen), [Microsoft Agent Framework](https://github.com/microsoft/agent-framework). --- ### The AI Act After 2 August 2026 https://rsmanagement.ai/en/blog/ai-act-after-2-august-2026/ Published: 2026-08-04 The AI Act after 2 August 2026: which obligations now apply, which moved to December 2027 under Regulation 2026/1744, and what HR teams should do. For more than two years, 2 August 2026 stood as the date the EU AI Act would apply in full. Six days before that deadline the picture changed. Regulation (EU) 2026/1744, published in the Official Journal on 24 July and in force from 27 July 2026, pushed the heaviest obligations back by well over a year. The deadline did not disappear, but it now means something different from what most compliance plans written in 2025 assumed. Classifying a specific system is worth doing with a qualified lawyer involved. #### The calendar worth keeping in view Regulation (EU) 2024/1689 entered into force on 1 August 2024 and has been arriving in stages ever since, under Article 113: | Date | What starts to apply | |---|---| | 1 August 2024 | Regulation (EU) 2024/1689 enters into force | | 2 February 2025 | Prohibited practices and the AI literacy obligation (Chapters I and II) | | 2 August 2025 | General-purpose models, supervisory bodies, penalties, confidentiality | | 2 August 2026 | The remainder of the Regulation, including Article 50 transparency and Article 101 | | 2 December 2026 | New Article 5 prohibitions; end of the transition on content marking | | 2 December 2027 | Standalone high-risk systems under Annex III (postponed) | | 2 August 2028 | High-risk systems embedded in Annex I products (postponed) | - 2 February 2025: prohibited practices and the AI literacy obligation (Chapters I and II). - 2 August 2025: general-purpose AI models, the supervisory authority structure, the penalty provisions and confidentiality (Chapter III Section 4, Chapters V, VII and XII except Article 101, plus Article 78). - 2 August 2026: the remainder of the regulation, including the Article 50 transparency obligations and Article 101, which covers fines for providers of general-purpose AI models. - 2 December 2027: stand-alone high-risk systems under Annex III, moved from 2 August 2026. - 2 August 2028: high-risk systems embedded in products covered by sectoral legislation under Annex I, moved from 2 August 2027. The amendment also added two intermediate dates. From 2 December 2026, new prohibitions under Article 5 take effect, covering the generation of non-consensual intimate material and child sexual abuse material. The same day closes the transition period for machine-readable content marking for systems placed on the market before 2 August 2026. #### What genuinely started on 2 August The Article 50 transparency obligations survived the reshuffle, and they are the operational work landing on desks right now. They come down to a handful of situations. Anyone interacting with an AI system has to be told. Synthetic audio, images, video and text have to be marked in a machine-readable format on the provider side. Emotion recognition and biometric categorisation systems require notice to the people involved, and deepfakes and public-interest text require disclosure by the deployer, with exceptions where a human takes editorial responsibility. In practice this reaches plenty of companies that do not consider themselves technology businesses: the chatbot on the website, the assistant in a customer service channel, an image generated for a marketing campaign. Reviewing those touchpoints takes a few working days and is the cheapest work available this quarter. #### Penalties, and the SME exception Article 99 sets three tiers: up to EUR 35 million or 7% of total worldwide annual turnover for breaching the prohibited practices, up to EUR 15 million or 3% for most other breaches, and up to EUR 7.5 million or 1% for supplying incorrect or misleading information.[^art99] For undertakings, the higher of the two figures applies. Here sits the detail most often missed in board conversations. Paragraph 6 of the same article reverses the rule for small and medium-sized enterprises, including start-ups: for them the lower of the two applies. The July amendment added a comparable mechanism for small mid-cap companies. For a business turning over a few tens of millions, that gap separates a painful fine from an existential one. #### HR as a high-risk area Point 4 of Annex III covers employment and workforce management. Sub-point (a) lists systems used for recruitment and selection, in particular for placing targeted job advertisements, analysing and filtering applications and evaluating candidates. Sub-point (b) covers systems informing decisions on terms of employment, promotion and termination, allocating tasks based on individual behaviour or personal traits, and monitoring and evaluating performance and conduct. A CV ranking tool, a candidate scoring model, analysis of recorded interviews, a system assigning tasks from a worker profile: each falls inside that point. The full requirements now bite on 2 December 2027, which hands HR teams roughly sixteen extra months. That time is worth using, because the work runs longer than it looks. A sensible order starts with an inventory of every tool touching candidates and employees, including AI features switched on inside an applicant tracking system without a separate purchasing decision. Then comes a review of supplier contracts against the documentation those suppliers must hand over, the design of human oversight with a named person with the standing to overrule the system, and the rules for informing candidates and staff. #### Deployer obligations beyond HR Article 26 places obligations on the organisation using a high-risk system, separate from the provider's. They cannot be contracted away, which tends to surprise teams who have just bought a finished tool from a reputable vendor. The core of these duties repeats across industries: using the system in line with the provider's instructions, assigning oversight to people with suitable competence and support, monitoring operation, and suspending use and informing the provider and supervisory authority where a risk to health, safety or fundamental rights appears. Deployers also retain automatically generated logs and keep input data appropriate to the purpose, to the extent they control it. Some, including public bodies and providers of certain services, additionally carry out the fundamental rights impact assessment under Article 27. #### Polish supervision starts in autumn The national layer closed at almost the same moment. The Polish Act of 3 July 2026 on artificial intelligence systems was published in the Journal of Laws on 27 July 2026, with most of its provisions taking effect on 11 August 2026. It establishes the Commission for the Development and Security of Artificial Intelligence (KRiBSI) as the national market surveillance authority. The Ministry of Digital Affairs expects the chair to be appointed in October 2026 and the Commission to be operational in November. The EU obligations run regardless of that body's readiness, so waiting for it moves no deadline. #### Making use of the extra sixteen months Pushing deadlines back is good news for delivery schedules and risky for discipline. What we see repeatedly is that projects deferred without a named owner reappear a quarter before the deadline, once the room to negotiate with suppliers has closed. A workable split looks like this. Close out the Article 50 obligations this quarter, since they already apply and are comparatively cheap. Run the inventory and Annex III classification through to the end of 2026, while decisions are still reversible. Renegotiate supplier terms at the next contract renewal rather than in 2027 under deadline pressure. That sequence costs little and removes most of the last-minute risk. [^art99]: Regulation (EU) 2024/1689, Article 99, Official Journal text: . --- ### Tokens and Context https://rsmanagement.ai/en/blog/reduce-llm-costs/ Published: 2026-07-21 | updated: 2026-09-02 Cutting AI running costs: prompt caching, history summarisation, retrieval instead of pasting, model routing and output length caps. An AI bill rarely grows because a team suddenly started asking more questions. More often it grows because every individual question became more expensive. Models charge by the token, meaning the chunks of text that go into the model and come back out of it, and most organizations have no idea how many tokens a single request actually carries. Without that number, optimization is guesswork. The tool for producing it sits on the provider's side: Anthropic exposes a separate function that counts tokens before a request is even sent. #### Why context inflates on its own Three mechanisms account for most of the growth. - A conversation with a model is stateless. The model remembers nothing from the previous turn, so the application resends the entire history with every new question. The tenth message costs several times what the first one did, even though the user typed exactly as much. - Instructions repeat on every call. A system instruction holding a role description, rules, examples and tool definitions can easily run to several thousand tokens, and it travels with every request, including the ones a single sentence would have answered. - Whole documents get pasted in. Someone drops in an 80-page policy to ask about one clause. The bill covers 80 pages, and it does so again with every follow-up question about the same document. Context windows now reach 1 million tokens[^okno], but a large window still has to be paid for. You pay for whatever you actually put in it. The three mechanisms stack, and that is the heart of the problem. History grows with every turn, the system instruction rides along with each of them, and a pasted document is duplicated together with the history. The bill therefore grows faster than linearly, even though the team asks exactly as many questions as it did a month ago. #### Prompt caching When a large part of the prompt is identical every time, providers will hold it on their side. On the Anthropic API (application programming interface) a cache read costs 10% of the standard input price[^cache], while writing an entry costs 1.25 times that price for a five-minute lifetime, or twice for a one-hour one (as of August 2026). With the shorter lifetime the mechanism breaks even on the second call against the same prefix; with the one-hour option it takes at least three. Other major providers follow similar logic, though entry lifetimes and write premiums differ between platforms, so each price list needs checking on its own terms. | Technique | Implementation effort | When it pays back | |---|---|---| | Prompt caching | Hours | From the second call against the same prefix | | Shortening the system instruction | Hours | Immediately, on every request | | Routing tasks to cheaper models | Days | At steady volume of routine work | | Batch processing | Days | When the answer need not be immediate | | Summarising conversation history | Weeks | On long sessions with recurring context | There is a catch here that breaks more implementations than everything else combined. Matching works on the prefix, character by character. Put the current date, a session identifier or a user's name near the top of the system prompt and nothing after it will cache. One change invalidates everything that follows it. Hence a simple design rule: stable content first, variable content last. Two limits are worth knowing in advance. Very short prompts are never cached at all, and the threshold depends on the model, falling roughly between 512 and 4096 tokens. The second point is the one most often confused: the discount applies to input only. Tokens the model generates cost what they always did, so any savings estimate stretched across output is inflated. #### Summarize rather than replay In long conversations, and in agents that run dozens of steps, history grows faster than the value it carries. A sensible pattern looks like this: the last few turns stay verbatim, earlier ones become a compact summary, and raw tool results are dropped once they stop being relevant. Some providers, Anthropic among them, offer this as a built-in feature; some teams write their own logic. The effect is the same either way, in that the cost per turn stops rising in step with the length of the conversation. The trade-off is explicit. A summary loses detail, so you have to decide what must never be lost in a given process, such as commitments made to a client or case numbers, and exempt it from compression. #### Retrieve instead of pasting When questions concern a fixed body of knowledge, pasting all of it stops paying off very quickly. The alternative is to search for the relevant passages and give the model only what bears on the question. This is usually called RAG (retrieval-augmented generation). With a handful of documents there is nothing to discuss, so paste away. With several hundred documents and steady traffic the difference becomes an order of magnitude. It is worth calculating the threshold for your own case rather than adopting someone else's. The gain is not purely financial either: shorter, better-targeted context also improves answer quality, because the model is not hunting for a needle in a haystack. #### Routing and a ceiling on response length Output tokens typically cost several times more than input tokens, and models have a marked tendency toward verbosity unless told otherwise. Two simple constraints work immediately: a hard length limit set in the call itself, and an instruction describing the expected shape of the answer. A classification task does not need a paragraph of reasoning when a label will do. Model choice sits alongside this. Routine work such as formatting, classification and short extractions does not require a frontier model. If the result is not needed immediately, look at the batch queue: on the Anthropic API, asynchronous processing costs half the standard price and most jobs finish within an hour. For overnight recalculations or bulk document processing, that is the simplest saving available. #### Measurement comes first All of these techniques share one precondition. Without cost broken down by process and by prompt, all anyone sees is a single number on an invoice, and that number does not say where to look. The minimum useful set of metrics covers input and output tokens per call, the share of input served from cache, reported by the Anthropic API in a dedicated response field, and cost split by use case. When the cached share stubbornly reads 0% despite a correct configuration, it almost always means something variable has crept into the top of the prompt. #### Where optimization stops Two boundaries deserve to be set deliberately. The first is about quality: aggressive context trimming degrades answer accuracy, so every change needs validating against a test set rather than against an impression. The second concerns data. Content placed in a cache is held on the provider's side for the lifetime of the entry, which in regulated organizations has to be reconciled with information classification and the retention policy that follows from GDPR. The order of work looks much the same in most cases: measure first, then cache, then cap output length and route by task, and only then rebuild how knowledge reaches the model. The first two steps tend to be the cheapest and usually deliver the larger share of the effect. [^okno]: Anthropic, model overview including context window sizes: . [^cache]: Anthropic, prompt caching pricing: reads at 0.1x, writes at 1.25x for the five-minute buffer and 2x for the one-hour buffer: . --- ### MCP or CLI https://rsmanagement.ai/en/blog/mcp-vs-cli-for-ai-agents/ Published: 2026-07-07 | updated: 2026-09-02 How the Model Context Protocol compares with CLI and script integrations: when standardization pays off, when a script is enough, and how to audit calls. When an AI agent is supposed to do something useful inside a company, it eventually has to reach into the system where the data lives: Jira, SharePoint, a warehouse, an ERP (enterprise resource planning) system or an internal API (application programming interface). That connection is usually treated as a technical detail for the team to settle, yet it determines what the integration costs to maintain, who is allowed to trigger it, and whether anyone can reconstruct what the agent did after an incident. #### Two ways to connect a tool The first is MCP (Model Context Protocol), an open protocol describing how an agent discovers the tools and resources a server exposes and how it calls them. An MCP server sits in front of the target system and speaks a shared language, so the client, be it an IDE assistant, a chat application or a custom agent, does not have to learn a new integration language for every system. The second is a CLI (command line interface) call. The agent is granted the right to run a specific command or script, and the contract is the arguments, the exit code and the output written to standard output. Authorization, validation and logging all live in code the team wrote itself. The difference is one of abstraction level. MCP standardizes the description of capabilities, the negotiation of permissions and the shape of results, while a script leaves those decisions to team convention, an advantage with one integration and a liability with ten. #### MCP status in September 2026 On 9 December 2025 MCP moved to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI, backed by Google, Microsoft, AWS, Cloudflare and Bloomberg. The announcement cited more than 10,000 active public MCP servers and more than 97 million monthly SDK (software development kit) downloads across Python and TypeScript.[^mcpaaif] A public server registry has run since September 2025. The specification revision in force is dated 2026-07-28 and brings the largest change since launch: a stateless core with no session handshake, per-request capability negotiation, tightened authorization rules and an extensions framework. The changes break backward compatibility, and the previous revision was dated 2025-11-25, so an integration written against the older specification needs a review before the next library upgrade. The standard has serious backing from the largest vendors and is also moving quickly, so an integration built on MCP needs budget for regular library upgrades well beyond the first deployment. #### When MCP earns its keep Standardization pays off when the same tool has to be called from several places. One server covers the IDE assistant, the chat application and a custom agent, instead of three pieces of glue maintained by three different people. The second strong case is a vendor-maintained server, which turns compatibility with successive API versions from the team's cost into part of a product somebody else owns. The third is server-side authentication. Where access has to be granted per user, with token refresh and revocation, the protocol's authorization layer does work that would otherwise be written by hand and maintained forever. The fourth is a changing tool set. When the catalogue of functions grows and shifts every few weeks, discovering tools at runtime is easier than updating prompts on every change. #### When a simpler script is enough For one integration used by one client, an MCP server adds a layer that returns nothing. If the repository already holds a tested script for issuing invoices or updating tickets, letting the agent call it is cheaper than rewriting it as a protocol server. Scripts also win on high-stakes operations, where the goal is a narrow and rigid surface of action. Five explicitly defined commands are easier to review than a server exposing forty tools the agent picks from on its own. In one deployment we settled on a read and write split: reads through the vendor's ready-made MCP server, every write through an in-house script with credentials in environment variables and a log entry per call. The trade-off is maintaining two mechanisms rather than one, and in exchange every state-changing operation requires an explicit path and leaves a trace. #### The context cost nobody mentions Tool definitions occupy space in the model's context, and with a dozen servers connected the catalogue alone can consume tens of thousands of tokens before the agent does anything useful. In November 2025 Anthropic described a pattern for calling MCP tools from code running in a sandbox: definitions loaded on demand, intermediate data processed in code, only the finished result handed back to the model. In its example, one workflow dropped from roughly 150,000 tokens to roughly 2,000.[^mcpkod] That is one documented case, so the numbers will not transfer directly to another environment, though the direction is telling: the boundary between the two approaches is blurring, because MCP supplies the tool descriptions while execution drops into code anyway. | Dimension | MCP | CLI and scripts | |---|---|---| | Entry cost | Higher: server, permissions, maintenance | Low: whatever the team already runs | | Context consumption | The tool catalogue takes prompt space | Zero until the call is made | | Resilience to API change | Tool description lives in one place | Every script separately | | Who owns the code | The server is often somebody else's | The code is ours and auditable | | When it wins | Many systems, frequent change | A few systems, stable interfaces | #### Security and the audit trail On 15 April 2026 researchers described an attack class named "Comment and Control."[^cc] Content injected into a pull request title or an issue comment hijacked agents triggered automatically in GitHub Actions, including Claude Code Security Review, Gemini CLI Action and GitHub Copilot Agent, and made them exfiltrate secrets from the runner. The vendors paid bug bounties without publishing CVE (common vulnerabilities and exposures) identifiers. The conclusion holds regardless of connection method. An agent treats the content it reads as trusted context, and its permissions become the attacker's permissions. Four controls applied together limit the blast radius: an allowlist of tools, an identity attached to every call, a log containing arguments and results, plus human approval on irreversible operations. Here a script holds an advantage worth remembering when audit gets involved: the call log appears by itself and the permission boundary is visible in the code. With MCP the audit trail has to be designed deliberately, because the call passes through a layer the team did not write, on a server that is often somebody else's. Extensions defined separately from the core protocol address this area, and which of them a given client supports is something to check during connection negotiation rather than during tool selection. #### Deciding a specific case Four questions are usually enough. How many clients will call this tool over the next year? Does the vendor maintain an MCP server, or would it have to be written and maintained in-house? Is the operation reversible, and if not, where does human approval sit? Does the repository already hold a reviewed script for the same job? The most common mistake is treating this as a one-time decision for the whole organization. It is better settled integration by integration, with a short written rationale, because within months both the protocol revisions and the list of maintained servers will have changed. [^mcpaaif]: Model Context Protocol, 9 December 2025 announcement of the move to the Agentic AI Foundation, including the server and SDK download figures: . [^mcpkod]: Anthropic, the pattern for calling MCP tools from code: . [^cc]: Cloud Security Alliance, research note on AI agents in GitHub Actions exfiltrating secrets: . --- ### Better Prompting at Work https://rsmanagement.ai/en/blog/better-prompting-at-work/ Published: 2026-06-23 Five parts of a prompt that actually change the output, before and after pairs from everyday office work, and how to iterate when the first answer misses. Across the teams we work with, the gap between someone who gets useful output from a model and someone who gives up after three attempts rarely comes down to knowing special phrases. It comes down to how much information reaches the prompt and how it is organized. The magic openers circulating online, along the lines of "act as a world-class expert," change little, because they add no knowledge about the task. Research bears this out: across 2 410 factual questions and 162 roles written into the prompt, adding the role alone did not improve answer accuracy over the version with no role at all.[^persona] What follows is the practice we use at RS Management daily on documents, analyses and correspondence, with concrete before and after pairs. #### Five parts of a good prompt - **Role**: who the model is writing as, and for whom. "A financial analyst preparing material for the board" narrows vocabulary and level of detail far more effectively than any adjective such as "professional." - **Context**: what the model needs to know so it does not have to guess. Industry, project stage, relationship history, constraints, decisions already made. Include only what the task needs: a 2023 study showed that models are easily distracted by irrelevant context and make more mistakes on problems padded with unnecessary detail (Shi et al., ICML 2023). - **Task**: one specific action expressed as a verb. "List the risks" and "judge which risk is largest" are two different tasks and come out better split into two steps. - **Output format**: length, structure, tone, language, table layout. Without it the model picks a format on its own, usually one that misses the need. - **Example**: one or two samples showing what a good answer looks like. The order matters less than whether all of them are there. When an answer disappoints, one is usually missing, most often the output format or the context. #### Three pairs from everyday work ##### The meeting note Before: > Summarize these meeting notes. After: > You are assisting a project manager. Below are raw notes from a 90-minute status meeting with the client and two vendors. Write a summary for a director who was not present and has two minutes to read it. Format: three sentences of substance, then a list of decisions taken, then a table of actions laid out as action / owner / due date. If an owner or due date was not stated explicitly, write "not agreed" rather than filling it in with a guess. That last sentence removes the most common defect in such summaries: politely inventing deadlines nobody agreed to. ##### The reply to a price increase Before: > Write an email to the vendor saying we do not accept the increase. After: > Context: three years of work with a service vendor, a framework agreement with an annual addendum, the vendor has announced a 12% rate increase from January, justified by labour costs. We want to keep the relationship and to spread the increase over two stages. Write a reply of up to 150 words, matter-of-fact and calm, no exclamation marks, closing with one question about their willingness to discuss the schedule. Below are two of our earlier emails to this vendor, keep to that tone. The two pasted emails do more work here than any description of style. ##### The sales spreadsheet Before: > Analyse this sales data. After: > Below is monthly revenue for 14 product categories over the last 18 months. Task: identify the categories where the year-on-year trend changed direction in the most recent quarter. For each, give the size of the change and the month of the reversal. Format: a table with columns category / year-on-year change / month of reversal / short comment. Do not interpret causes. If the data for a category is incomplete, list it separately below the table. "Do not interpret causes" earns its place: asked for open-ended analysis, a model will happily supply explanations that cannot be derived from the numbers in front of it. #### Ask for a plan before the work For any task longer than a page, it is worth asking for a plan first: 5 to 7 bullets stating what each section will cover and where the data comes from. Correcting a plan takes 2 minutes. Correcting a finished eight-page document takes 30 minutes. A plan also surfaces misunderstandings early, when the model has read the task differently than it was meant. This single habit changes more than the rest of the list combined. #### Iterate on the model's own mistakes The usual reflex after a weak answer is to fix it by hand. It pays more to treat each defect as a missing instruction and add it to the prompt. The model produced generalities instead of numbers, so the prompt gains a line requiring numeric values. It wrote three pages instead of one, so a hard word limit appears. After a few rounds the prompt produces a predictable result on the first attempt. Proven blocks are worth keeping. Ours live in one text file sorted by category: summaries, correspondence, data analysis, document review. Copying a block and swapping in fresh context takes under 1 minute, and the quality stays consistent. #### Verify before anything goes out Model output needs a check before it travels further: figures, dates, names and quotations from source documents. It helps to ask the model to point to the passage each claim came from, then verify two or three at random. If those spot checks stay clean for 4 weeks, they can be thinned out. If they fail, the problem usually sits in the prompt that let the model step outside the source material. A separate question is what goes into the chat window at all. Personal data within the meaning of GDPR, commercial terms and confidential material call for a tool the organization has approved, and a clear understanding of where that data is processed and how long it is retained. For sensitive data the decision is worth confirming with the people responsible for security and compliance. #### What a better prompt will not fix Prompt structure helps only when the task can be done with the material provided. A model will not invent data it never received. It will not answer a badly framed question well, including one the author cannot answer. And it does not substitute for system access: when the information sits in a database, an HR system or a document repository, the answer is integration, for example through MCP (Model Context Protocol), a standard for connecting models to company data sources, rather than an ever longer prompt. The practical starting point is simple: pick three tasks repeated every week, write a five-part prompt for each, test them over a few days and revise after each disappointing result. After a month, the difference in time and quality is visible without any measurement. [^persona]: Zheng et al., measurement of how a role written into the prompt affects answer accuracy: . --- ### Running Models Locally https://rsmanagement.ai/en/blog/running-ai-models-locally/ Published: 2026-06-09 | updated: 2026-09-02 A practical look at hardware tiers for running AI models locally, from laptops to unified-memory machines, and where the case against API breaks down. The question about running models locally comes up in almost every AI delivery conversation, usually phrased as "can we keep this in-house". The answer is yes, and it is easier than it was two years ago. The useful part is knowing which hardware tier still counts as simple and where the expensive territory starts. #### Four hardware tiers | Tier | Memory | What fits | What it is enough for | |---|---|---|---| | Laptop or desktop, no card | 16-32 GB RAM | quantised models of 4-14 billion parameters | classification, text rewriting, simple extraction | | Desktop with a graphics card | 24-32 GB card memory | 30B models lightly compressed, 70B heavily | coding assistant, summarising, knowledge-base search | | Workstation, professional card | 96 GB with error correction | the same models, but running continuously | round-the-clock work without chasing results that drift | | Memory shared by processor and card | 128-512 GB | models that would otherwise need several cards | experiments with the largest open models | **An ordinary laptop or desktop, 16 to 32 GB of memory.** With no dedicated graphics card, this tier holds the quantised models from the first row of the table. They work, they produce a handful to a couple of dozen tokens per second on CPU, and they handle classification, text rewriting and simple field extraction from documents. OpenAI states that gpt-oss-20b runs within 16 GB of memory, which marks the ceiling of this tier fairly well. That throughput is often too slow for real-time conversation with a person and entirely sufficient for overnight batch processing. **A machine with a 24 to 32 GB graphics card.** A high-end consumer card offers 32 GB of its own memory and is the first tier where 30B-class models fit under light compression and 70B models under heavy compression. This is where genuinely useful work begins: coding assistance, summarising long documents, retrieval over an internal knowledge base. **A workstation with a professional card.** A professional card carries three times the memory of a consumer one and adds a mechanism that detects and corrects memory glitches on its own. The difference is not only capacity: that correction and vendor support start to matter once the machine runs around the clock and nobody wants to hunt down why a result occasionally comes out different. **Machines with large unified memory.** The Mac Studio with the M3 Ultra chip, introduced in March 2025, offered up to 512 GB of memory shared between the processor and the GPU (graphics processing unit), which meant it could hold models that would otherwise require several graphics cards. NVIDIA's DGX Spark applies the same idea on NVIDIA hardware, with 128 GB of coherent memory in a box the size of a hardback book. #### What to run it with The software layer is now simpler than the hardware. Most of the ecosystem grew on llama.cpp and the ggml library, with GGUF, the file format used to publish compressed models. Ollama reduces model startup to a single command and exposes an OpenAI-compatible API (application programming interface), so swapping providers inside an existing application often comes down to changing an endpoint. LM Studio offers comparable capability through a graphical interface with a built-in model browser, and suits people who do not work in a terminal. For serving several concurrent users, vLLM is the right tool, since it uses the card far more efficiently under parallel load. One licensing note that matters in a corporate context: llama.cpp, Ollama and vLLM are open, while LM Studio remains closed source. #### How much memory a model needs The rule of thumb good enough for planning rests on a single conversion: a model at full accuracy takes roughly two bytes per parameter, and compression divides that figure at a small cost in quality. | Variant | Bytes per parameter | 30 billion parameter model | |---|---|---| | full accuracy | approx. 2 | approx. 60 GB | | eight-bit | approx. 1 | approx. 30 GB | | four-bit | approx. 0.5 | approx. 15 GB | On top of the figure from the table comes the context cache, which grows with prompt length. This is the source of the most common planning mistake: the model fits the card on paper and stops fitting once several tens of thousands of context tokens are loaded. The second surprise concerns unified-memory machines. They hold plenty of memory, but processing a long prompt before the first output token takes noticeably longer on them than on a dedicated card. With short queries the difference is invisible. With a hundred-page contract it is impossible to miss. #### Power, heat and maintenance A high-end graphics card draws roughly 575 W under full load, the professional version 600 W, and the whole machine wants a power supply in the 1000 W class, about what an electric kettle pulls. A machine running eight hours a day across twenty working days consumes around 110 kWh. At the EU business average of EUR 18.37 per 100 kWh that comes to about EUR 20 a month.[^prad] Electricity rarely decides the outcome. The rest carries more weight. Six hundred watts released into a small room behaves like a heater, raising summer temperatures by several degrees and forcing a cooling decision. The fans under sustained load are audible all day. Someone has to update drivers, track model versions and respond when the service stops answering on a Friday afternoon. In a smaller company that someone usually already has a full set of other responsibilities, and that is a cost no hardware price list shows. #### Where the line against API sits Three situations where local inference holds up without stretching the argument: - Data that cannot leave the organisation's own infrastructure for contractual or regulatory reasons, with the caveat that a provider's commitments on processing region and zero retention are frequently sufficient, and worth checking before buying hardware. - High and steady volume of simple tasks: classification, field extraction from documents, embedding generation. Unit cost under constant load comes out clearly lower on local hardware. - Work without connectivity, or on a network isolated from the internet. In most other cases the arithmetic favours API. Assume a workstation costing 25 000 to 40 000 PLN amortised over three years: that comes to 700 to 1 100 PLN a month before anyone touches it, plus electricity, plus administrative time. If a team currently spends under roughly a thousand PLN a month on API, buying hardware will not pay back on cost alone, and there is a quality gap to accept as well. The best open-weight models are good, yet on tasks that demand extended reasoning they still trail the frontier models available through API. #### 2026 has moved the numbers The calculation is worth doing on current prices, because they have shifted sharply. Prices of DRAM (dynamic random-access memory) rose roughly 90% in the first quarter of 2026 compared with the end of 2025[^dram], as manufacturers redirected production toward AI data centres. The effects show up in the price lists of large unified-memory machines: the highest-capacity variants either cost more or leave the line-up, and a configuration priced a year ago costs something different today. A case that favoured owned hardware in 2025 often points the other way in 2026, so check the vendor's current price list before deciding, not a note from last quarter. #### A practical way in Start at the cheapest tier every time. Ollama or LM Studio on hardware the company already owns, one concrete process, two weeks of measuring output quality and response time. That experiment costs a few hours of work and settles more than weeks of specification debate. Only once it is clear that a model of that class actually does the job, and that volume justifies a dedicated machine, does a conversation about a several-thousand-euro card make sense. This piece reflects practical research into hardware and cost questions. [^dram]: Counterpoint Research, memory prices up to 90% higher than in the fourth quarter of 2025: . [^prad]: Eurostat, electricity prices for non-household consumers, second half of 2025: . --- ### How to Read AI Model Benchmarks Without Buying Marketing https://rsmanagement.ai/en/blog/how-to-read-ai-benchmarks/ Published: 2026-05-26 | updated: 2026-09-02 Training data contamination, label errors and version variance make model leaderboards misleading. How to build a test set on your own data instead. Conversations about switching models increasingly start with a printed leaderboard. Someone points at a table where the new model beats the incumbent by a few pp and asks whether that justifies a migration. An honest answer requires stepping back and asking where those pp came from. Benchmarks make sense as a research instrument. The trouble starts when a lab result lands on a sales slide and begins to pose as a forecast of how the model will handle a particular company's invoices, contracts or service tickets. Three mechanisms account for most of the gap between the two. #### Contamination: the answer key leaked Benchmarks get published on the internet. Training data gets collected from the internet. The rest of the story writes itself: the longer a test set circulates in public, the higher the chance a model has already seen the problems, or their solutions, during training. Scale AI put a number on this in May 2024. The team built GSM1k, 1,205 fresh grade school math problems[^gsm1k] matched to the widely used GSM8K set on difficulty, number of reasoning steps and problem length. The most overfitted model families lost up to low double digits in pp, while frontier models dropped far less. The conclusion is measured: an overfitted model can still solve novel problems, it simply performs worse than its public score promised. A similar story played out on SWE-bench Verified (software engineering benchmark), a set of 500 issues lifted straight from open source repositories that served for two years as the unofficial scoreboard for coding ability. In February 2026 OpenAI published its reasoning for no longer reporting results on that set: growing contamination combined with flaws in the tests themselves meant that differences at the top of the table stopped carrying information. It pointed instead to SWE-bench Pro, released by Scale AI in September 2025, where part of the task pool is deliberately held back from publication so that overfitting can be detected. At launch, the strongest models scored under 25% there.[^swebenchpro] For a buyer, the creation date of a test set matters as much as the score: a 2021 set, where frontier models have long been scraping the ceiling of the scale, mostly measures memorization. #### Benchmarks measure a different skill MMLU (Massive Multitask Language Understanding), for years the most quoted general knowledge test set, is roughly fourteen thousand multiple choice questions across 57 subjects. In 2024 a research team manually reviewed a sample of 5,700 of those questions[^mmluredux] and published a corrected version called MMLU-Redux. Their estimate is that around 6.5% of items contain errors[^mmluredux], ranging from a wrong answer key to ambiguous questions and items with several defensible answers. Some subjects were far worse, with more than half the reviewed virology questions found faulty. Filtering out the broken items was enough to reorder models in the rankings. Even with a perfect answer key, a heavier difference remains. Corporate work rarely arrives with four options to choose from. It looks more like twenty pages scanned at 2013 quality, industry jargon, internal abbreviations, a requirement to cite the source of every number, and consequences that only show up in the books weeks later. The ability to pick the right item from a list correlates with that work only partially. | Trap | How it shows | What to do before buying | |---|---|---| | Test set contamination | The score rises, the work does not | Check when the set was created | | Errors in the answer key | Rankings shift once corrected | Ask which version of the set was scored | | A different skill than the job needs | Multiple choice versus a 20-page scan | Build your own set from company documents | | Closed task pool | No way to detect overfitting | Prefer sets with a held-out portion | #### Variance: same model, different numbers The third mechanism tends to be the most underrated. A benchmark score describes the whole harness around the model as much as the model itself: system prompt, available tools, number of attempts, verification method, token budget. On agentic tasks that layer accounts for a very large share of the spread between published numbers, and it is often summarized in a single footnote. Then there is the question of who reported the result. Most entries on public leaderboards come from the vendors themselves and have never been independently reproduced. In April 2025 researchers from Cohere Labs, AI2 and several universities published an analysis titled "The Leaderboard Illusion", describing among other things the practice of testing many private model variants before release and showing only the best of them. Ahead of the Llama 4 launch the figure reported was 27 variants. The arena operators accepted some of the criticism and disputed other parts, but the selection effect is a problem the reader of a ranking is left holding. Models also change under a fixed name. A version update or a shift in default parameters can move behaviour on edge cases, which means last quarter's table describes a slightly different object. #### Your own test set beats leaderboards The alternative is less impressive looking and considerably more useful. We build it like this: - **Where cases come from**: thirty to sixty drawn from production work, including the hard and edge cases where the process usually stalls. Clean cases mainly measure the optimism of whoever assembled the set. - **Who defines the output**: the person who does this work daily, not the technical team. Without that, evaluation degenerates into an argument about taste. - **When criteria get written**: before anyone sees results. The order matters, because criteria added afterwards reliably confirm whatever conclusion was already preferred. - **The same harness**: identical prompt, identical tools, identical number of attempts for every candidate. Otherwise the comparison is between configurations rather than models. - **What we measure alongside quality**: cost and response time. A model two points better and four times more expensive rarely wins on an annual view. - **Where the set lives**: with us only. Publishing it to a public repository starts exactly the contamination cycle that spoiled the industry benchmarks. Building a set like this usually takes one to three days of work from someone who knows the domain. The compromise is obvious: fifty cases is a small sample, so differences of a few pp on it mean just as little as they do on a public board. What the set does reliably distinguish is whether a model copes with our documents or fails on them, and that is precisely the information a leaderboard cannot supply. #### Four questions before quoting When a table makes it into a meeting anyway, run it through a short filter. Who reported the score and whether anyone independent reproduced it. When the task set was created and whether it could already sit in training data. Whether a held out pool exists so that overfitting can be detected. How the harness is described: prompt, tools, number of attempts. A leaderboard is good enough to narrow a shortlist from twenty candidates to three. The decision about which of those three goes into production rests on our own data. [^swebenchpro]: Scale AI, SWE-Bench Pro, September 2025: . [^gsm1k]: Scale AI, "A Careful Examination of Large Language Model Performance on Grade School Arithmetic", May 2024: . [^mmluredux]: Gema et al., "Are We Done with MMLU?", 5,700-question sample, estimated 6.49% error rate: . --- ### Commercial AI APIs or Open Weights https://rsmanagement.ai/en/blog/open-source-vs-commercial-llms/ Published: 2026-05-12 When a commercial API model wins and when open weights win: data confidentiality, cost at scale, quality in non-English languages, version control. The commercial-versus-open question comes up in almost every deployment project, usually halfway through a workshop and usually framed as a matter of principle. The answer is rarely a matter of principle. It depends on what the model has to do, how often, whose data it touches and who carries the consequences when the output is wrong. #### Three operating models to compare In practice there are three distinct operating models, even though the discussion tends to assume two. The first is a commercial model available only through the vendor's API (application programming interface): the GPT, Claude and Gemini families. The second is an open-weights model running at an external hosting provider, where the weights are public but the infrastructure still belongs to somebody else. The third is an open-weights model running on hardware you own or in your own private cloud. | Dimension | Commercial API | Open weights, hosted | Open weights, self-run | |---|---|---|---| | Data confidentiality | Zero retention and an EU region in the contract | The infrastructure is still somebody else's | Data never leaves the network | | Cost at low volume | Lowest: pay for what you use | Medium | Highest: the hardware idles | | Cost at high steady volume | Rises linearly | Depends on the contract | Lowest at full utilisation | | Control over model versions | The vendor can retire a variant | Limited | Full | | Team effort | Close to zero | Small | Monitoring, maintenance, on-call | It is also worth separating "open source" from "open weights". Most open models publish weights and architecture, while the training corpus and training code stay closed. For business use that distinction matters mainly when auditing data provenance. #### Data confidentiality This is the most common reason open models enter the conversation, and also the argument made least precisely. Commercial vendors now offer zero-retention agreements, exclusion of customer data from training, and a choice of processing region inside the European Union, including through cloud platforms. For most corporate data that is sufficient protection and a much shorter path than building your own infrastructure. A locally hosted model wins where the constraint is hard: data covered by professional secrecy, medical records, material from legal proceedings, information that security policy forbids from leaving your own network even to a trusted processor. In those cases the benchmark discussion becomes secondary, because security policy fixes the deciding variable before anyone looks at the scores. #### Cost at scale This is where we most often find an error in the arithmetic. Open models carry no licence fee, but they do carry running costs. Renting a single H100-class accelerator costs roughly two to three dollars an hour at specialist GPU (graphics processing unit) clouds and noticeably more at large public cloud providers. Running one continuously therefore costs well over a thousand dollars a month in hardware alone, before engineering time, monitoring and maintenance. The hardware footprint can be smaller than intuition suggests. OpenAI states that gpt-oss-120b fits on a single 80 GB GPU and that gpt-oss-20b runs within 16 GB of memory, which puts it inside a well-specified workstation. Both are published under Apache 2.0. The consequence is straightforward. At low and irregular volume the API wins almost every time, because you pay only for what you use. The break-even point appears at high, predictable volume on repetitive work: ticket classification, field extraction from documents, first-pass summarisation. That is when a dedicated instance runs near full utilisation and the arithmetic changes. Before anyone signs off on a migration plan, count actual request volume from the last three months. #### Quality outside English This is where commercial models held their largest lead for years, and the lead is still visible on work that needs stylistic range: drafting correspondence, handling register and tone, working with legal text. The gap has narrowed considerably. The Qwen3 family is published under Apache 2.0 and claims support for 119 languages and dialects. Mistral, a French company, publishes both its flagship Mistral Large 3 and the smaller Ministral 3 series in 14B, 8B and 3B variants under Apache 2.0, which adds a European option on the jurisdiction side as well. National ecosystems are worth knowing too. In Poland, the Bielik model from the SpeakLeash foundation, developed with support from the Cyfronet AGH computing centre and released under Apache 2.0, is trained on Polish data and splits Polish text into billing units differently, so the same text costs less than it would on models trained mainly on English. Its 11B version arrived at the start of 2026. For comparisons there is SpeakLeash's Open PL LLM Leaderboard on Hugging Face, built on Polish NLP (natural language processing) tasks. It measures classification and reading comprehension, so we treat it as a signal with limited reach; it says little about editorial quality. Our recommendation is a private evaluation set: 50 to 100 cases taken from the business, scored by the people who do that work daily. #### Version control and continuity This dimension is underrated and can decide the whole question. An API vendor can retire a model version, change its behaviour or tighten content filters, and a process that passed validation starts returning different results. An open-weights model downloaded once behaves the same way a year later, as long as you maintain the environment. For systems under validation, audit or compliance documentation, that reproducibility is valuable in its own right. #### Licensing and liability Read the licence of an open model before anyone builds a product on it, because the families are not equally open. The Llama 4 licence contains this clause: "With respect to any multimodal models included in Llama 4, the rights granted under Section 1(a) of the Llama 4 Community License Agreement are not being granted to you if you are an individual domiciled in, or a company with a principal place of business in, the European Union." Since the entire Llama 4 family is natively multimodal, a company headquartered in the EU faces a legal barrier that has nothing to do with model quality. Apache 2.0, the licence behind Qwen3, Mistral Large 3 and gpt-oss, carries no such restriction. The other side of that dimension is liability. Buying an API also buys a contract, a service level, a support channel and an entity answerable for the service. Running an open model means taking all of that in house: availability, security updates, output quality and the consequences when quality slips. One regulatory note. The EU AI Act grants providers of general-purpose models released under free and open licences a limited exemption from some documentation obligations, conditional on weights and architecture being publicly available and the model not being monetised. The exemption does not extend to models with systemic risk, and the obligations covering copyright policy and the training-data summary remain in force. Deployer obligations apply regardless of whether the model is open. #### What we usually recommend In most organisations we work with, the answer settles into a mixed architecture. The commercial model handles work that needs the strongest language quality and the widest context. The open model, running locally, handles repetitive volume and data that cannot leave the network. Draw the line once, write it into policy, and review it quarterly, because both sides of this market move faster than an annual budget cycle. --- ### From POC to Production https://rsmanagement.ai/en/blog/from-poc-to-production/ Published: 2026-04-28 | updated: 2026-09-02 Most AI proofs of concept never reach production. Five differences that separate a pilot ending in a demo from one that ships. The prototype works. The demo runs without a stumble, the room asks good questions, someone says this will change how the whole department operates. Three months later nobody remembers where the link was. This pattern repeats often enough that it stops being bad luck for one team and starts being a property of how prototypes are run. #### How often this actually happens In July 2024 Gartner forecast that at least 30% of generative AI projects would be abandoned after the POC (proof of concept) stage, the prototype whose only job is to show that an idea can work at all, by the end of 2025.[^gartner] The reasons listed were poor data quality, inadequate risk controls, escalating costs and unclear business value. The forecast never received a public reckoning, so we treat it as a description of the mechanism rather than a measurement of the market. The direction matches what shows up in delivery work: the barrier rarely sits with the model. It sits in the parts of the work a prototype deliberately skipped in order to move faster. #### A definition of success written before the start The cheapest thing you can do for a prototype's chances takes half a page and happens before the first line of code. One metric, a numeric threshold, an agreed way of measuring it and the name of the person who signs off on the result. Instead of "let's see whether AI can handle document verification," the note reads: > Across 100 cases sampled at random from last quarter, extraction of the key fields must be correct in more than 90% of cases, and average verification time must drop from 14 minutes to under 5. Without that, the prototype ends in an argument about whether the output is good enough, and nobody wins that argument, because every participant is holding a different threshold in their head. There is a genuine trade-off here. At the start you often have no idea what threshold is even achievable. In that case, write a provisional threshold together with the date you will revise it. A number you expect to correct works better than no number at all. #### Production data, not a sample Prototypes are usually tested on data someone has already tidied up: clean scans, complete fields, typical cases. Production looks different. A scan rotated 90 degrees, two documents in one PDF, a handwritten note in the margin, a 2019 file in a template nobody uses any more, a field filled in a way no form anticipated. The practical rule is to sample at random from the real stream and keep the long tail of odd cases in the sample. A set hand-picked by someone who wants to show a working result tells you about that set and nothing more. If the data cannot leave the organisation, the prototype gets built inside the organisation's environment. Anonymisation and agreeing a lawful basis for processing take weeks, so that thread is worth starting in week one. Sometimes only synthetic data is available at the start. Treat the first result as a signal about technical feasibility and postpone the conversation about quality until a production sample exists. #### A business owner with skin in the game A sponsor who supports the initiative is not enough. What the prototype needs is an owner: someone whose numbers change if the solution works, who will allocate their people's time for acceptance testing and who has the authority to change the process. The test is simple. Whose figures in the quarterly report will look different. If the answer does not arrive within a few seconds, the prototype has no addressee. IT can build the solution and can run it, but it cannot accept a business outcome on behalf of someone who does not need that outcome. This single point explains a large share of abandoned prototypes. They were built out of technical curiosity, detached from a specific problem someone genuinely wanted solved. #### Security from day one Three questions belong at the start of a prototype rather than at the handover to production. Where does the data go and under which contract. Who has access to logs, prompts and outputs. Who maintains this in 18 months, and out of whose budget. A 30-minute conversation with security and legal in week one costs less than discovering in week eight that the chosen model provider will not clear a risk assessment. In regulated organisations, add system classification, a data protection impact assessment and documentation that has to survive an audit. Specific obligations are worth confirming with a qualified adviser. Maintenance gets skipped even more often than security. Model versions change, prompt quality degrades as input data shifts, integrations break. It is reasonable to assume a standing annual budget line for maintenance instead of treating deployment as a one-off cost. #### A scale-or-stop decision within weeks The decision date belongs in the scope document alongside everything else. A six to eight week window works well in practice, with three possible outcomes: scale, fix one specific element and repeat the measurement once, or close it down. Closing is a normal outcome and worth reporting as a measurement result, without attaching the label of team failure. The worst case is a prototype that drifts for six months until everyone quietly stops mentioning it. Nobody learns anything, and the organisation remembers only that AI did not work here. When closing, a one-page note earns its keep: what was tested, the result against the threshold, what would be done differently. Three of those notes after a year are worth more than one prototype that never received a verdict. #### What this adds up to All five points cost very little: a few conversations, one page of writing, one data sample and a decision date in the calendar. Skipping them saves a week at the start and routinely wipes out the value of the following three months of work. It is also worth starting from the problem before choosing the tool. If a successful prototype would not move a number that somebody cares about, the technical result stays a curiosity. [^gartner]: Gartner, 29 July 2024 prediction on generative AI projects abandoned after proof of concept: . --- ### Chatbots and Voicebots in a Large Organization https://rsmanagement.ai/en/blog/enterprise-chatbots-voicebots/ Published: 2026-04-14 What decides whether a chatbot or voicebot works at enterprise scale: knowledge quality, data separation, escalation paths and content upkeep. Chatbot and voicebot projects in large organizations rarely fail because of the language model. They fail on the things a demo never shows: the state of the knowledge base, who may see which answer, the moment a conversation hands over to a person, and whether anyone still maintains the content six months after launch. This follows from how these systems are built. The standard pattern is RAG (retrieval-augmented generation), where the bot first searches company documents for relevant passages and only then composes an answer from them. The model sits at the end of that chain. What follows is a delivery-side read on those challenges, and on the benefits that do show up. #### The knowledge base decides A bot answers only as well as the content it draws on. The starting position looks much the same across industries: the procedure exists in three versions in three places, usually SharePoint, the intranet and an email attachment, one document dates from 2019 and carries no expiry date, and the exception that matters most was agreed over email and never recorded anywhere. The model will not resolve that contradiction. It picks the passage that best matches the question and delivers it confidently. Two moves pay for themselves quickly. First, inventory the sources and designate one authoritative document per subject area before anything gets indexed. Second, build a control set of 100 to 200 questions with answers approved by the subject-matter owners, and run it as a regression test after every change to content, prompt or model. Without it, every change is a gamble and the quality drop gets noticed by a customer first. #### Data separation and permissions In a large organization the same question can have different correct answers depending on who is asking: one scope for a head-office employee, another for a franchise partner, another again for an external customer. The permission filter has to operate at the retrieval stage, before anything reaches the model. A prompt instruction such as "do not disclose internal information" is only a suggestion, and a politely phrased question usually gets around it. Microsoft 365 Copilot shows this most clearly: by design it surfaces only content the asker is already authorized to open.[^copilot] So it breaks no permissions. What it does expose is how broad those permissions were: a folder shared with the whole organization years ago becomes searchable with one plain-language question. The bot often turns out to be the first effective permissions audit a company has ever run, and it runs it after go-live. The practical minimum: separate indexes or hard role-based filters, logging that captures the retrieved passages and not only the final answer, and adversarial testing aimed at pulling content the asker should not see. Repeat that last one on a schedule; the model and the content both keep changing. #### Escalation to a person Handing a conversation to a person deserves to be treated as a first-class product feature. We design it with the service team and trigger it on a few clear signals: low retrieval confidence, two failed attempts at the same question, an explicit request from the caller, language that signals a complaint, and topics excluded by policy such as financial settlements, HR matters or safety. Two details decide how this lands. The agent should receive the full transcript and the context already gathered, so the customer does not start over. And escalation must never dead-end: outside working hours the bot opens a ticket and states a specific callback commitment, for example within 24 hours on business days. #### Measuring effectiveness Containment alone is a misleading headline metric: a conversation that ended is not necessarily a matter resolved. A sensible set includes: cases closed in the automated channel, with a written definition of what counts; the rate at which the same person returns to the same topic within 7 days; escalation rate broken down by cause; the share of "I do not know" responses; and a weekly manual review of a sample, say 50 conversations, done by someone from the first line. | Metric | What it measures | The trap | |---|---|---| | Cases closed in the automated channel | Channel effectiveness, provided it has a written definition | Without a definition everyone counts differently | | Return to the same topic within 7 days | Whether the case was actually resolved | A finished conversation is not a closed case | | Escalation rate broken down by cause | Where the system genuinely fails | The rate alone, without causes, says nothing | | Share of "I don't know" answers | Gaps in the knowledge base | A drop can mean guessing rather than knowing | | Manual review of a sample, around 50 conversations weekly | Quality the numbers cannot see | Costs time from someone on the front line | Benchmarks published by platform vendors span a very wide range and rarely define the metric, so comparing against them adds little. A baseline measured on the existing channel for a few weeks before launch is worth far more. #### Keeping the content alive This is the least glamorous part of the project and the one that decides the second year. Every knowledge area needs a named owner, a review rhythm, in practice once every 90 days, and an expiry date on the document, and the first line needs one click to flag a bad answer. Clustered by topic, the bot's own logs double as the best content backlog available: they show what people actually ask, in their own words and their own order of priority. #### Voice adds a layer of its own The voice channel inherits everything from chat and adds problems of its own. The ASR (automatic speech recognition) engine that turns speech into text stumbles exactly where it hurts most: surnames, addresses, contract numbers and product codes. Three things help: confirming critical data by spelling or keypad entry, feeding a dictionary of proper nouns and product codes to the recognizer, and tolerating partial recognition instead of forcing the caller to repeat themselves. Add barge-in and background noise in a store or warehouse. The latency budget deserves its own reference point: in human conversation the gap between turns has a median of 100 ms, and the averages across ten languages studied run from 7 ms for Japanese to 469 ms for Danish.[^tury] A bot that answers after a full second falls outside that whole range, and the caller hears it even without being able to name it. Voice is best launched after chat, on a narrower set of intents, once the knowledge base has proven itself in the easier channel. #### The upside sits in the volume The value rarely comes from complicated cases. It comes from the volume of simple ones, and those form a surprisingly short list: order status, access reset, opening hours and deadlines, where to find a document, how to complete a form. Taking that core off the first line frees capacity for conversations where a person genuinely adds something. The second benefit is availability in the evening, at night and at weekends, where staffing a shift 24 hours a day and 7 days a week would not pay for itself. The third is consistency. 40 people on the first line produce 40 variations; the bot answers identically every time. That cuts both ways: a content error repeats identically too, across the whole channel. The same property also means a correction takes effect immediately and everywhere. #### You must say it is AI From 2 August 2026, the transparency requirements in Article 50 of Regulation (EU) 2024/1689, known as the AI Act, begin to apply.[^aiact] Systems intended to interact directly with natural persons must be designed so that the person knows they are dealing with an AI system, and that information has to be given clearly and distinguishably at the latest at the first interaction. In practice: one sentence in the chat greeting, one in the voicebot greeting, an entry in the AI inventory. The specific scope of obligations is worth confirming with a legal adviser. #### An order of operations that holds up Pick one area with high volume and reasonably tidy content. Build the control set of questions before the first line of code. Design the escalation path with the service team, before any production traffic arrives. Measure the pre-launch baseline over 2 to 4 weeks. Then name the content owner and block time in that person's calendar. Organizations that follow this sequence launch more slowly and end up with a system that still answers correctly a year later. [^copilot]: Microsoft Learn, data protection architecture for Microsoft 365 Copilot, on access limited to content the asker is authorized to open: . [^tury]: Stivers et al., measurement of gaps between conversational turns across ten languages: . [^aiact]: Regulation (EU) 2024/1689, Article 50 on transparency obligations: . --- ### The EU AI Act Is Already Law https://rsmanagement.ai/en/blog/eu-ai-act-for-leaders/ Published: 2026-03-10 | updated: 2026-08-04 The EU AI Act is already in force. A practical guide for leaders in banking, pharma and energy on what changed, who is liable and where to start preparing. > **Update, August 2026.** The legal position has moved since this post was published: the transparency obligations of Article 50 started applying on 2 August 2026, and Regulation (EU) 2026/1744 postponed the high-risk deadlines to 2 December 2027 (Annex III) and 2 August 2028 (Annex I). The current timeline and takeaways are covered in [The AI Act after 2 August 2026](/en/blog/ai-act-after-2-august-2026/). The text below has been updated with the new dates. For most of the last few years, the EU AI Act was easy to file under "future regulation." It was being negotiated, then drafted, then finalized. That phase is over. The Act, formally Regulation (EU) 2024/1689, has been in force since August 2024. Its obligations are landing in stages rather than all at once. Several stages have already passed. For leadership teams in banking, pharmaceuticals, energy and other regulated sectors, the relevant question is no longer whether the Act applies. It is how ready the organization is for the obligations already active and the ones still ahead. Organizations should confirm specific obligations with qualified counsel. What follows is meant to help leaders ask the right questions and start preparing before enforcement catches up with them. #### What changed The Act does not switch on all at once. It phases in by obligation type, and the calendar now looks like this: the Regulation entered into force on 1 August 2024; prohibited practices and the baseline staff AI literacy duty (Article 4) have applied since 2 February 2025; obligations for general purpose AI models, supervisory authorities and penalties since 2 August 2025; and the transparency obligations of Article 50, including telling people they are interacting with an AI system, since 2 August 2026. The high-risk deadlines were postponed by Regulation (EU) 2026/1744 to 2 December 2027 for Annex III use cases and 2 August 2028 for AI embedded in regulated products under Annex I. Regulators keep publishing guidance on classifying high-risk systems: the enforcement infrastructure is being built now, and the postponement has not stopped it. The enforcement mechanism itself follows a structure many organizations already recognize from GDPR: tiered penalties, calculated as a fixed amount or a percentage of global annual turnover, whichever is higher, with the more serious violations sitting at the steeper end of that scale. For small and medium-sized enterprises and startups, the cap is the lower of the two amounts (Article 99(6)). The practical implication: some obligations are not sitting on a future deadline. They already apply. #### Who is affected A common misunderstanding is that AI regulation is a vendor's problem. It is not. The Act distinguishes between providers (the organizations that build AI systems) and deployers (the organizations that use them in a professional context). Deployer obligations exist separately from provider obligations. They cannot be delegated away by contract. Consider a bank using a third party model for credit scoring, a pharmaceutical company using AI in clinical or quality workflows and an energy company using AI for grid or asset management: each of these is a deployer in its own right. Buying a compliant tool from a reputable vendor does not automatically satisfy the buyer's own obligations around oversight, monitoring, incident reporting and risk management. Responsibility sits with whoever puts the system to use, not only with whoever built it. #### What high-risk means The Act organizes AI systems into risk categories rather than treating all AI the same way. At a high level: certain practices are prohibited outright, a defined set of use cases is treated as high-risk and subject to the strictest obligations, another set carries lighter transparency obligations and everything else falls into a minimal risk category with few binding requirements. | Category | What it covers | Weight of obligations | |---|---|---| | Prohibited practices | Uses excluded from the market | Absolute ban | | High risk | Employment, creditworthiness, critical infrastructure | Heaviest: oversight, documentation, logs | | Transparency obligations | Chatbots, synthetic content, deepfakes | Notification and marking | | Minimal risk | Everything else | Few binding requirements | High-risk is the category that matters most for regulated industries, because it typically covers systems used in employment decisions, creditworthiness assessment, critical infrastructure operation and other contexts where an AI system's output materially affects a person's rights or a company's safety obligations. Exactly which systems in a given organization qualify as high-risk and exactly when each obligation starts to apply depends on the specific system and how it is used. That classification exercise is not optional or informal. It deserves a documented process, ideally with input from both technical and legal stakeholders. #### The obligation most teams miss Article 4 of the Act introduces a requirement that gets far less attention than the risk categories: AI literacy. Organizations must ensure that staff and others operating AI systems on their behalf have a sufficient understanding of those systems to use them responsibly. This obligation already applies. It is not limited to high-risk systems. It is a baseline requirement across the board. For most organizations, this means AI literacy cannot stay an informal skill picked up on the job. It needs to become a documented training obligation, sized to the role and the system in question. #### What to do now None of this requires a finished compliance program by next quarter. It does require a starting point. The organizations furthest ahead right now are the ones that treated this as operational work rather than a legal filing exercise. A reasonable starting sequence: - Build an inventory of every AI system in use across the organization, including tools adopted informally by individual teams. - Classify each system against the Act's risk categories, with a named owner accountable for the decision. - Review the transparency documentation available from vendors of any general purpose AI used in production. - Establish documentation and audit trail habits for AI-assisted decisions, particularly anywhere the output touches people, money or safety. - Put an AI literacy program in place for staff who interact with these systems, sized to their role. None of these steps require a final legal opinion to begin. They require ownership, a working inventory and a willingness to treat AI governance as a standing function rather than a one-time project. #### Where this leaves you The organizations that handle this well will not be the ones scrambling once enforcement reaches their sector. They will be the ones that used this window to get their own house in order: a clear inventory, a defensible classification and documentation that would hold up under scrutiny. The current legal position after 2 August 2026, together with the new calendar and the implications for HR teams, is covered in [The AI Act after 2 August 2026](/en/blog/ai-act-after-2-august-2026/). RS Management advises leadership teams in banking, pharmaceuticals, energy and other regulated sectors on AI governance and compliance readiness. If your organization is weighing how exposed its current AI use is, [we would welcome a conversation](/en/#contact). --- ### When One AI Agent Stops Being Enough https://rsmanagement.ai/en/blog/agent-swarm/ Published: 2026-02-26 Why a single generalist AI agent breaks down as scope grows, and how a coordinated swarm of specialists restores quality, control and accountability. Most organizations that adopt AI agents start with one, asking it to plan, write, review, secure and document because that is simpler to set up and easier to explain to a board. It works well at a small scale. It becomes a liability once the scope grows: more systems, more files, more decisions running through the same narrow context window. This is not a prompting problem. It is an architecture problem, and it has a well-established answer: stop asking one agent to do everything, and build a small team of specialists coordinated by an orchestrator instead. The pattern is not niche. It is how the research system at Anthropic is built, with a lead agent distributing work across subagents.[^anthropic] #### The limits of one general-purpose agent A generalist agent holding the full context of a complex environment has to divide its attention across all of it on every task. As scope grows, so does the context the agent must hold, and quality tends to degrade in predictable ways. A bigger context window does not fix this on its own: models retrieve information from the start and the end of a long input far more reliably than from the middle, and the gap widens as the input grows.[^kontekst] Tasks take longer to complete. Output becomes inconsistent between similar requests. Checks that matter, such as security, GDPR compliance and documentation, happen only when someone remembers to ask for them, rather than on a fixed schedule. None of this means the underlying model is weak. It means the operating model around it is wrong. The same limitation shows up in human teams: one generalist cannot review code, audit security, manage a project and maintain documentation to the same standard as four people who do each of those things full time. #### Splitting work into specialist roles The fix is decomposition. Instead of one agent covering every concern, the work is split into a small number of scoped roles, each with a narrow mandate, a defined deliverable and its own quality bar. In our own delivery and research operations, we run this pattern with five roles. Each request goes first to the Planner, which decomposes it into tasks. Next comes the Reviewer, checking only for defects and standards violations. A security and risk auditor grades exposure. A cleanup role removes dead code and enforces hygiene. A documentation role keeps written material aligned with what was actually built.
An orchestrator splits the work across five specialised roles, whose output funnels into a single human acceptance point Orchestrator Planner splits the work Reviewer hunts defects Auditor weighs exposure Cleanup removes dead code Documentation keeps docs true Human acceptance point before a decision that cannot be undone
The five roles from our own delivery and research operations. Each has its own input, output and quality bar; the orchestrator decides the order.
##### Where the pattern applies beyond software The same logic extends well beyond engineering teams. A document processing pipeline can split into extraction, verification against rules and exception handling. A customer-facing assistant can split into intent handling, escalation and review of anything compliance-sensitive before it reaches a customer. A finance or procurement workflow can split into drafting, checking against policy and audit logging. In every case, the principle is the same: narrow the scope of each role until its output is easy to check. #### Orchestration, not autonomy A common misreading of this pattern is that it means deploying several autonomous bots that act independently. It does not. Each specialist is a scoped instruction set, a mode with its own constraints and output format, that a central orchestrator switches into depending on the task at hand. The orchestrator decides what happens next and which specialist handles it. Nothing runs unsupervised simply because it has a role label. This distinction matters most in regulated environments, where the AI Act requires human oversight of high-risk systems and "autonomous" is a word that invites scrutiny.[^nadzor] A well-designed swarm behaves like a structured workflow with AI performing each step, not like a collection of independent decision-makers. #### Where human acceptance points belong Splitting work into specialist roles carries a governance benefit that is easy to overlook: it makes human review points easier to place. A single agent that plans, builds and ships in one pass gives a reviewer one large, mixed output to check. A swarm produces a narrower, more legible output at each stage, so an acceptance point can sit exactly where a decision has consequences: before a security-relevant change goes live, before a customer-facing message is sent, before a document classification is finalized. For leadership teams accountable to a board, a regulator or an audit function, this is often the deciding factor over any raw efficiency argument. It is also the language AI management standards speak, ISO/IEC 42001 foremost among them: documented oversight counts, an assurance that the system is safe does not. The question is rarely whether AI can do the work. It is whether someone can explain, after the fact, what it did and why it was allowed to proceed. #### Cost and quality: what actually changes Splitting one agent into several specialists costs more than intuition suggests. Anthropic reports that a multi-agent system burns around 15 times more tokens than an ordinary chat, while measuring 90.2% better performance than a single agent on its own internal research eval.[^anthropic] The maths works out where the result is worth that gap, and against you on tasks a single agent closes on the first pass. The rest of the cost shifts earlier, into the design of roles, the handoffs between them and the orchestration logic that ties them together. That upfront investment buys a system that is easier to test, easier to audit and easier to improve one role at a time, without retraining or re-prompting an entire generalist agent every time one part of the process changes. The quality argument follows the same logic as with any specialized team. A reviewer whose only job is to catch defects catches more of them than a generalist doing five jobs in the same pass, simply because its attention is not divided. #### What costs the most on a first swarm The most expensive part turns out to be settling exactly what one role hands to the next. Model and orchestrator costs are secondary to it. As long as the planner output is a loose description, the reviewer receives something that cannot be checked mechanically, and the whole benefit of the split disappears: somebody is again reading everything and judging by eye. So a first swarm is worth building from the handover format rather than from the number of roles. Three things are enough to start: a named field for task scope, a named field for the acceptance criterion, and a slot for the verification result. Roles can be added later; the handover format is the hardest thing to change. The second trap is organisational. A swarm with five roles and a single human acceptance point at the very end delivers exactly what a general-purpose agent delivers, only at higher cost. The acceptance point belongs where the decision is irreversible, not where the run happens to finish. For leaders running AI beyond a single pilot, the question worth asking is not whether to add more AI, but whether the current architecture can support what the organization is already asking it to do. RS Management designs and builds multi-agent systems for clients and applies the same discipline to its own operations. If you are assessing whether your AI systems need this kind of restructuring, we welcome the conversation. [^anthropic]: Anthropic, description of its multi-agent research system with measurements of the gain over a single agent and of token usage: . [^kontekst]: Liu et al., measurement of model accuracy against the position of the relevant information in the context: . [^nadzor]: Regulation (EU) 2024/1689, Article 14 on human oversight of high-risk systems: . --- ### Model Routing https://rsmanagement.ai/en/blog/model-routing/ Published: 2026-02-25 A practical framework for deciding which AI model should handle which task, based on cost, latency and risk rather than habit. Every AI-assisted workflow contains a decision that rarely gets made on purpose: which model should handle this particular task. Most organizations answer it once, by default, and then stop thinking about it. That single unexamined habit quietly accounts for a large share of both AI overspend and avoidable latency. This is not one vendor's quirk: the Anthropic price list and the OpenAI price list are built the same way, in tiers of differing capability and differing cost per token. #### What model routing means Model routing is the practice of matching each task to the model whose capability, cost and speed fit that task, instead of sending every request to the most capable model available. It is a small idea with large consequences once an organization runs AI at any real volume: dozens or hundreds of requests a day across teams, tools and workflows. The default habit most people fall into is treating "best model" as synonymous with "right model." It rarely is. Asking an Opus-class model to summarize a status update or reformat a table is a bit like asking a senior architect to answer routine email: technically capable, but a poor use of judgment, time and budget. #### Where "always the best model" breaks Three factors make the default-to-premium habit expensive in practice. ##### Cost It helps to see the rates side by side, because the gap is smaller than intuition suggests and larger than any single invoice reveals. Between the cheapest tier and the flagship it is exactly 5 times.[^cennik] | Model tier | Input per 1M tokens | Output per 1M tokens | |---|---:|---:| | Fast (Claude Haiku 4.5) | 1 USD | 5 USD | | Mid (Claude Sonnet 5) | 2 USD | 10 USD | | Flagship (Claude Opus 5) | 5 USD | 25 USD | At individual scale this difference is invisible. At the scale of a team running thousands of requests a month, it grows into a line item you can see in the budget, mostly avoidable for routine tasks. ##### Latency Larger models generally take longer to respond. That difference is easy to ignore in a single chat window and impossible to ignore inside an agent that calls a model dozens of times to complete one task, or inside a customer-facing product where every extra second of delay measurably affects completion rates. ##### Quality that has nowhere to go For well-defined, low-ambiguity tasks, a frontier model's extra reasoning capacity does not translate into a better result. The task does not require it, so the additional intelligence goes unused, paid for but never delivered. Not having a routing policy is not a neutral choice. It is a default policy, and usually an expensive one. #### A three-tier framework Rather than deciding model by model, it helps to route by task shape: - **Routine tasks**: lookups, single-file edits, formatting, short status updates, first-draft generation from a template. High volume, low individual stakes, easy to check. These belong on Haiku-class models, including free tiers where available. - **Working tasks**: multi-file implementation, structured analysis, drafting substantive sections of a document, reasoning across several steps. This is where most of the actual day-to-day work sits, and where a solid mid-tier general-purpose model earns its cost. - **Strategic tasks**: system design, architecture and irreversible decisions, synthesis across long or ambiguous context, anything with financial, legal or reputational exposure. This is a small share of total volume and the one place where paying for frontier reasoning is worth it. The question worth asking before every task is not which model feels safest to default to, but what it costs to be wrong here, and whether the task calls for deep reasoning or simply competent execution. ##### When routing does not pay off Routing carries its own cost: somebody maintains the rules, watches whether they still match reality, and reacts when a vendor retires a model variant. That cost only repays itself once routine tasks make up a clear majority of volume and recur in recognisable shapes. At a few dozen requests a day, scattered across different kinds of work, the saving on model choice is smaller than the time spent maintaining the rules. The honest decision there is a single mid-tier model as the default, with deliberate reach for the frontier model where the stakes are high. The threshold to check before adopting routing is simple: how many requests from the past three months map onto repeatable task shapes. If the answer is "fewer than half", routing will cost more than it returns. | Task class | Examples | Model class | Cost of getting it wrong | |---|---|---|---| | Routine | Formatting, short status notes, first draft from a template | Fast and cheap, free tiers included | Low, verified immediately | | Working | Structured analysis, editing material passages, multi-step reasoning | A solid mid-tier model | Medium, surfaces at review | | Strategic | Architectural and irreversible decisions, synthesis of ambiguous context | Frontier model | High: financial, legal, reputational | #### From manual routing to automatic cascades Once the three tiers are defined, the routing decision does not need to depend on someone remembering to make it each time. A cascade architecture attempts the task on the fast, inexpensive model first, checks the result against a simple rule or a lightweight verification step and escalates only the cases that fail that check to a stronger model. At the rates in the table above the arithmetic is simple: every escalated case costs 5 times what a case handled in place costs, so a cascade only earns its keep once the cheap model closes a clear majority of traffic. This is the pattern worth building into production AI systems: routing stops being a habit an individual has to maintain and becomes a property of the system itself, applied consistently whether the request comes from an employee, an internal tool or a customer-facing agent. #### Where routing needs a governance layer Cost and latency are not the only variables in a regulated environment. Some tasks should run on the same validated model configuration every time, independent of price, because consistency and explainability matter more than savings: decisions that touch personal data within the meaning of GDPR, financial disclosures or safety, or that must be defensible to a regulator or an auditor after the fact. For those tasks, routing is not an efficiency question but a governance one. It belongs in written policy, reviewed on a schedule, with a human in the loop wherever a decision is difficult to reverse. #### Building a routing matrix for your organization A workable starting point rarely needs more than four steps: inventory the AI tasks teams actually run over a couple of weeks; classify them by stakes and reversibility rather than novelty; assign a default model tier to each category and write it down; and build explicit escalation rules for the exceptions instead of leaving the choice to whoever happens to be at the keyboard. Because model capability and pricing shift quickly, the matrix is worth revisiting on a quarterly basis. A routing policy set once and never revisited tends to become wrong within months. RS Management designs and implements these routing systems, from the initial task inventory to the production cascade, as part of our broader AI advisory and delivery work for executive teams and regulated organizations. If your organization is spending more on AI than the work actually requires, or would like a second, more critical opinion on how model choices are made today, [we would welcome a conversation](/en/#contact). [^cennik]: Anthropic, model pricing per million tokens: . ---