In 2025 bestond het marketingteam van een middelgroot e-commercebedrijf in Taiwan uit vijf mensen die om de beurt drie socialemedia-accounts beheerden. De wachtwoorden werden opgeslagen in een gedeeld Google Sheet, waar iedereen toegang toe had. Niemand zag hier iets mis mee, totdat ze besloten een AI-agent in te zetten om het plaatsen van berichten te automatiseren.

Mijn eerste reactie was: "Geef de accountsleutel gewoon aan de medewerker."

Deze intuïtie is aanwezig in vrijwel elk bedrijf dat begint met het gebruik van AI. En ze is bijna altijd onjuist.

Stel een vraag voordat je de agent traint.

De meeste mensen die over AI-agenten praten, richten zich op hun mogelijkheden: Kan het zoeken? Kan het rapporten schrijven? Met welke tools kan het verbinding maken? Dit zijn allemaal terechte vragen, maar ze zijn van ondergeschikt belang.

De belangrijkste vragen zijn: Wat mag deze agent wel doen? Wat mag hij niet doen? En wie is verantwoordelijk als hij iets doet wat niet mag?

Dit is geen technisch probleem, maar een kwestie van governance. En wanneer bedrijven agents ontwerpen, is 90% van hun aandacht gericht op het technische aspect, terwijl bijna niemand het governance-aspect in overweging neemt.

Een agent zonder geautoriseerde grenzen wordt gevaarlijker naarmate hij machtiger is. Er is geen fundamenteel verschil in systeemarchitectuur tussen een assistent die alles kan en een kwetsbaarheid die op elk moment uit de hand kan lopen.

Dit is het uitgangspunt voor de ontwikkeling van het SPEAK-framework.

• 【S】 Skill 技能
• 【P】persoonlijkheid onderscheidende kenmerken
• 【E】Jarenlange ervaring ervaring
• 【EEN】Autoriteit Toestemming geven
• 【K】Kennis 知识

Van de vijf dimensies beschrijven S, P, E en K wat de Agent is , wat hij weet en wat hij kan doen . Alleen A [Autoriteit] beantwoordt een compleet andere vraag: hoe ver mag hij gaan?

"Elke machtiging die je aan een agent verleent, is als het openen van een deur. De vraag is niet hoeveel deuren er openstaan, maar of je weet welke deuren nooit geopend mogen worden."

Fysieke isolatie van wachtwoorden: de logica van procesproxy

Laten we teruggaan naar het verhaal van dat e-commercebedrijf. Uiteindelijk gaven ze de wachtwoorden van hun socialemedia-accounts niet aan de agent.

Wat ze deden was slimmer: de agent was alleen gemachtigd om het publicatieproces te starten , niet om de publicatie zelf uit te voeren. Wanneer de agent besloot een bericht te plaatsen, gaf hij de inhoud en het tijdstip door aan een scenario op Make.com , waar Make zijn echte gebruikersnaam en wachtwoord gebruikte om het inlog- en publicatieproces achter de schermen af ​​te ronden.

De autorisatieketen voor het gehele proces is als volgt:

Agent (weet wat te verzenden) → Activeert scenario (weet hoe te verzenden) → Houdt account en wachtwoord vast (heeft toestemming om te verzenden)

De agent zal het wachtwoord nooit tegenkomen. Hij weet niet wat het wachtwoord is en hoeft het ook niet te weten.

De kern van dit ontwerp is een principe dat al decennia bestaat in de beveiligingsarchitectuur van bedrijven: het principe van minimale bevoegdheden . Elke rol krijgt alleen de minimale machtigingen die nodig zijn om de taak uit te voeren, en niet meer.

Banksystemen, ziekenhuisinformatiesystemen en overheidsdatabases zijn allemaal op deze manier ontworpen. Maar in de wereld van AI-agenten is dit principe bijna vergeten, omdat iedereen haast heeft om agenten "krachtiger" te maken.

De kern van AI is dat het niet bedoeld is om mensen te vervangen, maar om met hen samen te werken. Samenwerking kent echter wel voorwaarden: elke deelnemer moet de grenzen van zijn of haar verantwoordelijkheden duidelijk begrijpen. Agenten onbeperkte bevoegdheden geven is geen vertrouwen, maar plichtsverzuim.

Dubbellaagse sleutel: Wanneer de vaardigheid zelf ook autorisatie vereist.

Procesisolatie lost het beveiligingsprobleem op de "operationele laag" op, maar er blijft een ander probleem over: hoe autoriseer je de vaardigheden zelf?

In het Agent Training Center-platform van Smart4A ( speak.smart4a.tw ) is elke skill versleuteld. De host gebruikt AES-versleuteling om de inhoud van de skill op te slaan; de gebruiker moet de bijbehorende decryptiesleutel op zijn of haar lokale computer hebben om de skill te ontgrendelen en te gebruiken.

Dit zorgt voor een elegante beveiligingsstructuur: vaardigheden worden niet "gedownload", maar "ontgrendeld". Het platform weet dat u gekwalificeerd bent om ze te gebruiken, en uw eigen sleutel verifieert uw identiteit; beide zijn onmisbaar.

Voor ondernemers is het voordeel van dit ontwerp niet technisch, maar psychologisch: u hoeft niet te begrijpen wat AES is; u hoeft alleen uw sleutel te beveiligen. Het platform regelt de complexe beveiligingslogica; u hoeft alleen de uiteindelijke sleutel te beheren.

Dit doet me denken aan de ontwerpfilosofie van kluizen: de beste kluizen vereisen niet dat gebruikers het slotmechanisme begrijpen, maar stellen gebruikers in staat slechts één combinatie te onthouden, waarbij al het andere wordt beschermd door mechanische structuren. De autorisatielaag van SPEAK doet hetzelfde.

De grens van de cashflow: geen afwijzing, maar het opwerpen van een extra barrière.

Zijn er dus scenario's denkbaar waarin een agent een proces kan starten, maar het niet zelfstandig kan voltooien?

Het antwoord is ja. Cashflow is daarvan het meest typische voorbeeld.

Voor afstemming, betalingsverzoeken en zelfs sommige betalingsprocessen kan de agent het proces initiëren, gegevens ordenen en cijfers invoeren. Op een cruciaal punt in het proces is echter een bevestiging vereist voordat het kan worden voortgezet. Dit is de ontwerpfilosofie van Human-in-the-Loop (HITL).

HITL-ontwerpprincipes

De agent zet het proces in gang, maar het proces wordt gepauzeerd voordat het wordt uitgevoerd, in afwachting van menselijke beoordeling en goedkeuring. Geld wordt niet overgemaakt zonder menselijke bevestiging. De rol van de agent is voorbereiden en herinneren; de beslissingsbevoegdheid blijft in menselijke handen – dit is geen technologische beperking, maar een weloverwogen ontwerp van het bestuurssysteem.

HITL wantrouwt AI niet, maar erkent juist dat sommige beslissingen onomkeerbare gevolgen hebben. Eenmaal een fout gemaakt, is er geen weg terug. Verduistering van geld, onjuiste betalingen – elke fout, in welk stadium dan ook, kan leiden tot onherstelbare verliezen. In dergelijke scenario's is het betrekken van mensen de meest verantwoorde keuze in het kader van empowerment design.

Een volwaardige vorm van autoriteit is geen binaire keuze tussen "geven" of "niet geven", maar eerder een hiërarchische autorisatieketen: welke stappen een agent mag nemen, welke stappen menselijke bevestiging vereisen en welke stappen alleen door specifieke rollen kunnen worden goedgekeurd. Zo ziet AI-governance op bedrijfsniveau er in de praktijk uit.

Een goede grondwet specificeert niet alleen wie welke bevoegdheden heeft, maar ook welke bevoegdheden gecontroleerd en in evenwicht gehouden moeten worden voordat ze kunnen worden uitgeoefend. Uw bevoegdheidsstructuur voor vertegenwoordigers zou hetzelfde moeten zijn.

De ware volgorde van SPEAK

Als je een AI-agent voor je bedrijf wilt ontwikkelen, doet SPEAK een onverwachte suggestie: begin niet met de S, maar met de A.

Stel jezelf eerst de volgende vragen: Tot welke systemen mag deze agent toegang hebben? Welke accountwachtwoorden mogen nooit in handen van de agent vallen? Voor welke handelingen is handmatige bevestiging vereist? Is er een grens die je onder geen enkele omstandigheid zou overschrijden?

Alleen door deze vragen duidelijk te beantwoorden, kan uw agent zich kwalificeren om vaardigheden te leren, persoonlijkheid te ontwikkelen, ervaring op te doen en kennis te vergaren.

Anders gezegd: wat je hebt getraind is geen assistent, maar een kwetsbaarheid die elk moment uit de hand kan lopen. Alleen spreekt het nog heel beleefd, dus je hebt het probleem nog niet ontdekt.

De kern van AI draait niet om het vervangen van menselijke banen door AI, maar om het herdefiniëren van de verantwoordelijkheden van zowel mens als AI. Het licentiëren van ontwerp is de meest concrete manifestatie van deze afbakening.

Het marketingteam van het e-commercebedrijf bouwde uiteindelijk een overzichtelijke Agent-architectuur op: de Agent was verantwoordelijk voor contentcreatie en planning, het Make-team voor de uitvoering en het accountmanagement, en het HR-team voor de uiteindelijke releasebeslissingen en betalingsverwerking. Deze drieledige taakverdeling zorgde ervoor dat elk team zijn specifieke verantwoordelijkheden nakwam.

Ze gaven aan dat hun belangrijkste conclusie na de implementatie van het systeem niet was "hoeveel tijd AI me bespaarde", maar eerder: "Voor het eerst had ik het gevoel dat ons systeem echt ontworpen was."

Dit is wat het SPEAK- framework voor elk bedrijf wil realiseren.