COMMENTARY: Security and procurement leaders at large enterprises face pressure from all sides: adopt AI fast. This unstoppable force now meets an immovable object: procurement rigor used for any enterprise vendor. Lengthy questionnaires. Legal reviews. Risk assessments. Months of back and forth.
This approach made sense for established SaaS companies. But it’s breaking down with AI. The SaaS approach may even miss what actually matters:
prompt injection, model manipulation,
training data poisoning, output drift. The risk is a process that's slow and incomplete.
[
SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]
Frameworks like
NIST AI RMF and laws like the
EU AI Act provide useful reference points for AI governance. But they focus on obligations for AI developers and deployers, not on how enterprise buyers should evaluate vendors. Most AI startups do not operate at the scale where formal compliance applies. Few have the resources to produce the documentation these frameworks assume.
The answer is not to lower the bar. It's to ask different questions.
Related reading:
Traditional security reviews rely on assessments and attestations as a proxy for risk mitigation. AI requires different assurances: ongoing testing, decision logging, and evidence of mitigation, among others.
Security professionals know their organizations, risk tolerances, and regulatory obligations better than any outside framework can capture. Below is a starting point for internal conversations about how procurement and security teams might adapt their approach to AI.
Five categories that matter for responsible AI
Traditional vendor questionnaires were not designed for AI systems. Rather than expanding them, consider focusing on categories that address AI-specific risks.
The categories below are not exhaustive. They represent gaps we believe translate between enterprise needs, existing frameworks, and startups building and deploying AI applications.
Security and reliabilityPrompt injection, training data poisoning, and
model manipulation present attack surfaces traditional software does not. Consider asking how vendors defend against these threats and what happens when models fail or drift. Red teaming should be ongoing, not a one-time certification.
AccountabilityAI outputs are
harder to audit than database queries. Consider asking how vendors log decisions, trace outputs to inputs, and support investigations when something goes wrong. The depth of inquiry will depend on your use case and regulatory environment.
GovernanceRegulation is being developed; vendors who build governance early will adapt faster than those who bolt it on later.
California's AB 2013, effective January 2026, requires disclosure of training data sources. The result is a new reference point for procurement teams evaluating foundation models themselves, or applications built on top of those models.
Privacy and dataAI raises questions about how customer data trains models, who accesses it, and how long it persists. Are prompts logged? Used to retrain the model? Accessible to vendor employees? For sensitive information, these questions matter as much as traditional data protection.
Output quality and downstream impactsAI carries risks traditional software does not: output bias, hallucinations, and training data memorization. None appear in SOC 2 certifications. Ask how vendors test for and mitigate these risks. If your use case touches customer outcomes in regulated domains, these questions become litigation exposure.
Translating these categories into a consistent, repeatable evaluation process is hard. At
Responsible Innovation Labs, we are developing a standardized evaluation agreement to address these challenges.
Who sits at the table
The questions matter. So does who asks them and when. Traditional procurement often brings security in late, after business teams have already selected their ideal vendor. AI changes the calculus. Technical evaluation, security review, and business assessment need to happen together.
What makes speed possible
Pilots need clear boundaries: limit data access; use sandboxed environments; require human review of outputs before they inform decisions; prohibit automated decision-making until you have validated performance. Build an exit plan before starting.
For organizations in highly regulated industries (e.g., banking, healthcare, insurance), these baseline controls may not be sufficient. Additional oversight and regulatory coordination will likely be necessary. High stakes pilots may also warrant tabletop exercises and incident response planning that includes escalation paths across security, legal, and communications.
The bottom line
Diligence that takes a year does not necessarily eliminate risk. It may shift risk from vendor failure to competitive disadvantage and lost learning.
Large technology companies will offer integrated AI solutions. Some will deliver. But the best tool for a specific use case may come from a startup that cannot survive an 18-month procurement cycle.
The goal is not to shortcut diligence. It is to concentrate diligence on what matters for AI, run bounded tests, and make better informed decisions faster.
This framework is meant to bridge responsible AI concepts and everyday procurement problems, not to replace the judgment of professionals who understand their organizations' needs. Speed alone is insufficient. Clarity is. Build it now so you can move with intention when the right opportunity arrives.
