Integrate AI with TOTVS Protheus or SAP: Safe Paths and Risks

Integrate AI with TOTVS Protheus or SAP: Safe Paths and Risks

To integrate AI with TOTVS Protheus, the safest path is to start with read access: the AI queries ERP data through a REST API or a controlled intermediate layer, without changing anything. Only after you have measured the quality of its answers does it make sense to consider write access, and then only through the ERP's official routines, with human approval. The reasoning is the same for SAP. What changes is the available interfaces and the level of governance required.

Key takeaways

• The AI should reach the ERP through a controlled interface (REST API or middleware), not through broad credentials or free-form database queries.
• Read first: looking up an order, stock level, receivable or master record already solves many workflows and carries almost no integrity risk.
• Writing directly to Protheus or SAP tables bypasses the system's business rules, tax validations and audit trails.
• When writing is necessary, it enters as a proposal or draft, goes through human approval and uses the ERP's official routine.
• Every pilot needs a log of each query, minimum permissions, personal data handled in line with Brazil's LGPD, and a success metric agreed in advance.

What are the ways to access Protheus or SAP?

There are four common paths. Each has a different risk profile, and the choice depends on the ERP version, the installed modules, licensing and the team that maintains the environment. Always confirm what is available in the official TOTVS or SAP documentation for your version, because what exists in one installation may not exist in another.

• REST API or services exposed by the ERP itself: in Protheus, you can publish REST services (including ones customized by your development team). In SAP, interfaces vary by version and may include OData, BAPIs and IDocs. This is the preferred path because it goes through the system's own rules.
• Direct database access: a read-only connection, preferably on a replica or on views built for this purpose. It works for reports and lookups, but it exposes the internal structure and demands great care with permissions.
• Middleware or integration layer: your own service between the AI and the ERP, translating AI requests into controlled calls. It can be an integration platform the company already uses or a lean service built for the purpose.
• Files and scheduled exports: spreadsheets, CSV files or reports generated by the ERP and read by the AI. It is simple and safe to start with, with the limit that data goes stale between one export and the next.

In practice, the healthiest combination is usually the ERP's API behind a small middleware, which is the only component the AI can see. The same design appears in integrations with smaller systems, as we describe in integrating AI with Bling, Omie and Tiny, except that in a mid-size or large ERP the rules are denser and a mistake costs more.

Why start with read access?

Reading is where AI already delivers value at low risk. Answering what the status of an order is, when a receivable falls due, whether an item is available or what a customer's payment terms are: these are lookup tasks. If the AI gets it wrong, the worst outcome is an incorrect answer that a person can correct, not a wrong entry in finance or tax records.

Starting with reading also teaches you things you need to know before any writing:

• Whether your ERP data is good enough. Duplicate records, free-text fields filled in different ways and ambiguous statuses show up quickly when an AI tries to use them.
• Which questions people actually ask. Query volume shows which endpoints are worth building.
• How much load the ERP can take. Too many queries can weigh on critical hours, and it is better to find that out with controlled reads.
• Where personal data lives. Customer records, tax IDs, addresses and purchase history fall under the LGPD, and a read pilot shows what truly needs to reach the model.

A good rule of thumb: if the task could be done by someone with a view-only profile in the ERP, it is a candidate for a first pilot.

Why is writing directly to the ERP risky?

The biggest mistake is treating the ERP like a spreadsheet the AI can edit. An ERP such as Protheus or SAP concentrates rules that are not visible in a table: tax validations, links between modules, triggers, stock control, reservations, approval levels and traceability. Writing straight to the database skips all of that.

The most common risks:

• Integrity: a record inserted without going through the official routine may lack the links other modules expect, and the problem only appears at period close or when issuing an invoice.
• Audit: changes made outside the system's routines may not leave the trail that accounting and auditors require.
• Support and warranty: vendors usually discourage writing directly to tables, and doing so can complicate support and version upgrades. Check your contract and your vendor's policy.
• Model error: language models can misread an instruction, and excessive autonomy (what OWASP calls excessive agency) is a risk listed in the OWASP Top 10 for LLM applications. Giving an agent unlimited write power multiplies the effect of any mistake.
• Repetition: if a call fails and is retried, the same order can be created twice. This is the problem idempotency keys solve, as the Stripe documentation on idempotent requests shows, mentioned here only as an example of the concept.

Writing through the official API reduces these risks but does not eliminate them. That is why writing deserves its own design, described further below.

How to design the intermediate layer for the AI

The middleware is what turns a complex ERP into a small set of safe actions. Instead of giving the AI generic access, you expose named, limited operations such as get_order, list_open_receivables or check_stock. Each operation receives validated parameters and returns only the fields that are needed.

Principles that tend to work:

• Minimum permissions: a dedicated credential for the integration, read-only at the start. The OWASP authorization cheat sheet helps you think about least privilege and deny by default.
• Per-user scope: if a branch clerk only sees that branch's customers in the ERP, the AI acting on their behalf should inherit that restriction rather than use a credential that sees everything.
• Minimum fields: do not send the model the whole record. If the answer only needs status and delivery estimate, that is all that leaves the middleware.
• Log everything: who asked, what was queried, what came back and what the model answered. Without this there is no way to investigate an error or prove what happened.
• Rate limits: protect the ERP from bursts of queries, including those generated by agent loops.

If the plan is to use the MCP protocol to expose these operations to an agent, read the official introduction to the Model Context Protocol and our article on building an MCP server for internal systems, read-only first. MCP is one way to standardize the bridge, but the permission and logging rules remain the responsibility of whoever builds it.

Step by step for a first read-only pilot

A simple outline that fits a small, real workflow:

• Step 1, choose one workflow: a repeated question whose answer already exists in the ERP. Example: the status of an order, or a copy of billing information.
• Step 2, measure the starting point: how long the team takes today, how often the question comes up and where errors occur. Without a baseline, you cannot tell whether things improved.
• Step 3, list the data needed: which fields, from which tables or services, and which of them are personal data.
• Step 4, choose the access path: the ERP's API or a read-only database view, always behind the middleware.
• Step 5, define permissions and limits: a dedicated credential, per-user scope, a maximum query rate and a list of what the AI never answers.
• Step 6, build the operations: few, named, and with lean responses.
• Step 7, test with anonymized real cases: compare the AI's answer with what the ERP shows and record the discrepancies.
• Step 8, run in parallel: the AI suggests or answers, and a person checks it for an agreed period.
• Step 9, decide: expand, adjust or stop, based on the metric defined at the start. Our article on how to measure an AI automation pilot details metrics and decision gates.

Illustrative scenario: order status for the sales team

Imagine, as an illustrative scenario, a distributor that runs Protheus and whose salespeople constantly ask finance and logistics whether a given order has been invoiced, when it ships and whether there is a credit block. The company builds a middleware with two read operations: order status and customer credit status. The AI agent, reached through an internal messaging channel, receives the salesperson's question, identifies the order number and calls the operation.

The middleware checks whether that salesperson is entitled to see that customer, returns only the status, expected date and reason for the block (no bank details or documents), and logs the query. If the order is not found or there is any doubt, the agent refers the person to the responsible department instead of guessing. Nothing is written to the ERP. After a period of comparing against human answers, the company decides whether to extend it to other questions.

When and how to allow writing safely

There are workflows where writing makes sense: creating a quote, logging an incident, opening a draft purchase order. The rule is that the AI never writes directly to the final record. A prudent design:

• The AI produces a structured proposal (for example, a draft order) in a queue or staging area.
• A person reviews and approves, seeing exactly what will be recorded.
• The write happens through an official ERP routine (the system's own API or service), never through direct SQL.
• Each operation uses an idempotency key or a duplicate check.
• There are limits on value, quantity and type of operation, and a switch to disable writing without taking down reading.
• Everything is logged, with the associated human decision.

If the workflow affects people, such as credit or eligibility decisions, also consider the right to review provided by the LGPD, which we explain in automated decision-making under the LGPD. And to validate the agent's inputs, outputs and actions before they reach the ERP, see guardrails for AI agents.

Does SAP change anything?

The logic does not change: controlled access, read first, writes through official routines and human approval. What changes is the ecosystem. In SAP environments, integration usually goes through a corporate integration layer and IT teams with more formal change processes, which lengthens the timeline but also helps ensure governance. Ask your basis and integration teams which interfaces are cleared for external use in your version and which require additional licensing. With either ERP, involving the people who maintain the system from the start avoids rework and surprises.

How we apply the method: map, limit, pilot, hand over

In ERP integration work, the method follows four stages. Map: understand the current process, who asks what and what the baseline is. Limit: define which data and which actions the AI may use, starting with reading. Pilot: run one real workflow, with logs and an agreed success metric. Hand over: deliver the documented operation to your team and decide, with evidence, whether to expand, adjust or end it. When a company prefers not to run it alone, maintenance and monitoring can be handled as a managed service by Be Human.

Frequently asked questions

Can I connect the AI directly to the Protheus database? Technically yes, but it is not the recommended path. If it is unavoidable, use a replica or read-only views, a dedicated credential and a middleware in between, and never allow writing. Prefer the API whenever it covers the need.

Do I need an MCP server to integrate AI with the ERP? Not necessarily. MCP is a way to standardize how the agent accesses tools, but a middleware with well-defined endpoints also works. What matters is that access is limited, logged and validated, whatever the protocol.

Can the AI post orders or invoices in the ERP on its own? We do not recommend it at the start, and in tax and financial workflows human approval tends to remain necessary. The safest design is for the AI to generate a draft, a person to approve it and the write to happen through an official routine, with duplicate protection and a complete record.

Can ERP data be sent to a cloud AI model? It depends on the data and the contract. Send the minimum necessary, avoid sensitive personal data when it is not essential, and assess the legal basis and whether an impact assessment is needed, as the case may be. Involve your legal team and data protection officer before the pilot, and consult the ANPD guidance.

Sources

• Model Context Protocol: introdução
• OWASP: guia de autorização
• OWASP Top 10 para aplicações com LLM
• Stripe: requisições idempotentes (exemplo do conceito)