Hoe kies je een bedrijf voor AI-implementatie: checklist met 20 vragen en contractvoorwaarden (AI Act, AVG, IP, acceptatiecriteria)

Het verschil tussen een AI-implementatie die meetbaar resultaat oplevert en een project dat eindigt met een presentatie, zit zelden in de technologie. Het zit in hoe je partner met data omgaat, hoe hij resultaat meet en wat er in het contract staat. Deze tekst is een lijst met vragen voor de eerste gesprekken met de leverancier en een lijst met bepalingen die in het contract moeten staan voordat het project start.

Dit is geen juridisch advies; laat contractbepalingen toetsen door een jurist, zeker bij systemen met hoog risico volgens de AI Act.

Belangrijkste conclusies

• Begin bij het probleem, niet bij het model. Een goede partner vraagt eerst naar het proces, de data en het verwachte resultaat en pas daarna naar de tech stack.
• Data bepalen het resultaat. Vraag naar een data-audit, toegang, toegangsrechten en waar de data verwerkt worden.
• Een AI-contract is anders dan een softwarecontract. Het moet rollen volgens de AI Act, een verwerkingsovereenkomst volgens de AVG, eigendom van code, prompts, configuraties en modelgewichten, acceptatiecriteria op basis van metrieken en de gebruikskosten van modellen afdekken.
• Acceptatie is statistiek, geen knop. Acceptatiecriteria worden gedefinieerd op een testset, met kwaliteitsdrempels, responstijd en kost per verzoek.
• Plan je exit. Documentatie, overdracht en vervangbaarheid van het model zijn bepalingen die je bedrijf beschermen na afloop van de samenwerking.

Wat is een AI-implementatie in een bedrijf

AI-implementatie is het bouwen en live zetten van een systeem dat machine learning-modellen of Large Language Models (LLM’s) inzet in een bedrijfsproces: een assistent voor medewerkers of klanten, een agent die taken uitvoert in systemen, een RAG-kennisbank, een voorspellend model. In de meeste zakelijke projecten bouw je geen eigen modellen from scratch; je gebruikt kant-en-klare modellen via API’s of open-weight-modellen en koppelt die aan de data en systemen van het bedrijf. Daarom zijn de competenties van de partner vooral belangrijk in integratie, data, security en het meten van effect.

Drie pijlers om een partner te beoordelen

Technologie en data

Vraag vóór de prijs hoe het bedrijf met data werkt: doen ze een audit van bronnen, hoe schonen ze data op, hoe nemen ze toegangsrechten over van bronsystemen naar AI, hoe kiezen ze een model (kost, kwaliteit, verwerkingslocatie) en kunnen ze het model vervangen zonder herbouw? Een partner die direct voorstelt een eigen model te trainen, moet kunnen onderbouwen waarom een kant-en-klaar model met RAG niet volstaat.

Business en meting

Een implementatie zonder discovery-fase (wat meten we, wat is de nulmeting, wat is succes) eindigt met features die niemand gebruikt. Een goede partner stelt een pilot voor op één proces met echte data, met meting vóór en na.

Recht en security

De AI Act geldt gefaseerd vanaf 2024 (verboden praktijken en AI-competenties vanaf februari 2025, transparantie vanaf augustus 2026, systemen met hoog risico vanaf december 2027). De AVG geldt volledig. De partner moet weten in welke rol hij optreedt (leverancier of toepasser volgens de AI Act, verwerker volgens de AVG) en wat dat betekent voor het contract.

Waarschuwingssignalen en best practices

Checklist: 20 vragen aan een AI-implementatiepartner

Ervaring

1. Kunnen jullie een AI-systeem laten zien dat in productie draait bij een klant, met cijfers? Zoek casestudy’s met metrieken (tijd, kosten, omzet), geen beschrijvingen.
2. Welke problemen kwamen voor in eerdere implementaties en hoe hebben jullie die opgelost? Het antwoord laat zien of de partner over risico’s praat vóórdat ze zich voordoen.
3. Hebben jullie ervaring in onze branche? Data in fintech, healthcare of productie stellen andere eisen aan security en compliance.
4. Hebben jullie systemen overgenomen van andere leveranciers en AI geïntegreerd met legacy-systemen? De meeste bedrijven bouwen niet from scratch.

Data en architectuur

1. Hoe ziet jullie data-audit eruit vóór de implementatie? Bronnen, kwaliteit, gaten, toegangsrechten.
2. Hoe kiezen jullie een model en maakt de architectuur vervanging mogelijk? Vraag naar afhankelijkheid van één leverancier.
3. Hoe beperken jullie hallucinaties? RAG op geverifieerde bronnen, bronvermelding, kwaliteitstests van antwoorden, weigering om te antwoorden bij gebrek aan data.
4. Hoe nemen jullie toegangsrechten over van bronsystemen naar AI? De gebruiker mag alleen zien waar hij recht op heeft.
5. Hoe testen jullie een systeem met niet-deterministische antwoorden? Testset, metrieken, regressietests na elke wijziging van model of prompt.
6. Wie monitort de kwaliteit na livegang en hoe? Logs, metrieken, alerts, plan voor bijscholing of vervanging van het model.

Security en recht

1. Waar worden onze data fysiek verwerkt en door welke partijen? Cloud van de modelleverancier, cloud van de klant, infrastructuur van de klant; lijst van subverwerkers.
2. Mogen bedrijfsgegevens worden gebruikt om modellen van de leverancier te trainen? Verwacht antwoord: nee, op basis van een zakelijke overeenkomst met de modelleverancier.
3. Hoe borgen jullie AVG-compliance? Verwerkingsovereenkomst, dataminimalisatie, DPIA indien vereist, recht op gegevenswissing.
4. In welke rol zijn jullie volgens de AI Act en in welke rol zijn wij? Leverancier of toepasser; risicocategorie; wat dat betekent voor documentatie en toezicht.
5. Welke beveiligingen passen jullie toe op data in prompts en antwoorden? Filters voor gevoelige gegevens, logging, toegangscontrole, securitytests (inclusief prompt injection).

Samenwerking en kosten

1. Hoe definiëren jullie de pilot en wat is het resultaat ervan? Scope, data, metrieken, beslissing over opschalen.
2. Hoe splitsen jullie de prijs uit? Bouw, gebruik van modellen (bij geschat aantal verzoeken), onderhoud en doorontwikkeling. Eén totaalbedrag zonder uitsplitsing is een waarschuwingssignaal.
3. Welke businessmetrieken volgen we? Tijdsbesparing, kosten per afhandeling, conversie, omzet; gemeten vóór en na.
4. Wie gaat concreet aan het project werken en in welk model? Dedicated team, uitbreiding van ons team, project met vaste scope; toegang tot een architect.
5. Wat krijgen we aan het einde en hoe ziet de overdracht eruit? Code, documentatie, prompts, configuraties, testsets; mogelijkheid tot onderhoud door een ander team.

Elementen van een contract voor een AI-implementatie

1. Rollen en verantwoordelijkheid volgens de AI Act

• Bepaal wie de leverancier van het systeem is (ontwikkelt en brengt op de markt) en wie de toepasser (gebruikt het in de eigen activiteiten). Als het systeem als maatwerk onder het merk van de klant ontstaat, kan de klant leverancier zijn; het contract moet dit expliciet benoemen.
• Classificatie van het risico van het systeem in het contract of een bijlage; bij hoog risico: wie verantwoordelijk is voor technische documentatie, logging, menselijk toezicht, conformiteitsbeoordeling.
• Transparantie: het systeem informeert de gebruiker dat hij met AI communiceert; gegenereerde content wordt gelabeld, conform art. 50.
• AI-competenties (art. 4): training van het team van de klant als onderdeel van de levering, niet als add-on.
• Incidentmelding: procedure en termijnen voor het informeren van de klant over systeemfouten en security-incidenten.

2. AVG en data

• Verwerkingsovereenkomst (art. 28 AVG) met de partner en een lijst van subverwerkers (inclusief modellleveranciers) met het recht om bezwaar te maken tegen wijzigingen.
• Verwerkingslocatie en regio’s (EU/EER), regels voor doorgifte buiten de EER.
• Verbod op het trainen van modellen van de leverancier op klantdata, bevestigd in de zakelijke overeenkomst met de modellleverancier.
• Dataminimalisatie en anonimisering vóór doorgifte aan het model; filters voor gevoelige gegevens.
• Gegevenswissing: architectuur (RAG in plaats van trainen op persoonsgegevens) maakt het mogelijk data van een persoon te verwijderen zonder het model te herbouwen; logretentie (voor hoogrisicosystemen min. 6 maanden volgens de AI Act).
• DPIA en, bij hoog risico voor bepaalde toepassers, de effectbeoordeling voor grondrechten (art. 27 AI Act): wie die opstelt.

3. Intellectuele eigendom

• Overdracht van vermogensrechten (geen licentie) op code, datascripts, documentatie, prompts, configuraties, test- en evaluatiesets, op alle exploitatievormen, bij betaling per fase.
• Modelgewichten: als de partner het model afstemt (fine-tuning), gaan de rechten op gewichten en trainingsdata over op de klant voor zover toegestaan door de licentie van het basismodel. Modellen van externe leveranciers (OpenAI, Anthropic, Google) kun je niet “kopen”; het contract moet dat duidelijk scheiden.
• Open-sourcecomponenten en open‑weight-modellen: lijst met licenties en bevestiging van geschiktheid voor commercieel gebruik.
• Door AI gegenereerde content: het auteursrecht beschermt menselijke werken; het contract moet de rechten op resultaten en de verantwoordelijkheid voor het gebruik ervan regelen, zonder bescherming te beloven die het recht niet biedt.
• Knowhow van de partner: als de partner eigen componenten of producten inbrengt (bijv. een kant-en-klare kennisbank), dan een licentie daarop met recht op verder gebruik na afloop van het contract.

4. Acceptatiecriteria

• Vooraf afgestemde testset (representatieve vragen en verwachte antwoorden) waarop de acceptatie wordt gemeten.
• Kwaliteitsdrempels passend bij de taak: voor een kennisbankassistent bijvoorbeeld het aandeel juiste, op bronnen gebaseerde antwoorden en het aandeel weigeringen bij gebrek aan data; voor classificatie: precisie en recall; voor extractie: veldnauwkeurigheid.
• Responstijd (bijv. 95e percentiel) en kost per verzoek bij een verondersteld volume.
• Security: tests op prompt injection en datalek, controle van toegangsrechten.
• Menselijk toezicht: waar een mens het resultaat goedkeurt voordat het bij de klant of in het systeem komt.
• Realiteitszin: AI heeft een foutmarge; acceptatie definieert een acceptabel niveau, geen 100%.

5. Kosten, onderhoud en exit

• Uitsplitsing van de prijs in bouw, gebruik van modellen (met mechanisme voor prijswijzigingen bij leveranciers) en onderhoud.
• SLA voor beschikbaarheid en reactietijd; kwaliteitsmonitoring als dienst, geen belofte.
• Vervangbaarheid van het model als architectuur-eis, vastgelegd in het contract.
• Exitclausule: overdracht van code, documentatie, data en configuraties in een afgesproken formaat, transitieperiode, support voor het volgende team.
• Vertrouwelijkheid en audit: recht van de klant op een security- en compliance-audit bij de partner en subverwerkers.

Welk type partner zoek je

De keuze hangt af van je startpunt: een andere partner past bij het toevoegen van AI aan bestaande systemen (softwarehouse gespecialiseerd in AI), een andere bij een transformatieprogramma in een corporate (grote integrator), weer een andere bij het ordenen van data (analyticsbedrijf). Een overzicht van AI-implementatiebedrijven in Polen, gegroepeerd per partnertype, vind je in onze ranking TOP 10 firm wdrażających AI w Polsce.

Startup House bouwt AI-assistenten, agents en RAG-kennisbanken voor middelgrote en grote bedrijven, ook in gereguleerde sectoren (fintech, healthcare, cybersecurity). Oplossingen draaien op geverifieerde klantdata, in de cloud van de klant, geïntegreerd met access policies; klantdata trainen geen publieke modellen. ISO 27001 compliant. Voorbeeld: een klantportaal met ingebouwde AI voor een cybersecurityplatform dat Fortune 500-klanten bedient, verkortte de onboarding met 95%, en de overname en modernisering van het logistieke systeem voor Omnipack verlaagden de ontwikkelkosten met 40%.

Zie ook: AI Act: co musi zrobić firma, która wdraża AI · Case studies Startup House

FAQ

Eigen AI-team of softwarehouse?

Het werven van een AI-team duurt maanden en de eerste implementatie vraagt ervaring met integraties en security. Voor de meeste bedrijven werkt het model: starten met een partner, parallel intern competenties opbouwen (trainingen, een product owner aan klantzijde), en het onderhoud stapsgewijs overnemen.

Wat kost een AI-implementatie?

Dat hangt af van de scope. Een pilot van een assistent op één proces met kant-en-klare modellen is een project van enkele weken; implementatie in meerdere afdelingen met integraties is een project van maanden. De prijs moet bouw, gebruik van modellen en onderhoud uitsplitsen.

Bemoeilijkt de AI Act implementaties?

Voor de meeste zakelijke implementaties (minimaal risico) komen de verplichtingen neer op AI-competenties bij medewerkers en transparantie naar gebruikers. Systemen met hoog risico (werving, kredietscoring, biometrie) vereisen documentatie, logging en menselijk toezicht, met ingangsdatum vanaf december 2027. Een partner die dit begrijpt, ontwerpt het systeem vanaf het begin conformeisend.

Wat zijn de grootste risico’s van een AI-implementatie?

Lage datakwaliteit, geen nulmeting, gebrek aan acceptatie in het team, afhankelijkheid van één modellleverancier en een contract dat eigendom van code, prompts en data niet regelt.

Hoe lang duurt de implementatie?

Een pilot op één proces met echte data kun je in enkele weken bouwen. Een productie-implementatie met integraties en security duurt langer en hangt af van het aantal systemen en de datakwaliteit.

Kan ik de modellleverancier tijdens of na het project veranderen?

Ja, als de architectuur dat voorziet en het contract dat vereist. Modellen veranderen elke paar maanden; een systeem waarin het model een verwisselbare component is, hoeft niet herbouwd te worden bij een leverancierswissel.

Waar begin ik met de voorbereiding op een AI-implementatie?

Begin met het analyseren van bedrijfsprocessen, beschikbare data en de behoeften van medewerkers. Kies vervolgens domeinen waar AI-tools meetbaar voordeel opleveren en wijs een verantwoordelijke voor het project aan. Volgende stappen zijn risicoanalyse, een pilot in een gecontroleerde omgeving en het geleidelijk uitbreiden van het gebruik in de dagelijkse werkzaamheden.

Wat is een AI-beleid en moet elk bedrijf dit opstellen?

AI-beleid is een intern document met regels voor het gebruik van AI-systemen in de organisatie. Het moet toegestane AI-tools, beperkingen voor datainvoer, regels voor verificatie van resultaten en verantwoordelijkheden van medewerkers en beheerders bepalen. Het kan ook de selectie van leveranciers, updates van AI-modellen en incidentmelding reguleren. Een goed AI-beleid ondersteunt juridische compliance en een veilige implementatie van AI-oplossingen.

Is een register van AI-systemen in elke organisatie verplicht?

Niet elke organisatie is verplicht een formeel register van alle AI-systemen bij te houden. Een intern AI-register is echter wel een goede praktijk voor risicobeheersing. Het moet de naam van het systeem, doel, leverancier, gebruikte data, risicocategorie en verantwoordelijke bevatten. Voor bepaalde hoogrisicosystemen voorziet de AI Act ook in registratieverplichtingen. De reikwijdte hangt onder meer af van de rol van de organisatie en de toepassing.

Hoe voer je een risicoanalyse uit vóór de implementatie van een AI-systeem?

Begin de risicoanalyse met het doel van het systeem, het type verwerkte data en de mogelijke impact op personen en de organisatie. Neem informatiebeveiliging, kwaliteit van AI-resultaten, foutieve beslissingen, menselijk toezicht en mogelijke verboden praktijken op. Bepaal ook of de toepassing als onaanvaardbaar risico of als hoogrisicosysteem kan worden geclassificeerd volgens de AI Act. De risicoanalyse is niet eenmalig — update haar bij wijzigingen in het systeem.

Vereist een AI-implementatie een DPIA?

Een beoordeling van de gevolgen voor gegevensbescherming (DPIA) is op grond van de AVG vereist wanneer een bepaald soort verwerking waarschijnlijk een hoog risico inhoudt voor de rechten en vrijheden van natuurlijke personen. Dit geldt met name voor bepaalde toepassingen van profilering en geautomatiseerde besluitvorming. Het enkele gebruik van AI leidt niet automatisch tot een DPIA-plicht. De DPIA vervangt niet de risicoanalyse vereist door de AI Act, omdat beide deels andere risico’s bestrijken.

Wat betekent AI literacy en welke trainingen moeten medewerkers volgen?

AI literacy betekent competenties om AI-systemen bewust, veilig en verantwoordelijk te gebruiken. Trainingen moeten de mogelijkheden en beperkingen van AI-modellen, bescherming van persoonsgegevens, verificatie van antwoorden en het herkennen van fouten omvatten. Stem trainingsmateriaal af op rollen en het gebruik van AI-tools in het dagelijks werk. Art. 4 AI Act voorziet in maatregelen om een passend niveau van AI-competenties te borgen bij leveranciers en toepassers.

Wie is leverancier en wie is toepasser volgens de AI Act?

Een leverancier is een entiteit die een AI-systeem ontwikkelt of de ontwikkeling uitbesteedt en het op de markt brengt of onder eigen naam of merk in gebruik geeft. Een toepasser gebruikt een AI-systeem in de uitoefening van zijn activiteiten, anders dan voor persoonlijk en niet-professioneel gebruik. De rolverdeling is van belang voor documentatie, toezicht, security en verplichtingen op grond van EU-recht. In bepaalde situaties kan de implementerende organisatie de verplichtingen van een leverancier overnemen.

Hoe werkt menselijk toezicht op AI, oftewel human in the loop?

Human in the loop is een werkmodel waarin de mens deelneemt aan de beoordeling of goedkeuring van AI-resultaten. Hij kan aanbevelingen controleren, fouten corrigeren en uiteindelijke beslissingen nemen in situaties die extra controle vereisen. Dit is vooral belangrijk bij automatisering van processen die invloed hebben op klanten, medewerkers of andere personen. Toezicht moet reëel zijn: de medewerker moet de beperkingen van het systeem begrijpen, het resultaat kunnen betwisten en de juiste bevoegdheden hebben om in te grijpen.

Tekst is informatief en vormt geen juridisch advies. Rechtsstand: oktober 2026 (AI Act na Digital Omnibus, verordening 2026/1744).