Een AI-agent rond Odoo is veilig in de volgorde lezen, concept, schrijven: lezen mag breed, concepten hebben een redacteur nodig, en schrijven heeft een gebruiker met de minste rechten nodig, een log, een noodknop en een mens op alles wat onomkeerbaar of geldgerelateerd is. Sla die volgorde over en het opruimen kost meer dan de automatisering bespaarde.
Je hebt vorige week een AI-assistent op Odoo aangesloten. Hij kan "hoeveel openstaande offertes heeft verkoop" in twee seconden beantwoorden, en het team is er dol op. Dan vraagt iemand hem om "de dubbele contacten op te ruimen", voegt hij twee partners samen die geen duplicaten waren, en de facturen op een van hen wijzen naar het verkeerde bedrijf. Nu ben je een wijziging aan het terugdraaien die niemand heeft beoordeeld.
Dit is de echte vraag bij AI-agenten en Odoo. Niet "kan het", maar "wat zou het op eigen houtje mogen doen". Een lezing is goedkoop om fout te doen. Een schrijfactie niet. Deze post behandelt wat een agent realistisch tegen Odoo kan doen, waar automatisering veilig is en waar het riskant is, en de waarborgen waarmee je het kunt gebruiken zonder de sleutels uit handen te geven.
Wat een "AI-agent" tegen Odoo werkelijk is
Strip de marketing eraf en een AI-agent is een taalmodel dat tools kan aanroepen. Tegen Odoo bereiken die tools je data via een van een paar deuren:
- De externe API (XML-RPC of JSON-RPC). De klassieke manier om Odoo-records van buitenaf te lezen en te schrijven. Let op: Odoo heeft aangekondigd dat XML-RPC en JSON-RPC op
/xmlrpc,/xmlrpc/2en/jsonrpcverwijderd worden in Odoo 22 (najaar 2028) en op Odoo Online in 21.1 (winter 2027). De vervanging is de nieuwe externe JSON-2 API. Als je iets nieuws bouwt, bouw dan op JSON-2. - Een MCP-server. Model Context Protocol is de standaard waarmee assistenten als Claude of ChatGPT via één connector met een systeem kunnen praten. Voor Odoo is er per medio 2026 geen officiële MCP-server van Odoo S.A. Wat er wel is, zijn communityprojecten en third-party modules (sommige gratis, sommige betaald in de App Store) die dezelfde RPC-API achter een MCP-laag verpakken.
- Odoo's eigen automatisering. Automatiseringsregels en serveracties zitten binnen Odoo. Een agent hoeft niet per se de automatisering te "zijn"; hij kan er een aanmaken of activeren.
Het deel dat het meest telt: elk van deze deuren loopt door Odoo's eigen beveiliging. Een lezing, schrijfactie of verwijdering wordt gecontroleerd tegen de toegangsrechten, recordregels en veldtoegang van de gebruiker waarmee de agent inlogt. De agent staat niet boven Odoo's rechtensysteem. Hij is een gebruiker, en hij erft precies wat die gebruiker mag doen. Dat ene feit is je sterkste waarborg, en de rest van deze post gaat over het goed benutten ervan.
De drie dingen die een agent doet, gerangschikt op risico
Denk aan agentacties in drie bakjes. Behandel ze verschillend.
Lezen (laag risico, begin hier)
Odoo vragen stellen. "Geef de achterstallige facturen voor deze klant." "Hoeveel van product X is geprognosticeerd voor volgende maand." "Vat de chatter op dit ticket samen." Een lezing kan je data niet corrumperen. In het slechtste geval krijg je een verkeerd antwoord, en een verkeerd antwoord is zichtbaar en herstelbaar. Hier zou bijna elk team moeten beginnen, en voor velen is het genoeg.
Concept (laag tot gemiddeld risico)
De agent bereidt iets voor dat een mens verzendt. Een conceptofferte. Een antwoord aan een klant dat in je outbox belandt, niet in hun inbox. Een voorgestelde productomschrijving. De agent doet het typen; een mens doet het versturen. Het risico is ingeperkt omdat er niets bij een klant of grootboek terechtkomt totdat iemand klikt. Dit is de sweet spot voor het meeste echte werk: snel, en toch beoordeeld.
Activeren / schrijven (gemiddeld tot hoog risico)
De agent wijzigt een record of activeert een actie: een order bevestigen, een factuur boeken, contacten samenvoegen, een prijs bijwerken, een voorraadhoeveelheid wijzigen. Hier gaat het mis, en hier heb je echte waarborgen nodig. Niet omdat de agent roekeloos is, maar omdat hij handelt op zijn lezing van een dubbelzinnige instructie, en "ruim de duplicaten op" is dubbelzinnig.
Eén zin trekt de grens goed: lezen en concepten mogen breed ingeschakeld worden; schrijven moet smal, specifiek en beoordeeld zijn. Een agent die op eigen houtje journaalposten boekt, is een andere risicocategorie dan een die een e-mail opstelt.
Waar automatisering veilig is, en waar niet
Veilig om een agent met weinig toezicht te laten doen:
- Data lezen en erover rapporteren die hij mag zien.
- Documenten en berichten in concept opstellen ter beoordeling door een mens.
- Een smalle, goed gedefinieerde actie activeren met een duidelijke "ongedaan maken", bijvoorbeeld een taak naar een fase verplaatsen of een interne notitie toevoegen.
Deze zijn riskant, dus houd een mens in de lus:
- Alles wat geld raakt: facturen boeken, betalingen registreren, kortingen toepassen.
- Alles wat onomkeerbaar of moeilijk omkeerbaar is: records samenvoegen, verwijderen, in bulk archiveren, massale veldupdates.
- Alles wat het bedrijf verlaat: e-mail naar klanten sturen, orders bevestigen die levering in gang zetten, inkooporders plaatsen.
- Alles tegen voorraad of boekhouding waar een verkeerde waarde doorwerkt: het wijzigen van aanwezige hoeveelheden, het bewerken van btw-instellingen, het wijzigen van betalingsvoorwaarden.
Het patroon is consistent: hoe meer een actie omkeerbaar, intern en smal is, hoe veiliger het is om te automatiseren. Hoe meer het onomkeerbaar, extern of geldgerelateerd is, hoe meer een mens nodig is. Onze eigen volgorde bij klanten volgt daaruit: draai de taak eerst buiten Odoo, als een assistent in een chat waar een mens elke actie goedkeurt, voordat je het als een vaste automatisering in de organisatie inbakt. De chatfase laat je de foutmarge zien, de randgevallen en de instructies die je vergeten was te schrijven, op een moment dat elke fout nog door een mens gaat. Alleen wat weken van dat toezicht overleeft, verdient een plek als ingebedde agent.
Mens-in-de-lus, goed gedaan
Mens-in-de-lus betekent niet dat iemand elke actie bekijkt. Dat haalt het hele punt onderuit. Het betekent dat je acties op risico sorteert en op elk het juiste niveau van beoordeling toepast. Een getrapt model werkt goed:
1. Laag risico: voer automatisch uit. Lezen, interne notities, fasewijzigingen. Gelogd, niet beoordeeld. 2. Gemiddeld risico: log voor beoordeling achteraf. De actie gebeurt, maar wordt vastgelegd zodat iemand de batch later kan controleren en patronen kan opmerken. Goed voor concepten die automatisch naar interne adressen worden verstuurd, of recordupdates met lage waarde. 3. Hoog risico: keur goed voordat het draait. De agent bereidt de actie voor en wacht. Iemand keurt goed of af. Gebruik dit voor geld, voor externe verzendingen en voor alles wat onomkeerbaar is.
In Odoo-termen betekent "keur goed voordat het draait" vaak dat de agent een conceptrecord aanmaakt (een conceptfactuur, een offerte in concept) en een mens het bevestigt in het normale Odoo-scherm. Je bouwt geen nieuw goedkeuringssysteem. Je gebruikt de concept-dan-bevestigen-flow die Odoo al heeft.
De waarborgen die er echt toe doen
Vijf dingen, de belangrijkste eerst.
Een speciaal daarvoor bestemde Odoo-gebruiker met de minste rechten voor de agent.
Richt een agent nooit op een adminaccount. Maak een aparte gebruiker, geef die API-sleutelauthenticatie (beschikbaar sinds Odoo 14, en de juiste keuze voor elke integratie: je kunt de sleutel intrekken of roteren zonder aan een login te komen), en verleen alleen de toegangsrechten en recordregels die de taak nodig heeft. Als de agent alleen verkoopdata leest, krijgt hij leesrecht op verkoop en verder niets. Dit is de waarborg die Odoo voor je afdwingt, dus benut hem ten volle.
Standaard alleen-lezen, schrijven bij uitzondering.
Begin elke agent als alleen-lezen. Voeg bewust schrijfrechten per model toe, wanneer er een duidelijke reden en een duidelijke beoordelingsstap is. Verleen geen brede schrijfrechten "voor de zekerheid" om later aan te scherpen. Later aanscherpen gebeurt zelden.
Concepten boven directe acties.
Overal waar Odoo een conceptstatus ondersteunt, laat je de agent het concept produceren, niet de definitieve versie. Conceptofferte, geen bevestigde order. Conceptmail, geen verzonden mail. De kosten zijn één menselijke klik. Het voordeel is een controlepunt op alles wat ertoe doet.
Een log die je kunt lezen, en een noodknop.
Twee dingen uit een ontnuchterende branche-enquête uit 2026: een meerderheid van de organisaties kon geen grenzen afdwingen aan wat hun agenten mochten doen, en een meerderheid kon een ontspoorde agent niet stoppen. Vermijd allebei. Log wat de agent doet op een plek die een mens leest, en zorg dat je zijn API-sleutel in één stap kunt uitschakelen als het misgaat. Met API-sleutelauthenticatie in Odoo is intrekken precies die ene stap.
Scope de instructie, niet alleen de rechten.
Rechten verhinderen dat een agent aankomt wat hij niet zou moeten aankomen. Ze verhinderen niet dat hij het verkeerde doet binnen wat hij wel mag. "Werk de prijs bij" is gevaarlijk; "zet de adviesprijs op product X op 49,00 en laat het me zien voordat je opslaat" is veilig. Smalle instructies, met een bevestiging op schrijfacties, dichten het gat dat rechten alleen openlaten.
Het stuk waar mensen over struikelen
Een paar dingen overkomen vrijwel iedereen
Een paar niet voor de hand liggende dingen waar teams hier last van hebben.
De agent erft de recordregels van de gebruiker, inclusief de regels die je vergeten was. Als je integratiegebruiker in een groep zit met een brede recordregel, ziet de agent meer dan je verwacht. Test wat de agent daadwerkelijk kan lezen door als die gebruiker in te loggen en te kijken, niet door iets aan te nemen.
"Alleen-lezen" via de API is niet altijd alleen-lezen in de praktijk. Sommige serveracties en berekende velden veroorzaken in randgevallen schrijfacties als neveneffect van een lezing, en sommige endpoints laten je methodes aanroepen, niet alleen velden lezen. Als je toegang geeft tot methode-aanroepen, heb je meer gegeven dan "lezen". Beperk je tot de specifieke modellen en operaties die je bedoelt.
Multi-company maakt het bereik moeilijker, niet makkelijker. In een multi-company database bepaalt de bedrijfscontext van de agent welke records hij ziet en bewerkt. Een agent die op het verkeerde bedrijf is ingesteld, kan de data van de verkeerde entiteit lezen of schrijven. Zet het bedrijf expliciet vast.
Concepten verbruiken nog steeds volgnummers en kunnen mensen op de hoogte stellen. Een conceptfactuur kan een factuurnummer pakken; een actie op een record kan de chatter activeren en abonnees mailen. "Het is maar een concept" betekent niet altijd "niemand heeft het gemerkt". Controleer wat er wordt geactiveerd voordat je een agent in bulk records laat aanmaken.
De deprecatieklok tikt echt. Als een leverancier of een interne build op gewone XML-RPC of JSON-RPC draait, heeft die een verwijderdatum (Odoo 22, najaar 2028; Odoo Online 21.1, winter 2027). Plan de overstap naar de JSON-2 API in plaats van er tijdens een upgrade achter te komen.
Snelle checklist
- De agent logt in als een speciaal daarvoor bestemde gebruiker, nooit als admin.
- Authenticatie is een API-sleutel die je in één stap kunt intrekken, geen wachtwoord.
- De gebruiker heeft toegangsrechten en recordregels met de minste rechten, getest door als die gebruiker in te loggen.
- De agent begint alleen-lezen; schrijven wordt per model toegevoegd, met een reden en een beoordelingsstap.
- Schrijfacties die geld raken, het bedrijf verlaten of onomkeerbaar zijn, vereisen eerst goedkeuring van een mens.
- De agent maakt concepten waar Odoo een conceptstatus ondersteunt.
- Acties worden ergens gelogd waar een mens ze leest.
- Je hebt getest of je de agent kunt uitschakelen en bevestigd dat hij dan stopt.
- Instructies voor schrijfacties zijn specifiek, met een bevestiging voordat er wordt opgeslagen.
- Elke gewone XML-RPC- of JSON-RPC-integratie heeft een plan om over te stappen naar JSON-2.
FAQ
Kan een AI-agent data in Odoo wijzigen?
Ja, als de gebruiker waarmee hij inlogt schrijfrechten heeft. Elke lezing, schrijfactie en verwijdering wordt gecontroleerd tegen de toegangsrechten, recordregels en veldtoegang van die gebruiker. De veilige standaard is om de agent alleen-lezen te starten en schrijftoegang smal te verlenen, één model tegelijk, met menselijke beoordeling op alles wat geld raakt of het bedrijf verlaat.
Is er een officiële Odoo MCP-server?
Nee. Per medio 2026 is er geen MCP-server die door Odoo S.A. wordt onderhouden. Er zijn communityprojecten en third-party modules, sommige gratis en sommige betaald in de App Store, die Odoo's RPC-API achter een Model Context Protocol-laag verpakken zodat assistenten als Claude of ChatGPT kunnen verbinden. Ze lopen nog steeds door Odoo's eigen rechtensysteem.
Hoe voorkom ik dat een AI-agent schade aanricht in Odoo?
Geef hem een speciaal daarvoor bestemde gebruiker met de minste rechten en API-sleutelauthenticatie in plaats van admintoegang, houd hem standaard alleen-lezen, vereis goedkeuring van een mens voor schrijfacties met hoog risico, log zijn acties waar een mens ze leest, en bevestig dat je zijn API-sleutel in één stap kunt intrekken om hem te stoppen.
Moet de agent orders automatisch bevestigen en facturen boeken?
Niet zonder goedkeuring van een mens. Het bevestigen van orders zet levering in gang en het boeken van facturen raakt je grootboek, beide moeilijk omkeerbaar. Laat de agent een conceptofferte of conceptfactuur voorbereiden en laat een mens het bevestigen in het normale Odoo-scherm.
Is XML-RPC nog steeds veilig om een agent op te bouwen?
Het werkt vandaag, maar het is op zijn retour. Odoo heeft de verwijdering van XML-RPC en JSON-RPC ingepland in Odoo 22 (najaar 2028) en op Odoo Online in 21.1 (winter 2027), met de externe JSON-2 API als vervanging. Bouw alles nieuws op JSON-2.