Bedrijven hebben de afgelopen twee jaar behoorlijk wat AI‑tools aangeschaft: chatassistenten, schrijfplug-ins, klantenservicerobots en interne kennisvragen. Maar er zijn weinig echt blijvende capaciteiten ontstaan. De instructies staan nog steeds op de persoonlijke computer, de bedrijfsprocessen liggen verspreid in de hoeken van documenten, na het live gaan van de intelligentie‑agenten ontbreekt feedback en herziening, en de kernmedewerkers worden nog steeds door dezelfde soort vragen overbelast. Het probleem zit vaak niet in het feit dat het model niet slim genoeg is, maar eerder in het feit dat het ‑systeem niet heeft voorzien dat ‘werk verrichten’ wordt omgezet in beheersbare functiecompetenties.
Laten we eerst duidelijk maken: waarom kan een chatvenster geen functie vervullen
Een chatbot beantwoordt een vraag en stopt dan. Een functie moet continu werk opnemen: informatie verzamelen, regels beoordelen, systemen aanroepen, statussen terugmelden en bij uitzonderingen escaleren. Reiskostenvergoeding is een typisch voorbeeld — een gebruiker zegt misschien eerst: “Help me met mijn reiskosten”, onderweg vraagt hij vervolgens: “Hoeveel budget heb ik deze maand nog over?”, en daarna voegt hij nog een factuur toe. Als het systeem elke dialoog als een nieuwe sessie behandelt, breekt het proces, gaat de context verloren en is achteraf niet meer te achterhalen of het fout zat in de regels of in de interface.
In de sector bestaat al de praktijk om intelligentie‑agenten te bouwen als “digitale medewerkers”: ze krijgen een functie, een personeelsnummer, duidelijke competentiegrenzen en een werkrecord, aangevuld met bewerkbare SOP’s, een kennisbank, hulpmiddelen en uitvoeringsroutes. Op de open‑source‑front, publiceert OpenBMB met StaffDeck een agent als een operationeel beheersbaar resource‑pakket, in plaats van slechts een stukje instructietekst. Voor bedrijven die zelf ontwikkelen of maatwerk maken, is het niet zozeer de productnaam die nuttig is, maar dit objectmodel.
Bedrijfslogica: in het systeem moeten minstens zeven soorten objecten aanwezig zijn
Bij het bouwen van een digitaal medewerker‑systeem, schrijf je eerst de zakelijke objecten in de specificaties, en pas daarna ga je over tot het kiezen van het juiste model.
- Functiedossier: naam of rollenaam, personeelsnummer, taken, online‑status, dienstverlening. Zonder dossier kunnen rechten en beoordeling nergens worden gekoppeld.
- Competentiegrenzen: welke documenten mogen worden gelezen, welke velden mogen worden ingevuld, wat mag niet worden beloofd. Deze grenzen moeten door beheerders kunnen worden aangepast, in plaats van vast te zitten in de instructietekst.
- SOP / processuele vaardigheden: complexe processen worden opgedeeld in knooppunten, met ondersteuning voor voorwaardelijke vertakkingen, het aanroepen van tools, het opzoeken van kennis en het doorverwijzen naar menselijke assistentie.
- Kennis‑ontologie: thema’s, regels, bronnen en handleidingen worden apart opgeslagen; antwoorden moeten altijd naar de bron kunnen verwijzen, en zoekopdrachten moeten debugbaar zijn.
- Tool‑integratie: via HTTP‑interfaces of MCP, om kredieten te controleren, documenten aan te maken en statussen te wijzigen, in plaats van alleen een tekstfragment te genereren.
- Periodieke taken: dagelijkse samenvattingen, tijdige opvolging van vertragingen, inventariscontroles en dergelijke periodieke activiteiten mogen niet wachten tot de gebruiker eerst iets zegt.
- Trace en feedback: registratie van routes, stappen, tools, kennis en antwoorden; likes, dislikes en handmatige overname gaan naar de volgende ronde van herziening.
Een echte aanvraag omvat vaak meerdere taken. Een digitale medewerker moet eerst de SOP voor vergoedingen betreden, alle velden verzamelen en regels toetsen, en vervolgens overschakelen naar de SOP voor kredietcontrole om de interface aan te roepen. Als de gebruiker onderweg vragen over beleid stelt, moet de huidige stap worden opgeslagen en na het antwoord weer naar het oorspronkelijke proces teruggegaan worden. Vragen die buiten de regels vallen, dienen de context door te geven aan de maker of de dienstdoende, zonder ongefundeerde harde antwoorden.
Ontwerpprincipes: rollen, statemachine, kennishiërarchie
Hoe schakel je tussen rollen
Er zijn minstens vier soorten personen: de maker (die ervaringen vastlegt in medewerkers), de beheerder (die rechten, publicaties en quota beheert), de gebruiker (die taken toewijst aan de digitale medewerker) en de dienstdoende (die uitzonderingen oppakt). De maker mag niet standaard de macht hebben om voorraad of prijzen te wijzigen; de gebruiker mag niet de volledige instructietekst of de sleutels zien. Ook open interfaces moeten gelaagd zijn: account‑sleutels kunnen middelen beheren, terwijl werknemer‑sleutels alleen sessies kunnen aanmaken en hun eigen trace kunnen lezen.
Gebruik SOP’s met statemachines, niet alleen gespreksgeheugen
Natuurlijke taal kan een eerste concept genereren, maar de uitvoering moet via een statemachine verlopen: huidige stap, verzamelde slots, aan te roepen tools, falen en herhaling, menselijke knooppunten. Na een onderbreking moet de context kunnen worden gereconstrueerd en naar de oorspronkelijke stap teruggegaan worden. Meerdere SOP’s mogen in real time worden gewisseld, maar bij elke overstap moet duidelijk worden gemaakt “van waar komt het, welke bevestigde informatie is meegebracht”, om dubbele formulierinvoer te voorkomen. Versies en takken moeten terugrolbaar zijn; als één instructietekst ter plekke wordt aangepast, gaat het meteen live, waarna achteraf geen verantwoordelijkheid meer kan worden vastgesteld.
Maak kennis niet tot een grote, rommelige zoekmachine
Bouw navigeerbare indexen per document, hoofdstuk, pagina en samenvatting; bepaal eerst in welke categorie de informatie zich waarschijnlijk bevindt, en lokaliseer daarna de originele tekst. Kennis moet worden gegroepeerd: regelgeving, productbeschrijvingen, after‑sales‑taal en uitzonderingsgevallen moeten apart worden gehouden; gerichte zoekopdrachten zijn betrouwbaarder dan wereldwijde trefwoorden. Elk antwoord moet gekoppeld zijn aan bron, regel en zakelijk thema; in de testomgeving moet duidelijk zichtbaar zijn “waarom deze passage werd getroffen”. Debuggen van zoekopdrachten lost vaker problemen op dan het vervangen door een groter model.
Implementatie: interfaces, isolatie, observatie, acceptatie
Tijdens het gebruik wordt een uniforme ingang aanbevolen, om te voorkomen dat elke vaardigheid een eigen pad volgt en zo de status drift veroorzaakt. Ontdekking van capaciteiten, isolatie van uitvoering, integriteit van werkpakketten en berekening van quota moeten tijdens het gebruik worden afgerond, in plaats van te vertrouwen op afspraken. Voordat vaardigheden op de interne markt worden gepubliceerd, moet een rechtenscan worden uitgevoerd: certificeringskoppen, omgevingsvariabelen en verbindingsreferenties mogen niet in gewone leesinterfaces verschijnen.
- Uitvoeringskanalen: synchrone streaming is geschikt voor gesprekken; asynchrone Run + eventstream is geschikt voor onderbroken verbindingen en taakwachtrijen; beide delen dezelfde kernel.
- Kanalen en identiteit: WeChat, Enterprise WeChat, Feishu en DingTalk kunnen als ingang dienen, maar werknemersidentiteit, sessies en Trace moeten uniform zijn; het is verboden dat elk kanaal een eigen geheugen opbouwt.
- Veiligheid: Modelconfiguraties mogen alleen bestaande configuratienummers gebruiken; leverancierssleutels mogen niet worden teruggezonden; resultaten van tools moeten bij het invoeren van Trace worden gedesinfecteerd.
- Menselijke back‑up: bij tijdsoverschrijding, lage vertrouwenswaarde, overtreding van bevoegdheden of wanneer de gebruiker zelf overgaat naar menselijke assistentie, moeten alle vier de situaties de context volledig kunnen overdragen.
Acceptatie mag niet alleen testen of “kan chatten”. Geef een set herhaalbare scripts: normale gesloten cyclus, onderweg gestelde vragen, tekort aan krediet, interface‑timeout, schrijven met overtreding van bevoegdheden, weigeren zonder bron. Controleer bij elk script: of knooppunten zijn hersteld, of documenten correct zijn ingevuld, of Trace compleet is, en of uitzonderingen bij mensen zijn beland. De doorstromingssnelheid van controles, de snelheid van het afhandelen van timeouts en het aantal ongegronde antwoorden zijn beter geschikt als toegangscontrole voor lancering dan sterrenbeoordelingen van tevredenheid.
Lancering volgorde: eerst een stuk repetitief werk
Begin niet meteen met een alles‑kunnen‑assistent. Kies een segment uit sales‑follow‑upnotities, goedkeurings‑opvolging, vragen over regelgeving of kostenpre‑review dat dagelijks meer dan een half uur wordt herhaald; schrijf input, output, rechten en uitzonderingen in vier zinnen, en voeg daarbij SOP’s en twee of drie alleen‑lezen of beperkt‑schrijven interfaces. Als de masterdata vuil is of de goedkeuringsknopen onduidelijk, vul dan eerst objecten en statussen aan, en voeg daarna intelligente uitvoering toe — nadat vuile data geautomatiseerd is, verspreidt het zich alleen maar sneller door het hele bedrijf.
Hoe weet je of het ontwerp goed is: het segment dat vroeger afhankelijk was van groepsopvolging en formulierinvulling is niet langer de hoofdroute; notities, opvolging en samenvattingen kunnen worden vergeleken met documenten; onduidelijke situaties hebben een escalatie‑object; gevoelige operaties worden door mensen gecontroleerd en logboeken kunnen worden ingezien. Om te beoordelen of de ontwikkeling voldoet, kijk naar of dezelfde SOP na een onderbreking kan worden hersteld, of antwoorden naar de bron kunnen verwijzen, en of grenscases kunnen doorgaan naar de volgende ronde van herziening. Als deze drie punten zijn gehaald, kun je de functies uitbreiden; dit is stabieler dan eerst veel chat‑ingangen te openen.
De technische moeilijkheid van een digitaal medewerker‑systeem zit niet in het genereren van gesprekken, maar in het omzetten van functies, processen, kennis, tools en trajecten in software‑objecten die versie‑geschikt zijn. Instructieteksten kunnen tien keer per week worden aangepast, maar als het objectmodel eenmaal uiteenvalt, zal elke vaardigheid later een eigen set schrijven.Laat eerst deze zeven soorten objecten en de statusmachine goed werken; alleen dan kun je het model upgraden. Anders is elke modelwijziging een nieuw project, geen configuratieverandering.