Hoe koppelt u AI veilig aan Outlook, Gmail, Zoho en ERP?
Een veilige koppeling loopt via de officiële API van elk systeem, met OAuth 2.0 en zo weinig rechten als nodig. De AI begint met lezen, schrijft pas later en alleen waar u dat toelaat, en elke schrijfactie wordt gelogd. Wachtwoorden en sleutels staan in een kluis, nooit in code of in een mail, en u kunt de toegang op elk moment intrekken.
Langs welke weg krijgt AI toegang tot uw systemen?
Via de officiële API van elk systeem, nooit via een gedeeld wachtwoord of een script dat schermen naspeelt. Een API is de toegangsdeur die de leverancier zelf bouwt, documenteert en beveiligt. U bepaalt per deur wat erdoor mag. Dat maakt de toegang controleerbaar en intrekbaar.
Voor de vier systemen uit de titel ziet dat er zo uit.
| Systeem | Officiële toegang | Waar u op let |
|---|---|---|
| Outlook en Microsoft 365 | Microsoft Graph API, met een app-registratie in uw eigen Microsoft 365-omgeving | Gedelegeerde of applicatierechten, welke mailboxen binnen bereik vallen, wie als beheerder toestemming geeft |
| Gmail en Google Workspace | Gmail API met OAuth 2.0 en scopes per soort toegang | De smalst mogelijke scope. Lezen, verzenden en volledig beheer zijn aparte scopes |
| Zoho (CRM, Books, Desk en andere) | REST API's per toepassing, met OAuth 2.0 | Scopes per module en per bewerking, het datacenter waar uw Zoho-account draait, de levensduur van tokens |
| ERP of boekhoudpakket | De API van de leverancier. Bestaat die niet: exportbestanden of afgesproken databaseweergaven | Wat uw licentie toelaat, een aparte gebruiker met een eigen rol, schrijven alleen via de weg die de leverancier ondersteunt |
Elk ERP is anders. Sommige pakketten hebben een volwaardige API, andere alleen een export. Wat kan, leest u in de documentatie van uw leverancier of vraagt u daar na. Meer over die afweging leest u op de pagina over ERP-integraties.
Wat is OAuth 2.0 en waarom hoeft niemand uw wachtwoord te kennen?
OAuth 2.0 is de standaard waarmee u een toepassing beperkte toegang geeft zonder uw wachtwoord af te geven. U of uw beheerder meldt zich aan bij Microsoft, Google of Zoho zelf, ziet welke rechten gevraagd worden en keurt die goed of af. De toepassing krijgt daarna een token dat alleen voor die rechten geldt.
Die rechten heten scopes. Bij Gmail is er bijvoorbeeld een scope om mails alleen te lezen, een aparte scope om te verzenden en een scope voor volledige toegang, inclusief definitief verwijderen. Google raadt in zijn documentatie over Gmail-scopes aan om de smalste scope te kiezen en niets te vragen wat de toepassing niet nodig heeft. Een systeem dat alleen antwoorden voorbereidt, heeft geen recht nodig om mails te verwijderen.
Zoho werkt op dezelfde manier. Volgens de OAuth-documentatie van Zoho wordt een toegangstoken altijd uitgegeven voor de scopes uit de aanvraag, ziet de gebruiker die scopes bij het toestemmen, en verloopt het token na korte tijd. Een vernieuwingstoken zorgt voor een nieuw toegangstoken en kan worden ingetrokken.
Wat is het verschil tussen gedelegeerde rechten en applicatierechten?
Bij gedelegeerde rechten handelt de toepassing namens een aangemelde gebruiker en kan ze nooit meer dan die gebruiker zelf. Bij applicatierechten handelt de toepassing onder een eigen identiteit, zonder aangemelde gebruiker, en kan ze aan alle gegevens waarvoor het recht geldt. Dat tweede is nodig voor achtergrondwerk, maar het is een veel zwaarder recht.
Microsoft beschrijft dit onderscheid in het overzicht van Microsoft Graph-rechten. Applicatierechten kunnen alleen door een beheerder worden goedgekeurd. Microsoft noemt ze daar sterk bevoorrecht en raadt gedelegeerde rechten aan telkens wanneer die volstaan.
In de praktijk van een KMO betekent dit het volgende.
- Een medewerker die in de chat iets opzoekt in zijn eigen mailbox: gedelegeerd. De AI ziet wat hij mag zien.
- Een gedeelde mailbox zoals info@ die ook 's nachts verwerkt wordt: applicatierechten, maar beperkt tot die ene mailbox en niet tot het hele bedrijf.
- Vraag bij elk applicatierecht welke mailboxen of mappen binnen bereik vallen en hoe dat bereik technisch wordt afgedwongen.
Welke rechten geeft u, en welke niet?
U geeft het kleinste recht waarmee de taak lukt. Dat principe heet least privilege of minimale rechten. Een koppeling die alleen leest, kan niets stukmaken. Een koppeling die alles mag, maakt van elke fout of elk lek een groot probleem.
Werk daarom met aparte serviceaccounts. Een koppeling met uw boekhoudpakket draait niet onder de login van de zaakvoerder of de boekhouder, maar onder een eigen gebruiker met een eigen rol. Zo ziet u in elk logboek wat de koppeling deed en wat een mens deed. En u kunt de koppeling afsluiten zonder dat iemand zijn werk kwijt is.
Een goede vuistregel: als u niet in één zin kunt uitleggen waarom een recht nodig is, vraag het dan niet aan.
Waar bewaart u sleutels en tokens?
In een kluis voor geheimen, versleuteld en met eigen toegangscontrole. Niet in de broncode, niet in een gedeeld document en nooit in een mail. Een client secret of vernieuwingstoken is even gevoelig als een wachtwoord, want wie het heeft, heeft de toegang.
Spreek daarnaast af dat sleutels een vervaldatum hebben en periodiek vernieuwd worden, dat alleen de koppeling zelf ze kan uitlezen, en dat ze bij een vermoeden van misbruik onmiddellijk vervangen worden. Dit artikel bevat bewust geen voorbeelden van sleutels of configuratie.
Waarom eerst lezen en pas later schrijven?
Omdat u bij lezen de kwaliteit kunt beoordelen zonder risico. De eerste weken zoekt de AI op, vat samen en stelt voor. Uw mensen zien of de voorstellen kloppen. Pas wanneer dat vertrouwen er is, krijgt de koppeling een schrijfrecht, en dan nog voor één duidelijk afgebakende handeling.
- Lezen. Mails, documenten, klantfiches en artikelen worden alleen geraadpleegd.
- Voorbereiden. De AI maakt een concept: een antwoord, een offerte, een boekingsvoorstel. Het concept blijft in afwachting.
- Schrijven na goedkeuring. Een medewerker keurt goed. Pas dan gaat de mail weg of komt de lijn in het ERP.
- Loggen. Elke schrijfactie wordt vastgelegd: wat, wanneer, in welk systeem, door wie goedgekeurd en op basis van welke gegevens.
Zo werkt Arqen ook. Het bestaande boekhoud- of ERP-pakket blijft, en Arqen leest en schrijft alleen waar dat mag. Bij de mailmodule komt elke mail binnen met een voorstel van antwoord, maar een medewerker verstuurt.
Wat krijgt het taalmodel eigenlijk te zien?
Niet uw hele mailbox of uw hele ERP. Bij een vraag worden eerst de relevante fragmenten opgezocht, en alleen die fragmenten gaan samen met de vraag naar het taalmodel. Het model onthoudt ze niet voor een volgende gebruiker. Een goed opgezet systeem toont bij elk antwoord ook waarop het gebaseerd is, zodat u het kunt nakijken.
Het opzoeken moet de rechten van de gebruiker volgen. Een technieker die in de centrale chat een vraag stelt, mag geen fragmenten uit loonbrieven of uit de mailbox van de zaakvoerder terugkrijgen. Dat vraagt één rechtenmodel dat bij elke zoekopdracht wordt toegepast, niet alleen bij het aanmelden.
Beperking: rechten lossen slordige bronnen niet op. Staat een vertrouwelijk document in een map die iedereen kan openen, dan vindt de AI het ook voor iedereen. Ruim uw mappenrechten op voor u koppelt.
Waar staat de index en waar draait het model?
Om snel te kunnen zoeken, maakt het systeem een index van uw mails en documenten. Die index bevat uw bedrijfsgegevens en verdient dezelfde bescherming als de bron. Vraag dus altijd waar hij staat. Er zijn twee gangbare antwoorden: lokaal op een toestel in uw eigen netwerk, of bij een hostingpartij binnen de EU.
Bij Arqen zijn beide mogelijk. De Core is een toestel in uw eigen serverruimte waarop het taalmodel binnen uw netwerk draait. Het alternatief is hosting binnen de EU, met bewaartermijnen die per module vastliggen. Hoe u tussen die twee kiest, leest u in lokale AI of EU-cloudhosting en op de pagina over lokale AI.
Let op één punt: een lokale index verandert niets aan de plaats van de bron. Uw Microsoft 365-, Google- of Zoho-gegevens blijven staan in het datacenter van die leverancier. In mails staan bijna altijd persoonsgegevens, dus de AVG geldt voor de hele keten. Wie in uw opdracht gegevens verwerkt, doet dat onder een verwerkersovereenkomst.
Hoe trekt u de toegang weer in?
U trekt de toestemming in bij de bron, niet bij de leverancier van de AI. In Microsoft 365 verwijdert uw beheerder de toestemming of de app-registratie. In Google Workspace schrapt de beheerder de toegang van de toepassing. In Zoho trekt u het vernieuwingstoken in. In uw ERP schakelt u de gebruiker van de koppeling uit.
Doe daarna nog drie dingen: vervang de sleutels die in de kluis stonden, laat de index verwijderen en vraag daar een bevestiging van, en bewaar de logboeken zolang uw bewaartermijn dat vraagt. Test het intrekken één keer voor u in productie gaat. Dan weet u dat het werkt wanneer het nodig is.
Welke vragen stelt u aan een leverancier?
- Welke scopes of rechten vraagt u precies, en waarom elk daarvan?
- Gedelegeerd of applicatierecht, en hoe is het bereik beperkt?
- Onder welk account draait de koppeling met ons ERP?
- Waar staan sleutels, index en logboeken, en in welk land?
- Wat ziet het taalmodel bij één vraag, en wordt dat bewaard?
- Hoe trekken wij zelf de toegang in, zonder uw hulp?
Een leverancier die deze vragen zonder omweg beantwoordt, heeft erover nagedacht. Wilt u ze aan Arqen stellen, dan kan dat in een eerste gesprek van dertig minuten.