Lokalne AI, MCP i Revit: asystent BIM na własnym komputerze
Najciekawszy kierunek dla AI w BIM nie polega na tym, że model językowy napisze za projektanta kilka ogólnych zdań. Ciekawsze jest coś bardziej przyziemnego: lokalny model, który rozumie polecenie, lokalny serwer MCP, który wystawia kontrolowane narzędzia, oraz panel w Revit, który pokazuje co ma się wydarzyć z modelem, zanim cokolwiek zostanie zmienione.
To kierunek eksperymentalny, ale bardzo konkretny technicznie, bo łączy kilka światów: lokalne modele uruchamiane przez Ollama, Model Context Protocol, Revit API, dockable panel w dodatku Revit, Autodesk Platform Services, Autodesk Forma oraz starsze środowiska takie jak Revit 2024, Revit 2025, Revit 2026, Inventor czy inne narzędzia projektowe z własnym API.
W klasycznym dodatku do Revita użytkownik klika przycisk, wybiera opcje i uruchamia konkretną funkcję. W podejściu z AI zmienia się warstwa wejścia: użytkownik może napisać lub powiedzieć, czego chce, ale system nadal powinien działać na jasno opisanych narzędziach. AI nie powinno bezpośrednio „grzebać” w modelu. Powinno dobrać narzędzie, wypełnić argumenty, pokazać plan i dopiero po zgodzie uruchomić akcję.
Dlaczego lokalnie, a nie od razu w chmurze?
Lokalny model ma jedną mocną zaletę: może działać blisko danych projektowych, bez automatycznego wysyłania każdego promptu do zewnętrznej usługi. Ollama udostępnia lokalne API pod adresem `http://localhost:11434/api`, co pozwala pisać aplikacje, które rozmawiają z modelem podobnie jak z lokalnym serwerem. To nie znaczy, że temat prywatności znika. Nadal trzeba myśleć o logach, historii promptów, licencjach modeli, danych wprowadzanych przez użytkownika i tym, czy dany komputer ma prawo przetwarzać konkretne informacje.
W BIM lokalność jest szczególnie kusząca, bo modele projektowe bywają wrażliwe. Nie zawsze chodzi o tajemnice państwowe. Czasem wystarczy, że projekt jest objęty NDA, dotyczy inwestycji przemysłowej, infrastruktury, danych kosztowych albo wewnętrznego standardu firmy. Lokalny model może być dobrym pierwszym krokiem do eksperymentów, w których nie wysyłamy fragmentów modelu, nazw pomieszczeń, list elementów czy komentarzy koordynacyjnych do zewnętrznego API.
Trzeba jednak uczciwie powiedzieć: mały lokalny model nie będzie magicznie znał całego Revit API, wszystkich wyjątków projektowych i aktualnych reguł organizacji. Jego siłą nie musi być „wszechwiedza”. Jego siłą może być interpretacja intencji, wybór narzędzia i ułożenie odpowiedzi na podstawie danych, które dostanie z kontrolowanego serwera.
Czym MCP różni się od zwykłego API?
API to sposób komunikacji z konkretnym systemem: Revit, Autodesk Platform Services, bazą danych, plikiem, usługą firmową albo prostym skryptem. MCP, czyli Model Context Protocol, próbuje uporządkować warstwę pomiędzy modelem językowym a takimi narzędziami. W dokumentacji MCP pojawiają się trzy ważne role: host, client i server. Hostem może być aplikacja AI, klient utrzymuje połączenie z serwerem, a serwer wystawia zasoby, prompty i narzędzia.
Najważniejsze dla praktyki są narzędzia. Serwer MCP może powiedzieć modelowi: mam funkcję `read_selected_elements`, `list_views`, `check_missing_parameters`, `create_report`, `prepare_sheet_names` albo `get_forma_project_files`. Każde narzędzie powinno mieć nazwę, opis i schemat wejścia. Model nie musi znać wewnętrznego kodu. Musi zrozumieć, kiedy narzędzie pasuje do pytania użytkownika i jakie argumenty powinien przygotować.
To jest ogromna różnica jakościowa. Zamiast prosić AI: „zrób coś w Revit”, pokazujemy mu katalog bezpiecznych czynności. Model może wybierać z tego katalogu, ale katalog jest napisany przez człowieka. To tam ustala się granice: które narzędzia są tylko do odczytu, które mogą zmieniać model, które wymagają potwierdzenia, które zapisują log i które są dostępne tylko dla określonego projektu.
Dockable panel w Revit jako klient, a nie ozdobny chat
Panel dokowany w Revit może wyglądać jak chat, ale jego rola powinna być szersza. To nie musi być tylko okno do pisania promptów. Dobrze zaprojektowany panel powinien pokazywać: jaka jest aktualna selekcja, jakie narzędzie model chce wywołać, jakie argumenty zostały rozpoznane, jaki będzie zakres działania i czy operacja wymaga transakcji w Revit.
Revit API ma swoje zasady. Operacje zmieniające dokument muszą działać w odpowiednim kontekście aplikacji, najczęściej przez transakcje i mechanizmy takie jak `ExternalEvent`, jeśli żądanie wychodzi z interfejsu użytkownika. To ważne, bo AI nie powinno uruchamiać dowolnego kodu w losowym momencie. Panel może pełnić rolę bramki: przyjmuje wynik od MCP, zamienia go na bezpieczną komendę Revita i dopiero wtedy wykonuje ją w kontrolowanym zakresie.
W praktyce taki panel mógłby obsługiwać proste scenariusze: „pokaż elementy bez parametru branży”, „zrób raport widoków bez szablonu”, „sprawdź nazwy arkuszy”, „wypisz typy rodzin użyte w zaznaczeniu”, „przygotuj listę pomieszczeń bez numeru”, „znajdź koryta kablowe bez poziomu referencyjnego”. To są zadania, które nie wymagają od razu pełnej autonomii. Wymagają dobrej integracji odczytu, filtrowania i raportowania.
Najpierw narzędzia tylko do odczytu
Pierwsza wersja takiego systemu powinna być prawie całkowicie read-only. AI może pytać model, ale nie powinno go zmieniać. To daje przestrzeń na testowanie promptów, opisów narzędzi i jakości odpowiedzi bez ryzyka, że błędna interpretacja zepsuje dokument. Odczyt selekcji, parametrów, widoków, arkuszy, kategorii, typów i poziomów wystarczy, żeby zbudować wiele wartościowych funkcji.
Dopiero druga warstwa mogłaby tworzyć propozycje zmian. Nie „zmień model”, tylko „proponuję zmienić 37 elementów, w tym 12 ścian, 18 drzwi i 7 rodzin instalacyjnych; oto lista, oto wartości, oto powód”. Użytkownik powinien zobaczyć podgląd i móc odrzucić część operacji. Trzecia warstwa to dopiero kontrolowana transakcja.
Takie podejście jest mniej efektowne niż film, w którym AI samo modeluje budynek po jednym zdaniu. Ale jest bliższe realnej pracy projektowej. W modelu BIM odpowiedzialność nie znika tylko dlatego, że po drodze pojawia się model językowy.
Autodesk APS, Forma i dawne ACC jako warstwa danych
Revit to tylko jedna część ekosystemu. Coraz więcej danych projektowych żyje w chmurze: pliki, wersje, foldery, issues, pakiety, komentarze, modele opublikowane, dane z koordynacji, a także informacje związane z projektami i hubami. Autodesk Platform Services, dawniej kojarzone przez wielu z Forge, są warstwą API do pracy z tym ekosystemem. Autodesk opisuje Forma APIs jako sposób dostępu do danych projektowych, modeli, workflow budowlanych i integracji z narzędziami AECO.
W 2026 roku Autodesk komunikuje też zmianę nazewnictwa i kierunku: Autodesk Construction Cloud jest włączane w Autodesk Forma jako szerszy industry cloud dla AECO. W praktyce dla użytkownika ważne jest to, że nie chodzi tylko o „folder z plikami”. Chodzi o środowisko, w którym dane z projektowania, koordynacji, budowy i analiz mają być coraz bardziej połączone. Dla lokalnego asystenta AI oznacza to potencjalnie dodatkowy kontekst: nie tylko to, co jest otwarte w Revit, ale też to, co jest w hubie, projekcie, folderze, issue albo opublikowanej wersji modelu.
Przykład: użytkownik w Revit pyta panel, czy bieżący model odpowiada temu, co jest opublikowane w projekcie Forma/ACC. Lokalny panel nie musi sam znać całej chmury. Może przez MCP wywołać narzędzie, które pyta APS o listę projektów, folderów, wersji albo plików. Model językowy pomaga zrozumieć intencję, ale dane pochodzą z API, a nie z domysłów.
Nie tylko Revit 2027
Ten kierunek nie jest ograniczony do Revit 2027. Różne wersje Revita mają różne środowiska .NET i inne szczegóły techniczne, ale sama idea może działać także niżej: w Revit 2024, 2025 i 2026, jeśli dodatek zostanie przygotowany pod właściwą wersję API i runtime. W praktyce oznacza to osobne kompilacje, świadome zarządzanie zależnościami i ostrożność przy funkcjach, które pojawiły się dopiero w nowszych wersjach.
To samo myślenie można przenieść dalej: Inventor, Civil 3D, Navisworks, AutoCAD, narzędzia do kosztów, wewnętrzne bazy standardów, Excel, SharePoint, firmowe API. MCP jest interesujące właśnie dlatego, że pozwala myśleć o wielu narzędziach jako o zestawie kontrolowanych funkcji. Projektant nie musi pamiętać, czy dana informacja jest w Revit, w APS, w pliku CSV czy w firmowej bazie. System może mieć narzędzia do każdego z tych miejsc, ale nadal powinien jasno pokazywać, skąd pochodzą dane.
Co taki asystent mógłby robić w praktyce?
Najbardziej realistyczne pierwsze funkcje to nie automatyczne projektowanie, tylko porządkowanie pracy. Asystent może odpowiadać na pytania o model: ile elementów nie ma wymaganego parametru, które widoki nie mają szablonu, które arkusze mają niezgodne nazwy, które elementy są poza zakresem poziomu, które typy rodzin pojawiają się tylko raz, gdzie są puste wartości w zestawieniu.
Druga grupa to przygotowanie raportów. Zamiast ręcznie budować filtr, użytkownik pyta: „pokaż mi drzwi bez klasy odporności ogniowej w tym widoku”. Panel uruchamia narzędzie odczytu, zwraca listę i pozwala ją zapisać. Trzecia grupa to działania kontrolowane: nadanie parametru z listy, zmiana nazwy widoków według wzorca, utworzenie zestawu arkuszy, przygotowanie eksportu, wygenerowanie komentarza koordynacyjnego.
W chmurze APS/Forma dochodzą inne scenariusze: porównanie wersji pliku, sprawdzenie folderów, szybki opis paczki, przygotowanie listy plików do pobrania, raport z issue, podsumowanie aktywności projektu albo połączenie lokalnego modelu z informacją z huba. To może być szczególnie ciekawe dla BIM managerów, którzy nie chcą kolejnego dashboardu, tylko narzędzie pomagające szybciej dojść do konkretnej informacji.
Ryzyka: prompt injection, uprawnienia i fałszywa pewność
AI wpięte w narzędzia projektowe wymaga ostrożności. Jeżeli model może czytać komentarze, pliki, nazwy elementów albo dane z zewnątrz, może też trafić na treść, która próbuje wpłynąć na jego decyzję. W świecie LLM mówi się o prompt injection. W BIM może to wyglądać mniej spektakularnie, ale nadal jest realne: opis pliku, komentarz issue albo tekst w parametrze nie powinien móc przejąć kontroli nad narzędziem.
Dlatego granice muszą być po stronie narzędzi, nie tylko promptu. Narzędzie do odczytu nie może nagle zapisywać zmian. Narzędzie do zmiany parametru powinno znać dozwolone kategorie i wartości. Narzędzie do APS powinno działać na tokenie użytkownika albo jawnie opisanym zakresie uprawnień. Panel powinien logować akcje. Operacje masowe powinny wymagać potwierdzenia.
Drugie ryzyko to fałszywa pewność. Model może odpowiedzieć płynnie nawet wtedy, gdy nie ma danych. Dlatego dobry asystent BIM powinien często mówić: „nie wiem, muszę odczytać model”, „nie mam dostępu do tego huba”, „to jest wniosek z 12 elementów, nie z całego projektu”, „ta operacja wymaga potwierdzenia”. Taki komunikat jest mniej efektowny, ale dużo bardziej profesjonalny.
Jak powinien wyglądać pierwszy prototyp
Rozsądny pierwszy prototyp powinien być lokalny i bardzo wąski. Ollama działa jako lokalny serwer modelu. Mały model interpretuje polecenia. MCP server udostępnia kilka narzędzi: `get_selection_summary`, `list_active_view_elements`, `check_parameter_values`, `create_markdown_report`. Revit add-in z panelem dokowanym pokazuje rozmowę, wynik narzędzi i listę elementów. Na tym etapie model nie wykonuje automatycznych zmian w dokumencie.
Drugi krok to narzędzia z podglądem zmian, ale bez zapisu. Na przykład propozycja nowych nazw widoków albo wartości parametrów. Trzeci krok to transakcja po potwierdzeniu. Czwarty krok to APS: lista projektów, folderów, wersji plików albo issues. Dopiero gdy te warstwy są czytelne, można myśleć o bardziej ambitnych akcjach.
Największą wartością nie będzie sam chat. Wartością będzie połączenie języka naturalnego z prawdziwym kontekstem: zaznaczeniem w modelu, aktywnym widokiem, parametrami, standardem biura, folderem w Forma/ACC, wersją pliku, listą błędów i historią decyzji. Dopiero wtedy AI zaczyna być narzędziem BIM, a nie tylko oknem do pisania ogólnych pytań.
Podsumowanie
Lokalne AI z MCP może być spokojnym, technicznym kierunkiem rozwoju narzędzi BIM. Nie tylko dla Revit 2027, ale także dla niższych wersji Revita, Inventora i innych aplikacji projektowych, o ile mają API albo dają się połączyć przez kontrolowaną warstwę narzędzi. W połączeniu z APS i Autodesk Forma, czyli następcą dawnego rozumienia ACC jako osobnej chmury budowlanej, taki system może łączyć lokalny model, chmurę projektową, standard biura i decyzje użytkownika.
Najważniejsze jest jednak, żeby nie oddać modelowi językowemu odpowiedzialności za projekt. AI może pomóc znaleźć dane, uruchomić narzędzie, przygotować raport, zaproponować zmianę i wyjaśnić wynik. Ale w BIM nadal liczy się kontrola: kto pyta, z jakich danych korzysta, jakie narzędzie zostało wywołane, co ma zostać zmienione i kto to zatwierdził.