Dit artikel maakt deel uit van een serie over hoe i-spark AI gebruikt in ons werk. Zie ons begeleidende artikel voor een overzicht van de drie hoofdcategorieën waarin AI wordt gebruikt: ideeënvorming, hulp bij code en gegevensanalyse.
AI-ondersteund coderen is nu standaardpraktijk bij alle gegevensinitiatieven, bij het schrijven van code en het nakijken van code. De meeste ontwikkelteams gebruiken het. De kans is groot dat elke leverancier waarmee je werkt het ook gebruikt, of ze het je nu vertellen of niet.
Dat laatste is de moeite waard om even bij stil te staan.
Wat AI-ondersteund coderen eigenlijk betekent in een gegevensproject
In een dataprojectomgeving (denk aan dbt, GitHub, Power BI, Snowflake) maken AI-coderingstools rechtstreeks verbinding met je codeopslagplaatsen. Ze lezen je code, analyseren die en genereren op basis daarvan nieuwe code. De praktische voordelen zijn snellere levering, minder bugs en lagere projectkosten.
Als je het goed gebruikt, verbetert het echt zowel de snelheid als de kwaliteit van het ontwikkelwerk. Het sleutelwoord is goed. AI-assistentie werkt als degene die het gebruikt echt begrijpt wat hij bouwt: de bedrijfslogica, de architectuur, de vereisten. Het helpt ervaren ontwikkelaars om sneller betere resultaten te behalen.
Het vervangt de noodzaak om te weten wat je doet niet, het versterkt het. Een ontwikkelaar die de code die hij genereert niet begrijpt, vormt een risico, ongeacht de tools die hij gebruikt.
“Een AI-tool koppelen aan je repository” is niet hetzelfde als een nieuwe ontwikkelaar toevoegen aan een Slack-kanaal. Er zijn een aantal implicaties die de moeite waard zijn om te bekijken voordat je er je handtekening onder zet.
Drie dingen die je aandacht verdienen
1. Waar uw gegevens eigenlijk terechtkomen
Code en gegevens horen gescheiden te zijn. In de praktijk vervaagt de grens meer dan de meeste mensen beseffen.
Je archief bevat architectuur en bedrijfslogica: hoe je datamodellen zijn gestructureerd, hoe je rapporten zijn opgebouwd. Dat is je intellectuele eigendom. Het is specifiek voor jouw bedrijf en het vertelt een verhaal over hoe jouw bedrijf werkt.
Het kan ook quasi-data bevatten: opmerkingen die verwijzen naar specifieke klanten, hard gecodeerde waarden en testscenario’s uit echte records. Deze komen vaak voor in echte repositories en ze zijn gevoelig, zelfs als ze code lijken te zijn. We weten dat dit geen best practice is, maar het gebeurt in bijna elke echte repository.
Afhankelijk van je configuratie kunnen de eigenlijke gegevens daar ook in staan.
Power BI is een duidelijk voorbeeld.
Met het oudere .pbix formaat kunnen bestanden uiteindelijk gecommit worden naar een repository, maar ze zijn daar niet echt nuttig opgeslagen. Met het nieuwere .pbir formaat worden bestanden meestal helemaal niet naar GitHub gepushed.
Echter, in de importmodus worden de feitelijke gegevens lokaal gecached op de machine van de ontwikkelaar. Als er een AI codeerprogramma draait in diezelfde omgeving, kunnen die lokaal opgeslagen gegevens toegankelijk zijn voor dat programma, afhankelijk van hoe het programma is geconfigureerd en wat de ontwikkelaar ermee deelt, zelfs als het nooit je repository aanraakt. Het blootstellingspunt verschuift, maar verdwijnt niet.
De vraag die je aan je leverancier moet stellen: Hoe is onze Power BI geconfigureerd: directe query of importmodus? En hebben jullie een beleid voor wat wordt vastgelegd in het archief?
2. De reikwijdte van toegang is niet altijd transparant, inclusief menselijke toegang
Paragraaf 1 schetste wat je archief in het ergste geval kan bevatten. De realiteit is dat het vaak onduidelijk is tot hoeveel, wanneer en hoe een AI-tool daadwerkelijk toegang heeft. In tegenstelling tot een bestand in versiebeheer, verwerken AI-tools actief je code: ze nemen het op, analyseren het en genereren het. De reikwijdte van die verwerking is niet altijd vooraf gedocumenteerd en het is de moeite waard om hiernaar te vragen voordat je begint.
Afgezien van wat het AI-model verwerkt, is er een aparte vraag over wie bij het verkopende bedrijf je code kan zien. AI-tools zijn softwareproducten en zoals elk softwareproduct worden ze gebouwd, onderhouden en gecontroleerd door mensen. Afhankelijk van de interne toegangscontroles van de leverancier, kunnen ondersteunend personeel, technici of beveiligingsteams de inhoud van repository’s bekijken.
De vragen die u aan uw leverancier moet stellen: Wie binnen uw organisatie heeft toegang tot onze code of repository-inhoud? Welke toegangscontroles en audit logging zijn er?
3. Geopolitieke risico’s en leveranciersrisico’s, inclusief de toeleveringsketen
De meeste AI-coderingstools zijn in de VS gebaseerd. Als je organisatie een bewuste keuze heeft gemaakt om EU-infrastructuur te gebruiken (GitLab op locatie, Europese cloudproviders of vergelijkbaar), dan is het verbinden met een Amerikaanse AI-leverancier geen neutrale uitbreiding van die keuzes.
Het introduceert een nieuwe overweging met betrekking tot het verblijf van gegevens die in strijd kan zijn met je bestaande governancebeslissingen.
Wat het moeilijker maakt om dit te beoordelen, is dat AI-tools vaak niet geïsoleerd werken. De tool die je leverancier gebruikt, kan zelf onder de motorkap andere AI-services aanroepen: subverwerkers die niet altijd vooraf worden bekendgemaakt. Een product dat er aan de oppervlakte EU-vriendelijk uitziet, kan je code nog steeds via een in de VS gevestigde modelprovider routeren.
Onder GDPR is het doorgeven van persoonlijke gegevens naar een derde land zonder adequate waarborgen niet toegestaan en “het leek Europees” is geen verdediging.
Er is ook een stabiliteitskwestie. AI-leveranciers zijn nieuwer en het regelgevende en politieke klimaat rondom hen verandert snel. Servicevoorwaarden kunnen veranderen. Relaties met leveranciers kunnen veranderen. Dat is een ander risicoprofiel dan gevestigde infrastructuuraanbieders.
De vragen die je aan je leverancier moet stellen: Welke AI-tools gebruiken jullie en wie zijn hun subverwerkers? Waar wordt onze code verwerkt en opgeslagen? Hoe voldoet je tooling aan GDPR wanneer gegevens buiten de EU worden overgedragen?
De risico’s in verhouding houden
Dit zijn reële overwegingen, maar ze hebben context nodig.
Als je code al gehost wordt op GitHub, dan staat het al op de Amerikaanse infrastructuur. Het toevoegen van een AI-laag is een extra risico, geen compleet nieuwe categorie. Dezelfde bestuurlijke vragen: wie heeft toegang tot je code, waar is het opgeslagen, wat bevat het, pas toe of er AI bij betrokken is of niet. AI maakt die vragen urgenter, niet helemaal nieuw.
De risico’s die hierboven beschreven zijn, zijn ook weinig waarschijnlijk als er een goede hygiëne in het repository aanwezig is: duidelijk beleid over wat er gecommit wordt, hoe bestanden geconfigureerd worden en wat er in codecommentaar komt.
Dat gezegd hebbende, “lage waarschijnlijkheid” is niet hetzelfde als “niet de moeite waard om naar te vragen”. De waarde van deze vragen is om vast te stellen dat je leverancier hierover heeft nagedacht, beleidsregels heeft opgesteld en een duidelijk antwoord kan geven.
Het doel is niet om AI-tooling te vermijden. Goed gebruikt levert het echte voordelen op. Het doel is om het te gebruiken met dezelfde intentie die je zou toepassen op elke tool die je code en je gegevens aanraakt.
Waarom dit gesprek bestaat
Transparantie is hier niet alleen een goede ethiek. Het is goed bestuur. Je verdient het om te weten welke tools worden gebruikt op jouw project, wat ze raken en welke waarborgen er zijn, zodat je weloverwogen beslissingen kunt nemen, vroegtijdig zorgen kunt uiten en grenzen kunt stellen waar dat nodig is.
Als je vragen hebt over hoe AI-tooling wordt gebruikt in jouw project, stel ze dan. Elke leverancier die het waard is om mee in zee te gaan, moet een duidelijk antwoord kunnen geven.
Vragen over i-sparks benadering van AI en governance? Neem contact met ons op.
