10 Questions Your GRC Team Should Be Asking Your Existing Vendors Right Now

Your existing vendors could be shipping AI to you, whether your contract covers it or not

Your organization did not have to go looking for AI risk. It came to you, bundled into a product update, rolled out in a new feature release, or quietly embedded in a platform you have used for years. The HR software your team logs into every day. The ITSM platform your operations runs on. The document management system your legal team has trusted since before AI was a board-level conversation. Vendors across every category are shipping AI-enabled capabilities into existing products and existing contracts, often without explicit notification, and almost always without a corresponding update to the data-handling terms you agreed to when you signed.

This is not a question of whether your vendors are AI companies. Most of them are not, or were not, when you signed your contract. It is a question of whether the products you are already paying for have become AI-enabled without your governance program catching up. The answer for most organizations is yes. These ten questions are designed to help you close that gap, with the vendors you already have, under the contracts you already hold.

For each question, you will find a direct answer to why it matters, what to listen for in the response, and, where it helps, a reference table for evaluating what you hear. These are not questions reserved for new vendor onboarding. They are questions you may need to go back and ask the vendors you thought you already knew.

Question 1: What AI or machine learning capabilities are currently embedded in your product?

Your first task is to establish what has changed since you signed. Vendors across every software category – HR, ITSM, ERP, legal, finance, security – are embedding AI into existing products via feature releases, not new contracts. This question forces an explicit disclosure and creates the baseline inventory your updated assessment depends on.

Many vendors have been quietly shipping AI capabilities under softer language: 'smart suggestions,' 'intelligent automation,' 'enhanced search,' 'predictive analytics.' These are AI features. The vendor may not volunteer that framing, particularly if their original product was sold as a non-AI platform. A complete answer should name specific features, describe what they do, and distinguish between machine learning models, large language models, and rule-based automation. Each carries a different risk profile, and each may have materialized after your original contract was executed.

What a strong answer looks like: A named inventory of AI-powered features introduced since your contract was signed, the type of AI involved, whether those features are enabled by default, and whether any of them involve processing your organization's data.

What should give you pause: Vague responses ('we use AI to enhance the user experience'), inability to distinguish AI from traditional automation, or, most telling, surprise that you are asking. If a vendor seems caught off guard by this question, that is itself a governance signal.

Question 2: Is our data used to train, fine-tune, or improve your AI models?

This is one of the most consequential questions on this list, and one that almost no legacy contract addresses. If a vendor introduced AI after your agreement was signed, there is a high probability that your original data processing terms say nothing about model training. If your data is being used to train or improve their AI, you may have consented to that by default simply by continuing to use the product.

Data used in model training does not just disappear, it can surface in outputs, influence behavior across the entire customer base, or be partially reconstructed through adversarial techniques. And unlike a data breach, you may never know it happened. This risk is compounded when AI is added to an existing product mid-contract, because there is typically no amendment process, no re-consent mechanism, and no notification that the data relationship has changed.

Question 3: How long is inference data retained, and who can access it?

Every time a user interacts with an AI-powered feature, asking a question, running an analysis, generating a report, that interaction may be logged as inference data. Understanding how long that data is retained and who can access it is essential for data minimization compliance and breach impact assessment.

Inference logs can contain highly sensitive information depending on the use case: query content, document excerpts, decision inputs. In regulated industries, this data may be subject to retention limits under HIPAA, GDPR, CCPA, or sector-specific frameworks. If a vendor cannot articulate their inference data lifecycle, that is a data governance gap that belongs in your risk register.

Key follow-up questions:

• Are inference logs accessible to vendor employees, and under what conditions?
• Can inference data be subpoenaed or accessed by government authorities?
• Is retention configurable by the customer, or fixed by the vendor?
• Is inference data included in your organization's data deletion rights?

Question 4: What foundation models or third-party AI services power your product?

Most AI-powered vendor products are not built on proprietary models, they are built on top of foundation models from providers like OpenAI, Google, Anthropic, or Meta, or use third-party AI APIs. Your vendor's risk profile is therefore partially determined by the risk profile of their AI providers. You need to know who they are.

This is the nth-party AI risk problem. Your vendor may have excellent security practices, but if their AI provider has permissive data retention policies, weaker access controls, or a different regulatory posture, that risk flows to you through the dependency chain.

Question 5: How autonomously does your AI operate, and what decisions does it make without human review?

Autonomy is the multiplier on every other AI risk. An AI that surfaces recommendations for humans to act on carries very different risk than one that takes action automatically. Understanding where a vendor's AI sits on the autonomy spectrum tells you how much human oversight exists between the model's output and a consequential decision.

For GRC purposes, autonomous AI decisions create accountability gaps: if the AI acts incorrectly, who is responsible, and how do you document it? This matters for incident response, regulatory reporting, and audit trails. It is also increasingly relevant to emerging AI liability frameworks in the US and EU.

Vendors operating at the Delegated or Autonomous level should be classified at a higher risk tier regardless of other factors, and your contract should specify override capabilities, audit logging requirements, and liability in the event of an autonomous error.

Question 6: Have your AI models been tested for adversarial vulnerabilities, bias, or unexpected behavior?

AI models can be manipulated, biased, or coaxed into producing harmful outputs, not through traditional exploits, but through prompt injection, adversarial inputs, or distributional shift. Asking whether a vendor tests for these failure modes tells you how seriously they treat AI-specific security risk, as distinct from general application security.

This is an emerging but rapidly maturing area of vendor security assessment. NIST's AI Risk Management Framework and the EU AI Act both place significant emphasis on model testing and validation. A vendor who cannot speak to adversarial testing, red-teaming, or model evaluation practices is likely behind the curve on AI security maturity.

What to ask for:

• Evidence of red-team or adversarial testing against their AI models
• Results or summaries from bias evaluations or fairness audits
• Documentation of how unexpected model behaviors are identified and addressed
• Whether model testing is performed by an internal team or an independent third party

Question 7: How are AI model outputs logged, and how long are those logs retained?

Auditability is non-negotiable for any system that influences consequential decisions. If a vendor's AI produces an output that leads to an incident, a false positive that triggers an alert, a recommendation that turns out to be wrong, you need a log of what the model produced, when, and based on what inputs. Without that, root cause analysis is guesswork.

AI output logging is also increasingly a regulatory expectation. Financial services regulators, healthcare oversight bodies, and federal cybersecurity frameworks are all moving toward requirements that AI-influenced decisions be traceable. Getting ahead of this now protects you from having to retrofit auditability into vendor relationships later.

Minimum logging expectations for AI-enabled vendors:

• Timestamped record of model inputs and outputs for consequential decisions
• Retention period aligned with your regulatory requirements
• Customer access to logs on request
• Tamper-evident log storage
• Defined process for log review in the event of an incident

Question 8: Who in your organization is accountable for AI risk, and what does your AI governance structure look like?

A vendor's ability to answer this question clearly is itself a signal. Organizations that have genuinely invested in AI governance have a named owner, a defined structure, and documented policies. Those that have not will either name the wrong person, describe an informal process, or acknowledge that no formal structure exists yet.

You are not looking for a perfect AI governance program, many mature organizations are still building theirs. You are looking for intentionality: evidence that the vendor has thought carefully about AI accountability, assigned responsibility, and created a mechanism for surfacing and escalating AI risk internally.

Question 9: How will you notify us if your AI capabilities change materially?

This question matters most for vendors you already have. When a vendor ships AI into an existing product, they are not typically obligated under legacy contracts to tell you, unless you have negotiated that requirement. Without a formal notification clause in place, a vendor can add an AI feature, change their underlying model, or update their data handling practices with a product release note buried in their changelog. Your GRC program may not find out until the next annual review, or not at all.

For existing vendors, this is a contract conversation as much as an assessment question. If your current agreement predates the vendor's AI capabilities, push to add a notification amendment. The goal is a written commitment that triggers proactive disclosure whenever the vendor's AI risk profile changes materially, new features, new model providers, new data handling practices. Think of it as retrofitting an early warning system into a relationship that was built before the risk existed.

What to push for contractually:

• Written notification requirement for new AI features that affect data handling or processing
• Advance notice (30-90 days where possible) before changes to the underlying AI model or provider
• Notification if the vendor's AI provider relationship changes
• Right to re-assess following material AI changes without penalty

Question 10: What is your incident response process specifically for AI-related failures or unexpected model behavior?

Traditional incident response processes were not designed for AI failure modes. A model producing biased outputs, a prompt injection attack that manipulates system behavior, or inference data exposed in a breach all require response procedures that go beyond standard breach notification. Ask whether the vendor has developed those procedures, or whether they are applying general incident response processes to AI-specific problems.

AI incidents often do not look like traditional security incidents. There may be no obvious breach, no exfiltrated file, no malware signature. A model may begin producing incorrect outputs gradually, or a subtle manipulation may go undetected for weeks. Vendors who have thought through AI-specific incident response will have detection mechanisms, classification criteria, and escalation paths designed for these scenarios.

AI-specific incident response capabilities to ask about:

• Defined criteria for what constitutes an AI incident (distinct from a general security incident)
• Process for identifying and containing prompt injection or model manipulation events
• Customer notification obligations for AI-specific incidents, even when no traditional data breach has occurred
• Post-incident review process that includes model evaluation, not just infrastructure forensics

Putting the Questions to Work

These ten questions are most effective when they are built into your standard vendor assessment process rather than used as a one-time checklist. Consider incorporating them at three points in the vendor lifecycle:

• Existing vendor review: Start here, audit your current vendor roster for AI capabilities that postdate your original agreements. Prioritize Tier 1 and Tier 2 vendors first
• Contract amendment: For any existing vendor whose AI capabilities fall outside your original data processing terms, open a contract conversation. Questions 2, 3, and 9 are your leverage points
• New vendor onboarding: Embed all ten questions into your standard due diligence process so you are never in this position again with a net-new vendor

Not every vendor will have strong answers, particularly those who added AI to existing products quickly and without a formal governance process to match. That is useful information. Gaps belong in your risk register, your contract renegotiations, and your monitoring program.

The goal is not to disqualify vendors who are still maturing their AI governance; most of the software industry is still figuring this out. The goal is to stop operating under the assumption that a contract you signed two or three years ago governs the product you are actually using today. In most cases, it does not. These questions are how you find out where the gaps are, and how you start closing them.

About Fortress Information Security

Fortress Information Security specializes in supply chain cybersecurity and cyber risk management for critical infrastructure. Our Cyber GRC solutions are designed to give security leaders the tools and frameworks they need to govern vendor risk in complex, AI-driven environments.

This article is intended for informational purposes and reflects current industry practices as of the date of publication. Regulatory requirements vary by sector and jurisdiction.