Kies de architectuur op basis van de opdracht, niet op basis van het model

Het model is een late beslissing

De meeste gesprekken over architectuur beginnen op de verkeerde manier.

Welk model? Welke leverancier? Cloud of on-prem? Met of zonder agenten? Een bestuursdocument staat vol met logo’s nog voordat iemand de functie heeft benoemd.

Zo komt het dat bedrijven een platform aanschaffen en toch e-mails handmatig opnieuw moeten invoeren.

Een goed functionerend model is eenvoudig te implementeren. Het lastigste deel is het creëren van een veilige omgeving ervoor binnen de bedrijfsvoering. Dat betekent dat moet worden vastgelegd wat het model mag lezen, welke resultaten het mag retourneren, hoe de output wordt gevalideerd en wat er gebeurt wanneer het een fout maakt.

Kies de architectuur op basis van de taak. Bepaal vervolgens waar de inferentie plaatsvindt. Pas daarna, en alleen dan, kiest u een model dat die taak binnen die beperkingen kan uitvoeren.

Ten eerste: geef de functie een naam

Vrijwel elke nuttige operationele taak bestaat uit een van deze elementen, of uit een korte reeks daarvan.

Uittreksel. Zet rommelige tekst of een document om in velden die het systeem al kent.

Classificeren. Deel een zaak in een categorie in: type uitzondering, wachtrij, urgentie, taal.

Zoek en beantwoord. Zoek goedgekeurd materiaal en beantwoord de vraag aan de hand daarvan. Vermeld de bron. Weiger wanneer de bron ontbreekt.

Opstellen. Stel een bericht, een samenvatting of een checklist op. Dit wordt nog steeds door iemand verzonden.

Neem een besluit. Kies uit de bekende volgende stappen. Dit is het moment waarop mensen enthousiast worden, en waarop u streng moet zijn.

Actie. Schrijf naar het registratiesysteem, roep een API van een provider aan, wijzig een status. Dit is niet „het model“. Dit is software, na validatie.

Als een team niet naar een van die woorden kan verwijzen, hebben zij geen use case. Zij hebben een gevoel. Stop en benoem de taak voordat iemand een modelnaam noemt.

Ten tweede: geef het referentiesysteem een naam

Het model is niet de bron van de waarheid.

Een order staat in het ERP- of TMS-systeem. De voorraad staat in het WMS. Een ticket staat in het casussysteem. Een klanttoestemming staat in het CRM. Andere processen lezen deze gegevens al.

Als u niet kunt benoemen wat u gaat lezen en wat u mogelijk gaat schrijven, bent u nog niet klaar om een architectuur te kiezen. „We zullen onze gegevens koppelen“ is geen benaming.

Het registratiesysteem bepaalt het schema. Het bepaalt de juridische statusovergangen. Het bepaalt wie een afleveradres mag wijzigen. Het model hoeft deze regels niet opnieuw in proza te ontdekken.

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

Ten derde: geef aan wat een fout antwoord kost

Dit is de vraag die het verschil maakt tussen een copiloot en een gecontroleerde stap.

Als het model een lange discussie samenvat en iemand toch de e-mail verstuurt, is een slecht antwoord tijdverspilling. Vervelend. Maar te overleven.

Als het model een vrachtbrief, een voorraadaanpassing, een douanecode of een belofte aan de klant opstelt, wordt een onjuist antwoord voor alle anderen als feit beschouwd.

Vraag hardop: kan dit proces mislukken? Is er een wachtrij? Een aangewezen verantwoordelijke? Een manier om het officiële verslag ongewijzigd te laten wanneer het vertrouwen laag is?

Indien het antwoord ‘nee’ is, plaats het model dan niet op het schrijftraject. Gebruik het naast het werk, of gebruik het helemaal niet.

Hoge kosten in combinatie met het ontbreken van een uitzonderingsprocedure zorgen ervoor dat „AI-transformatie“ uitmondt in een onopgemerkt gegevensincident.

Kies vervolgens het juiste sjabloon, niet de leverancier.

Zodra de taak, het dossier en de kosten van de fout zijn benoemd, is het patroon doorgaans duidelijk.

Alleen regels. Als een deterministische tabel volstaat, voeg dan geen model toe. Type aanlegplaats, openingstijden, „READY kan niet volgen op CANCELLED.“ Software is goedkoper en eenvoudiger uit te leggen.

Eerst extraheren of classificeren, daarna een commit-gate. De standaardprocedure voor e-mail, PDF’s en scannotities. Gestructureerde uitvoer. Schema. Bedrijfsregels. Betrouwbaarheid. Schrijven of in de wachtrij plaatsen.

Raadpleeg goedgekeurde bronnen. Voor beleid, standaardprocedures en specificaties. Eerst opzoeken. Pas daarna antwoorden. De passage laten zien. „Ik weet het niet“ wanneer de passage ontbreekt. Een model dat uit het hoofd antwoordt, vormt een risico.

Copiloot naast het werk. Concepten, toelichtingen, checklists. De mens blijft verantwoordelijk. Corrigeer wanneer de kosten van fouten hoog zijn en u nog niet klaar bent om het schrijfproces te automatiseren.

In-process-model. De behandelaar heeft de zaak al in beheer en de afleiding vormt één gecontroleerde stap binnen dat proces. Hier kan een hoger volume daadwerkelijke efficiëntie opleveren, mits de validatie- en escalatiecontroles streng genoeg zijn.

Agent met hulpmiddelen. Meerdere stappen, meerdere systemen, een plan dat gaandeweg verandert. Beschouw dit als de uitzondering, niet als de norm. Stel een toegangslijst op voor de hulpmiddelen. Geen stille wijzigingen. Eerst een regel of een persoon, dan pas een commit. Als u de toegangslijst niet kunt opstellen, hebt u geen agent. U hebt hoop.

Toepassingsvoorbeeld: het omzetten van een bestellingsmail in een ERP-update

Taak: uittreksel. Record: de orderregel. Foutkosten: gemiddeld. U mag de taak met een negatief resultaat afsluiten.

Architectuur: extractie tijdens de verwerking. Mailbox-gebeurtenis, de thread en de kandidaat-opdracht laden, gestructureerde velden, valideren, schrijven of in de wachtrij plaatsen.

Geen assistent. De meerwaarde ligt in het voorkomen van dubbel invoerwerk, niet in het verstrekken van een mooiere samenvatting aan de administratief medewerker. Geen tussenpersoon. Er is één taak en één verslag.

Geen RAG. U beantwoordt geen vraag. U stelt velden voor.

Toepassingsvoorbeeld: het beantwoorden van de vraag „Wat is de huidige retourprocedure?“

Taak: opzoeken en beantwoorden. Dossier: de goedgekeurde documentenreeks. Kosten van fouten: hoog indien verzonnen.

Opbouw: RAG boven bronnen die door een persoon als actueel zijn gemarkeerd. Verwijs naar de alinea. Indien twee versies met elkaar in strijd zijn, of indien er geen overeenstemming is, wijs de bron dan af.

Geen gegevensuitlezing naar het ERP-systeem. Geen medewerker die „op zoek gaat naar dingen“. De manier waarop een behulpzame stagiair zou falen, is precies wat u probeert te vermijden.

Een copiloot die het open web doorzoekt, is niet het juiste product. De medewerker beschikt al over Google. Hij of zij heeft het goedgekeurde antwoord nodig.

Toepassingsvoorbeeld: het omzetten van een uitzonderingsmelding uit het magazijn in een concrete casus

Taak: classificeren, eventueel een aanwijzing over de locatie of hoeveelheid eruit halen. Registratie: de WMS-uitzondering.

Foutkosten: hoog indien de voorraad stilzwijgend wordt aangepast. Gemiddeld indien er alleen wordt doorgestuurd.

Architectuur: classificatie tijdens de verwerking op basis van het bestaande uitzonderingsobject. Het model stelt een type en een route voor. De software beslist of die route toegestaan is. De statusupdates blijven deterministisch.

Als de notitie vaag is, wordt deze afgewezen. „Misschien gangpad 4, te bevestigen door de ploegleider“ is geen locatie-update.

Toepassingsvoorbeeld: het beantwoorden van de vraag „Waar is mijn zending?“ op basis van actuele operationele gegevens

Taak: ophalen. Registratie: TMS/WMS-statusgebeurtenissen. Foutkosten: zeer hoog indien verzonnen.

Architectuur: haal de officiële status op. Gebruik eventueel een model om een onduidelijke verwijzing („de bestelling van Anderson van afgelopen donderdag”) te koppelen aan een ID, en toon vervolgens de betreffende rij.

Schrijf alleen proza als een omkadering van feiten die u al hebt. Als de scan ontbreekt, vermeld dan dat de scan ontbreekt. Vul het verhaal niet aan.

Dit is het gebruiksscenario waarbij de architectuur het vaakst verkeerd wordt gekozen: een chatwidget met een algemeen model en een zoekplug-in. Zo krijgt u een zorgeloze vrijdag.

Toepassingsvoorbeeld: het verleidelijke idee van een „autonome planner“

Er zal vraag zijn naar een agent die de vraag in kaart brengt, afspraken verplaatst, vervoerders omboekt en de klant e-mailt.

Noem de taken. Dat zijn: gegevens ophalen, beslissen en handelen — verspreid over verschillende registratiesystemen. De kosten van fouten zijn het netwerk van die dag.

De eerlijke opbouw is doorgaans: doe dit niet als één agent.

Splits het op. Haal de beperking eruit. Presenteer een voorgesteld plan. Laat de bestaande optimalisatie of een planner dit goedkeuren. De documenten worden via het TMS verwerkt. De e-mail aan de klant wordt gegenereerd zodra de officiële afspraak is vastgelegd.

Indien u toch een agent wenst, is de allowlist kort en zijn de commit-regels streng. Wat niet met een specifiek genoemde tool kan worden gedaan, kan ook niet worden gedaan. Alles wat een belofte wijzigt, wordt uitgesteld.

Autonomie is geen strategie. Het is een voorrecht dat het proces moet verdienen, stap voor stap.

Of er inferentie wordt toegepast, is een beslissing die afhangt van de werklast

Pas nu is het zinvol om te spreken over cloud, EU, on-prem of hybride.

De vraag is niet welk logo in de mode is. Het gaat erom wat deze werklast vereist: latentie, volume, modelcapaciteit, dataklasse, opslaglocatie, kosten en wie er om 3 uur ’s nachts wordt opgeroepen.

Een cloud-eindpunt is vaak de juiste keuze wanneer de gegevenshoeveelheid klein en strak afgebakend is, zoals één e-mail en één bestelling, in plaats van een volledige klantendatabase.

Een regionaal of in de EU gevestigd model is geschikt wanneer het werk binnen de EU moet blijven. CodexCell maakt voor die beperking gebruik van Mistral. Microsoft Foundry en AWS Bedrock zijn integraties in platforms die u wellicht al gebruikt. Zij vormen de verbindingen. Zij vormen geen aanspraak op soevereiniteit.

Inferentie op locatie is de juiste keuze wanneer de organisatie de bytes en de serving-stack in eigen beheer moet houden. Hiermee worden ook capaciteit, upgrades en beschikbaarheid ondergebracht in uw eigen bedrijfsvoering.

Hybride werkwijzen komen veel voor: het systeem waarin gegevens worden vastgelegd blijft waar het is; alleen de taakgegevens worden verzonden; sommige taken verlaten het gebouw nooit.

Geen van deze is „de architectuur“. Het zijn plaatsingen van één stap.

Vier vragen die een strategische offsite vervangen

Wanneer u een voorstel ontvangt waarin in de eerste zin een modelnaam wordt genoemd, stel dan in plaats daarvan de volgende vragen.

Wat gebeurt er als het model niet klopt? Als niemand het antwoord weet, is het nog niet klaar.

Wie is verantwoordelijk voor de uitzondering? Als de verantwoordelijke „het team“ is, is er geen verantwoordelijke.

Kunt u de transactie zes maanden later toelichten? Opdracht, transactiebedrag, validatie, uitvoerder, resultaat. Zo niet, dan beschikt u niet over een audittraject. U hebt slechts een vaag idee.

Is het dinsdagochtend anders? Als dezelfde persoon nog steeds dezelfde e-mail naar hetzelfde tweede scherm kopieert, heeft u een tabblad gekocht.

Deze vier antwoorden zullen een betrouwbaardere keuze voor de architectuur opleveren dan een vergelijkingsdia van leveranciers.

De strategie vormt de grens

U heeft geen meer autonoom model nodig om te beginnen.

U moet weten welke taak wordt uitgevoerd, welke rij als definitief geldt en wat het proces doet wanneer het antwoord slechts waarschijnlijk juist is.

Het model kan probabilistisch zijn.

De operatie mag niet slordig verlopen.

Kies de architectuur op basis van dat feit, en de rest van de stack wordt een reeks gewone technische keuzes. Kiest u eerst het model, dan bent u een jaar bezig met het koppelen van een ‘brein’ aan een bedrijf dat nog steeds in een ander tabblad draait.