Asystent AI w biurze konstrukcyjnym: szybciej i bez wycieku wiedzy
AI nie zaprojektuje za was detalu i nie zastąpi konstruktora. Robi jedną rzecz, która realnie odciąża biuro: przejmuje żmudną pracę z tekstem i dokumentem (szukanie w dokumentacji, wstępne opisy i specyfikacje, tłumaczenia, kontrola kompletności), pracując na własnej dokumentacji firmy. Efekt uboczny jest równie ważny jak główny: skoro ten sam problem, dla którego konstruktorzy wklejali treść do publicznych czatów, rozwiązuje narzędzie wewnętrzne, dane przestają wyciekać. To działa pod jednym warunkiem: wynik zawsze przechodzi przez człowieka, zanim trafi do klienta albo na produkcję.
Dla kogo: kierownicy biur konstrukcyjnych i technologicznych, właściciele firm produkcyjnych rozważający AI w obszarze inżynieryjnym, osoby odpowiedzialne za bezpieczeństwo wiedzy technicznej.
Kontekst
Praca w biurze konstrukcyjnym to w dużej części praca z tekstem i dokumentem: opisy techniczne, noty do rysunków, specyfikacje, listy materiałowe, korespondencja z klientem, tłumaczenia. To dokładnie te zadania, w których publiczne modele językowe są najbardziej kuszące, bo skracają godzinę pracy do kilku minut. Do tego dochodzą trzy rzeczy, które robią z tego obszaru trudny grunt pod automatyzację: znaczna część wiedzy inżynierskiej jest niepisana i siedzi w głowach dwóch, trzech doświadczonych osób, dane wejściowe bywają chaotyczne (skan PDF, zdjęcie z telefonu, szkic odręczny), a koszt pomyłki jest wysoki, bo błąd w wymiarze kończy się źle wykonanym detalem i reklamacją. W tej rzeczywistości shadow AI, czyli korzystanie z publicznych narzędzi poza wiedzą działu IT, pojawia się sam. Konstruktor pod presją terminu wkleja opis, mail od klienta albo fragment dokumentacji do darmowego czatu, bo to najszybsza droga do wyniku. Ta strona opisuje jeden workflow, który odpowiada na obie sprawy naraz: odciąża konstruktora w tych samych żmudnych zadaniach i jednocześnie sprawia, że dane nie muszą wychodzić z firmy.
Problem
Dwa problemy są tu splecione i dlatego rozwiązywanie ich osobno zawodzi. Pierwszy to koszt czasu. Konstruktor spędza zaskakująco dużo godzin na szukaniu (w której normie jest ten zapis, jak rozwiązaliśmy podobny węzeł trzy lata temu, gdzie leży karta katalogowa profilu) oraz na pisaniu powtarzalnych dokumentów od zera. To praca żmudna, nisko twórcza i łatwa do odłożenia pod presją, więc kontrola kompletności bywa odpuszczana jako pierwsza. Drugi to wyciek wiedzy przez shadow AI. Kiedy konstruktor wkleja problem do publicznego narzędzia, rzadko wkleja sam plik. Wkleja kontekst: do czego to służy, jaki materiał, jakie wymaganie klienta, czego nie udało się rozwiązać wcześniej. To jest właśnie know-how firmy, a nie geometria, którą i tak dałoby się odtworzyć z gotowego wyrobu. Drugim wrażliwym strumieniem są dane klienta w treści zapytania: nazwa odbiorcy, warunki handlowe, mail wklejony w całości. Zakaz wpisany do regulaminu tego nie zatrzyma, bo nie usuwa powodu, dla którego ludzie sięgają po te narzędzia. Zmienia tylko jedno: pracownik przestaje o tym mówić, a zjawisko schodzi głębiej.
Rozwiązanie
Zamiast zakazu, zastąpienie. Skoro ludzie sięgają po publiczne AI, bo rozwiązuje realne zadanie, trzeba dać im narzędzie, które rozwiązuje to samo zadanie bez wyprowadzania danych na zewnątrz. W praktyce to kontrolowany asystent AI wpięty w firmowe repozytorium dokumentów, działający w modelu retrieval-augmented generation (RAG) nad własną dokumentacją: normami, kartami katalogowymi, historią projektów, wcześniejszymi opisami i specyfikacjami. Taki asystent robi cztery rzeczy, które realnie działają dziś w polskich realiach, pod warunkiem rozsądnego zakresu: szuka i streszcza dokumentację z podaniem źródła, przygotowuje pierwszą wersję opisów, specyfikacji i tłumaczeń na bazie danych projektu, sprawdza kompletność i spójność (czy rysunek ma wszystkie widoki, czy zestawienie zgadza się z modelem), oraz pomaga wyciągnąć z dokumentacji parametry do wstępnej wyceny. Wspólny mianownik jest zawsze ten sam: AI przygotowuje, porządkuje i podpowiada, a decyzję i odpowiedzialność zachowuje człowiek. Kluczowe jest to, że treść nie opuszcza infrastruktury firmy, więc znika powód, dla którego konstruktor sięgał po publiczne narzędzie. Kiedy wewnętrzny asystent jest co najmniej tak wygodny jak publiczny, motywacja do obchodzenia zasad znika sama.
Jak to działa (workflow)
1. **Konstruktor zadaje pytanie albo zleca zadanie.** „Znajdź, jak rozwiązaliśmy podobny węzeł", „przygotuj opis techniczny do tej oferty", „sprawdź, czy ten komplet jest kompletny". Punktem wejścia jest normalna, codzienna czynność, nie osobny system do obsługi. 2. **Asystent przeszukuje firmowe repozytorium (RAG).** Model wyciąga z własnej dokumentacji najbardziej pokrewne fragmenty: normy, karty katalogowe, poprzednie projekty i opisy, i podaje źródło, do którego można zajrzeć. To retrieval decyduje o jakości, nie sam model. 3. **Przygotowuje pierwszą wersję.** Na bazie znalezionych danych szkicuje opis, specyfikację albo tłumaczenie, albo zestawia listę braków po kontroli kompletności. Konstruktor dostaje punkt startu zamiast pustej kartki. 4. **Sygnalizuje niepewność.** Gdy dane wejściowe są kiepskie albo niekompletne, dojrzały asystent zaznacza, czego brakuje, zamiast zmyślać wymiar, którego nie ma na rysunku. 5. **Człowiek weryfikuje i zatwierdza.** Konstruktor koryguje wynik, odrzuca fałszywe tropy i bierze odpowiedzialność za treść, która idzie dalej. AI zawęża, człowiek rozstrzyga. 6. **Dane zostają w firmie, a zatwierdzone dokumenty zasilają repozytorium.** Nic nie wychodzi na zewnątrz, a kolejne zamknięte projekty poprawiają jakość podpowiedzi dla następnych. Pętla się domyka, a kanał shadow AI traci rację bytu.
Dlaczego biuro konstrukcyjne jest trudne, a mimo to warte
Automatyzacja lubi zadania powtarzalne, dobrze udokumentowane i z jasnym kryterium poprawności. Biuro konstrukcyjne łamie wszystkie trzy warunki: wiedza jest w dużej części niepisana, dane wejściowe bywają chaotyczne, a koszt błędu wysoki. Wniosek nie jest taki, że AI nie ma tu sensu, tylko taki, że sensowne wdrożenie celuje w konkretne, dobrze ograniczone zadania, a nie w „zastąpienie konstruktora". Paradoksalnie to samo, co czyni biuro trudnym gruntem pod pełną automatyzację, czyni je świetnym gruntem pod asystenta: dużo pracy z tekstem i dużo rozproszonej wiedzy, którą warto szybko odnaleźć.
Co taki asystent realnie automatyzuje
Cztery zastosowania działają dziś, pod warunkiem rozsądnego zakresu i konstruktora trzymającego rękę na pulsie. Wyszukiwanie i streszczanie dokumentacji skraca kwadranse szukania do kilkunastu sekund i podaje źródło. Wstępne generowanie opisów, specyfikacji i tłumaczeń zamienia pisanie od zera na korektę pierwszej wersji. Sprawdzanie kompletności i spójności wyłapuje braki, które człowiek odpuszcza pod presją czasu, bo narzędzie nie męczy się przy dwudziestym rysunku. Pomoc przy wstępnej wycenie wyciąga z dokumentacji parametry do oszacowania pracochłonności i materiału, dając ofertowaniu punkt startu. Więcej o tym ostatnim w nocie o przejściu z rysunku technicznego do wyceny, a o tym, co kontrola dokumentacji faktycznie wychwytuje, w AI w kontroli jakości dokumentacji technicznej.
Co AI tylko obiecuje
Kilka obietnic dobrze wygląda na slajdzie i wypada na starannie dobranym przykładzie, ale w codziennej pracy biura się jeszcze nie broni. Generowanie gotowego modelu 3D z jednego zdania działa na prostych bryłach, nie na realnym detalu z tolerancjami i historią decyzji. Pełna automatyczna interpretacja dowolnego rysunku to co innego niż odczyt skanu z odręcznymi dopiskami i wymiarami w trzech konwencjach. Samodzielne wariantowanie pod nowego klienta rozbija się o reguły, których nikt nie spisał. Mechanizm jest zawsze ten sam: demo pokazuje najlepszy możliwy przypadek na danych przygotowanych pod pokaz, a wartość narzędzia zależy od tego, jak radzi sobie z waszym najbardziej typowym bałaganem.
Gdzie naprawdę wycieka wiedza i dlaczego zakaz nie działa
Warto oddzielić ryzyko realne od wyobrażonego. Najczęstszy i najbardziej niedoceniany wyciek to nie pojedynczy rysunek, tylko kontekst: do czego to służy, jaki materiał, jakie wymaganie klienta, czego nie udało się rozwiązać wcześniej. Drugi wrażliwy strumień to dane klienta w treści zapytania, gdzie ryzyko jest podwójne, własne i kontraktowe. Sama geometria czy pojedynczy wymiar są najczęściej wyolbrzymiane, bo i tak są odczytywalne z fizycznego detalu.
Typowa pierwsza reakcja, czyli zakaz w regulaminie, adresuje objaw, nie przyczynę. Konstruktor nie sięga po publiczne AI z lekceważenia, tylko dlatego, że ma realne zadanie i narzędzie, które je skraca. Zakaz nie zmienia ani zadania, ani presji czasu, zmienia tylko to, że pracownik przestaje o tym mówić. Dlatego skuteczna reakcja to zastąpienie, nie zakaz: wewnętrzny asystent, który rozwiązuje ten sam problem bez wyprowadzania danych, plus krótka, zrozumiała zasada, co wolno wkleić, a czego nie. Czy taki asystent lepiej zbudować, czy kupić, rozłożyliśmy w porównaniu build vs buy, a mechanizm bezpiecznej pracy na własnej dokumentacji w nocie RAG do dokumentacji technicznej.
Jak ocenić ofertę bez marketingu
Przed decyzją warto zadać dostawcy cztery pytania. Na jakich danych mam to przetestować, przy czym dobra odpowiedź to wasze własne, typowe rysunki i dokumenty, łącznie z tymi brzydkimi. Gdzie kończy się automat, a zaczyna człowiek, bo uczciwie zaznaczony punkt zatwierdzenia jest bardziej wiarygodny niż obietnica pełnej autonomii. Co się dzieje, gdy dane wejściowe są kiepskie, bo dojrzałe narzędzie sygnalizuje niepewność, zamiast zmyślać. I gdzie zostają nasze dane, bo w biurze konstrukcyjnym dokumentacja to często rdzeń przewagi firmy. Ten sam porządek pytań wraca u nas przy dziesięciu pytaniach przed RFP.
Od czego zacząć
Najrozsądniejsza pierwsza decyzja to nie wybór narzędzia, tylko wybór jednego, wąskiego zadania, które boli najbardziej i daje się zmierzyć. Wyszukiwanie w dokumentacji albo wstępne opisy techniczne to dobry początek, bo ryzyko jest niskie, a efekt widać w tygodniach. Jeśli nie wiecie, czy firma jest gotowa na taki krok, zacznijcie od pięciu pytań o gotowość do AI. Szerszy obraz zastosowań, z kolejnością wdrażania, daje przewodnik o pięciu workflowach AI w polskiej produkcji.
Czego ta strona nie pokrywa
To opis jednego workflow i jego granic, nie instrukcja wdrożenia ani porównanie narzędzi po nazwie. Nie wchodzimy w konfigurację techniczną, formaty plików ani wymagania sprzętowe. Nie rozstrzygamy on-prem kontra chmura, choć w biurze konstrukcyjnym wymóg zachowania danych u siebie bywa twardy (to osobny temat, który rozłożyliśmy w porównaniu on-prem czy chmura). Nie podajemy liczb typu „o ile szybciej" ani kwot oszczędności, bo zależą od waszego punktu wyjścia. Nie omawiamy też obowiązków regulacyjnych, to osobna ścieżka.
Powiązane
- Pięć workflowów AI, które już dziś amortyzują się w polskiej produkcji
- Drawing-to-offer AI: z rysunku technicznego do wyceny
- RAG do dokumentacji technicznej: jak AI korzysta z DTR i instrukcji maszyn
- Build vs buy AI dla fabryki: zbudować własne czy kupić gotowe
- Jak ocenić gotowość firmy produkcyjnej do wdrożenia AI: 5 pytań