AI vendors:
what to assess before you sign

AI vendors receive data with every call and change versions without notice

An ordinary SaaS stores the data the company puts into it. AI vendors receive new data with every call, in the context assembled for that question. Four characteristics change the assessment:

• the vendor may retain the content sent for monitoring, debugging or model improvement, depending on the terms of the plan purchased;
• the service usually depends on subprocessors and third-party models, and the data travels along a longer chain than the company under contract;
• the model version changes at the vendor's discretion, and the behaviour of an approved flow changes with it;
• the service asks for access to the company's systems, and the credential granted defines the reach of what it reads and writes.

The topic belongs to supply chain risk management. NIST covers it in its guide to cybersecurity supply chain risk management, updated in 2024, which describes the loss of visibility into how acquired technology is developed, integrated and operated. With AI, that loss extends to the data that flows in every question.

Assessing AI vendors covers six blocks

A useful questionnaire organises the questions by topic, and each area knows which part is its own:

• Data: how long the content sent is retained, whether it is used to train or fine-tune models, in which country it is processed, which subprocessors receive it and how deletion is proven at the end of the contract.
• Security: certifications and their scope, isolation between customers, control of encryption keys, testing and incident notification.
• Privacy and the LGPD: the role of processor in handling personal data, international transfer and its mechanism, and contractual obligations on security, confidentiality and support for data subject requests.
• Model: which model is in use and who owns it, how version changes are communicated, how quality is evaluated and which limits are declared.
• Integration and permissions: which credentials the service asks for, whether it respects each person's permissions in the source systems or reads everything with a service account, and whether each access is logged.
• Exit and portability: how to export configurations, prompts, history and the context that has been built, and how much of the integration has to be redone if the contract ends.

The integration block usually gets less attention than the data block and accounts for a large share of the exposure. An assistant connected to the CRM with an administrative account answers any user with everything that account can reach. The permissions the company has configured over years in the source system are left out of the answer.

Three warning signs show up as early as the commercial proposal

• Vague terms about training: expressions such as use to improve the services, without saying whether that includes training models on the customer's content and without a contractual opt-out.
• Credentials with full access: a request for an administrative account or unrestricted read access to the CRM, ERP or drive when the use case needs a slice.
• No access log: the vendor cannot show which data was read in each call, on whose behalf and with what result.

Any one of the three justifies a round of negotiation before signing.

Exposure adds up with each AI vendor connected to the sources

Each new service arrives with its own integration to the CRM, the helpdesk and the drive and with its own credential. Over time, the company ends up with several parallel chains of data leaving its systems, each with different terms and permissions.

The due diligence done at contracting describes that moment. Switching vendors means redoing connections, filters and access rules, and that exit cost weakens the company in renegotiation.

The Company Brain reduces what each vendor receives

In the Company Brain, the connection to CRM, ERP, helpdesk and documents is made once, in the customer's environment, and organised into a knowledge graph, a business ontology and a semantic layer. The AI vendors' models and tools receive context through this layer, without their own credential in each source system.

For each question, the minimum slice the answer requires is served over MCP, already filtered by the inherited permissions of the person who asked. When the model runs as an external service, what leaves the perimeter in that call is that slice, subject to the negotiated terms. When it runs on the company's infrastructure, the slice stays inside too.

Because the integration belongs to the company, switching models or vendors does not require redoing connections, definitions and permissions. Each query is logged with source and identity, which answers the third warning sign without depending on the log kept by the vendor.

Contracts and due diligence are still needed with any architecture

The slice sent to the model still contains customer information, and the terms on retention, use for training and location still apply to it. The security assessment, the contract with LGPD clauses and the periodic review of AI vendors remain work for procurement, legal and security, with less data at stake.

Reviewing AI vendors starts with the ones that receive customer data

The practical starting point is a short questionnaire, with one or two questions per block, applied to the AI vendors the company already uses. The order follows the sensitivity of the data: first the services that receive customer data or personal data, then the ones that read internal documents.

The answers show where there are broad credentials, retention with no time limit or vague terms about training. Those cases go first to renegotiation or to migration to a path in which context comes from the layer the company controls, with inherited permissions and a log of every query.