One enthusiastic developer has connected an AI client to Odoo within an hour. That is precisely the moment governance becomes necessary: not to slow things down, but to prevent the organisation ending up with ten uncontrolled integrations with credentials on as many laptops.
What you record before you scale up
- Purpose per integration. Which question does this connection solve? Without a purpose you can't restrict scopes.
- Owner. A person, not a team alias. That person approves extensions of permissions.
- Data categories. Which models and fields come into view, and which explicitly do not (personnel files, bank details, BSN-type identifiers).
- Actions. Read only? Create drafts? Write? Execute methods? A decision per category, not a one-off “everything on”.
- Log retention period. How long do you keep calls and metadata, and who may view them?
Roles that work in practice
Three levels are enough. The administrator of the environment manages connections, users and capabilities. The user (member) gets a subset of models and actions, depending on their role. The auditor only reads logs. In a multi-tenant setup this hangs off the tenant: policy centrally, refinement per user.
Logging as evidence, not as reassurance
For an audit or incident investigation you need, per call: timestamp, actor, tenant, tool used, model affected, result status and originating IP. If you want to demonstrate that logs haven't been tampered with, a chain in which each line hashes the previous one helps. For privacy, that includes: IP anonymisation after X days and full deletion at the data subject's request.
GDPR and EU AI Act, in practice
An MCP gateway is a processor: put a data processing agreement in place, name sub-processors, describe security measures and the place of processing. For the EU AI Act, the core for this type of use is not certification but transparency and human oversight: let users know that an AI is looking at company data, keep human approval mandatory for anything that leaves the organisation, and make sure you can reconstruct which model did what. Data minimisation is also a security measure here: fewer fields in the response means less risk.
Uitrol in vier fasen
- Explore (week 1). Staging or development, read-only, one owner, three models. Goal: learn which questions people really ask.
- Read-only on production (weeks 2–3). Same scope, real data, field blocks on, logging checked. Measure which tools are used and where things go wrong.
- Create drafts (month 2). Allow creation of drafts (quotation line, ticket reply, project schedule) with human approval. Still no writing to existing records.
- Controlled writing (month 3+). Release per model and per user, with rate limits, quotas and alerting. Evaluate monthly based on logging.
Measure whether it works
Governance without numbers becomes bureaucracy. Track: number of calls per environment, share of failed calls, most-used tools and models, number of manual approvals that were rejected, and time saved on the use cases you started with. That's also the conversation with the business: not “we've connected AI”, but “this question used to take 20 minutes and now takes 2”.
Practical tip: don't start the governance document as a policy paper but as a single A4 sheet with the five points from the first section, filled in for your first integration — that sheet grows along naturally and actually gets read. Want to spar about roles, logging or the phasing for your own organisation? Contact DAADit Group — we have guided this process at several Odoo environments.
Verder lezen: MCP security best practices and the technische productdocumentatie.
Want to try it yourself? The DAADit Hosted MCP server for Odoo is free to start with 50 calls per day — no installation, no credit card. Create a free account or read the technische productdocumentatie.