Een transparant overzicht van de beveiligings-, privacy- en compliancemaatregelen die zijn geïmplementeerd voor de AI-gestuurde ESS Assistant binnen het Employee Self Scheduling (ESS) platform.
1. Algemene informatie
De ESS Assistant ondersteunt medewerkers binnen het Employee Self Scheduling platform door middel van intelligente begeleiding via conversatie-AI.
De integratie maakt gebruik van Microsoft's Semantic Kernel framework om backenddiensten veilig te verbinden met een Large Language Model (LLM). Het momenteel gebruikte model is OpenAI GPT-4.1, geselecteerd op basis van interne evaluaties van prestaties, betrouwbaarheid en beveiliging.
AI-technologieën worden continu geëvalueerd en verbeterd. Eventuele toekomstige modelwijzigingen worden beoordeeld op beveiliging, compliance en operationele betrouwbaarheid.
2. Architectuur op hoofdlijnen
De ESS Assistant fungeert als een beveiligde tussenlaag tussen medewerkers en het ESS-platform.
Communicatie met de backend verloopt via gecontroleerde API's, waardoor alle rechten, autorisaties en beveiligingsgrenzen gelijk blijven aan die van de reguliere ESS-applicatie.
3. Gebruikersinteractie
Medewerkers communiceren met de assistent via natuurlijke taal.
De assistent interpreteert gebruikersvragen en haalt de benodigde informatie veilig op via geauthenticeerde backendintegraties en vooraf gedefinieerde plugins.
4. Modeltoegang en autorisaties
Token-gebaseerde authenticatie
- Alle backend-aanroepen vereisen een geldig toegangstoken.
- Het LLM beschikt niet over toegangstokens en slaat deze ook niet op.
- Autorisatiecontroles zijn identiek aan die van de reguliere ESS-gebruikersinterface.
Endpointbeperkingen
- Alleen goedgekeurde ESS Assistant API-endpoints kunnen worden gebruikt.
- Het LLM kan niet rechtstreeks OWS-API's aanroepen.
- Functionaliteit wordt uitsluitend aangeboden via gecontroleerde plugins.
- Beschikbare plugins bieden alleen functionaliteit waarvoor de geauthenticeerde gebruiker bevoegd is.
Geen directe database-toegang
- Gegevens blijven binnen de omgeving van de klant.
- Gegevens worden uitsluitend opgevraagd via geauthenticeerde API's.
- Het LLM kan geen directe databasequery's uitvoeren.
5. Gesprekscontext en caching
Om natuurlijke en consistente gesprekken mogelijk te maken, wordt Redis gebruikt voor tijdelijke opslag van gesprekscontext.
- Prompts en antwoorden worden opgeslagen in Redis.
- Alleen de chatgeschiedenis van de huidige gebruiker wordt gebruikt.
- De opgeslagen context verloopt automatisch één uur na de laatste interactie.
- Gebruikers kunnen geen chatgeschiedenis van andere gebruikers benaderen.
6. Logging
Gebruikersinteracties worden gelogd voor monitoring, probleemoplossing en toekomstige verbeteringen.
- Logbestanden worden op een write-only manier opgeslagen.
- Het LLM heeft geen leestoegang tot logbestanden.
- Logs worden 90 dagen bewaard.
- Na 90 dagen worden logs automatisch en permanent verwijderd.
7. Microsoft Data Processing Commitment
Microsoft garandeert contractueel dat klantgegevens die naar Azure OpenAI worden verzonden niet worden gebruikt voor het trainen van foundation models.
Meer informatie over gegevensverwerking, opslag en privacy binnen Azure OpenAI is beschikbaar in de Microsoft-documentatie:
Azure OpenAI Data Privacy Documentation
Belangrijkste beveiligingsprincipes
- Rolgebaseerde toegangscontrole blijft volledig van kracht.
- Geen directe database-toegang voor het LLM.
- Tokenbeveiliging is gelijk aan de standaard ESS-authenticatie.
- Gebruikersgesprekken zijn volledig gescheiden per gebruiker.
- Tijdelijke opslag van context met automatische vervaldatum.
- Write-only logging met gecontroleerde bewaartermijn.
- Enterprise privacybescherming via Azure OpenAI.
Opmerkingen (0 opmerkingen)