Van Vage AI-Vraag Naar Afgebakende Opdracht: Het Scopen Van Een AI-Project

Gepubliceerd door de LLMnet Consultancy Redactie | Leestijd: ca. 8 minuten

Het is een scenario dat we in de AI-consultancy vrijwel wekelijks tegenkomen. Een directielid of manager leest een veelbelovend artikel over Generatieve AI, roept een team bijeen en zegt: "We moeten iets met ChatGPT doen voor onze interne documenten." Vervolgens wordt deze opdracht over de schutting gegooid bij de IT-afdeling of een innovatieteam.

Het resultaat? Eindeloze "proof of concepts" die nergens toe leiden, gefrustreerde ontwikkelaars, ontspoorde budgetten en uiteindelijk de conclusie dat "AI toch nog niet klaar is voor ons bedrijf". Het probleem ligt in de meeste gevallen echter niet bij de technologie, maar bij een fundamenteel gebrek aan scoping.

In dit artikel leggen we exact uit hoe u een vage AI-vraag omzet naar een strak afgebakende, realistische en uitvoerbare opdracht. We behandelen het formuleren van de juiste acceptatiecriteria, het vastleggen van randvoorwaarden en we bieden een direct bruikbaar AI Project Scoping Canvas.

Waarom is het scopen van AI anders dan traditionele IT?

Voordat we de methodiek in duiken, is het cruciaal om te begrijpen waarom u een AI-project niet op dezelfde manier kunt scopen als de bouw van een reguliere webapplicatie of het uitrollen van een nieuw CRM-systeem.

Traditionele IT is deterministisch. Als u in een webwinkel op 'Bestellen' klikt, verwacht u 100 van de 100 keer hetzelfde resultaat. De regels zijn door mensen geprogrammeerd (als X, dan Y). Bij deterministische systemen kunt u dus binaire acceptatiecriteria schrijven: een feature werkt, of hij werkt niet.

AI, en specifiek Large Language Models (LLM's) of machine learning systemen, zijn probabilistisch. Ze werken op basis van waarschijnlijkheden. Het model genereert een output die statistisch gezien het meest logisch is. Dit betekent dat 100% foutloosheid een onmogelijk streven is. U kunt altijd te maken krijgen met onverwachte output, variaties in formulering of zelfs hallucinaties (waarbij het model feitelijk onjuiste informatie vol overtuiging presenteert). Leer overigens meer over het voorkomen van LLM hallucinaties op ons educatieve domein.

Daarnaast is bij AI de data onderdeel van de logica. Bij traditionele software levert slechte data hooguit een leeg veld of een foute rapportage op. Bij AI leidt slechte of incomplete trainings- of contextdata tot een fundamenteel falend systeem. U kunt dus geen AI-project scopen zonder de onderliggende data te scopen.

Stap 1: Het echte probleem scherp krijgen (Problem Framing)

De eerste stap in het scopen is het negeren van de technologie. "We willen een AI-chatbot" is een oplossing, geen probleem. De vraag is: welk zakelijk of operationeel probleem proberen we op te lossen?

Gebruik de 'Five Whys' (Vijf keer 'Waarom') techniek om tot de kern te komen:

Ineens is het probleem niet meer een gebrek aan AI, maar een synchronisatieprobleem in de backend. Mocht u na deze analyse toch uitkomen op een AI-toepassing (bijvoorbeeld het automatisch samenvatten van lange, complexe juridische dossiers ter voorbereiding van advocaten), dan heeft u nu een kraakhelder doel voor ogen: Tijdsbesparing realiseren bij de voorbereiding van juridische dossiers.

Stap 2: Succescriteria en Acceptatiecriteria Formuleren

Nu het probleem helder is, moeten we definiëren wanneer het project geslaagd is. Hierbij maken we een hard onderscheid tussen Succescriteria (business perspectief) en Acceptatiecriteria (technisch en functioneel perspectief).

Succescriteria (De Business Case)

Succescriteria gaan over de waarde die het project oplevert. Bijvoorbeeld:

Tip: Zorg dat u de huidige situatie (de nulmeting) kent, anders kunt u het succes niet aantonen. Wilt u dit financieel maken? Lees dan ons artikel over het berekenen van de ROI van AI-projecten.

Acceptatiecriteria (De Techniek & Functionaliteit)

Dit is waar probabilistische systemen lastig worden. U kunt niet schrijven: "Het model mag nooit een fout maken." U moet nadenken over acceptabele foutmarges en snelheden.

Belangrijke aanname bij AI Acceptatiecriteria

Accepteer dat een AI-systeem zelden beter zal presteren dan de 'ground truth' of een menselijke expert met beperkte tijd. Stel als doel dat het systeem 'goed genoeg' is om de business value te behalen, niet dat het perfect is. Een mens maakt immers ook fouten.

Voorbeelden: Goed vs. Slecht

Domein Slecht Acceptatiecriterium (✗) Goed Acceptatiecriterium (✓)
Nauwkeurigheid Het systeem mag geen enkele fout maken bij het classificeren van inkomende documenten. Het systeem classificeert in minimaal 85% van de gevallen het document correct. Bij een betrouwbaarheidsscore onder de 70% routeert het systeem het document naar een menselijke medewerker (Human-in-the-Loop).
Snelheid / Latency De AI moet direct antwoorden. De Time-To-First-Token (TTFT) is gemiddeld minder dan 1.5 seconden en de totale generatietijd per antwoord (tot max 500 woorden) overschrijdt de 5 seconden niet in 95% van de gevallen.
Reikwijdte (Scope) De chatbot moet alle vragen van klanten over hun producten kunnen beantwoorden. De chatbot ondersteunt in deze fase specifiek drie flows: Wachtwoord vergeten, Status van bestelling (API-koppeling) en Retourbeleid raadplegen. Alle overige intents resulteren in een hand-over.
Veiligheid & Guardrails De AI mag geen rare dingen zeggen tegen klanten. Bij het invoeren van prompts gerelateerd aan politiek, geweld, of concurrentie, of bij prompt-injectie pogingen, retourneert het systeem een vooraf gedefinieerd weigeringsbericht. Dit wordt wekelijks getest met een rode-team testset van 100 injectie-prompts.

Stap 3: De Scope Afbakenen (In/Out)

Scope creep (het ongemerkt steeds groter worden van het project) is de sluipmoordenaar van AI-initiatieven. Tijdens een project ontdekken ontwikkelaars vaak nieuwe mogelijkheden van een model, of krijgt de business nieuwe ideeën ("Oh, kan hij dit óók? Laten we dat toevoegen!").

Het is essentieel om keihard vast te leggen wat Out of Scope is. Soms is de Out of Scope lijst belangrijker dan de In Scope lijst.

Stap 4: Aannames en Risico's Documenteren

Bij de start van een AI-traject weet u nog niet alles. De kwaliteit van uw data is vaak een zwarte doos totdat u ermee aan de slag gaat. Documenteer daarom uw aannames en identificeer direct de projectrisico's.

Veelvoorkomende aannames:

Stap 5: Data- en Toegangsvereisten (Governance)

Zonder data, geen bruikbare AI. Voordat er één regel code wordt geschreven of één prompt wordt ge-engineerd, moet duidelijk zijn welke data benodigd is en hoe deze wordt ontsloten.

Stel uzelf de volgende vragen:

  1. Locatie: Waar staat de data nu? (SharePoint, AWS S3, SQL database, externe leverancier?)
  2. Formaat: Is de data gestructureerd (tabellen) of ongestructureerd (tekst, audio, video)?
  3. Privacy & Security: Bevat de data Persoonlijk Identificeerbare Informatie (PII)? Moet deze geanonimiseerd worden voordat deze naar een LLM wordt gestuurd? Dit is een kritiek punt onder de AVG/GDPR. Meer hierover leest u in ons artikel over AI-governance in het MKB.
  4. Toegangsrechten: Als de AI namens medewerker X een zoekopdracht doet in SharePoint, mag de AI dan ook HR-documenten zien die medewerker X normaliter niet mag inzien? Het inregelen van Role-Based Access Control (RBAC) in combinatie met AI is vaak het meest complexe deel van het traject.

Stap 6: Een Realistische Fasering (Van Pilot naar Productie)

Een succesvol AI-project wordt zelden in één keer van begin tot eind gebouwd en gelanceerd (de 'Big Bang' aanpak). Bij AI leert u gaandeweg hoe het model op uw specifieke bedrijfsdata reageert. Wij adviseren daarom altijd een gefaseerde aanpak. Als u dit vastlegt in uw projectscope, managet u direct de verwachtingen van de directie.

Het Concrete AI Project Scoping Canvas

Om u te helpen bij het daadwerkelijk vastleggen van al deze elementen, hebben we het LLMnet AI Project Scoping Canvas ontwikkeld. Dit is een pragmatisch format dat u direct kunt kopiëren naar uw eigen tekstverwerker of wiki-systeem (zoals Confluence of Notion).

Zorg dat dit document wordt ingevuld tijdens een kick-off meeting waar zowel de technische lead, de data-eigenaar, als de zakelijke opdrachtgever bij aanwezig zijn.

📋 AI Project Scoping Canvas
1. PROJECT INFORMATIE Projectnaam: Opdrachtgever (Sponsor): Technisch Lead: Startdatum: Beoogde Opleverdatum Pilot: 2. HET PROBLEEM (Problem Statement) - Wat is het huidige probleem of de huidige inefficiëntie? (Benoem de pijn, geen AI-oplossing) - Huidige procesbeschrijving (in 3 zinnen): - Huidige (gemeten) tijdsbesteding of kosten verbonden aan dit probleem: 3. SUCCESCRITERIA (Business Value) - Doel 1: (Bijv. 20% reductie in tijd besteed aan X) - Doel 2: (Bijv. X euro besparing per kwartaal) - Hoe wordt dit gemeten? (Welke metric/dashboard gebruiken we hiervoor) 4. ACCEPTATIECRITERIA (Technisch & Functioneel) - Kwaliteit/Accuratesse: (Bijv. "In min. 80% van de test-cases levert het systeem het juiste antwoord.") - Performance/Snelheid: (Bijv. "Antwoord binnen 3 seconden.") - Fallback/Error-handling: (Wat moet er gebeuren als het model het antwoord niet weet?) 5. SCOPE AFBAKENING IN SCOPE: - - - OUT OF SCOPE (Expliciet uitgesloten): - - - 6. DATA- EN INTEGRATIEVEREISTEN - Bronnen: (Specificeer welke systemen: bijv. AFAS, Exact, lokaal fileshare) - Toegang: (Wie moet API-keys leveren of firewalls openzetten?) - Privacy: Bevat de data persoonsgegevens? [ ] Ja [ ] Nee - Anonimisering benodigd? [ ] Ja [ ] Nee 7. BELANGRIJKSTE AANNAMES EN RISICO'S - Aanname 1: - Aanname 2: - Risico 1: (Bijv. LLM API limieten worden overschreden) -> Mitigatie: ... - Risico 2: (Bijv. Adoptie door medewerkers valt tegen) -> Mitigatie: ... 8. FASERING & GO/NO-GO MOMENTEN - Datum Haalbaarheidscheck (Go/No-go): - Datum Proof of Concept presentatie: - Datum start MVP/Pilot met eindgebruikers: 9. AKKOORD [ ] Zakelijk opdrachtgever akkoord [ ] Technisch lead akkoord [ ] Data owner / Security officer akkoord

Conclusie

Het succes van een AI-project wordt niet bepaald door het kiezen van het nieuwste model met de meeste parameters, of door het schrijven van de meest ingenieuze prompts. Het succes wordt, net als in de bouw, bepaald in de tekenkamer.

Door de tijd te nemen om uw AI-project rigoureus te scopen – door het echte probleem te identificeren, probabilistische acceptatiecriteria te hanteren en de data-eisen keihard vast te leggen – voorkomt u dat uw project strandt in de beruchte "pilot vagevuur" fase. Gebruik bovenstaand canvas bij uw volgende AI-initiatief en u zult merken dat discussies over verwachtingen en resultaten aanzienlijk soepeler zullen verlopen.