Hyland opent OpenArch voor AI op bedrijfsdocumenten

Hyland stelt OpenArch op 10 november beschikbaar als open-source laag onder Apache 2.0 die AI toegang geeft tot bestaande bedrijfsdocumenten; het bedrijf zegt dat bronrechten bij elke vraag via API’s van gekoppelde opslagsystemen worden gecontroleerd.

Een Nederlandse organisatie met klantdossiers, procedures en contracten in verschillende systemen kan zo één ingang voor een documentassistent krijgen, zonder eerst alle bestanden naar een nieuw platform te verhuizen. De inzet zit in de toegang: medewerkers mogen alleen documenten vinden waarvoor hun account rechten heeft. De organisatie kiest ook waar de index en het gebruikte AI-model draaien.

Eén ingang voor meerdere documentbronnen

OpenArch plaatst een contentlaag tussen bestaande documentopslagplaatsen, in vaktaal repositories, en AI-diensten. Hyland beschrijft het als een centrale toegang tot documenten en de metadata en rechten die eraan vastzitten. De oorspronkelijke bestanden blijven in de systemen die ze beheren. Een team kan de laag verbinden met een zelfgekozen AI-dienst en kiezen waar OpenArch draait. Hyland noemt Docker Compose als manier om OpenArch op een cloudserver of eigen server te draaien; Content Innovation Cloud is niet vereist.

De index zelf is wel een nieuwe technische component. Alfresco, Nuxeo en Microsoft SharePoint staan in de repository als voorbeelden; de beschrijving noemt ook metadata, tekstchunks, vectoren en bronrechten via ACL’s, lijsten met toegangsregels. Chunks zijn doorzoekbare tekstfragmenten; vectoren helpen zoeken op betekenis. De bestanden hoeven dus niet te verhuizen, maar een AI-klare afgeleide komt wel in de index terecht. Dat onderscheid is relevant voor bewaartermijnen, verwijderverzoeken en de vraag welke tekst naar een gekozen model gaat.

Hyland presenteert OpenArch als een volgende stap in zijn open-source geschiedenis met Alfresco en Nuxeo. Het bedrijf zegt dat ontwikkelaars de code kunnen bekijken, aanpassen en zelf beheren. Dat geeft meer ruimte om de architectuur te wijzigen dan een gesloten inhoudsplatform, maar zegt nog niet hoeveel integratiewerk een organisatie zelf moet doen.

Bronrechten worden bij elke vraag gecontroleerd

De productpagina geeft een concreet antwoord op de vraag hoe rechten blijven gelden. Hyland zegt dat OpenArch de permissies van een gebruiker dynamisch controleert wanneer die een vraag stelt, door de API van de bronrepository aan te roepen. Het bedrijf zegt dat beveiligingsregels niet worden gekopieerd of gecachet en dat wijzigingen in het bronsysteem direct voor AI-queries gelden. Dat bevestigt de claim op productniveau, maar het blijft Hylands eigen beschrijving van de werking.

De openbare repository beschrijft daarnaast het overnemen van toegangsregels via ACL’s. Dat kan samengaan met controle bij de bron: de index kan ACL-informatie bewaren en bij een vraag ook de bron raadplegen. De documentatie werkt alleen niet uit welke route iedere connector volgt, welke authenticatie nodig is en wat er gebeurt als een bron-API tijdelijk niet bereikbaar is. Vraag daarom per gebruikte bron hoe de controle werkt en welke terugval geldt als die bron niet reageert.

De koppeling lost niet elk RAG-probleem op

OpenArch richt zich op toegang tot verspreide documenten. Het maakt verouderde versies, tegenstrijdige procedures of ontbrekende metadata niet vanzelf betrouwbaar. Bij retrieval augmented generation (RAG), waarbij een model eerst relevante bronpassages ophaalt en daarna antwoordt, tellen schone bronnen, toegangsrechten per gebruiker en testen met echte vragen mee naast de modelkeuze. Een centrale index helpt pas als duidelijk is welk document leidend is en wie het mag zien.

Een aparte laag is ook niet voor elk team nodig. De afweging hangt onder meer af van hoeveel de bronnen verschillen, hoe actueel informatie moet zijn, hoe gevoelig die is en hoe vaak medewerkers zoeken. Als één bestaande suite de documenten en rechten al goed beheert, kan een extra index alleen een nieuwe plek voor beheer en storingen toevoegen. Verspreide repositories met uiteenlopende regels maken een gedeelde laag relevanter.

Connectoren bepalen wat de belofte waard is

Andere aanbieders laten zien dat toegang en synchronisatie verschillende vormen kunnen aannemen. Google documenteert voor SharePoint een federatieve zoekroute waarbij resultaten zijn gebaseerd op de rechten van de ingelogde gebruiker. Bij geïndexeerde data moeten organisaties toegangsregels en synchronisatie inrichten. Google zegt dat incrementele synchronisatie standaard elke drie uur draait en geen identiteitsgegevens of verwijderingen meeneemt; daarvoor gelden aparte synchronisaties. Dat is Googles ontwerp, geen test van OpenArch, maar het maakt zichtbaar waarom de gekozen connectorroute ertoe doet.

Workday koos voor een andere toepassing van hetzelfde vraagstuk: externe agents kunnen daar live HR- en financiedata opvragen met bestaande rechten, goedkeuringen en auditregistratie per verzoek. OpenArch richt zich op documenten uit meerdere repositories, niet op Workday-processen. In beide gevallen moet de toegangsregel meelopen met de aanvraag en met de identiteit van degene die de AI gebruikt.

OpenArch staat volgens Hyland nu op GitHub onder Apache 2.0, maar de release bevat geen prijs voor implementatie, prestatiecijfers of volledige lijst van ondersteunde connectors. De repository noemt enkele voorbeelden, maar geeft geen complete lijst van kant-en-klare koppelingen of hoeveel werk een extra bron vergt. Daardoor blijft voor een Nederlandse organisatie eerst te beantwoorden welke bestaande systemen al aansluiten en waar maatwerk nodig is.

De bruikbare proef is concreet: geef twee testgebruikers verschillende rechten, wijzig die rechten in de bron en stel daarna dezelfde documentvraag opnieuw. Controleer ook of een verwijderd of verouderd bestand uit de index verdwijnt en wat er naar de gekozen AI-dienst wordt gestuurd. OpenArch belooft een centrale route zonder de oorspronkelijke repositories te vervangen; de waarde ervan hangt af van die controles per connector.