Iedereen heeft AI aangeschaft. Bijna niemand heeft het in de praktijk toegepast.

Het proces is vrijwel ongewijzigd gebleven

De afgelopen jaren hebben bedrijven toegang tot inlichtingen ingekocht.

Zij kochten copiloten. Chat-interfaces. Bedrijfsabonnementen. Interne assistenten. Toegang tot API’s. Modellen met grotere contextvensters, betere redeneringen en steeds indrukwekkendere benchmarks.

En toch ziet de dinsdagochtend binnen veel organisaties er opvallend hetzelfde uit als voorheen.

Er komt een e-mail binnen.

Iemand opent het.

Zij nemen daar informatie uit over.

Zij voeren die informatie in een ander systeem in.

Men vraagt aan een AI wat dit betekent.

Zij kopiëren het antwoord.

Zij keren terug naar het oorspronkelijke systeem.

Zij werken een veld bij.

Vervolgens sturen zij nog een e-mail waarin zij iemand informeren over wat er is veranderd.

Het model kan buitengewoon zijn.

Het proces is vrijwel ongewijzigd gebleven.

Dat onderscheid is van belang.

Mensen toegang geven tot AI is niet hetzelfde als AI in een bedrijfsproces integreren.

Een chatbot kan deze vraag beantwoorden.

Een operationeel systeem moet lezen, beslissen, valideren, handelen, registreren en herstellen.

Dat zijn zeer uiteenlopende verantwoordelijkheden.

En het verschil tussen beide is waar het grootste deel van het nuttige werk op het gebied van AI voor bedrijven zal plaatsvinden.

Iedereen beschikt over AI. Bijna niemand heeft het werk aangepast.

Begin met de zo eenvoudig mogelijke definitie.

Een taalmodel is software die buitengewoon goed is in het verwerken van rommelige menselijke informatie.

E-mails. PDF’s. Vrije-tekstnotities. Verzoeken van klanten. Opmerkingen uit het magazijn. Productbeschrijvingen. Contracten. Tickets. Afbeeldingen en documenten die niet als perfecte databaserijen binnenkomen.

Geef die informatie aan een model en het kan vaak de structuur eruit halen, de bedoeling classificeren, een situatie samenvatten of voorstellen wat er vervolgens zou moeten gebeuren.

Dat vermogen is krachtig.

Maar let op het woord voorstellen.

Het model weet niet zomaar welke databaserij de officiële bestelling vertegenwoordigt.

Het systeem weet niet automatisch of een klant een afleveradres mag wijzigen.

Het is onduidelijk of „READY” een geldige status is na „CANCELLED”.

Het systeem weet niet automatisch welk magazijnsysteem als referentie geldt, welke velden mogen worden gewijzigd, wie een uitzondering moet goedkeuren of wat er in een auditlogboek moet worden vastgelegd.

En het zorgt zeker niet voor een verbetering van uw bedrijfsvoering, louter en alleen omdat het een overtuigende alinea heeft opgeleverd.

Er moet nog iets anders zijn dat intelligentie met werk verbindt.

De meeste organisaties hebben dat bepaalde element nog niet ontwikkeld.

In plaats daarvan fungeert de medewerker als de integratielaag.

De medewerker haalt informatie uit het eigen systeem, voert deze in de AI in, wacht op een antwoord, beoordeelt dit, voert het resultaat terug en wijzigt handmatig het officiële dossier.

De AI is intelligent.

De werkstroom verloopt nog steeds handmatig.

Dit is de reden waarom zoveel AI-piloten tijdens een demonstratie spectaculair aanvoelen, maar een maand later vreemd genoeg onzichtbaar lijken.

De demonstratie bewijst dat het model de vraag kan beantwoorden.

De productieafdeling moet aantonen dat de organisatie veilig iets met het antwoord kan doen.

Dat zijn niet dezelfde problemen.

Een chatbot doet een voorstel. Een brug gaat een verbintenis aan.

Stelt u zich eens een team voor dat verantwoordelijk is voor het orderbeheer.

Er komt een e-mail binnen:

„Bestelling 4412 — 12 pallets, laadperron 3, vrijdag klaar.”

In de versie van AI met het zijtabblad merkt iemand de e-mail op.

Zij nemen het over.

Zij lanceren een chatbot.

Zij plakken het erin.

Het model vermeldt bestelling 4412, hoeveelheid 12 pallets, laadperron 3, leveringsdatum vrijdag. Uitstekend.

Vervolgens voert de medewerker deze vier waarden weer in het ordersysteem in.

Wij hebben u wat leeswerk bespaard.

Wij hebben de werkwijze niet herzien.

De persoon is nog steeds bezig met het overzetten van informatie tussen systemen.

Beschouw nu dezelfde gebeurtenis als een operationele AI-brug.

De e-mail komt binnen.

Die gebeurtenis start een handler.

De medewerker identificeert de betreffende bestelling.

Er wordt uitsluitend de informatie geladen die voor deze taak nodig is.

Hiermee wordt de relevante tekst en context naar het model verzonden.

Het model retourneert gestructureerde kandidaatvelden.

Deze velden worden getoetst aan een schema.

Er wordt rekening gehouden met bedrijfsregels.

Er wordt gekeken naar zelfvertrouwen.

Indien het resultaat geldig is, wordt het bestaande orderrecord bijgewerkt.

Indien er onduidelijkheid bestaat, wordt de zaak doorgestuurd naar een wachtrij voor uitzonderingsgevallen met een aangewezen verantwoordelijke.

Het resultaat wordt vastgelegd met voldoende metagegevens om later te kunnen begrijpen wat er is gebeurd.

Geen kopiëren. Geen plakken. Geen dubbele betekenis.

Geen mysterieuze chatbot-conversatie die in de browsergeschiedenis verdwijnt.

De AI is een gecontroleerde stap binnen het bestaande proces geworden. Dat is de brug.

Het belangrijkste gedeelte volgt nadat het model heeft geantwoord.

AI-demonstraties richten zich onevenredig sterk op inferentie.

Er wordt een opdracht ingevoerd. Er komt iets intelligents uit. Applaus.

In een operationeel systeem komt dat ongeveer halverwege het verhaal voor.

De netelige vraag is: Wat gebeurt er nu?

Stel dat het model order_id 4412, hoeveelheid 12, laadperron 3 en klaarstellingsdatum vrijdag retourneert.

Moeten die waarden onmiddellijk in de database worden bijgewerkt?

Natuurlijk niet.

Ten eerste kan de software deterministische vragen stellen.

Bestaat bestelling 4412? Wordt hier een hoeveelheid verwacht? Is laadperron 3 geldig voor deze locatie? Kan de leverdatum in dit stadium nog worden gewijzigd? Heeft de bron toestemming om die wijziging door te voeren? Voldoet de uitvoer aan het verwachte schema? Is de betrouwbaarheid hoog genoeg? Is voor een andere bedrijfsregel menselijke goedkeuring vereist?

Voor geen van deze vragen is kunstmatige intelligentie nodig.

En dat is nu juist het punt.

Een goede AI-architectuur vraagt het model niet om taken uit te voeren die gewone software betrouwbaarder kan uitvoeren.

Gebruik implicaties bij dubbelzinnigheid.

Gebruik software om de regels na te leven.

Gebruik ‘mensen’ bij gevolgonzekerheid.

Door die scheiding is het systeem goedkoper, begrijpelijker en veel moeilijker te misleiden.

Wat er werkelijk achter het scherm schuilgaat

Het chatvenster is zelden het product zelf.

Achter een bruikbaar operationeel AI-systeem schuilt doorgaans een keten die er ongeveer als volgt uitziet: operator → interface → registratiesysteem → opgeslagen toestand → handler → model → validatie → terugschrijven.

Afhankelijk van de werkstroom kunnen meerdere van deze onderdelen worden samengevoegd tot één aanvraag. Het principe blijft hetzelfde.

Het model zweeft niet als een alwetend brein boven de organisatie. Het wordt door software ingeschakeld voor een specifieke taak.

Die software bepaalt wat het model mag voorlezen. De software bepaalt in welk formaat het moet worden teruggestuurd. De software bepaalt of het antwoord aanvaardbaar is. En de software bepaalt wat er gebeurt als dat niet het geval is.

Dit is een veel minder glamoureuze beschrijving van AI. Het komt ook veel dichter in de buurt van de manier waarop serieuze AI-systemen daadwerkelijk van nut zijn.

De database is het contract. Het model is het voorstel.

Dit is een van de meest bruikbare mentale modellen voor het ontwerpen van operationele AI.

De database vormt het contract.

Niet letterlijk alleen een database. Het kan gaan om een ERP-, WMS-, CRM-, TMS- of ticketingsysteem, of een ander registratiesysteem.

Het punt is dat er ergens in de organisatie een persistente toestand bestaat waarop andere processen vertrouwen.

Een bestelling heeft een status. Een zending heeft een eigenaar. Een factuur heeft een bedrag. Een klant heeft rechten. Een dossier heeft een geschiedenis. Andere software handelt op basis van deze feiten.

Het model mag deze begrippen niet zomaar herdefiniëren.

In plaats daarvan: Het model stelt voor. Het systeem valideert. Het systeem voert uit.

Die grens verandert de manier waarop AI moet worden ontwikkeld.

Overweeg twee invalshoeken.

Invoer A: „Bestelling 4412 – 12 pallets, laadperron 3, klaar op vrijdag.” Het model haalt er een volkomen geldige structuur uit. Het schema wordt goedgekeurd. De bestelling bestaat. Het laadperron bestaat. De statusovergang is toegestaan. Het vertrouwensniveau is hoog. Het systeem voert de wijziging door.

Input B: „Ik denk dat de Anderson-bestelling waarschijnlijk ergens rond vrijdag moet worden verzonden. Misschien kunt u het gebruikelijke laadperron gebruiken.” Een mens begrijpt ongeveer wat deze persoon bedoelt. Een operationeel systeem zou zich hier veel terughoudender over moeten opstellen.

Welke bestelling van Anderson? Wat betekent „waarschijnlijk“? Welke vrijdag? Wat is „de gebruikelijke laadkade“?

Dit mag niet stilletjes uitmonden in een database-update, louter omdat een model dit kan genereren. Het moet met een foutmelding worden afgesloten. Stuur het naar een persoon. Vraag om opheldering. Houd de onzekerheid in stand.

Wachten is goedkoper dan het officieel dossier opzettelijk te vervalsen.

AI dient in het midden probabilistisch te zijn en aan de randen deterministisch.

Hier begint zich een bruikbare architectuur af te tekenen.

De invoergegevens kunnen rommelig zijn. De interpretatie kan probabilistisch zijn. Maar de grenzen rond die interpretatie moeten saai strikt zijn.

Dat levert ons een patroon op. Vóór de inferentie: bepaal wat het model kan waarnemen. Tijdens de inferentie: vraag om een afgebakend, gestructureerd resultaat. Na de inferentie: valideer het resultaat voordat iets als operationele waarheid wordt beschouwd.

Het model zou kunnen zeggen: „Dit lijkt een wijziging van de leverdatum te zijn.” Het omringende systeem vraagt: „Is dit een geldige wijziging van de leverdatum voor deze bestelling, afkomstig van deze bron, in deze fase, met voldoende zekerheid om door te gaan?”

Die vragen lijken op elkaar. Architectonisch gezien liggen ze mijlenver uit elkaar.

Het ene is gevolgtrekking. Het andere is controle. En productie-AI heeft beide nodig.

Waar de conclusie wordt getrokken, is een ontwerpkeuze, geen merkkeuze.

Zodra AI in aanraking komt met operationele gegevens, rijst onmiddellijk een andere vraag: Waar vindt de inferentie plaats?

Er is geen algemeen geldend antwoord.

Een cloudmodel-eindpunt kan zinvol zijn. Een specifieke regionale implementatie kan zinvol zijn. Een privéomgeving kan zinvol zijn. Lokale hardware kan zinvol zijn. Een hybride architectuur kan zinvol zijn.

De beslissing dient te worden gebaseerd op de werklast en de gegevens, en niet op welke modelaanbieder er toevallig die maand in de mode is.

In een cloudconfiguratie kan de operationele database precies blijven waar deze zich nu bevindt, terwijl de applicatie een bewust beperkte gegevenslading naar een inferentie-eindpunt verzendt. Alleen de informatie die nodig is voor de taak mag worden verzonden.

In een on-premises-configuratie kan inferentie plaatsvinden op infrastructuur waarover de organisatie rechtstreeks zeggenschap heeft. Dit vergroot de controle en zorgt ervoor dat de inferentie binnen de omgeving van de organisatie blijft, maar het brengt ook de verantwoordelijkheid voor hardwarecapaciteit, het aanbieden van modellen, upgrades, monitoring en beschikbaarheid onder uw eigen operationele verantwoordelijkheid.

Geen van beide architecturen is automatisch „beter“.

De juiste vraag is: Wat vereist deze werklast eigenlijk?

Latentie. Volume. Modelcapaciteit. Beveiliging. Gegevensclassificatie. Vereisten inzake gegevensopslag op het grondgebied. Kosten. Beschikbaarheid. Integratiebeperkingen.

Dit betreft technische input. De merkpositionering komt daarna.

Indien het werk binnen de EU moet blijven, maakt CodexCell gebruik van op Mistral gebaseerde implementaties die aan die vereisten inzake gegevensopslag voldoen. Microsoft Foundry en AWS Bedrock kunnen nog steeds worden geïntegreerd wanneer deze reeds deel uitmaken van uw omgeving, maar wij beschouwen deze als platformkeuzes, niet als bewijs van EU-gegevenssoevereiniteit.

Vijf situaties waarin deze aanpak zijn vruchten begint af te werpen

Dit alles doet er niet toe als de architectuur slechts een diagram blijft.

Waar komt een operationele AI-brug dan eigenlijk van pas?

Meestal op het punt waar ongestructureerde informatie aansluit bij een bestaand proces.

1. Verwerking van e-mail en documenten. Het handmatige proces komt veel voor. Iemand opent soortgelijke e-mails, PDF’s of bijlagen, zoekt het ordernummer, de klant, de datum, het bedrag of de referentie op en voert deze gegevens vervolgens in een ander systeem in. Met een koppeling in plaats daarvan zet het binnenkomende bericht het proces automatisch in gang. Het relevante document wordt opgehaald, het model haalt uitsluitend de goedgekeurde velden eruit en de software valideert het resultaat voordat er iets wordt teruggeschreven. Gevallen met een hoge betrouwbaarheid worden doorgestuurd naar het bestaande systeem. Alles wat onzeker is, gaat naar een controlemachine. Het model vervangt het orderbeheersysteem niet. Het neemt het repetitieve lezen en opnieuw invoeren rondom dit proces weg.

2. Uitzonderingen in het magazijn. Een scanner meldt iets onverwachts. Er ontbreekt een pallet. Een hoeveelheid klopt niet. Een order kan niet worden voltooid. De nuttige rol van AI is niet om de operationele waarheid te verzinnen. Het kan de aantekening van de medewerker interpreteren, de uitzondering categoriseren, relevante context verzamelen en de juiste aanpak aanbevelen. De workflow bepaalt nog steeds wat er vervolgens kan gebeuren. De magazijnmedewerker heeft geen behoefte aan nog een chat-applicatie. Hij of zij wil dat de uitzondering verschijnt op de plek waar uitzonderingen al worden afgehandeld.

3. Goedgekeurde bedrijfskennis. Medewerkers vragen herhaaldelijk wat het retourbeleid is, welke specificatie van toepassing is, welke procedure momenteel geldt en wat zij deze klant moeten vertellen. Een bruikbaar kennissysteem mag geen antwoorden geven op basis van willekeurige, vaag relevante tekst die een model zich herinnert. Het moet informatie ophalen uit bronnen die door de organisatie zijn goedgekeurd, een antwoord genereren dat op die bronnen is gebaseerd en aangeven waar dat antwoord vandaan komt. Als de bronnen een antwoord niet ondersteunen, kan het juiste resultaat simpelweg zijn: Ik weet het niet. Dat is een functie.

4. Intelligente overdrachten. Het ene team rondt zijn deel van het werk af en een ander team moet het overnemen. Tegenwoordig leest iemand vaak de zaak door en beslist vervolgens waar deze naartoe moet. Wanneer die beslissing op een duidelijke logica berust, volstaan eenvoudige regels. Wanneer deze afhangt van vrije tekst, bijlagen of een bredere context, kan inferentie helpen bij het classificeren van de zaak, het voorbereiden van de overdracht en het automatisch doorsturen van zaken met een hoge betrouwbaarheid. Alles wat onzeker is, wordt geëscaleerd ter beoordeling. De intelligentie blijft binnen de overdracht zelf, in plaats van een afzonderlijke tool te worden.

5. De organisatie een nieuwe manier van werken bijbrengen. Zelfs een goed opgezet systeem kan falen als mensen niet begrijpen hoe het werk erdoorheen moet verlopen. AI kan helpen de context uit te leggen, volgende stappen voor te stellen en gebruikers door onbekende processen te begeleiden, maar voor een succesvolle implementatie is meer nodig dan alleen het toevoegen van een gespreksassistent. De beoogde workflow moet eenvoudiger zijn dan de tijdelijke oplossing. De verantwoordelijkheid moet duidelijk zijn, uitzonderingen moeten een vastomlijnd traject volgen en mensen moeten kunnen zien wanneer de AI heeft ingegrepen en deze indien nodig kunnen overschrijven. Anders wordt het nieuwe systeem wellicht genegeerd en keert de oude spreadsheet stilletjes terug.

Als mensen het niet kunnen volgen, hebt u weer een ongebruikt tabblad gecreëerd.

Er is nog één laatste fout die de aandacht verdient, omdat deze anderszins goede AI-projecten tenietdoet.

Teams ontwerpen de modelintegratie. Zij ontwerpen de API. Zij ontwerpen de wijzigingen in de database. Zij ontwerpen prompts, evaluatiesets en veiligheidsmaatregelen. Vervolgens deelt iemand de volgende mededeling aan de medewerkers mee: „Hier is de nieuwe AI-tool.”

Dat is geen adoptie.

Adoptie betekent een andere loopbaanrichting inslaan.

Waar begint de medewerker? Wat verschijnt er automatisch? Wat doet de AI zonder dat daar om wordt gevraagd? Wat doet de AI nooit zonder toestemming? Waar doen zich onduidelijke gevallen voor? Wie is daarvoor verantwoordelijk? Hoe kan een persoon het resultaat corrigeren? Wat gebeurt er na de correctie? Kan iemand zes maanden later nog begrijpen waarom het dossier is gewijzigd?

Die vragen hebben net zo goed betrekking op productontwerp als op AI-architectuur.

Als de goedgekeurde procedure trager of onduidelijker is dan het openen van ChatGPT in een ander tabblad, zullen mensen het andere tabblad gebruiken.

En bovendien heeft het bedrijf zijn bedrijfsvoering niet veranderd. Het heeft slechts een tweede interface aangeschaft.

Het doel is geen autonome AI.

Het gaat om gecontroleerde hefboomwerking.

Er is enorme aandacht voor agenten die meer kunnen doen. Meer hulpmiddelen gebruiken. Meer stappen plannen. Langer actief blijven. Zelfstandig meer beslissingen nemen.

Die vaardigheden zullen van belang zijn.

Maar in de meeste bedrijven is de directe kans veel minder spectaculair.

Er zijn duizenden kleine momenten waarop een persoon momenteel fungeert als schakel tussen informatie en software.

Lees dit. Begrijp dit. Zoek het juiste record. Haal deze waarden eruit. Bepaal naar welke wachtrij het wordt doorgestuurd. Bereid de volgende stap voor. Werk het systeem bij. Markeer de afwijkende gevallen.

Dat is al een enorm oppervlak.

De bedrijven die AI bruikbaar maken, zullen niet noodzakelijkerwijs de bedrijven zijn met de meest autonome agenten.

Zij zijn degenen die precies begrijpen waar onzekerheid thuishoort binnen een verder gecontroleerd systeem.

Het model kan probabilistisch zijn.

De operatie mag niet slordig verlopen.

Het model is niet de transformatie.

De werkwijze is als volgt.

Binnenkort zal toegang tot krachtige modellen de norm zijn.

De interessante vraag zal niet langer zijn: “Welke AI gebruikt u?”

De vraag luidt: „Wat gebeurt er anders doordat het er is?”

Wordt de factuur in het systeem ingevoerd zonder dat iemand deze moet invoeren?

Wordt de afwijking in het magazijn nog op tijd aan de planner doorgegeven, zolang deze nog van belang is?

Wordt de klant al een betrouwbare indruk gegeven zonder dat er een e-mail wordt verzonden?

Vindt de medewerker het goedgekeurde antwoord zonder door vijf mappen te moeten zoeken?

Wordt onzekerheid aan de juiste persoon gemeld, in plaats van dat deze stilletjes verandert in een zelfverzekerde gok?

Wordt het officiële verslag op veilige wijze gewijzigd?

Kunt u uitleggen waarom?

Als het antwoord ja is, is AI in het proces geïntegreerd.

Als het antwoord ‘nee’ is, beschikt u waarschijnlijk nog steeds over een chatbot.

En nog een tabblad is geen transformatie.