Vandaag heb ik iets gebouwd waar ik al langer naartoe wilde: INDY. Geen losse chatbot die alleen advies geeft, maar een directe en afgeschermde koppeling tussen AI, mijn WordPress-websites en de servers waarop ze draaien.
Het doel is simpel. Ik wil in gewone taal kunnen vragen wat er speelt, een artikel laten voorbereiden of een technische controle laten uitvoeren, zonder telkens door verschillende dashboards te klikken. Tegelijkertijd wil ik voorkomen dat AI zomaar ingrijpende wijzigingen uitvoert. Snelheid is belangrijk, maar controle blijft belangrijker.
Van losse informatie naar één operationele assistent
Websitebeheer is vaak versnipperd. WordPress bevat de content, Ploi beheert de servers, monitoring bewaakt de beschikbaarheid en back-ups leven weer ergens anders. Wie een probleem onderzoekt, moet al die bronnen combineren voordat duidelijk is wat er werkelijk aan de hand is.
INDY brengt die informatie samen. De assistent kan de actuele serverstatus lezen, websites inventariseren, publieke pagina’s controleren, recente opdrachten bekijken en open incidenten verzamelen. Daardoor kan ik één concrete vraag stellen, zoals: “Controleer mijn servers en websites op actuele problemen.”
Het antwoord is dan geen algemene uitleg, maar een samenvatting op basis van de echte omgeving. Welke servers zijn actief? Waar loopt de schijfruimte op? Welke back-up staat stil? Zijn er mislukte SSL-verlengingen of beveiligingswaarschuwingen? Dat maakt AI ineens veel bruikbaarder voor dagelijks beheer.
AI met duidelijke grenzen
Een directe koppeling brengt ook verantwoordelijkheid met zich mee. Daarom heb ik INDY niet ontworpen als een assistent die overal onbeperkt bij kan. De koppeling werkt met een vaste inventaris van toegestane websites en servers. Geheimen blijven buiten de gesprekken en destructieve handelingen zijn niet beschikbaar.
Voor risicovolle acties gelden extra bevestigingen. Een server herstarten vereist bijvoorbeeld de exacte actuele servernaam. Publiceren moet expliciet worden gevraagd. Een incident oplossen mag pas nadat de voorgestelde oplossing is goedgekeurd, uitgevoerd en onafhankelijk gecontroleerd.
Dat klinkt misschien streng, maar juist deze beperkingen maken automatisering betrouwbaar. Goede AI-automatisering draait niet om zoveel mogelijk autonomie. Het draait om de juiste autonomie binnen heldere grenzen.
Wat INDY vandaag al deed
Tijdens de eerste echte controles bracht INDY acht actieve servers en tientallen websites in kaart. De assistent combineerde actuele belasting, RAM- en schijfgebruik met back-upstatussen en technische inzichten. Zo werden onder andere certificaatproblemen, verouderde software, beveiligingsmeldingen en een gepauzeerde databaseback-up zichtbaar.
Daarna gebruikte ik dezelfde koppeling voor WordPress. INDY controleerde eerst of de website actief en beheerd was, las bestaande artikelen om de stijl te begrijpen, maakte een nieuw artikel aan en publiceerde het pas nadat die opdracht expliciet was gegeven. Vervolgens werd de publieke URL zonder ingelogde sessie gecontroleerd.
Dat laatste vind ik essentieel. Een geslaagde actie in een beheersysteem betekent nog niet dat een bezoeker het juiste resultaat ziet. Verificatie aan de publieke voorkant hoort daarom bij iedere wijziging.
Incidenten worden voorstellen, geen wilde reparaties
Ook fouten krijgen een vaste route. Wanneer een opdracht mislukt, maakt INDY daar een incident van. Eerst volgt read-only onderzoek. Daarna wordt een herstelvoorstel opgeslagen met de vermoedelijke oorzaak, impact, voorgestelde wijziging, risico’s en een verificatieplan.
Pas na mijn expliciete akkoord mag een beperkte herstelactie worden uitgevoerd. De assistent kan zijn eigen voorstel dus nooit namens mij goedkeuren. Daarmee voorkom ik dat een verkeerde aanname automatisch uitgroeit tot een grotere storing.
De kracht zit in de directe koppeling
Zonder koppeling kan AI vooral uitleggen hoe iets zou moeten werken. Met een directe koppeling kan het actuele informatie verzamelen en een gecontroleerde taak uitvoeren. Dat verschil is enorm.
- Geen gegevens handmatig uit dashboards kopiëren.
- Geen technische commando’s onthouden voor terugkerende controles.
- Geen losse rapportages interpreteren zonder context.
- Wel één begrijpelijke opdracht met een controleerbaar resultaat.
- Wel een auditspoor van wat is bekeken, voorgesteld en uitgevoerd.
Deze aanpak is niet alleen interessant voor technisch websitebeheer. Hetzelfde principe werkt voor marketingrapportages, contentprocessen, CRM-opvolging en interne workflows. Zodra AI veilig toegang krijgt tot de juiste systemen, wordt automatisering veel minder omslachtig.
Wat ik hiervan heb geleerd
De moeilijkste stap is niet het genereren van tekst of het aanroepen van een systeem. De echte uitdaging is het ontwerpen van bevoegdheden. Welke informatie mag worden gelezen? Welke actie mag direct? Waar is bevestiging nodig? En hoe bewijs je achteraf dat een wijziging werkelijk goed is gegaan?
Ik merk opnieuw dat kleine, specifieke tools beter werken dan één onbeperkte toegang. “Controleer deze publieke pagina” is veilig en duidelijk. “Voer een willekeurig servercommando uit” is dat niet. Hoe kleiner de actie, hoe beter de risico’s te begrijpen en het resultaat te verifiëren zijn.
Dit is nog maar het begin
INDY is nog niet af. Nieuwe mogelijkheden voeg ik alleen toe wanneer ze dezelfde veilige structuur volgen: eerst inventariseren, dan de actuele situatie controleren, gericht uitvoeren en onafhankelijk verifiëren.
Wat vandaag begon als een koppeling voor servers en WordPress voelt daardoor steeds meer als een praktische operationele collega. Niet eentje die alles overneemt, maar eentje die continu kan meekijken, het repetitieve werk versnelt en precies weet wanneer mijn akkoord nodig is.
Dat is voor mij de interessantste vorm van AI: niet nóg een scherm waar ik tegen moet praten, maar een veilige laag boven op de systemen die ik toch al gebruik. Dat is INDY.