Bij technical due diligence op een AI-gebouwd product draait het zelden om de vraag of AI de code schreef. Het draait om de vraag of uw team die code kan uitleggen, testen en onderhouden. Investeerders en overnemende partijen kijken bij een product dat grotendeels met AI-codingtools is gebouwd scherper naar drie dingen: wie de code begrijpt, wat de tests bewijzen en waar code en licenties vandaan komen.
Deze gids legt uit wat technical due diligence omvat, wat investeerders controleren, op welke rode vlaggen zij letten en hoe u zich voorbereidt voordat de data room opengaat. Voor het bredere beeld leest u onze gids over AI-gebouwde producten veilig in productie brengen.
TL;DR
Technical due diligence is de onafhankelijke controle die een investeerder of overnemende partij vóór een deal uitvoert op de code, architectuur, infrastructuur, security, gegevensverwerking, IP en het engineeringteam van uw product. Bij een AI-gebouwd product stellen de reviewers steeds één extra vraag: is dit team eigenaar van zijn code, of bedient het die alleen? Bevindingen werken direct door in prijs, garanties en voorwaarden voor closing.
- Wat investeerders controleren: Technical due diligence omvat zes gebieden: architectuur, eigendom van code en licenties, security en persoonsgegevens, infrastructuur, testen en kennis in het team.
- Rode vlaggen bij AI-gebouwde code: De rode vlaggen in een AI-gebouwde codebase zijn onderdrukte fouten, gedupliceerde code, tests die samen met de code zijn geschreven, secrets in de repository, open databasetoegang en kennis bij één persoon.
- Hoe u zich voorbereidt: De voorbereiding bestaat uit vier stappen voordat de data room opengaat: inventariseren, onafhankelijke review, deal blockers oplossen en bewijs documenteren.
Wat technical due diligence is, en wat het niet is
Technical due diligence is een deskundige beoordeling van de producttechnologie van een bedrijf, in opdracht van een investeerder of overnemende partij vóór een deal. De beoordeling omvat de code, architectuur, infrastructuur, security, gegevensverwerking en het engineeringteam dat dit alles onderhoudt. Technische due diligence vindt meestal plaats tijdens de exclusiviteitsfase, nadat beide partijen een letter of intent (LOI) hebben getekend: een niet-bindende afspraak over de belangrijkste dealvoorwaarden.
Technical due diligence wordt vaak verward met twee smallere controles. Tabel 1 laat het verschil zien.
| Type | Wat wordt onderzocht | Typische vraag |
|---|---|---|
| Technical due diligence | Het product: code, architectuur, infrastructuur, security, data, IP en team | Kan dit product schalen, en kan dit team erop doorbouwen? |
| IT due diligence | Interne systemen zoals finance, CRM en kantoor-IT | Kunnen de backofficesystemen het bedrijf na de deal dragen? |
| Cyber due diligence | Alleen de securitypositie | Welke securityrisico’s en eerdere incidenten komen met dit bedrijf mee? |
Ook de opdrachtgever maakt verschil. Bij buyer-side due diligence betaalt de koper voor een onderzoek naar het doelbedrijf. Bij vendor due diligence laat de verkoper vooraf een review uitvoeren en deelt die om het proces te versnellen. Een review aan verkoperszijde is zinvol als het product snel of grotendeels met AI-tools is gebouwd en u een technische koper verwacht.
Technical due diligence is ook geen leveranciersselectie. Het controleren van een outsourcingpartner voordat u tekent, behandelen we in onze gids over due diligence bij uitbesteding.
Waarom een AI-gebouwd product strenger wordt bekeken
Investeerders waarderen een product niet lager omdat het met AI-tools is gebouwd; zij waarderen code lager die niemand kan uitleggen. Bij een AI-gebouwd product verschuift de vraag van de reviewer van “is de code goed?” naar “is dit team eigenaar van zijn code?”
Drie patronen verklaren de extra aandacht. AI-tools leveren bijna-juiste code op die oppervlakkige tests doorstaat maar faalt in randgevallen. Elke prompt begint met een nieuwe context, waardoor dezelfde functie vaak in meerdere versies bestaat. En tests die in dezelfde sessie als de code zijn gegenereerd, bevestigen meestal de aannames van de AI in plaats van die te toetsen. De herkomst van licenties voegt een vierde vraag toe: waar komt elk stuk code vandaan, en onder welke voorwaarden?
Geen van deze patronen blokkeert op zichzelf een deal. Ze worden duur als de reviewer ze als eerste vindt, omdat elk patroon dan uitmondt in een prijsaanpassing, een specifieke garantie of een voorwaarde om vóór closing te herstellen. De founder die het bewijs vooraf kan tonen, houdt dat gesprek in eigen hand.
Wat investeerders controleren: zes gebieden
Elke technical due diligence omvat zes gebieden, en bij een AI-gebouwd product heeft elk gebied een typische rode vlag. Tabel 2 koppelt elk gebied aan het bewijs dat die vlag beantwoordt.
| Gebied | Waar de reviewer om vraagt | Rode vlag bij AI-gebouwde code | Bewijs dat de vraag beantwoordt |
|---|---|---|---|
| Architectuur en onderhoudbaarheid | Architectuuroverzicht, hoofdcomponenten, bekende technical debt | Dezelfde logica in meerdere modules; geen structuur die een nieuwe engineer kan volgen | Architectuurdiagram, debt-register, refactoringplan |
| Eigendom van code, IP en licenties | Eigendom van repositories, overeenkomsten met contributors, licenties van dependencies | Onduidelijke herkomst van codefragmenten; copyleftlicenties in de dependency tree | Licentierapport, IP-overdracht van elke contributor, voorwaarden van AI-tools |
| Security en persoonsgegevens | Securityreview, toegangsbeheer, datastromen, incidenthistorie | Secrets in de code; geen toegangsregels op de database | Onafhankelijke review met herstelstatus, verwerkingsregister |
| Infrastructuur, deployment en herstel | Hosting, deploymentproces, back-ups, operationele kosten | Handmatige deploys; geen geteste restore; onduidelijke model- en API-kosten | Beschrijving van deployment, restoretest, kostenoverzicht |
| Testen en kwaliteit | Testdekking, CI-pipeline, foutmonitoring | Tests in dezelfde sessie als de code geschreven; onderdrukte fouten | Overzicht testdekking, gereviewd testplan, foutlogs |
| Team en kennis | Wie wat onderhoudt, documentatie, afhankelijkheid van sleutelpersonen | Alleen één persoon, of alleen de AI-tool, kan billing en authenticatie uitleggen | Kennisoverzicht, walkthrough door een tweede engineer |
Eigendom van code verdient extra aandacht. Een copyleftlicentie, zoals de GPL, staat gebruik van opensourcecode toe onder één voorwaarde. Verspreidt u software waarin die code zit, dan publiceert u uw eigen broncode onder dezelfde licentie. De GNU AGPL breidt die plicht uit naar software die mensen via een netwerk gebruiken. Een AI-tool kan zulke code ongemerkt in uw product kopiëren, dus reviewers scannen de dependency tree: de volledige lijst bibliotheken waarop uw product draait. Zij lezen ook de gebruiksvoorwaarden van de AI-tool over eigendom van output. De eigendomsvraag zelf behandelen we in eigenaar van code die door AI is geschreven.
Voor security en persoonsgegevens toetsen investeerders het product aan benoemde maatstaven. Artikel 32 van de AVG (GDPR) vereist beveiligingsmaatregelen die passen bij het risico, en ISO/IEC 27001:2022 is de managementsysteemnorm waar veel reviewers naar verwijzen. Ook operationele kosten horen bij het infrastructuurgebied: kosten voor modellen en API-gebruik maken deel uit van de unit economics die een investeerder toetst.
Het gebied team en kennis beslist vaker over een deal met een AI-gebouwd product dan de codestijl. Bereid dat gebied als eerste voor.
Technical due diligence-vragen die u kunt verwachten
De meeste vragen in een technical due diligence vallen binnen de zes gebieden, en de vragen hieronder treffen AI-gebouwde producten het vaakst. Bij elke vraag staat wat een goed antwoord bevat.
- Welke delen zijn met AI-tools gegenereerd, en hoe is die code gereviewd? Een eerlijke schatting, plus de reviewstap die elke wijziging heeft doorlopen.
- Wie kan de code voor authenticatie en billing uitleggen zonder de AI-tool? Een engineer met naam die een reviewer erdoorheen kan leiden.
- Wat dekken uw tests, en wie heeft ze geschreven? Dekking van de kritieke flows, en tests die zijn gereviewd door iemand anders dan de auteur van de code.
- Welke opensourcelicenties zitten in de dependency tree? Een gegenereerd licentierapport, met uitleg bij elke copyleftlicentie.
- Waar staan persoonsgegevens, en wie heeft er toegang toe? Een datakaart en een toegangslijst voor productiesystemen.
- Hoe deployt u, en hoe draait u een release terug? Een herhaalbare pipeline en een geteste rollback.
- Welke secrets bestaan er, en hoe worden ze beheerd? Een secrets manager, en geen sleutels in de code of de historie ervan.
- Wat gebeurt er als de founder of de belangrijkste freelancer vertrekt? Documentatie en een tweede persoon die de kritieke modules kent.
- Welke AI-modellen of API’s roept het product aan, en onder welke voorwaarden? Een lijst van aanbieders, datavoorwaarden en maandelijks gebruik.
- Heeft een onafhankelijke partij de code gereviewd? Een recent rapport met bevindingen en herstelstatus.
Ook reviewers gebruiken AI-tools om repositories te scannen op dependencies, secrets en duplicatie. Zij accepteren een door AI gegenereerd rapport echter niet als de beoordeling zelf. Investeerders betalen voor een reviewer met naam die elke bevinding kan verdedigen.
Investeerders vertrouwen bevindingen die u zelf als eerste vond. Een onafhankelijke review van uw AI-gebouwde product geeft u onderbouwde bevindingen, een geprioriteerde actielijst en documentatie voor uw data room.
→ Bekijk wat een AI-built product review omvat
Rode vlaggen in een AI-gebouwde codebase, en het bewijs dat ze beantwoordt
Zes rode vlaggen komen het vaakst voor wanneer reviewers een AI-gebouwde codebase onderzoeken. Voor elke vlag bestaat specifiek bewijs dat de zaak beslecht, zoals tabel 3 laat zien.
| Rode vlag | Waarom een reviewer dit belangrijk vindt | Bewijs dat de zaak beslecht |
|---|---|---|
| Onderdrukte fouten (uitgeschakelde lintregels, lege catch-blocks) | Fouten treden ongemerkt op in productie | Weer ingeschakelde controles, logs van foutmonitoring |
| Gedupliceerde utilities en dode code | Elke wijziging moet op meerdere plekken gebeuren | Refactoringverslag, schoon rapport van statische analyse |
| Tests die samen met de code zijn gemaakt | Tests bevestigen aannames in plaats van gedrag | Onafhankelijke testreview, tests voor bekende randgevallen |
| Secrets in de historie van de repository | Sleutels kunnen al zijn uitgelekt | Geroteerde sleutels, scan van de historie, secrets manager in gebruik |
| Geen toegangsregels op de database | Elke gebruiker kan mogelijk gegevens van anderen lezen | Review van toegangsregels, resultaten van een autorisatietest |
| Eén persoon heeft alle kennis | Het product staat stil als die persoon vertrekt | Kennisoverzicht, opgenomen walkthroughs, tweede beheerder |
Elke rode vlag in authenticatie, betalingen of persoonsgegevens moet vóór closing zijn opgelost. Stijlkwesties niet.
Zo bereidt u zich voor: vier stappen voordat de data room opengaat
Bereid technical due diligence voor vóórdat u een letter of intent tekent, want herstelwerk tijdens de exclusiviteitsfase gebeurt onder dealdruk. Vier stappen zijn genoeg:
- Inventariseren. Breng de coderepositories, dependencies en licenties, datastromen en elke AI-tool en elk model in kaart die het product gebruikt.
- Onafhankelijke review. Laat een AI code audit uitvoeren, zodat u de bevindingen ziet voordat de investeerder ze ziet.
- Deal blockers oplossen. Los eerst problemen op in authenticatie, betalingen, persoonsgegevens en secrets.
- Bewijs documenteren. Zet rapporten, herstelstatus en de resultaten van een production readiness review in de data room.
Laat zelf een review vóór de due diligence uitvoeren als het product snel met AI-tools of door één developer is gebouwd. Sla die over als er een recente onafhankelijke audit bestaat en uw team een reviewer door de code kan leiden.
Technical due diligence-checklist voor uw data room
Een technical due diligence-checklist voor een AI-gebouwd product somt de documenten op die een investeerder in de data room verwacht:
- architectuuroverzicht en -diagram
- rapport van dependencies en licenties
- lijst van gebruikte AI-tools en modellen, met hun voorwaarden
- securityreview of auditrapport, met herstelstatus
- verwerkingsregister (artikel 30 AVG) en verwerkersovereenkomsten (artikel 28)
- register van datalekken
- beschrijving van deployment, back-up en herstel
- overzicht van testdekking
- toegangslijst voor productiesystemen
- kennisoverzicht van het team
- verklaring over uw rol onder de AI-verordening (aanbieder of gebruiksverantwoordelijke) als het product AI-functies bevat
- notitie over de vraag of de NIS2-richtlijn op uw bedrijf van toepassing is
Wat bevindingen met de deal doen
Bevindingen uit technical due diligence veranderen de dealvoorwaarden op vijf algemene manieren. De investeerder of overnemende partij kan de prijs verlagen of een specifieke garantie of vrijwaring vragen. Ook kan een deel van de koopprijs in escrow worden gehouden: geld dat bij een derde partij blijft tot aan voorwaarden is voldaan. Een derde route is een voorwaarde om vóór closing te herstellen, en de laatste is afhaken. Welk mechanisme geldt, hangt af van de ernst van de bevinding en de onderhandeling; over de voorwaarden zelf adviseert uw advocaat.
Wat founders wel in de hand hebben, is wie het probleem vindt. Een bevinding die u zelf hebt ontdekt, opgelost en gedocumenteerd, verschuift de prijs zelden. Dezelfde bevinding, ontdekt door de reviewer van de investeerder, roept een tweede vraag op: wat is er nog meer niet gevonden?
Hoe Sunbytes AI-gebouwde producten voorbereidt op due diligence
Investeerders controleren niet of een mens elke regel heeft getypt; zij controleren of uw team kan uitleggen, onderhouden en beveiligen wat er is gebouwd. Een AI-built product review van Sunbytes levert dat bewijs. De review staat los van eventueel herstelwerk, waardoor de bevindingen gewicht hebben bij investeerders.
Software-engineers en securityspecialisten reviewen het product samen. U ontvangt bevindingen met het bewijs erachter, een geprioriteerd actieplan en een technische overdracht, uitgelegd in begrijpelijke taal in plaats van als scannerexport. Sunbytes werkt binnen een ISO/IEC 27001:2022-gecertificeerd ISMS met governance vanuit Nederland, en heeft in meer dan 15 jaar ruim 300 projecten opgeleverd.
Elk product en elke deal is anders, dus de scope stemmen we per situatie af. Neem contact op over een review voordat uw ronde of verkoop de fase van de letter of intent bereikt.
