• “Key questions for the board” uit J.B. Mantas, Intelligent Approaches to AI
• Gartner toolkit: Selecting and Prioritizing AI Use Cases
• De Data Protection Impact Assessment template op gdpr.eu (geen officiële EU-publicatie)
• Het ontwerp van een Trustworthy AI Assessment list, in voorbereiding door de EU High Level Expert Group on AI
• Het overzicht tools voor ethiek van het Kenniscentrum Data&Maatschappij
• De Data Project Checklist van Fast.ai
• …

De ene vragenlijst is technisch, de andere descriptief, nog andere proberen zoveel mogelijk in cijfertjes te gieten. Dé ultieme checklist maken is onbegonnen werk, want veel hangt af van wie het doelpubliek is van de analyse: de projectleider vindt andere dingen belangrijk dan de CEO, de aandeelhouder of de eindgebruiker.

Goed beseffend dat nòg een extra vragenlijst dat probleem niet oplost, kunnen we het toch niet laten om zelf ook enkele overwegingen te lanceren die wij maken in ons werk bij overheidsdiensten. Zonder te claimen volledig te zijn, 5 kernvragen die wij ons vaak stellen:

1. Hoe zou je het probleem oplossen zonder AI?

Is er wel een goede usecase, en vereist die wel een AI-oplossing? Te vaak wordt AI voorgesteld als hét toverstokje dat alle problemen oplost vanuit het niets. Was dat maar waar: in het echte leven zijn AI-systemen moeilijk om goed geconfigureerd te krijgen, vragen ze constante opvolging en monitoring, en veel werkuren door specialisten. Een dure zaak, daarom kan het geen kwaad om eerst grondig na te gaan: wat is eigenlijk het probleem dat we willen oplossen? Is dat welgedefinieerd en goed afgelijnd? Wat is de situatie vandaag en waar willen we naartoe? Weegt de geschatte ROI van een AI-oplossing wel op tegen die van een aanpak met traditionele IT of zelfs manueel werk? Heb je die andere opties überhaupt overwogen?

2. Zijn de succescriteria (KPIs) goed gekozen, gedefinieerd en meetbaar?

Een enkel AI-systeem lost veelal een klein, welomschreven probleem op. Allerlei criteria kunnen aangewend worden om te meten of dat ook voldoende goed gebeurt: precisie en recall, de tijdspanne nodig voor de berekening, de reductie in manueel werk, … Wat men ook hanteert als KPIs, goede meetbaarheid en opvolgbaarheid zorgen voor gemakkelijker monitoren of kwantificeren van de resultaten. Juist meten is niet noodzakelijk gemakkelijk. Welke accuraatheid wordt verwacht van het AI-systeem, wat is “fout” en wat is “correct”? Bij die vergelijkingen mag men gerust de kanttekening toevoegen dat ook mensen fouten maken als zij dezelfde taak manueel zouden uitvoeren. Is er al eens gemeten hoe vaak dat gebeurt en wat de gevolgen daarvan zijn? Vanaf wanneer zou het AI-systeem ook effectief tot verbetering leiden in de praktijk?

3. Welke praktische beperkingen zijn er?

Elk bedrijf dat niet dezelfde cashpositie heeft als pakweg Amazon of Google, past best zijn verwachtingen inzake AI wat naar verhouding aan. Talent is schaars, zeker als iemand naast AI en data science ook nog vertrouwd moet zijn met projectmanagement en de praktische aspecten van softwareontwikkeling. Zelfs met wat geluk op HR-vlak, is technologische infrastructuur nog steeds niet gratis. De trial-en-error methodiek die de ontwikkeling van AI-systemen vaak kenmerkt, vergt een zekere financiële ademruimte – zeker bij toepassingen waarbij 1 iteratie van 1 trainingsproces al tot een aardige energiefactuur leidt. Daarnaast zijn er ook de ethische en legale beperkingen, bijvoorbeeld inzake gebruik van gevoelige gegevens. Veel van de software aan de basis van een AI-systeem zal van derde partijen afkomstig zijn, of gebruikmaken van open source componenten of een (public) cloud – wat risico’s met zich meebrengt aangaande stabiliteit, onderhoudbaarheid, ondersteuning op langere termijn, licentiëring, confidentialiteit van gegevens, …

4. Zijn er genoeg middelen voor deployment, monitoring, onderhoud?

Een AI-systeem bouwen is 1 ding, het in productie zetten is nog iets anders. Er moeten heel wat waters doorzwommen worden voordat een stuk code ontwikkeld op enkele laptops uiteindelijk klaar is om 24/7 blootgesteld te worden aan de buitenwereld. De extra overhead gevormd door CD/CI, backups, testing, code review, etc. is onmisbaar voor de langere termijn maar kost allemaal tijd en geld. AI-projecten zijn anders dan klassieke softwareprojecten in die zin dat het niet afgelopen is eens de software is opgeleverd. Integendeel, bij oplevering begint het pas, en start een fase van actieve monitoring die schier eindeloos kan zijn: blijft de software wel doen wat ervan verwacht wordt in de buitenwereld? Zeker als nieuwe data wijzigt van karakter, zal je vaak actief moeten bijsturen.

5. Hoe transparant is dat allemaal?

De GDPR legt beperkingen op aan systemen die automatisch beslissingen nemen: er moet altijd de mogelijkheid zijn om de beslissing te laten (her)bekijken door een mens (art. 22). In het gehele AI-beleid dat de EU hoopt te voeren is transparantie een sleutelwoord, waarmee de EU tracht zich te onderscheiden van andere grootmachten. Het kunnen uitleggen waarom een AI-systeem tot een bepaald resultaat komt is belangrijk voor die transparantie, maar is niet noodzakelijk evident wanneer de trainingsdata onoverzichtelijk groot is, misschien niet onder eigen beheer ligt, of wanneer het aantal parameters van het model onoverzichtelijk groot is. Je wil ook niet met je mond vol tanden staan als ooit een journalist of wakkere burger je voorschotelt: is er een ethische evaluatie en Data Privacy Impact Assessment gebeurd, en waar kan ik mijn data raadplegen en beslissen wat ermee gebeurt?

Praktisch

Veel analyses kunnen erg langdradig zijn, dagen in beslag nemen en leiden tot rapporten van 50 bladzijden die niemand achteraf nog leest. Ook is niet alles even relevant voor elke usecase: een AI die een keukenrobot aanstuurt heeft niet dezelfde KPIs of foutentoleranties als eentje die een pacemaker aanstuurt. Om het overzicht te bewaren kan het handig zijn om, voor de eigen usecases, de belangrijkste vragen uit verschillende analyses mee te nemen in een eigen assessment, waarvan de resultaten bijvoorbeeld in een grafiek zoals deze kunnen weergegeven worden:

Dit was uiteraard maar een greep uit de bedenkingen die men kan maken bij de start van een nieuw AI-project. Zulke denkoefening, vooraleer geld en middelen in de uitvoering te steken, is de investering meestal wel dubbel en dik waard.

______________________

Dit is een ingezonden bijdrage van Joachim Ganseman, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

In een vorige blog had ik het reeds over het uitbesteden van gemeenschappelijke zaken, nodig voor meerdere ondernemingen, applicaties & diensten, aan een derde, hierin gespecialiseerde partij. Hetgeen deze laatste partij doet, noemen we “horizontale dienstverlening”; men opereert namelijk in een horizontale markt.

Nu wil ik graag enkele voorbeelden geven van hoe de overheid hetzelfde zou kunnen doen via een data-centric eGovernment (bovenop de vele zaken die ze reeds doet, met b.v. sterke eID authenticatie, de G-Cloud, en het eHealth platform).

Een aantal voorbeelden:

1. Chipkaarten

   In diezelfde vorige blog vernoemde ik de voordelen die er zouden ontstaan indien we het beheer van chipkaarten zouden afzonderen bij één horizontale chipkaartenbeheerder, en alle gebruikers van deze kaarten dan hiervan gebruik zouden kunnen maken. In een vergevorderd stadium zou het zo in principe zelfs mogelijk worden dat we via één enkele chipkaart van allerlei diensten, aangeboden door verschillende bedrijven (overheid of privé) gebruik kunnen maken, en we dus niet met een veelheid van de plastieken ondingen in onze portefeuille zouden moeten rondlopen. Dergelijke dienstverlener zou zelfs via een SaaS platform ook aan kleine ondernemingen een paar opties kunnen geven om b.v. aan een bestaande QR code op de chipkaart van een persoon, een klantenkaart te koppelen. Kortom, “one card to rule them all“. Misschien zou de overheid dit kunnen aanbieden via de eID?

2. “Waar-woon-ik-as-a-Service”

   Een eenvoudig, maar krachtig voorbeeld van nuttige en toch min of meer private data, zijn adressen en adreswijzigingen. Wat als elke adreswijziging die iemand onderging, onmiddellijk door alle (overheids-)diensten, door de post, door koeriers, en eventueel door een resem andere belanghebbenden was geweten? Dit scenario werkt als volgt:

   1. De burger verhuist, en de nodige (fysieke) controles gebeuren.
   2. De gemeenteambtenaar voert dit gegeven in (Dit gegeven valt trouwens onder de noemer “civic moment“: een belangrijke gebeurtenis in de levensloop van een burger (of bedrijf), die een aantal administratieve gevolgen kan triggeren).
   3. Vanaf dan zijn deze gegevens (zowel het nieuwe adres als de adresverandering) automatisch beschikbaar voor alle overheidsdiensten die er sowieso recht op hebben. Dit is mogelijk via het opvragen van de gegevens (b.v. via REST APIs), maar evenzeer kunnen sommige applicaties onmiddellijk op de hoogte worden gebracht (via Events). Bijgevolg kunnen deze diensten dus automatisch eventuele veranderde rechten en plichten van de burger die van zijn adres afhangen, aanpassen, en uiteraard ook hun briefwisseling naar het nieuwe adres richten.

      

   4. Daarnaast kan de overheid, als data custodian (zo noemen we de horizontale dienst van het databeheer), ook een applicatie aanbieden aan de burger zelf, waar deze de mogelijkheid krijgt om applicaties van andere bedrijven toegang te geven tot deze gegevens. Dit zou een beetje kunnen werken zoals een Google of Facebook account: ook tot deze accounts kan men (beperkte en specifieke) toegang verlenen aan andere applicaties. De burger zou dus b.v. op die manier aan Bpost de toestemming kunnen geven om deze gegevens automatisch te ontvangen. Vanaf dan zou de post automatisch naar het nieuwe adres kunnen worden doorgestuurd. Sterker nog: men zou het zo kunnen regelen, dat men brieven kan versturen op naam (en/of eventueel een unieke identifier die een burger voor zichzelf kan genereren in de toepassing), en dat de post deze dan vanzelf aan het juiste adres levert. Op die manier zou men niet meer overal zijn échte adres moeten opgeven en verhoogt men dus zelfs de privacy van de burger.
   5. Ook andere koeriersbedrijven zouden op deze dienst kunnen intekenen en door de burger geauthenticeerd kunnen worden om gebruik te maken van diens door de service gekende adres. Ik wacht trouwens nog steeds op de mogelijkheid om een account te creëren bij een koeriersbedrijf en daarna niet meer mijn adres te moeten geven in elke aparte webshop die ik gebruik, maar gewoon te kunnen aanvinken dat mijn gekozen koerier mijn adres reeds kent!

   In het voorbeeld maakte ik abstractie van een eventueel apart correspondentie-adres, of het gebruik van meerdere adressen, maar deze zou men even goed door de burger zelf kunnen laten beheren in een centraal aangeboden toepassing.

3. Civiele “Half-Open” Data

   Naast het adres heeft de overheid nog een schat van andere informatie over haar burgers en bedrijven. We moeten uiteraard rekening houden met de privacy van dergelijke data, maar desalniettemin kan deze functie van Data Custodian worden uitgebreid met heel wat interessante mogelijkheden. (Ik verwees in de chipkaartenblog reeds naar het gescheiden beheer van gegevensnetwerken versus de applicaties die ervan gebruik maken. De vortex van enablers maakt dit reeds perfect mogelijk.)

   Men zou bijvoorbeeld automatisch rechten kunnen afleiden uit bepaalde situaties die burgers ondergaan (verlies van werk, fysiek letsel, …) indien deze gebeurtenissen (dit zijn Civic Moments en Events!) en hun corresponderende nieuwe gegevens snel en automatisch door alle nodige diensten werden opgevangen.

   In het voorbeeld van het fysiek letsel zou de burger aan een dokter de toestemming kunnen geven om gegevens i.v.m. langdurige werkonbekwaamheid automatisch door te sturen naar instanties die hiervoor uitkeringen betalen. Een gelijktijdig gevolg, met communicatie naar de Fod SZ, zou kunnen zijn dat de burger automatisch een parkeerkaart voor personen met een handicap zou krijgen toegestuurd.

   Deze, en nog vele andere mogelijkheden die ontstaan door de juiste data op het juiste moment op de juiste plaats te krijgen, tonen nogmaals aan dat data-centric IT meer dan ooit van belang is (en – niet te vergeten – data-centric security).

Digitale transformatie

Het eGovernment heeft onlangs reeds een fenomenale stap vooruit gezet als horizontale dienstverlener via de G-Cloud, die ervoor zorgt dat men op infrastructuur- en middlewarevlak synergieën kon creëren. Nu is stilaan het moment aangebroken om verder te beginnen denken: ook bovenop de infrastructuur, binnen en tussen applicaties en vooral door hergebruik van gegevens, ligt er nog een goudmijn van mogelijkheden op ons te wachten. In dergelijke context praat men momenteel dan ook graag over “Digital Transformation” (een evolutie die eigenlijk al heel lang gaande is).

Tot nu toe focuste deze trend zich binnen de overheid daarbij vooral op kostenbesparingen: hoe hetzelfde doen, maar dan op een efficiëntere manier? Dit is uiteraard nuttig, maar Digitale Transformatie gaat veel verder dan dat (ook volgens de blogosphere, en ook wanneer het specifiek over Cloud gaat). De ware kracht van deze trend mag niet verloren gaan in oeverloze discussies over hoe alles goedkoper kan, of hoe de bestaande zaken met de nieuwe technologie efficiënter kunnen worden gemaakt.

Ik durf hierbij zelfs Bob Lewis bij te treden: IT plannen moeten niet gedreven worden door de noden van de business, maar de business strategie moet gedreven worden door de nieuw beschikbare technologische mogelijkheden!

Welnu: de technologieën die een grote evolutie mogelijk maken, zijn gearriveerd. Laten we onze inspiratie de vrije teugels geven, en bedenken wat voor interessante diensten we nog kunnen bieden, aan zowel de ambtenaren van ons land, als aan zijn burgers en bedrijven.