Governed AI in Your ERP

Every ERP vendor now has an AI story. The question worth asking is not what the assistant can do; it is what it cannot do, and who decided. Governed AI means the answer to that second question is an administrator in your building, and the answer is written down where you can read it.

In Nama, the assistant has no capability of its own. It cannot query the database. It cannot call an endpoint. Everything it does goes through a tool somebody defined on the AI Tool Definition screen — a query, a report, an entity flow, or a ready-made system tool — and every tool executes as a real user, with that user’s permissions, dimensions and validation rules applied.

The constraint is the feature

That sounds like a limitation, and it is. It is also the only version of this that survives contact with a real finance department.

The usual failure is a second permission system: the AI is given its own credentials, its own scope, its own list of what it may touch — and from the day it ships, that list drifts out of step with the real one. Somebody changes a security profile and nobody changes the AI’s copy. Nama does not have a second list. The assistant runs inside the one permission model the system already enforces, so a salesperson asking it about margins gets exactly what that salesperson could have opened themselves, and nothing more.

Per-tool control sits on top of that. Each tool definition carries an access-control grid, and a line can name a user, a security profile or a user group. At execution time the system takes the first line that matches — the user’s own line first, then their profile, then their group — and if a prevented user calls the tool, the call is rejected with a clear message rather than silently returning nothing.

What it does once you let it

With tools defined, the assistant sits in the top toolbar and inside screens:

• Answers from your data — how many invoices this month, the top five customers by balance — in Arabic or English.
• Runs your reports, inferring the parameters from the question, then reads the output back and summarises it.
• Acts on a document through an entity flow: approve it, post it.
• Reads a record, or imports new ones, where those tools are enabled.
• Reads the documentation, if you turn that tool on.

Open the chat while a report is on screen and the report’s output becomes context the assistant can analyse. Open it on a record and the record is what it discusses.

You can see the working

Expert Mode turns the conversation from a chat into a trace. Every message is classified — your message, the model’s reply, the system instructions, and the result of each tool call — so you can see which tool ran, with which parameters, and what came back.

This is the part that makes an assistant auditable rather than merely impressive. When an answer looks wrong, the question “is this the tool’s description, the query behind it, or this user’s permissions?” has an answer you can read, not a guess you have to make.

Your model, your keys, your policy

Eleven providers are supported — OpenAI, Anthropic, Google Gemini, AWS Bedrock, GCP, Azure, Mistral, DeepSeek, and any OpenAI-compatible or self-hosted endpoint — and the keys are yours. Models are chosen per conversation, so a fast one can handle routine questions and a stronger one the analysis.

Which model sees your data, and whether that model runs inside your own network, is therefore an administrative decision you make and can change. It is not a property of the product you have to accept.