AI-functionaliteit integreren in bestaande software lijkt vandaag de dag een logische stap. Denk aan opties voor samenvatten, classificeren, doorzoekbaar maken of vertalen. Het ligt anders wanneer je als ISV software levert aan meldkamers, de politie of veiligheidsregio’s. Voeg je AI toe, dan maak je niet alleen een productkeuze, maar kies je ook de infrastructuur namens de klant. Dat brengt in de sector openbare orde en veiligheid specifieke gevoeligheden en risico’s met zich mee. Hoe kun je daar proactief mee omgaan en ook op anticiperen? Dat lees je in dit blog.
Waarom ligt ‘AI toevoegen’ gevoelig in de veiligheidssector?
Zodra een prompt, document of stuk metadata de klantomgeving verlaat en naar een externe modelprovider gaat, ontstaat er een verwerkingsketen. Met daarbij subprocessors en telemetrie die in deze sector lastig te verantwoorden zijn. Voor politiegegevens is dat verschil duidelijk. De Wet politiegegevens (WPG) stelt eisen aan doelbinding, beveiliging, logging en auditeerbaarheid. Die eisen zijn vrijwel onhoudbaar als niet duidelijk is hoe een externe AI-dienst input, output en metadata verwerkt. Lokale of soevereine AI kent dezelfde documentatieplicht. Het verschil is dat een organisatie daar dan zelf over kan rapporteren, in plaats van te vertrouwen op de verklaringen van een derde partij.
Dit is geen theorie meer, maar praktijk
Kijk wat dit alles voor jou als softwareleverancier betekent, want de ontwikkelingen rondom AI gaan razendsnel. De integratie van AI-features en alles wat daarmee samenhangt is geen theoretisch scenario meer, maar praktijk. Dat laat de Rijksoverheid zelf al zien. Zo ontwikkelt SSC-ICT, IT-partner van en voor het Rijk, met Vlam-chat een AI-omgeving met een eigen overheidsdatacenter, gebaseerd op Europese taalmodellen. Deze omgeving is een alternatief voor commerciële chatbots, zoals ChatGPT of Gemini, bij schrijven, samenvatten, vertalen en documentanalyse. Zo blijven de data binnen het overheidsnetwerk, en daarmee onder strikte Nederlandse controle. Dit praktijkvoorbeeld verschuift dan ook het gesprek. Niet langer is de vraag ‘mag dit?’, maar ‘onder welke voorwaarden richten we dit goed in?’ Klanten in de veiligheidssector die deze vraag al bij zichzelf stellen, stellen deze vervolgens ook aan hun softwareleveranciers.
Wat betekent dit voor independent software vendors (ISV’s)?
Concreet betekent dit voor een ISV dat de AI-backend van een product vervangbaar moet zijn. Dat vraagt om een duidelijke scheiding tussen applicatielogica en modelbackend, zodat je een externe API kunt inwisselen voor een lokaal of soeverein gehost model, zonder het hele product opnieuw op te bouwen. Ook ondersteuning voor lokale deployment voor de klanten die dat nodig hebben, is belangrijk. Net als transparantie over welke data waarheen gaat. En het vraagt om goede beheermogelijkheden voor logging, toegangsbeheer en policy enforcement die de klant zelf aan en uit kan zetten én controleren. Je beperkt je als leverancier wanneer je uitsluitend bouwt op één externe AI-API zonder de scheiding van applicatielogica en modelbackend. Zodra een klant in de veiligheidssector deze vraag stelt, sta je in dat geval als leverancier met lege handen. Dat wil je uiteraard niet.
Waar zit de winst?
De winst zit niet in het bouwen van het krachtigste model, maar in het bouwen van de meest verantwoorde inzet ervan. Een iets kleiner lokaal model dat aantoonbaar binnen de eigen omgeving blijft, is voor de doelgroep in de veiligheidssector vaak waardevoller dan een krachtiger extern model waarover de klant geen zeggenschap heeft. Wie dat als ISV nu al in de architectuur verankert, hoeft niet te wachten tot een aanbesteding het afdwingt.
Wil je weten wat wij nog meer betekenen voor de Openbare Orde en Veiligheid, of specifiek voor softwareleveranciers? Klik dan op de desbetreffende pagina’s. Meer weten over onze diensten? Klik dan hier.