What people mean by this

“Can we connect ChatGPT to Odoo?” usually means one of three quite different things.

Using a language model to draft text inside Odoo — descriptions, emails, summaries.

Asking questions about your data in plain language instead of building a report.

Having it carry out actions — create a quotation, update a record, send something.

The first is straightforward and useful. The second is useful with care. The third is where most of the risk sits, and where most of the enthusiasm is.

Worth noting first: Odoo now includes AI natively across the system. For many of these uses you do not need a separate connection at all.

Drafting text

The clearest application.

What it does well:

• Product descriptions from attributes
• First drafts of customer emails
• Summarising a long thread or record
• Knowledge base articles
• Adapting one message for different audiences
• Shortening something that is too long

What it does badly:

• Anything requiring a fact it does not have
• Your specific tone, without being shown examples
• Prices, dates, availability — it will produce plausible ones
• Anything with legal or contractual weight

The rule: read every word before it reaches a customer. Generated text is fluent. Fluent and correct are different properties.

Asking questions of your data

Genuinely useful for the one-off questions nobody would build a report for.

The catch is definitional. Does “revenue” mean invoiced, ordered or delivered? Does “this year” mean calendar or fiscal? Are cancelled orders excluded?

The answer arrives confidently either way, and unlike a report you designed, you may not know what it counted.

Practical position: ask freely, verify before acting, and use defined reports for anything you have to defend to a board, a bank or an auditor.

Taking actions

Where it gets interesting and where it needs limits.

A model can be given the ability to create records, update fields and send messages. Technically this works.

Three problems.

It can be confidently wrong. A misread instruction that creates a wrong record is worse than no automation, because it looks like it worked.

Permissions are inherited. Whatever access you give it, it has. A model with the ability to post journal entries can post wrong ones.

Explanation is hard. When something unexpected happens, tracing why is genuinely difficult.

A workable boundary: let it prepare things. Draft the quotation, populate the record, compose the message. A person confirms.

Draft-and-confirm captures most of the time saving and almost none of the risk.

Where your data goes

A practical question that is easy to overlook.

If you connect an external model, your data is sent to that provider. Customer names, order details, whatever is in the prompt.

Three questions to ask before connecting anything:

Is our data retained? For how long?

Is it used to train their models? Business tiers usually say no. Free tiers often say yes.

Does this comply with our obligations? Customer personal data, contracts, anything covered by data protection rules where you operate.

For much business data this is acceptable, and it is the same decision you already made choosing cloud software. But it should be a decision, not an accident — and it deserves particular attention for payroll, personal data and contracts.

This is one reason Odoo’s native AI matters: fewer moving parts and a clearer data path.

What not to automate

Five, and they hold regardless of how good the model gets.

Anything posting to the ledger. A person reviews and posts. Always.

Anything sending to a customer unread. Scale turns one error into a thousand.

Anything with contractual weight. Quotes, terms, commitments.

Pricing decisions. It can apply your price list. It should not invent a price.

Anything you cannot explain afterwards. If a regulator or auditor asks how a figure was arrived at, “the AI decided” is not an answer.

A sensible starting point

1. Check what Odoo already does natively. For drafting, summarising and document reading you may not need an external connection at all.

2. Start with internal drafting. Descriptions and summaries. No customer sees the output while you learn where it is weak.

3. Move to customer-facing drafts with review. Emails and replies, read before sending.

4. Add plain-language questions for exploration, with verification before acting.

5. Consider actions only in draft-and-confirm form.

6. Decide your data position explicitly before connecting anything external.

What it will not do

Understand your business. It recognises patterns in language. It does not know that this customer is difficult, or that the margin looked bad because you took a strategic order.

Fix your data. It will report what is there, confidently. If your product costs are wrong, you now have a faster route to a wrong conclusion.

Replace configuration. Odoo has automated actions, scheduled jobs, email templates and approval rules built in. Many “we need AI for this” requests are settings.

The short version

Language models are very good at drafting and summarising, useful for exploring your data, and risky when they act without confirmation.

Draft and confirm. That boundary captures most of the value and almost none of the danger.

Check what Odoo does natively before connecting anything external — and if you do connect something, decide the data question deliberately rather than by default.