Uit de praktijk

Ollama en Open WebUI op het bedrijfsnetwerk: een lokale AI-assistent

Van lokale test naar gedeelde AI-dienst: plan toegang, model-API, datastromen, back-up en beheer met Ollama en Open WebUI.

InfrastructuurIntegratie
DAXS-logo boven verbonden gespreks- en modelverwerkingssymbolen binnen een gezamenlijke beschermende grens.

Een lokaal taalmodel is snel uit te proberen. Een gedeelde AI-assistent heeft daarnaast geregelde toegang, duidelijke datastromen en een verantwoordelijke beheerder nodig. Ollama en Open WebUI kunnen samenwerken: de ene component voert modellen uit, de andere biedt de interface voor het dagelijkse werk.

Voor een bedrijf begint de planning met een concrete taak: teksten opstellen vanuit goedgekeurde notities, interne aantekeningen ordenen of helpen bij technische vragen. Bepaal vóór de hardwarekeuze welke invoer is toegestaan, hoe resultaten worden gecontroleerd en welke reactietijden in de praktijk passen.

Twee componenten met verschillende taken

Ollama levert de runtime en een API voor taalmodellen. Open WebUI voegt een beheerbare webinterface toe. Een lokaal geïnstalleerde interface zegt echter niet waar ieder aangesloten model rekent. Cloudmodellen, zoeken op het web en extra tools kunnen andere datastromen gebruiken.

Medewerkers bereiken Open WebUI via beveiligde HTTPS-toegang. Alleen de webinterface communiceert met Ollama in het interne servicenetwerk. Data, back-up en beheer worden afzonderlijk behandeld.
Een mogelijke indeling: goedgekeurde toegang tot de interface en modelaanroepen op het interne servicenetwerk. De concrete uitvoering volgt de bestaande omgeving.

In dit beheerconcept bereiken medewerkers de interface via goedgekeurde toegang. Open WebUI verbindt intern met Ollama. De model-API blijft beperkt tot diensten die haar daadwerkelijk nodig hebben. Verbindingen tussen afzonderlijke containers of servers moeten expliciet worden gepland: localhost verwijst telkens naar de eigen netwerkomgeving van de component.

Van één werkplek naar een gedeelde dienst

Het verschil zit vooral in wat na de eerste geslaagde chat gebeurt. Deze vergelijking beschrijft een mogelijke uitbreiding voor een klein bedrijf; het is een planningshulpmiddel en geen gedocumenteerd klantproject.

Voorbeeld: een technische test voorbereiden voor een goedgekeurde gebruikersgroep.
Onderdeel Individuele test Gedeeld gebruik
Toegang Eén persoon test op de eigen computer. Persoonlijke accounts, vastgelegde rollen en geregeld intrekken van toegang.
Data Niet-gevoelige voorbeelddata. Goedgekeurde datatypen, bewaartermijnen en aantoonbare rechten op bronnen.
Beschikbaarheid De computer staat tijdens de test aan. Afgesproken gebruikstijden en gedocumenteerd herstel.
Capaciteit Eén aanvraag geeft een bruikbaar antwoord. Gelijktijdige taken, wachttijden en langere invoer worden gemeten.
Wijzigingen Model en software worden uitgeprobeerd. Geteste versies, back-up vóór wijzigingen en een betrouwbare terugvalroute.

Beveilig toegang en model-API afzonderlijk

Volgens de leverancier vereist de lokale Ollama-API geen eigen authenticatie. Netwerktoegang vervangt daarom geen toegangscontrole. Voor een bedrijfsdienst moet de model-API alleen via de noodzakelijke interne verbindingen bereikbaar zijn. Een poort die voor alle werkplekken of het internet openstaat, is geen geschikt uitgangspunt. Ollama: authenticatie (externe link).

Configureer aanmelding, gebruikersgoedkeuring en beheerdersrechten bewust. Een bestaande identiteitsdienst kan een zinvolle aansluiting zijn; de passende integratie hangt af van de omgeving. Een proxy mag een aangemelde identiteit alleen doorgeven via vertrouwde informatie die hij zelf instelt. Open WebUI: toegang en rechten (externe link).

HTTPS beschermt de verbinding van de browser naar het toegangspunt. Bij meerdere systemen wordt ook het vervolg naar de backend naar behoefte versleuteld en beperkt. Certificaten, omleidingen en de verbindingen die de interface nodig heeft, worden samen getest. Open WebUI: HTTPS en reverse proxy (externe link).

Controleer “lokaal” aan de hand van de echte datastroom

Voor uitsluitend lokale modelaanroepen biedt Ollama een modus zonder zijn cloudfuncties. Dit vervangt niet de controle van andere verbindingen in Open WebUI of toegevoegde tools. Ook modeldownloads en software-updates vereisen een geplande aanvoerroute. Ollama: lokaal gebruik en cloudfuncties (externe link).

  • Model: Welke exacte versie verwerkt de aanvraag en waar draait die?
  • Documenten: Waar worden uploads, geëxtraheerde teksten, zoekindexen en back-ups opgeslagen?
  • Aanvullende diensten: Worden andere aanbieders gebruikt voor zoeken, tekstherkenning, spraak of embeddings?
  • Tools: Welke verbinding mag gegevens lezen of acties uitvoeren, en met wiens rechten?

Cloud en hybride diensten kunnen geschikte aanvullingen zijn. Leg dan aanbieders, datatypen en goedkeuringen expliciet vast. Overschakelen naar een externe dienst hoort niet ongemerkt te gebeuren omdat het lokale model bezet is.

Bedrijfskennis vereist gerichte rechten

Een aanmelding bepaalt eerst wie de interface gebruikt. Daaruit volgt niet automatisch het recht om alle geüploade documenten te zien. In het voorbeeld kan een goedgekeurde handleiding voor alle pilotgebruikers beschikbaar zijn, terwijl personeelsdossiers volledig buiten de pilot blijven.

Controleer bij latere aansluiting van meer bronnen de rechten per verzameling, document en gebruiker. Ook zoekresultaten, citaten, gedeelde chats en opgeslagen antwoorden kunnen informatie onthullen. Wijzigingen in groepen of bronrechten moeten doorwerken in de kennisoplossing. Meer informatie op de vakpagina’s Bedrijfskennis & RAG en AI-beveiliging en rechten.

Back-up en updates horen bij het concept

Maak back-ups van de werkelijk gebruikte gegevens: database, uploads en configuratie, plus de sleutels die voor herstel nodig zijn. Documenteer modelnaam en exacte versie, ook voor aangepaste modellen en eigen uitbreidingen. Bewaar de back-up met beschermde toegang apart van het draaiende systeem.

Vóór een update zijn een herstelbare back-up, controle van releaseopmerkingen en een test buiten productie nodig. Een oude containerimage alleen herstelt na een databasemigratie niet noodzakelijk de vorige toestand. Open WebUI: updates, back-up en terugvalroute (externe link).

Een zinvolle hersteltest begint in een afzonderlijke omgeving. Controleer daar aanmelding, modelverbinding, een niet-gevoelige testtaak en de verwachte rechten. Pas daarna is in te schatten hoe lang een echte storing duurt. Een draaiende VM of bestaande back-upmap toont dat niet zelfstandig aan.

Een werkende interface bewijst nog geen werkend model

Monitoring moet onderscheid maken tussen een bereikbare interface, een beschikbaar gekozen model en een volledig werkende aanvraag. Ook de Open WebUI-documentatie onderscheidt deze niveaus. Open WebUI: functionele monitoring (externe link).

Volg voor het afgesproken beheer ook opslaggebruik, beschikbare capaciteit, foutpercentages en wachttijden. Testaanvragen bevatten geen vertrouwelijke informatie. Logs moeten voor probleemoplossing volstaan zonder standaard alle gesprekken te dupliceren. Leg vóór breder gebruik vast wie op storingen reageert en wie updates goedkeurt.

Een overzichtelijke acceptatie vóór de start

  1. Toegang controleren: Een goedgekeurde gebruiker komt binnen; een niet-goedgekeurde gebruiker en een ongeoorloofd netwerksegment blijven uitgesloten.
  2. Datastroom controleren: Model, interface en alle aanvullende diensten gebruiken uitsluitend de afgesproken verbindingen.
  3. Rechten controleren: Twee testrollen krijgen alleen hun eigen toegestane inhoud. Ingetrokken toegang werkt ook na een eerder geslaagde zoekopdracht.
  4. Belasting controleren: Typische taken draaien afzonderlijk en tegelijk; aanvaardbare wachttijden en grenzen worden vastgelegd.
  5. Herstel controleren: Een back-up kan apart worden teruggezet; verantwoordelijkheden en terugvalroute zijn gedocumenteerd.

Benodigde hardware hangt af van model, contextlengte, gelijktijdig gebruik en kwaliteitsdoel. Uit de architectuur volgt daarom geen algemeen aantal gelijktijdig te bedienen gebruikers. Het bestaande artikel Lokale AI testen: een pilot met betekenisvolle belasting verdiept deze capaciteitstoets.

Zinvol beginnen met een afgebakende taak

DAXS kan de bestaande infrastructuur beoordelen, datastromen en toegang plannen en de oplossing in het afgesproken beheer integreren. Een afgebakende toepassing met aantoonbaar nut is een goede eerste stap. Daaruit blijkt of een lokale dienst, cloudaansluiting of combinatie economisch en organisatorisch past.

Lokale LLM’s & infrastructuur · MCP & interfaces · AI-advies & automatisering aanvragen

Bronnen: het voorbeeld beschrijft een mogelijke architectuur en toetsingsprocedure, geen universele installatiehandleiding. Productfuncties, modellicenties en daadwerkelijke systeemcompatibiliteit worden voor de gebruikte versies gecontroleerd.