Vendor AI Usage Transparency

A manufacturing company's enterprise resource planning vendor had deployed multiple AI capabilities across their platform over the previous two years. The vendor's AI capabilities were well-documented in their product materials , anomaly detection in production data streams, predictive maintenance recommendations, inventory optimisation, and demand forecasting. The manufacturing company's TPRM assessment had evaluated the vendor's AI product security, reviewing the training data practices, model documentation, and API security for each of the disclosed AI features. The assessment was thorough for the disclosed AI use cases. What the assessment had not surfaced was the vendor's internal AI programme , a set of models that the vendor used operationally to manage their customer relationships, not to power product features. These models included a customer health scoring model that analysed the enterprise's usage patterns, support ticket history, and contract renewal behaviour to predict churn probability; a lifetime value model that classified customers into tiers that influenced how support resources were allocated; and a product adoption model that identified which features each customer was likely to purchase and routed marketing and sales activity accordingly. The manufacturing company's operational data , their usage patterns, support interactions, and contract history , was being used as training data and inference input for the vendor's internal AI programme. The enterprise had never been informed of these use cases, had never consented to this use of their operational data, and had no visibility into how these models affected the service they received.

What is Vendor AI Usage Transparency, Really?

Vendor AI usage transparency is the disclosure and accountability framework for all ways a vendor uses AI that affects the enterprise customer , including both the AI-powered product features that are marketed to the customer and the internal AI systems that use the customer's data for vendor-operational purposes such as customer scoring, lifetime value classification, churn prediction, support routing, and sales intelligence. Full AI transparency requires disclosure of both dimensions: what AI does for the customer and what AI does about the customer.

The internal AI programme opacity problem is the core transparency gap. Vendors increasingly use AI internally to manage their customer relationships and optimise their operations , entirely legitimate commercial activities. The opacity problem arises when the customer's operational data , their usage patterns, support interactions, communication history, and contractual behaviour , is used as training data or inference input for these internal models without the customer's knowledge or consent. The customer has typically consented to the vendor processing their data for the purpose of providing the service. They have not typically consented to their data being used to build models that classify them as customers and influence the service they receive.

The differential service risk is the specific consequence. AI-driven customer classification systems that allocate support resources, prioritise feature requests, and route customer success activity based on predicted lifetime value or churn probability create differential service quality , customers classified as high value receive different treatment than customers classified as low value. The enterprise customer who does not know about this classification system cannot assess whether they are being treated equitably or whether the classification is accurate. A manufacturing company classified as low lifetime value because its usage patterns suggest they may not renew may receive slower support response, lower priority for feature requests, and reduced customer success engagement , with no transparency about why.

The GDPR and regulatory dimension applies where personal data is involved. If the operational data that vendors use for internal AI includes personal data , employee email addresses in support tickets, names in usage logs, personal identifiers in audit trails , the use of that data for internal AI modelling requires a legal basis under GDPR. Processing personal data for the purpose of providing a service does not automatically authorise processing that personal data to build customer classification models. Vendors who have not assessed the legal basis for their internal AI's use of customer operational data may be creating regulatory exposure for both themselves and the enterprise.

Why this matters

Vendor AI usage transparency matters for TPRM because the enterprise's data , its usage patterns, support history, and operational behaviour , may be used by vendor AI systems in ways that affect the service the enterprise receives, the pricing it is offered, and the strategic decisions the vendor makes about the relationship. The enterprise that does not know about these uses cannot assess their fairness, accuracy, or impact on the commercial relationship.

Where most teams get this wrong

The most consistent failure is limiting AI transparency assessment to product features , the AI that the vendor markets and discloses. Internal AI systems that use enterprise data for vendor-operational purposes are not typically disclosed in product documentation and are not typically covered by standard AI vendor assessments.

• AI assessment limited to disclosed product features
• Internal AI programme using enterprise data not disclosed or assessed
• Differential service risk from customer classification not assessed
• Legal basis for internal AI use of customer data not assessed
• Data processing agreement not covering internal AI use of operational data

What good looks like

Mature AI transparency assessments ask vendors to disclose all AI systems that process enterprise data , not just the product features , and require contractual commitments about the permissible uses of enterprise operational data for internal AI model training and inference.

• Ask for disclosure of all AI systems that process enterprise operational data
• Require internal AI use restrictions in data processing agreement
• Ask about customer classification systems and their effect on service delivery
• Assess legal basis for internal AI use of operational data
• Require notification of new internal AI uses of enterprise data

Tooling

AI Transparency , EU AI Act compliance frameworks, NIST AI RMF

The EU AI Act introduces transparency requirements for AI systems used in commercial relationships that may affect individuals and enterprises. For TPRM practitioners in scope for EU AI Act compliance, understanding which vendor internal AI systems qualify as AI systems under the Act , and whether they meet the Act's transparency requirements , provides a regulatory framework for AI disclosure requirements.

Governance challenges

The governance challenge with vendor AI transparency is the commercial sensitivity of internal AI programme disclosure. Vendors may resist disclosing their internal customer scoring and classification models as commercially sensitive. The governance resolution is requiring disclosure of the data uses rather than the model details , the enterprise has a right to know that their operational data is being used for internal AI, even if the model architecture is commercially sensitive.

• Require disclosure of all uses of enterprise data for AI training and inference
• Include internal AI use restrictions in DPA
• Ask specifically about customer scoring, classification, and routing systems
• Require notification of new internal AI uses
• Assess legal basis for personal data in operational data used for internal AI

If you are a small team

Add one question to every AI vendor assessment: beyond the AI features in your product, do you use any AI systems internally that process our operational data , including our usage patterns, support tickets, contract history, or communication records , for purposes such as customer scoring, lifetime value modelling, churn prediction, or support routing? And is our consent required for those uses? That question surfaces the internal AI programme that product feature assessments miss.

• Ask about internal AI systems that process enterprise operational data
• Ask specifically about customer scoring, classification, and routing
• Ask whether enterprise consent is required for internal AI uses
• Include internal AI use restrictions in DPA

What to require

Ask directly:

"Beyond your product's AI features , do you use any AI systems internally that process our operational data, including usage patterns, support history, or contract behaviour, for purposes such as customer scoring, churn prediction, or support routing? And are those uses covered by our data processing agreement?"

Expect as evidence

• Internal AI system disclosure for enterprise data uses
• Data processing agreement coverage of internal AI uses
• Customer classification and routing disclosure
• Legal basis for internal AI use of operational data

A vendor who confirms AI product transparency should be asked about internal AI transparency. Product AI is what the vendor discloses. Internal AI is what the vendor uses. Both use enterprise data. Only one is typically assessed.

How to evidence it

• Internal AI disclosure assessment records
• DPA coverage of internal AI uses
• Legal basis assessment for operational data in internal AI
• Customer classification disclosure records

Key Takeaway

Product AI features: disclosed, assessed, secured. Internal AI , customer health scoring, lifetime value classification, support routing: undisclosed, unassessed, using the enterprise's operational data. The enterprise knew what the AI did for them. They did not know what the AI did about them. AI transparency is the full picture: what the vendor's AI does for the customer and what it does about the customer. Both use enterprise data. Both affect the commercial relationship. Both require disclosure. The DPA that covers the product features must also cover the internal AI programme. The assessment that evaluates the product AI must also ask about the operational AI.

More on AI governance

• AI API Key Exposure
• AI Adversarial Attacks
• AI Attack Surface Expansion