AI diligence
Jak sprawdzić claimy AI w data roomie
To nie jest porada prawna. To memo decyzyjne o systemach, danych, ryzyku wdrożeniowym i pytaniach, które warto zabrać do zarządu, prawnika albo dostawcy.
Krótka odpowiedź
Claim AI w data roomie jest użyteczny tylko wtedy, gdy da się go połączyć z systemem, danymi, procesem review, kosztami i odpowiedzialnością. Sam deck, demo albo nazwa modelu nie wystarcza do decyzji inwestycyjnej.
Dobre diligence dzieli claimy na realne, warunkowe, niesprawdzone i ryzykowne. Dzięki temu zarząd lub inwestor wie, co można uwzględnić w tezie, a co wymaga pytania uzupełniającego, korekty wyceny albo zatrzymania.
Kiedy to ma znaczenie
Ten test przydaje się przy software, usługach opartych o automatyzację, document intelligence, voice AI, workflow back-office i firmach, które opowiadają o własnym modelu, agentach albo przewadze danych. Największe ryzyko pojawia się wtedy, gdy AI jest częścią narracji wzrostu, ale nie ma dowodów operacyjnych.
Test decyzyjny
| Claim w data roomie | Pytanie diligence | Dowód, który powinien istnieć |
|---|---|---|
| “Automatyzujemy większość procesu.” | Które kroki są automatyczne, a które nadal wymagają review? | Logika workflow, stany review, przykłady błędów i fallback. |
| “Mamy unikalne dane.” | Czy dane są dostępne, legalnie używalne i jakościowo wystarczające? | Źródła danych, zgody, retencja, próbki, data quality notes. |
| “Model jest lepszy od konkurencji.” | Jak mierzono wynik i na jakim zbiorze? | Evals, metryki, przykłady porażek, monitoring driftu. |
| “To działa produkcyjnie.” | Kto odpowiada za koszt, awarie, support i zmianę modelu? | Architektura, SLA, koszty, ownership, incident path. |
Dowody do zebrania
- Lista claimów AI wyciągnięta z decków, rozmów managementu i materiałów produktowych.
- Mapowanie claimów do konkretnych workflow i danych, nie do ogólnych funkcji.
- Próbki outputów, błędów, edge cases i decyzji reviewerów.
- Evals, monitoring, koszt inference, zależności API i limity dostawców.
- Granice systemu: gdzie zaczyna się model, gdzie proces, gdzie człowiek, gdzie vendor.
- Ryzyka regulacyjne i data governance tylko tam, gdzie realnie wpływają na decyzję.
Czerwone flagi
- Demo działa tylko na przykładach wybranych przez sprzedającego.
- Nie ma listy znanych błędów albo edge cases.
- Management mówi o proprietary AI, ale nie potrafi pokazać system boundary.
- Evals są jednorazowym eksperymentem, bez monitoringu po wdrożeniu.
- Koszt działania modelu nie jest połączony z marżą, wolumenem i SLA.
Czego nie wyciągać jako wniosku
Diligence AI nie zastępuje oceny finansowej, legalnej ani security review. Pokazuje, czy claim technologiczny ma pokrycie w artefaktach i czy ryzyko jest wystarczająco nazwane, żeby wejść do decyzji transakcyjnej lub zarządczej.