Itdaily - AI-agents krijgen toegang tot je klantdata. Wie bepaalt wat ze mogen?

AI-agents krijgen toegang tot je klantdata. Wie bepaalt wat ze mogen?

AI-agents krijgen toegang tot je klantdata. Wie bepaalt wat ze mogen?

Een prospect bekijkt in twee weken drie keer de prijzenpagina en opent twee mails zonder te reageren. Een AI-agent in het CRM ziet dat patroon, stelt een bericht op dat precies die aarzeling adresseert en legt het klaar bij de accountmanager. Die leest het, past een zin aan en verstuurt.

Er is in dat proces iemand geweest die heeft bepaald dat de agent dit gedrag mocht zien, welke velden hij mocht gebruiken en dat hij niet zelf op verzenden mocht drukken. In veel organisaties is die iemand er niet. De agent staat aan omdat hij in de licentie zat.

Dat is het echte vraagstuk rond agentic AI in commerciële systemen. Niet of de technologie werkt, want dat doet ze inmiddels. Maar wie de grenzen trekt, en op basis waarvan.

De autorisatievraag zit niet in het model, maar in je CRM

Discussies over AI-veiligheid gaan meestal over het model: welke leverancier, welke hosting, wordt er getraind op onze invoer. Terechte vragen, alleen niet de vragen die bepalen wat er maandag in je klantendossier gebeurt.

Wat een agent feitelijk mag, wordt bepaald door de inrichting van het systeem waarin hij draait. Welke objecten en eigenschappen zijn zichtbaar voor de rol waaronder hij werkt. Mag hij een contactpersoon aanmaken, een dealfase wijzigen, een mail versturen. Zijn gespreksnotities van een klantcase toegankelijk voor een agent die prospects benadert. Staat er ergens vast welk type gegeven nooit in een gegenereerde tekst terecht mag komen.

Dat zijn geen modelinstellingen. Dat zijn permissies, eigenschapsniveaus en workflowrechten in het CRM, en die zijn in de meeste organisaties historisch gegroeid. Ze zijn ingericht toen alleen mensen het systeem gebruikten, en mensen hebben oordeel. Een agent leest een veld letterlijk en gebruikt wat er staat.

Het gevolg zie je terug in de praktijk. Een agent die keurig binnen zijn rechten blijft en toch een e-mail opstelt waarin informatie uit een ander klanttraject doorschemert, heeft geen fout gemaakt. Het systeem heeft hem dat toegestaan.

Toestaan is een keuze, geen instelling

De tweede laag is de vraag hoever een agent mag gaan voordat een mens ernaar kijkt. Ontwerpers van deze systemen maken die keuze bewust. Sommige agents leveren een concept op in plaats van zelf te versturen, precies omdat de laatste stap een menselijke beoordeling verdient.

Die grens is verplaatsbaar, en daar begint het gesprek dat de meeste organisaties overslaan. Wat mag een agent zelfstandig afhandelen, en wanneer wordt het een voorstel dat iemand goedkeurt. Bij een afspraakbevestiging ligt dat antwoord ergens anders dan bij een offerte of een prijsafspraak.

Wie die grens niet expliciet vastlegt, krijgt hem alsnog, alleen dan zoals de leverancier hem standaard heeft gezet. Dat is een acceptabele uitkomst voor een pilot en een slechte uitkomst voor een systeem dat de complete commerciële operatie raakt.

De AI Act dwingt bedrijven de komende jaren om per toepassing aan te tonen welk risiconiveau erbij hoort en welke waarborgen er zijn. Wie nu al kan laten zien welke agent onder welke rol draait en waar de menselijke tussenstap zit, heeft die documentatie grotendeels liggen. Wie dat niet kan, gaat het achteraf reconstrueren.

Wie beslist dit eigenlijk?

In de praktijk valt deze beslissing tussen wal en schip. IT beoordeelt de leverancier en de datastromen. Marketing en sales zetten de agent aan omdat hij tijd bespaart. Niemand voelt zich eigenaar van de vraag welke klantgegevens een geautomatiseerd systeem mag gebruiken om namens het bedrijf te communiceren.

Die vraag hoort thuis bij degene die verantwoordelijk is voor het commerciële systeem als geheel, met IT en privacy als toetsers. Er zijn drie dingen die vastliggen voordat een agent live gaat: onder welke rol hij draait en welke gegevens die rol ziet, welke handelingen hij zelfstandig uitvoert en welke hij ter goedkeuring aanbiedt, en wie erop toeziet dat dit klopt als de inrichting verandert.

Dat laatste punt wordt onderschat. Een nieuw veld of een gewijzigde rol verandert stilzwijgend wat een agent kan.

Precies daar zit het verschil tussen een implementatiepartij die een licentie inricht en een partner die het onderliggende model op orde brengt. Bij een partij zoals Leapforce begint een agentic-traject daarom niet bij het aanzetten van de agent, maar bij de vraag welke data er onder ligt, wie waarvoor verantwoordelijk is en waar de menselijke tussenstap blijft staan. Zonder die grenzen doet een agent precies wat hij mag, en dat is zelden wat je bedoelde.

Organisaties die deze afweging serieus willen maken, doen er goed aan de vraag mee te nemen in de partnerkeuze zelf. In de HubSpot partnerlijst van Leapforce staat waar dat soort verschillen tussen partijen zitten.

De technologie is klaar. De inrichting eronder meestal nog niet.


Dit is een ingezonden commerciële bijdrage. De redactie is niet verantwoordelijk voor de inhoud.