,

Lovable wycenione na 13,3 mld USD: Ryzyka i koszty wdrożenia AI w architekturze korporacyjnej

Szwedzka spółka Lovable, twórca platformy vibe-coding, pozyskała 400 mln USD finansowania, podwajając swoją wycenę do 13,3 mld USD w osiem miesięcy. Inwestycja, w której uczestniczy Komisja Europejska, sygnalizuje systemową zmianę w sposobie wytwarzania oprogramowania, ale audyty bezpieczeństwa wskazują na krytyczne luki w izolacji danych w aplikacjach budowanych przez AI.

Finansowanie i „Build Economy”: Skala zjawiska

Szwedzki startup Lovable, założony w 2023 roku przez Antona Osikę i Fabiana Hedina, zabezpieczył rundę Series C o wartości 400 mln USD. Wycena spółki wzrosła z 6,6 mld USD w grudniu 2025 roku do 13,3 mld USD w sierpniu 2026 roku. Spółka deklaruje roczne powtarzalne przychody (ARR) na poziomie 500 mln USD, dążąc do 600 mln USD przed końcem sierpnia 2026 roku. Skala operacji jest bezprecedensowa: na platformie powstało ponad 60 mln projektów, które generują 900 mln wizyt miesięcznie.

Kluczowe wskaźniki i podmioty rundy Series C: Wycena: 13,3 mld USD. Kapitał: 400 mln USD. Liderzy rundy: Menlo Ventures oraz zarządzany przez EQT unijny fundusz Scaleup Europe Fund. Przychód na pracownika: 2,77 mln USD ARR (przy 146 pracownikach w czerwcu 2026). * Główni klienci: Nvidia, Adidas, Deutsche Telekom, Zendesk, Hearst, Checkr, Handshake.

Wejście Komisji Europejskiej do akcjonariatu poprzez wart 5 mld EUR fundusz Scaleup Europe Fund ma na celu przeciwdziałanie migracji europejskich czemponów technologicznych na giełdy w USA. Dla architekta IT istotny jest fakt, że 80% twórców na platformie to osoby nietechniczne, co przesuwa ciężar odpowiedzialności za standardy inżynieryjne z dewelopera na samą platformę i procesy nadzoru.

Mechanizm technologiczny i wydajność inferencji

Platforma Lovable opiera się na koncepcji vibe-coding, umożliwiając budowę systemów poprzez komendy w języku naturalnym. Architektura rozwiązania jest celowo niezależna od modeli (model-independent), co pozwala na dynamiczne przełączanie się między dostawcami (np. Anthropic, OpenAI, modele open-source) w zależności od specyfiki zadania i kosztu tokenów. W sierpniu 2026 roku firma ogłosiła partnerstwo z Cerebras Systems, wykorzystując platformę inferencyjną Wafer-Scale Engine do eliminacji opóźnień w wieloetapowych przepływach pracy AI.

Wydajność i integracje platformy: Infrastruktura: Współpraca z Cerebras umożliwia niemal natychmiastową generację tokenów w obciążeniach typu decode-bound. Ekosystem: Głęboką integrację z Google Workspace, Microsoft 365, Salesforce, Stripe oraz ElevenLabs. Baza danych: Standardowe połączenie z platformą Supabase, wykorzystującą PostgreSQL. Zgodność: Uzyskanie certyfikatu AIUC-1, będącego standardem bezpieczeństwa dla agentów AI.

Mimo imponującej szybkości prototypowania (przypadek firmy Nursa, która przebudowała platformę 12-krotnie szybciej), dyrektorzy produktu, tacy jak Jorge Luthe z Zendesk, ostrzegają, że narzędzia te mogą jeszcze nie zapewniać poziomu niezawodności wymaganego przy masowej obsłudze wielokanałowych żądań klientów.

Krytyczne ryzyka bezpieczeństwa i audyt kodu

Dla specjalistów ds. bezpieczeństwa kluczowe są wyniki audytu AxonBuild z lata 2026 roku, który objął 21 aplikacji zbudowanych przez AI. W 9 z nich wykryto luki w mechanizmie Row-Level Security (RLS), a w 7 przypadkach potwierdzono ścieżkę pozwalającą jednemu zalogowanemu użytkownikowi na odczyt lub modyfikację danych innego użytkownika. Problem nie leży w samej technologii Supabase/PostgreSQL, ale w błędnej konfiguracji polis, które często ograniczają dostęp do osób „zalogowanych”, zamiast do „właściciela rekordu”.

Zidentyfikowane wektory ataku i uchybienia: 1. Wyciek kluczy „service_role”: Umieszczenie klucza serwisowego w kodzie frontendowym (browser bundle) całkowicie omija polisy RLS i daje pełny dostęp do bazy danych. 2. Luki w funkcjach RPC: Funkcje typu `security definer` uruchamiane z uprawnieniami twórcy, które przyjmują `user_id` jako argument bez weryfikacji tożsamości wywołującego. 3. Brak bram deploja: 17 z 21 audytowanych aplikacji nie posiadało żadnych mechanizmów kontroli wdrożenia (deploy gate) ani monitoringu błędów. 4. Ataki „denial-of-wallet”: W 12 z 14 aplikacji z funkcjami AI, niezalogowani użytkownicy mogli generować koszty po stronie właściciela poprzez nadużywanie otwartych punktów końcowych.

Historyczne dane wskazują na powtarzalność problemów: w maju 2025 r. badacz Matt Palmer znalazł 303 wystawione punkty końcowe w 170 projektach Lovable, co doprowadziło do wycieku danych osobowych i kluczy do usług zewnętrznych. W odpowiedzi Lovable wprowadziło polisę ubezpieczeniową od Lloyd’s oraz zautomatyzowane skanowanie bezpieczeństwa.

Koszty wdrożenia i parametry „Production Ready”

Osiągnięcie statusu gotowości produkcyjnej dla aplikacji z Lovable nie jest natychmiastowe i wymaga od 2 do 8 tygodni pracy inżynieryjnej. Platforma oferuje dwa rodzaje skanów: Basic scan (10-15 sekund, sprawdza zależności i schemat) oraz Deep scan (ok. 4 minuty, agentowy przegląd kodu pod kątem wycieków sekretów i błędów RLS). Jednak same skany nie gwarantują poprawnej logiki biznesowej ani izolacji kont.

Tabela 1: Szacowany czas doprowadzenia aplikacji do stanu produkcyjnego

Typ aplikacji Czas pracy Kluczowe działania
Single-tenant CRUD (bez płatności) 2–14 dni Poprawa polis RLS, czyszczenie sekretów, testy odzyskiwania.
Multi-role z płatnościami i danymi live 4–8 tygodni Walidacja webhooków, idempotentność płatności, izolacja ról.
Systemy z migracją danych +1–2 tygodnie Opracowanie planów rollback i migracji schematu.

Architekci muszą brać pod uwagę ograniczenia hostingu Lovable: brak natywnego mechanizmu rollback w panelu oraz fakt, że każdy „publish” to statyczna migawka. Rozwiązaniem zalecanym jest aktywacja GitHub Sync, co umożliwia dwukierunkową synchronizację kodu i wdrożenie własnego potoku CI/CD (np. na Vercel, Netlify lub Cloudflare), co daje kontrolę nad historią wersji i podglądem gałęzi (preview builds).

Wnioski praktyczne i rekomendacje

Wnioski praktyczne i rekomendacje

  • Skonfiguruj GitHub Sync jako pierwszy krok po stworzeniu prototypu, aby uzyskać dostęp do historii wersji, mechanizmów rollback i możliwości audytu kodu poza edytorem platformy.
  • Uruchom Deep Scan w projekcie i zweryfikuj wszystkie krytyczne znaleziska; nie polegaj wyłącznie na automatycznym skanie Basic, który uruchamia się podczas publikacji.
  • Zweryfikuj izolację danych poprzez prosty test behawioralny: zaloguj się na dwa różne konta i spróbuj odpytać API o rekordy pierwszego konta, używając tokena drugiego użytkownika.
  • Przeskanuj bundle JavaScript w przeglądarce pod kątem ciągów znaków takich jak `service_role`, `sk_` czy `key_`; każdy znaleziony tam sekret wymaga natychmiastowej rotacji, ponieważ jest dostępny publicznie.
  • Weryfikuj funkcje typu security definer w bazie danych PostgreSQL; upewnij się, że nie przyjmują one identyfikatora użytkownika jako prostego argumentu, który można zmanipulować bez sprawdzenia `auth.uid()`.
  • Zaimplementuj limity żądań (rate limiting) na poziomie serwera dla wszystkich akcji generujących koszty (AI, e-mail, płatności), aby zapobiec atakom typu denial-of-wallet.
  • Wdróż monitoring błędów (np. Sentry) poza systemem logów platformy, aby maintainer miał wgląd w błędy runtime, których użytkownik nietechniczny nie zgłosi.
  • Przetestuj procedurę odzyskiwania danych poprzez przywrócenie backupu do osobnego projektu i wykonanie pełnego cyklu testowego kluczowego procesu biznesowego.

Źródła

Przemysław Majdak

Przemysław Majdak · AI Automation Engineer

Założyciel Baluarte i wydawca BitBiz.pl. Członek ISSA Polska. Ekspert z 18-letnim stażem w branży IT — wdraża bezpieczne automatyzacje AI, systemy full-stack i zaawansowane procedury cyberbezpieczeństwa dla firm. Wszystkie artykuły autora →

Jedna odpowiedź

💬 Kliknij tutaj, aby dodać komentarz

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Wymagane pola są oznaczone *

  1. Awatar Wiktor

    Za każdą aplikacją zbudowaną przez AI stoi ktoś, kto odpowiada za wyciek danych – i to nie jest Lovable.