You are evaluating an AI assistant for your enterprise. The vendor shows you a smooth demonstration: the agent answers questions about your supplier contracts, active commitments, and pending invoices in seconds. The sales rep explains they need a copy of your data in their infrastructure for performance reasons.
What the sales rep does not tell you: this parallel copy strips your entire permission model. An assistant that should only answer questions from a procurement manager can now return all data from your system, including contracts that manager is not authorized to view.
Two ways to connect AI to your data, and only one is safe
When you connect an AI assistant to your information system, two architectures are possible.
The first: the vendor extracts a copy of your data, loads it into a separate index (usually a vector database), and connects the agent to that copy. Each time a user asks a question, the agent searches the separate index and returns what it finds. This approach is simple to implement and enables fast responses, because the index is optimized for semantic search.
The second: the assistant queries your business platform through the APIs you already expose, using a user profile that carries permissions. When a user asks a question, the agent formulates a query to the platform presenting itself as that user, receives only the data that user can access, then builds its answer. This approach requires your platform to have a stable programmatic interface and for you to define an access profile for the assistant.
Only the second preserves your access rights. Only the second allows you to trace who accessed what. Only the second guarantees that the data in the response is current at the time of the question. Everything else is a convenience tradeoff presented as a technical constraint.
The parallel copy: why the separate index loses your permissions along the way
A vector index is a store of text fragments transformed into numerical coordinates. To fill this index, the vendor extracts your documents: contracts, invoices, reports, purchase requests, project tracking. The extraction can be complete (a mirror copy of your business database) or partial (a monthly export on a chosen scope).
The problem appears during indexing. Text fragments carry their content, but they no longer carry the access rights context that your platform attached to each document. A supplier contract in your ERP might be visible only to procurement managers, the CFO, and the CEO. In the vector index, that same contract becomes a text fragment among others, with no indication of who can view it.
Result: when a user who does not have rights to that content asks a question whose answer is in the indexed fragment, the assistant returns that answer. The leak is not an accident, it is structural. It is built into the architecture, because the index cannot evaluate rights at each query if it did not receive those rights during indexing.
Some vendors add filters to the index: they segment fragments by department, hierarchical level, or project. These filters reduce the leak surface, but they do not recreate your rights model. A user who changes roles remains associated with the filter of their old scope until you update the segmentation in the index. A user who obtains temporary access to a project never receives the fragments from that project in the assistant, unless you manually modify the filter.
The separate index also loses audit logging. Your business platform traces all access: who opened which document, when, from which workstation. The assistant connected to the index queries that index, not your platform, so no access trace flows back into your audit logs. In case of a review or dispute, you have no way to prove that a user never accessed sensitive data, because the assistant never told you whether that data was included in an answer.
The rule: AI is a user like any other, with its profile and scope
The safe architecture rests on a simple rule: the AI consumes your platform like a human user, with the same interfaces, the same rights, the same traces.
Concretely, this means the assistant queries the APIs of your ERP, your CRM, your document management system, exactly as a mobile app or internal dashboard would. Each assistant query is authenticated with the profile of the user asking the question. Your platform evaluates the rights attached to that profile, filters results accordingly, and returns only the data that user can see.
This approach eliminates the leak risk by architecture. If a user does not have permission to read a contract, the API will not return that contract to the assistant, so the assistant cannot build an answer from that contract. There is no parallel copy, so there is no fragment orphaned from its rights.
It also preserves audit logging. Each assistant call to the API generates a line in your platform's audit logs, with the user's profile, timestamp, and data accessed. These logs are the same as those that trace human user actions, so your existing audit procedures apply without modification.
It finally guarantees data freshness. The assistant reads data at the moment the user asks the question, not at the moment of an indexing run that happened the previous night or last week. If a supplier contract was modified ten minutes ago, the assistant's response integrates that modification.
The cost of this architecture is that your platform must expose a stable programmatic interface. If your ERP has no documented API, or if your document management system does not allow querying documents through a structured request, connecting the assistant in secure mode first requires building that interface. This is not a trivial technical cost, but it is an investment that serves all future integrations, not just the AI assistant.
What this implies on the platform side: a single interface, rights evaluated at each query, access logging
For AI to work as a user, your platform must meet three technical conditions.
First condition: a single interface. All systems that should be queryable by the assistant must expose a REST or GraphQL API with up-to-date documentation. This API must cover the same operations accessible via the human interface: view a document, read a supplier list, retrieve project history, extract pending invoices. If a user can see data in your ERP's web application, that data must be accessible via the API.
This assumes your business systems have a programmatic exposure layer. Recent SaaS platforms have this layer by default. Legacy ERPs (SAP, Oracle, Microsoft Dynamics) have APIs, but they often require specific configuration and additional modules. In-house developed applications sometimes have no API: you must then build one, or accept that they remain out of the assistant's reach.
Second condition: rights evaluated at each query. The API must receive an authentication token identifying the user for whom the assistant is asking the question, then filter results according to that user's rights. This filtering must be dynamic: if a user loses access to a project at 3pm, an assistant query formulated at 3:05pm for that user must no longer return project documents.
This rights model already exists in your business platform. It is not about creating a new one for the assistant, it is about verifying that the API applies the same model as the human interface. The classic trap: an API that bypasses rights for performance reasons. An API that returns all data then lets the client application filter according to the connected user's rights. These shortcuts break the secure architecture.
Third condition: access logging. Each assistant call must generate a trace in the platform's audit logs, with the user's profile, timestamp, resource accessed, and data scope returned. These logs must be accessible to your compliance teams with the same granularity as logs of human actions.
This logging is rarely a technical problem. Most business platforms already trace all API requests. The problem is more operational: who analyzes these logs, at what frequency, and with what tool. If your teams have never reviewed ERP audit logs, they will not review assistant logs either. Connecting an AI is a good opportunity to implement the monitoring processes you should have had all along.
Data freshness: what delay you accept, and for which uses
The connected architecture guarantees the assistant reads current data at the time of the question. This does not mean all questions require this guarantee.
Some uses tolerate a delay. An assistant that answers questions about internal company policies can work from a copy of documentation updated once a month. An assistant that helps users understand a product catalog can index that catalog nightly without operational risk. In these cases, a parallel copy simplifies integration without creating a rights leak, because the indexed data is public within the company.
Other uses tolerate no delay. An assistant that answers questions about project progress status must query the tracking system in real time, because outdated information can lead to incorrect decisions. An assistant that extracts invoices pending approval must read data at query time, because an invoice might have been approved ten minutes earlier.
The practical rule: if the assistant returns data that influences an operational decision, it must query the platform in real time. If the assistant returns reference or documentation data, a delay of a few hours or days is acceptable. If the assistant handles personal or sensitive data, freshness is secondary to respecting access rights: in that case, real-time connection is mandatory even if delay would be tolerable.
Three questions to ask the vendor before the demo
When a vendor presents an AI assistant solution, ask three questions before going further.
First question: where is our data stored while the assistant uses it? If the answer mentions a separate index, data lake, or vector database hosted by the vendor, ask how your platform's rights model is replicated in that index. If the answer is vague or the vendor talks about department-based filters, assume you are losing your permissions.
Second question: how does the assistant authenticate with our business systems? If the assistant uses a single service account with elevated rights to query all data, then filters responses based on the user asking the question, this architecture introduces risk. A bug in filtering, a flaw in the assistant's code, or an attack on the assistant's session exposes all data accessible by that service account.
The safe answer: the assistant formulates each query with the profile of the user asking the question, using a delegated authentication token or an impersonation mechanism managed by your platform. If the vendor has never heard of OAuth delegated access or service account impersonation, assume their architecture is not compatible with an enterprise system.
Third question: how do we trace the access performed by the assistant? If the answer is that the vendor will provide logs on their side, those logs will never be audited by your compliance teams, because they are not in the same tool as your business platform logs. The safe answer: all assistant access generates traces in your ERP, CRM, document management audit logs, exactly like human access.
What remains out of an assistant's reach, and why that is a good sign
A safely connected assistant can only answer questions whose data is accessible via your platform's APIs, within the permission scope of the user asking the question. This leaves many cases out of reach.
An assistant cannot answer a question about a document that has not been stored in the document management system. If a user keeps a supplier contract locally on their workstation, the assistant will never see it. This may seem like a limitation, but it is actually an incentive to centralize documents in traceable systems.
An assistant cannot answer a question that requires aggregating data from multiple business systems if those systems do not expose APIs. For example, crossing invoices from the ERP with projects from the CRM and purchase requests from the procurement management system. This limitation forces you to build the missing programmatic interfaces or accept that certain questions remain out of reach.
An assistant cannot bypass access rights to answer a question asked by a user who does not have the necessary permissions. If a team manager asks the assistant to show contracts signed by senior management, and that manager does not have access to those contracts in the ERP, the assistant will refuse to answer. This limitation protects your rights model, but it may frustrate users who expect an AI assistant to be omniscient.
These limitations are quality indicators. A vendor who presents an assistant capable of answering all questions, including about data you do not manage centrally, is selling you a parallel copy that bypasses your rights. A vendor who tells you from the start what the assistant cannot do is proposing an architecture that respects your security and compliance constraints.
FAQ
If we connect an AI assistant to our data via APIs, do response times remain acceptable for a user?
Response times depend on your API performance and the question's complexity. A question that queries a single resource (for example, "give me the list of pending invoices") can be resolved in one to two seconds if your ERP's API responds quickly. A question that requires aggregating data from multiple systems (for example, "how much did we spend on project X between January and March") can take five to ten seconds if the assistant must call multiple APIs then reconstruct a global result. These delays are longer than a vector index that returns an answer in under a second, but they remain acceptable for professional uses where reliability and traceability matter more than raw speed.
How do we handle the case of a user who needs temporary access to sensitive data?
The connected architecture solves this case naturally. You grant the user temporary access via your business platform, with an expiration date. While the access is active, the assistant can answer the user's questions including that data. As soon as the access expires, the assistant will stop including it in responses, because the API will filter that data at query time. No manual intervention on the assistant is needed, and no parallel copy retains data after access expires.
Can an assistant connected to APIs still function if one of the business systems fails?
No, and that is an accepted consequence of the architecture. If your ERP is unavailable, the assistant cannot answer questions that require ERP data. However, it can still answer questions that only involve the CRM or document management, because those systems are still online. This dependency is the same as for your business applications: if the ERP is down, human users cannot access ERP data either. An assistant that continues to function during a business system outage is necessarily reading an outdated copy, which can be worse than no response.
What is the integration cost of an API-connected assistant, compared to a separate-index assistant?
The initial cost is higher if your business systems do not have documented APIs or if your rights model is not exposed programmatically. You must then build those interfaces, which can represent several weeks of development. However, those interfaces also serve all future integrations: mobile applications, decision dashboards, inter-system synchronizations. The integration cost of a separate-index assistant is low at the start (a few days to extract data and fill the index), but it generates permanent technical debt: each modification to your rights model must be replicated in the index, each new business system must be extracted and segmented, and you have no unified traceability.
How do we know if our business platform already exposes the APIs needed to connect an assistant securely?
Consult the technical documentation of your ERP, CRM, and document management system. If those systems are recent SaaS solutions (Salesforce, HubSpot, Microsoft Dynamics 365, SAP S/4HANA Cloud), they almost certainly have a well-documented REST API. If you use on-premise versions or legacy systems, check with your IT teams whether an API layer has been built in-house. If no API exists, the AI assistant project also becomes a system modernization project, which can be an opportunity to resolve technical debt blocking other integrations.
Want to connect an AI assistant to your information system without losing control of your data? ClaroDigi helps you audit your system, identify missing APIs, and design a secure integration architecture. Explore API integration for AI, review our approach to system integration, or discover our AI transformation services.