Enterprise AI: begin met het proces, niet het model

Het gesprek over enterprise AI begint vaak met het model: welk model redeneert beter, wat kost minder, wat heeft meer context, of kan meer tools gebruiken. In een bedrijf komt die beslissing later.

Eerst moeten we definiëren naar welk operationeel resultaat we op zoek zijn, welke informatie het systeem kan gebruiken, welke acties het kan uitvoeren, welk foutenniveau aanvaardbaar is en wat er moet gebeuren als de zaak verder gaat dan verwacht.

1. Een model is geen bedrijfssysteem

Een model kan samenvatten, classificeren, extraheren, opschrijven, vergelijken of voorstellen. Om herhaaldelijk waarde te kunnen creëren, heb je een omgeving nodig die deze mogelijkheid omzet in een gecontroleerde operatie.

Die omgeving omvat bronnen van waarheid, instructies, tools, machtigingen, gebruikersidentiteit, validaties, limieten, activiteitenregistratie, afhandeling van uitzonderingen en daaropvolgende actie.

Een demo kan werken met een schoon document en een goed geformuleerde vraag. De operatie moet onvolledige informatie, onverwachte formaten, tegenstrijdige gegevens, verschillende gebruikers, kapotte integraties en situaties overleven die niemand in de demo heeft opgenomen.

AI brengt capaciteit. Het systeem zet dat vermogen om in een gecontroleerd resultaat.

2. Begin met een processtatistiek

‘AI gebruiken’ is geen zakelijk doel. “De bestandsclassificatietijd verkorten zonder het aantal fouten te vergroten”, “voorstellen sneller voorbereiden met behoud van menselijke beoordeling” of “verzoeken detecteren die aandacht nodig hebben voordat een SLA wordt overschreden” zijn operationele doelstellingen.

Definieert een primaire metriek en verschillende vangrailstatistieken. Als je de snelheid optimaliseert, let dan op de kwaliteit. Als u de autonomie optimaliseert, let dan op uitzonderingen. Als u de kosten optimaliseert, monitor dan de klantervaring.

3. Ontwerp acht lagen vóór productie

1. Doelstelling

Welk resultaat zou moeten verbeteren en hoe weten we of het is verbeterd.

2. Trigger

Waarmee het systeem start: een verzoek, een document, een statuswijziging, een gesprek of een planning.

3. Toegang

Welke gegevens heb je minimaal nodig en hoe valideer je dat deze aanwezig zijn?

4. Context

Welke bronnen u kunt raadplegen, welke prevaleert bij conflicten en welke informatie u niet mag afleiden.

5. Redenering

Welke cognitieve taak het uitvoert: classificeren, extraheren, vergelijken, genereren, prioriteren of binnen bepaalde grenzen beslissen.

6. Actie

Welke systemen kunt u raadplegen of aanpassen? Het lezen van een CRM en het verzenden van een betaling zijn zeer verschillende risiconiveaus.

7. Controle

Wat heeft goedkeuring nodig, welke drempels zijn er en welke omstandigheden vereisen dat er gestopt moet worden.

8. Waarneembaarheid

Wat wordt vastgelegd om inzicht te krijgen in kwaliteit, kosten, fouten, beslissingen en gedrag in de loop van de tijd.

4. De bron van de waarheid is belangrijker dan de aanleiding

Als een beleid, prijs, klantstatus of contractueel document in meerdere versies bestaat, kan het model een organisatorische tegenstrijdigheid niet op magische wijze oplossen.

Definieert welke repository de leiding heeft, wie deze onderhoudt en hoe de huidige versie wordt geïdentificeerd. Als het systeem context uit meerdere bronnen ophaalt, stelt u autorisatieprioriteiten en filters in.

AI kan met grote flexibiliteit informatie vinden, maar die flexibiliteit is geen vervanging voor data governance.

5. Scheid kennis van actie

Een systeem dat een vraag beantwoordt en een systeem dat de wereld verandert, mogen niet op dezelfde manier worden behandeld.

Het is handig om de architectuur in twee stappen te verdelen:

1. Bepaal wat er moet gebeuren.
2. Autoriseer en voer de actie uit.

Door deze scheiding kunt u deterministische validaties, machtigingen en goedkeuringen toepassen voordat u gegevens aanraakt, communicatie verzendt of transacties uitvoert.

6. Vraag niet “kun je het doen?”, maar vraag “moet je het alleen doen?”

De mate van autonomie moet afhangen van de kosten van de fout, de omkeerbaarheid en het gemak waarmee kan worden opgemerkt dat er iets mis is gegaan.

Menselijk toezicht mag geen decoratieve knop zijn. De toezichthoudende persoon heeft voldoende context nodig, autoriteit om in te grijpen en een beoordelingslast die compatibel is met het volume.

7. Vermijd “menselijke goedkeuring” die niet kan werken

Als een persoon honderden door AI gegenereerde beslissingen ontvangt en slechts enkele seconden heeft om deze te beoordelen, kan goedkeuring een formaliteit worden.

Ontwerp de beoordeling zo dat deze de informatie toont die nodig is om te beslissen: bron, bewijsmateriaal, mate van vertrouwen als deze bestaat, voorgestelde wijzigingen en consequenties van goedkeuring.

Het definieert ook wanneer een beoordeling verplicht is en wanneer het systeem direct kan handelen.

8. Beheer risico's op basis van impact en context

Het AI RMF-framework van NIST stelt voor om AI-risico’s continu en contextueel te beheren, waarbij rekening wordt gehouden met de impact, rollen, metingen en governance gedurende de hele levenscyclus. NIST beveelt ook aan om processen voor menselijk toezicht te definiëren en de risico's en voordelen van systeemcomponenten in kaart te brengen.

In de Europese Unie stelt de AI-wet specifieke eisen vast voor systemen die als hoog risico zijn geclassificeerd, waaronder risicobeheer, gegevensbeheer, documentatie, administratie, transparantie, menselijk toezicht, nauwkeurigheid, robuustheid en cyberbeveiliging. Niet alle AI-systemen brengen een hoog risico met zich mee; De classificatie is afhankelijk van het gebruik en het kader dat door de verordening wordt gedefinieerd.

Voor een zakelijk project kan een eenvoudige matrix elke actie evalueren door:

• Omvang van mogelijke schade.
• Waarschijnlijkheid van fouten.
• Detecteerbaarheid.
• Omkeerbaarheid.
• Gegevensgevoeligheid.
• Impact op mensen.
• Wettelijke of contractuele verplichtingen.

9. Definieer machtigingen met de minste bevoegdheden

Het systeem mag alleen de machtigingen hebben die nodig zijn voor zijn werking. Als u bestellingen moet lezen, hoeft u niet noodzakelijk klanten te bewerken. Als u concepten opstelt, heeft u niet noodzakelijkerwijs verzendbaarheid nodig.

Wanneer een tool gevoelige acties toestaat, introduceert deze limieten: maximumbedragen, recordtypen, toegestane omgevingen, geautoriseerde domeinen of acties die altijd goedkeuring vereisen.

10. Gebruik het model niet voor regels die mogelijk deterministisch zijn

Het valideren van het e-mailformaat, het controleren van een maximumbedrag, het verifiëren dat er toestemming is of het voorkomen van een actie buiten kantooruren zijn regels die doorgaans betrouwbaarder zijn als deterministische logica.

Gebruik AI waar het waarde toevoegt: dubbelzinnig taalgebruik, flexibele classificatie, tekstextractie, synthese of beslissingsondersteuning. Combineer het met traditionele software voor limieten en controles.

11. Evalueer gedrag, niet indrukken

Maak vóór de productie een reeks cases die representatief zijn voor het echte werk. Omvat normale, dubbelzinnige, onvolledige, ongunstige en grensgevallen.

Bepaal voor elk geval welk resultaat aanvaardbaar is. De evaluatie kan het volgende meten:

• Nauwkeurigheid van classificatie.
• Correcte winning van velden.
• Naleving van regels.
• Gebruik van geautoriseerde bronnen.
• Correcte schaalverdeling.
• Kwaliteit van de voorgestelde actie.
• Latentie.
• Kosten.

Het is niet voldoende om iemand te vragen of het antwoord ‘goed lijkt’. Een tekst kan uitstekend klinken en gebaseerd zijn op de verkeerde gegevens.

12. Test integratiefouten

Het systeem moet weten wat het moet doen als een API niet meer reageert, een inloggegevens verlopen, een database gedeeltelijke gegevens retourneert of een tool een actie te laat bevestigt.

Ontwerp idempotence wanneer er een risico bestaat op dubbele acties, gecontroleerde nieuwe pogingen, time-outs en tussenliggende toestanden waardoor u weet wat er werkelijk is uitgevoerd.

13. Neem voldoende op om te onderzoeken

Waarneembaarheid moet het mogelijk maken antwoorden te geven op de volgende vragen: welke input het systeem heeft ontvangen, welke context het heeft gebruikt, welke beslissing het heeft genomen, welk instrument het heeft opgeroepen, welk resultaat het heeft ontvangen en wat er daarna is gebeurd.

Niet alles moet voor onbepaalde tijd worden bewaard. Het ontwerp van logs moet de privacy, veiligheid en dataminimalisatie respecteren.

14. Beheers de kosten en latentie als onderdeel van het product

Een technisch correcte stroom is mogelijk niet levensvatbaar als deze te lang duurt of meer kost dan de waarde die deze oplevert.

Meet de kosten per case en latentieverdelingen. Kijk vooral naar complexe gevallen, omdat deze vaak meer context, meer telefoontjes en meer tools vergen.

Bepaal vervolgens waar u een krachtiger model, een kleiner model, deterministische logica of cache wilt gebruiken.

15. Ontwerp de operatie na de lancering

AI elimineert onderhoud niet. Het introduceert een nieuwe laag die ook in de loop van de tijd verandert.

16. Versieprompts, tools en evaluaties

Als je instructies, model, tools of bronnen wijzigt, verandert het gedrag van het systeem. Behandel het als een nieuwe versie.

Voer de evaluatiesuite uit vóór de productie en vergelijk de resultaten. Dit vermindert onzichtbare regressies.

17. Verschil tussen modelfalen, procesfalen en datafalen

Wanneer een uitvoer onjuist is, classificeert u de oorzaak. Als het model een instructie niet begreep, is de oplossing anders dan wanneer de bron een verouderde prijs bevatte of als niemand had gedefinieerd wat er in dat geval moest gebeuren.

Deze taxonomie vermijdt dat u alle problemen probeert op te lossen door de prompt te wijzigen.

18. Hoe u de eerste use case kiest

Zoek naar een herhaalde, meetbare situatie, met toegankelijke gegevens en beheersbare foutenkosten. Er moet een baseline zijn en een persoon die het resultaat kan valideren.

Een goed eerste geval heeft meestal:

• Voldoende volume.
• Waarneembaar resultaat.
• Gegevens beschikbaar.
• Omkeerbare of controleerbare actie.
• Beheersbare uitzonderingen.
• Voordeel dat meetbaar is.

Bovendien moet het herbruikbare mogelijkheden genereren: authenticatie, toegang tot gegevens, evaluatie, waarneembaarheid, afhandeling van uitzonderingen en controles.

19. Architectuurvoorbeeld: verzoekclassificatie

Hypothetisch voorbeeld: Een bedrijf ontvangt verzoeken per e-mail en formulier. Het doel is om ze te classificeren en aan het juiste team toe te wijzen.

1. Het systeem ontvangt het verzoek.
2. Valideer dat er minimale informatie bestaat.
3. Raadpleeg een geautoriseerde bron om de klant of het contract te identificeren.
4. AI classificeert intentie en prioriteit.
5. Deterministische regels valideren dat prioriteit de grenzen niet overschrijdt zonder bewijs.
6. Gevallen met een laag vertrouwen worden ter beoordeling verzonden.
7. Normale zaken worden aangemaakt in het ticketingsysteem.
8. Het resultaat en het eindklassement worden vastgelegd.
9. Menselijke correcties voeden toekomstige evaluaties.

AI is slechts stap 4. De bedrijfswaarde hangt af van het hele systeem.

20. Tekenen dat je er nog niet klaar voor bent

• Er is geen bron van waarheid.
• Je kunt niet uitleggen wat resultaat succes betekent.
• Niemand is eigenaar van het proces.
• De organisatie weet niet welke acties goedkeuring behoeven.
• Er is geen manier om fouten op te sporen.
• De zaak hangt af van gegevens die niet op betrouwbare wijze toegankelijk zijn voor het systeem.
• Het enige argument is: “de concurrentie gebruikt AI.”

Conclusie

Het voordeel van een bedrijfssysteem met AI komt niet voort uit het kiezen van het meest flitsende model. Het komt voort uit het integreren van probabilistisch vermogen binnen een helder proces, met geautoriseerde informatie, limieten, vergunningen, toezicht, evaluatie en bediening.

Wanneer deze elementen zijn ontworpen, kan het veranderen van modellen een technische beslissing zijn. Als dat niet het geval is, lost geen enkel model het gebrek aan proces op.

Officiële bronnen en referenties

• NIST – AI-risicobeheerkader.
• NIST AIRC—AI RMF Core, inclusief praktijken op het gebied van menselijk toezicht, het in kaart brengen van risico's en controles.
• NIST: Generatief AI-profiel.
• Europese Commissie — structuur van de AI-wet, vereisten voor systemen met een hoog risico en daarmee samenhangende verplichtingen.
• Europese Commissie — gids over verplichtingen van leveranciers en exploitanten.

In dit artikel worden de ontwerp- en werkingscriteria uitgelegd; Het is geen vervanging voor juridisch advies om specifieke verplichtingen op grond van de AI-wet of andere regelgeving vast te stellen.

Als je wilt zien hoe we de analyse structureren voordat we een systeem implementeren, zie dan hoe wij werken.