Product Owners - Overwegingen voor je volgende project met leveranciers

De risico's van softwareontwikkeling

Er zijn altijd risico's bij het bouwen van software, er zijn veel praktijken en tools om het risico te minimaliseren en eerlijk gezegd verandert de introductie van AI niet veel aan die risico's. Een onbetrouwbare partner vinden zal kostbaar zijn, maar mogelijk is het door AI moeilijker om betrouwbaarheid vanaf het begin te herkennen.

• Software kan altijd bugs bevatten of beperkt worden door resources en pieken in de vraag
• Software kan altijd in de loop van tijd achteruitgaan, gehaast zijn, onderontwikkeld zijn of gebrek hebben aan tools en inzichten
• Software kan altijd worden beïnvloed door externe bronnen, zoals Apple of Android (Native ontwikkeling)
• Etc.

In werkelijkheid is er niet veel veranderd, dus in theorie zijn veel van je huidige juridische overeenkomsten en overwegingen geldig en zullen ze je nog steeds grotendeels dekken.

Wat dit artikel probeert te bereiken is het vernieuwen van die overwegingen en ook meer inzicht geven in de AI-aspecten.

Wat verandert AI dan

Het eerste en grootste risico is het lekken van gevoelige informatie, dit kunnen API-sleutels zijn, .env variabelen etc. Dit kan vaker gebeuren door simpelweg de codebase als context voor een prompt te geven of door specificatie- en juridische documenten op te stellen met AI en real-world data.

1) Wordt AI gebruikt? Waar en hoeveel? Gebruikt deze provider ook AI om specificatiedocumenten, architectuur, juridische documenten etc. op te stellen? Kunnen er fouten, gevoelige informatie of andere overwegingen zijn?

Zorg ervoor dat je jezelf beschermt met betrekking tot gevoelige informatie en aansprakelijkheid. Als informatie naar de cloud wordt gestuurd voor AI-verwerking, zorg er dan voor dat de aansprakelijkheid en beperkingen vanaf het begin duidelijk en afdwingbaar zijn.

Dus de volgende vraag die je jezelf moet stellen is, als je x bedrag per uur betaalt, maar een AI doet veel van het werk en deelt ook potentieel gevoelige informatie met de cloud, is dat het waard?

2) Hoeveel vertrouwt je provider op AI? Mijn advies hier is om dit kritisch te vragen in je gesprekken en vergaderingen, uit te zoeken hoe ze AI gebruiken, in welke mate, en waar je precies voor betaalt.

Enige AI-verwerking is eigenlijk een goede zaak, kan dingen versnellen, mogelijk kosten verlagen in het aantal benodigde uren, maar te veel vertrouwen betekent dat je een premium zou kunnen betalen voor een black-box van potentiële risico's en problemen.

Enkele overwegingen om over na te denken:

• AI kan niet worden gebruikt voor kritieke delen van de infrastructuur
• Overige gebieden moeten beperkt, afgebakend of beschermd zijn
• Provider moet diep inzicht en kennis hebben van het project en moet dit kunnen delen
• Documenten moeten als sjabloon worden opgesteld, daarna handmatig worden ingevuld met specifieke en kritieke/gevoelige informatie

Dit is vergelijkbaar met het huidige probleem waar mensen mee te maken hebben gehad, waarbij ontwikkelaars mogelijk te afhankelijk zijn van externe pakketten en software voor te veel van de projectscope. Te veel projecten die ik heb overgenomen vertrouwden op tientallen externe pakketten om kleine basiselementen van het project op te lossen, wat problemen veroorzaakte met upgrades en onderhoud.

Maar het toegevoegde aspect is het vertrouwen op AI om documenten op te stellen die ook gevoelige informatie kunnen bevatten.

Eigendom

Meestal wanneer je betaalt voor een dienst, betaal je voor een licentie om de software te gebruiken die voor jou is gemaakt, of je hebt eigendom van de broncode en gerelateerd materiaal.

Als we kijken naar beeld- en ontwerp generatie door tools zoals Midjourney, is het auteursrecht en eigendom daar allesbehalve eenvoudig.

• Gegenereerde afbeeldingen zijn in het publieke domein
• Gegenereerde afbeeldingen zijn getraind op bestaand auteursrechtelijk beschermd materiaal

Er zijn momenteel openstaande rechtszaken en internationale discussies over de juridische impact van dergelijke tools, dus als je provider veel vertrouwt op Midjourney voor het ontwerp, zonder transformatieve veranderingen die het uniek en specifiek maken, open je de deur voor anderen om je ontwerp te gebruiken en heb je geen juridisch recht om dit te bestrijden (naar mijn begrip).

• Zorg ervoor dat je clausules opneemt over de correcte en rechtmatige overdracht van eigendom van het ontwerp en de code

Houd er rekening mee dat het ontwerp Fonts en Iconografie in het publieke domein zal gebruiken, misschien stockfoto's of assets met commerciële licenties, Open source pakketten voor kernaspecten van de technische basis, wat allemaal volkomen normaal is.

Echter, als het ontwerp 1-op-1 of grotendeels van diensten zoals Midjourney komt en code grotendeels door AI is geschreven, roept het een hoop vragen op over eigendom.

Een goede technische partner vinden

Ik zou willen dat ik een tool of gids kon bieden die dit een eenvoudig proces zou maken zodat je de juiste partner voor je behoeften kunt vinden. In werkelijkheid is er, net als bij het vinden van elke leverancier, soms heel weinig dat je kunt doen behalve hun referenties en reputatie controleren.

Anders dan bij huisonderhoud hier in Nederland, is er geen register of certificaten voor betrouwbare softwareontwikkelaars.

Dus, wat kun je doen? Vind transparante partners

Het eerste is een leverancier vinden die transparant is over hun processen, tools, team, diensten etc. Elk bedrijf dat volledige transparantie biedt in hun proces, welke overwegingen ze maken, is een geweldige plek om te beginnen.

Als je ze hoort zeggen "Oh ja we gebruiken co-pilot, het is geweldig en stelt ons in staat om snel en effectieve code te ontwikkelen" zonder de dingen te noemen die ze doen om de code en informatie die als gevoelig kan worden beschouwd te beschermen, kan dat een rode vlag zijn.

Stel betekenisvolle vragen

Als commercieel persoon zou het kennen van technische specificaties niet vereist moeten zijn, maar er is een vragenreeks die je kunt volgen om enkele indicatoren te krijgen:

• Wat maakt deze technologieën of bibliotheken volgens jou het beste voor ons project?
• Wat verwacht je dat het meest uitdagende aspect van het project zal zijn?
• Wat zijn je foutmarges of zorgen met het project?

Bij Goldmund zullen we altijd open zijn over al deze details, soms is wat onze klant complex vindt "rapportage", misschien niet wat wij het meest complex vinden "Data modellen" en door transparant te zijn over die aspecten geven we onze klanten inzicht in ons denken en redeneren in het project.

Krijg een duidelijk specificatiedocument Als het dan gaat om het technische scope document dat ze leveren, dingen waar je op moet letten:

• Gebruik van AI en AI-diensten
• Foutafhandeling en monitoring
• Uitsplitsing van uren/complexiteit op aspecten van het project
• Overwegingen om niet voor andere oplossingen of software te kiezen
• Overwegingen voor het beschermen van data en informatie

Het doel zou moeten zijn om hun denken en redenering achter het project te zien. Is dit gewoon nog een sjabloonproject? Een project dat ze oplossen terwijl ze bezig zijn? Een project waarvoor ze van plan zijn veel externe diensten en AI te gebruiken? etc.