The Executive Summary
Praxis AI is a chat-and-action assistant built into the Praxis ERP. It reads your data, drafts your documents, and runs your workflows β but only what the logged-in user is allowed to touch. Structured PII is stripped before anything leaves. No shadow copy of your database. Ever.
The Operational Vulnerability
Most "AI features" bolted onto business software fail one of three tests, and enterprises are learning it the expensive way.
**Test 1 β Where does the data actually go?** A junior clerk types "summarize this client's history" into a chat box. The vendor's AI pulls the client's full record, the last twelve invoices, the payment disputes, and the account number, and ships it to a model API somewhere in California, Beijing, or Frankfurt. Nobody in the building knows it happened. There is no audit trail. The DPA nobody read says the vendor "may retain inputs for 30 days for quality purposes."
**Test 2 β Who is the AI acting as?** A warehouse operator, whose HTTP permissions only let them scan barcodes, asks the assistant to "draft a supplier invoice for 4.2M XAF and mark it for payment." The AI, helpful as ever, does exactly that. The immutable ledger dutifully records the entry. The audit trail is perfect. It just records an action the operator had no right to perform.
**Test 3 β What actually leaves the perimeter?** Even with a signed contract, if the tool sends raw IBANs, credit card numbers, tax IDs, and phone numbers over the wire on every prompt, the contract is a promise, not a control. Promises fail. Controls don't.
Three tests, and most "AI-enabled" ERPs on the market today fail at least two.
The Engineered Solution
Praxis AI is engineered around one rule: **the assistant never exceeds the calling user, and sensitive text never leaves the building unredacted.** Here is what that looks like in the machine room.
**1. RBAC is enforced at the AI layer, not just the UI layer.** Every action the AI can take β reading a client, drafting a quotation, transitioning a dossier, posting a costing β is registered in a permissions catalogue with a required grant like `SLS-04:create`. Before the executor runs, the AI checks the user's grants through the exact same cache the HTTP middleware uses. If the grant is missing, the action is refused and logged. If the permission requirement itself is missing from the catalogue, the action still refuses β **fail closed**. A forgotten declaration produces a visibly broken button, not an invisibly open door.
**2. Tenant isolation is structural, not procedural.** Every read the AI performs runs through the caller's tenant-bound database connection. A user in Tenant A cannot be handed a row from Tenant B, because the connection literally cannot see Tenant B's schema. This is enforced by PostgreSQL, not by us remembering to check.
**3. Field-level confidentiality gates the knowledge base.** Documents and chunks in the vector store carry a confidentiality tag. Retrieval filters by what the calling user is cleared to see. A confidential HR memo cannot be pulled into the AI's context by a user without HR grants β not because the AI is asked politely to ignore it, but because the SQL query never returns it.
**4. Structured PII is redacted before egress.** Before any text leaves for the language model, a pattern-based sanitizer strips IBANs, credit card numbers, OHADA-zone RIB bank accounts, tax IDs (NIU, SSN), phone numbers, emails, and long digit runs. This runs on the user's message, the conversation history, the running summary, the retrieved knowledge, and every tool result. What the external model sees is `[IBAN]`, `[RIB]`, `[NIU]`, `[PHONE]` β not the customer's actual account.
**5. The AI has tools, not a data lake.** The assistant does not have a copy of your database. It has a catalogue of named actions β `get_client`, `list_open_dossiers`, `draft_invoice` β each with a permission requirement. To answer a question, it calls a tool, which runs a scoped query as the calling user, returns the answer, and forgets. There is no vector shadow of your books sitting in someone else's cloud.
**6. Every prompt and every action is audited.** Outbound prompts, tool calls, denials, and executions are logged. If a regulator asks "what did the assistant do for user X on Tuesday" β there is an answer.
**7. Sovereign deployment is a config change, not a rewrite.** For clients who cannot send anything to a foreign API β banks, government, health β the same architecture points at a locally hosted model running on the client's own hardware, or on a Lagos / Douala sovereign-cloud GPU. The Praxis code doesn't change. Only the endpoint URL does.
The Final ROI
- **Zero unauthorized AI actions.** The permission catalogue closed the audit finding where ten write actions were reachable through the assistant regardless of the user's module grants. That vector no longer exists.
- **Compliance-ready egress.** Structured PII redaction + no-training DPAs at the vendor layer + a documented audit log means the AI feature clears legal review instead of blocking it.
- **Deployable in regulated sectors.** Sovereign-model swap turns a "cloud AI risk" conversation into a "server in your data center" conversation. Same product, different endpoint.
- **Real productivity, not demo-ware.** Because the AI runs inside the permission and data model β not alongside it β users can actually trust it with real work: drafting quotations, opening dossiers, summarizing client history, chasing payments. Reported time-savings on document drafting alone: **60β80% per document** across pilot tenants.
**Bottom line:** Praxis AI is not a chatbot glued to an ERP. It is the ERP's permission model, audit trail, and data isolation β with a language interface. The assistant is exactly as powerful as the user asking, and never one row more.