Hoe UCLL Copilot laat antwoorden vanuit eigen bronnen

UCLL is een van de grootste hogescholen van Vlaanderen: meer dan 18.000 studenten op campussen in Leuven en Limburg. De hogeschool rolde Microsoft 365 Copilot-licenties uit naar medewerkers én studenten. En de ambitie reikte verder dan gebruik alleen. UCLL wilde teams die hun eigen agents bouwen, op hun eigen kennis.

Die ambitie botste op een herkenbare muur. Copilot heeft op alles een schitterend antwoord, behalve op vragen over de organisatie waarvoor het werkt.

Een docent heeft de actuele versie van een examenreglement nodig. Dat kan op het Drupal-intranet staan. Of op een van de SharePoint-sites van het departement dat er eigenaar van is. Of op allebei, in twee versies waarvan er maar één actueel is. Drie zoekopdrachten later mailt ze een collega. Zo vinden de meeste mensen in de meeste organisaties nog altijd hun weg.

Vermenigvuldig dat met 18.000 studenten en enkele duizenden medewerkers, en de kost is geen zoekprobleem meer. Het zijn duizenden kleine onderbrekingen per week die terechtkomen bij de mensen die toevallig weten waar alles staat.

Copilot verbinden met die bronnen klinkt als simpel loodgieterswerk. Dat is het niet. Twee dingen maken het moeilijk.

Permissies: een hogeschoolpubliek is niet één publiek. Studenten, docenten en centrale diensten zien elk andere dingen. Een agent die een student antwoordt met content van een HR-site voor medewerkers is geen nuttige agent.

Eigenaarschap: het intranetteam is eigenaar van het intranet. Departementen zijn eigenaar van hun SharePoint-sites. Elke oplossing die hun content naar een tweede plek kopieert, met een tweede set regels, creëert een schaduwsysteem dat veroudert vanaf de dag dat het live gaat.

Het governance-spoor kwam eerst, niet laatst. Toegang tot kennis volgt de bestaande Microsoft Entra-omgeving van UCLL: de identiteiten en groepen die de hogeschool al beheert, al onderhoudt, al auditeert. Geen parallel permissiemodel, geen tweede plek om synchroon te houden. Een agent toont een gebruiker wat die gebruiker zelf had kunnen vinden.

Hetzelfde kader dekt ook de agents zelf: wie er een mag bouwen, waarmee die mag verbinden en hoe kwaliteit doorheen de tijd bewaakt wordt. Met 150+ Copilot-gebruikers die agents bouwen of configureren, is dat kader het verschil tussen groei en wildgroei.

UCLL had twee dingen nodig die elkaar meestal tegenwerken: een architectuur op maat van het eigen landschap, en een uitrol op het tempo van een onderwijsorganisatie.

Custom .NET-services doen het werk dat engineeringcontrole vraagt: kennisbronnen extraheren, chunken en vectoriseren, en ze ontsluiten voor agents. Copilot Studio en zijn standaardconnectoren doen het werk dat licht moet blijven: agentconfiguratie, en SharePoint-integratie voor gevalideerde sites.

Die splitsing is de reden dat het team van UCLL zelf verder kan. De zware engineering gebeurt één keer en staat daarna niet in de weg. De laag waarin agents gebouwd worden is low-code. En net daar kunnen het IT-team van een hogeschool en op termijn ook de departementen zonder ons verder.

Onder de motorkap gelden twee principes. Extractie is event-driven: verandert content aan de bron, dan volgt de index zonder volledige re-crawls. Het bronteam behoudt het eigenaarschap. En content wordt één keer gevectoriseerd en hergebruikt: dezelfde vectoren voeden meerdere zoektoepassingen, niet één enkele chatbot.

Ontworpen rond intentie, niet rond opslag

De agents zijn gebouwd rond wat medewerkers en studenten proberen te doen, niet rond waar documenten toevallig staan. Die insteek is meteen ook de basis voor de volgende stap: agents die niet alleen antwoorden, maar ook de volgende stap zetten.