Introduction
Most enterprise AI deployments have a security gap. It is not in the model. It is not in the vendor's infrastructure. It is in the questions no one asked before the system went live.
The organizations that discover this the hard way typically share a common pattern: the business case was solid, the productivity gains were real, and the procurement process touched the obvious bases. What did not happen was a structured conversation about what the AI system actually does with data, how access is governed, what regulatory obligations attach to its outputs, and what the security team would do if something went wrong.
Getting that conversation right does not require a new framework from scratch. It requires knowing which questions cut through the noise and which answers are genuinely sufficient versus which ones just sound like they are.
What follows are seven questions that enterprise security, compliance, and governance teams should ask before any significant AI deployment—and what strong answers actually look like
The Real Business Problem
Confidence in AI security is outpacing actual security controls—and the gap is measurable.
A CSC survey of 300 senior security executives in early 2026 found that 98% are concerned about giving third-party AI systems access to company data. In the same survey, 73% still say AI presents more opportunity than risk for their organization. Both things are true simultaneously, which is exactly why structuring the security evaluation matters so much.
The Team8 2025 CISO Village Survey found that AI risk has become the top security priority, outpacing vulnerability management, data loss prevention, and third-party risk. That represents a significant reordering of where security leadership is focusing attention.
But attention is not the same as controls. A 2026 EY/AIUC-1 Consortium survey found that only 38% of organizations monitor AI traffic end-to-end across prompts, tool calls, and outputs. Only 17% continuously monitor agent-to-agent interactions. And according to IBM's 2025 Cost of a Data Breach Report, 97% of organizations that suffered a breach of an AI model or application lacked proper AI access controls.
The seven questions below are designed to help close that gap between awareness and actual protection.
Why It Matters Today
The regulatory clock has started. Governance gaps that were tolerable last year carry legal weight now.
The EU AI Act reached full application for high-risk systems in August 2026, covering AI in manufacturing, finance, and healthcare. Penalties can reach 7% of global annual turnover—higher than GDPR's ceiling. Separately, Italy fined OpenAI €15 million for GDPR violations in training data processing, establishing that regulators are willing to act, not just publish guidance.
For organizations operating across multiple jurisdictions, the legal environment for AI data has become materially more complex. At least 34 countries have enacted or strengthened data localization requirements that affect where AI processing can occur. And across the enterprise software ecosystem, vendors are updating data processing policies in ways that affect what happens to organizational data by default—sometimes quietly, sometimes with short notice windows.
The organizations that are best positioned here are not necessarily the ones with the biggest security teams. They are the ones that asked the right questions before signing agreements and deploying systems, which means they built the audit evidence they will need rather than trying to reconstruct it afterward.
Enterprise Risks: What You Are Actually Assessing
Before walking through the seven questions, it is worth being clear about the risk categories they cover.
Data exposure risk is the most immediately understood: the possibility that confidential, regulated, or proprietary data moves into systems, training pipelines, or external APIs in ways that violate policy or law.
Access risk is less visible but equally serious: AI systems and agents that operate with more permissions than they need, creating a blast radius that extends well beyond the intended use case.
Vendor risk sits at the intersection of data exposure and access risk: the question of what commitments AI vendors actually make in writing, versus what their marketing materials imply.
Governance risk is the operational reality that most enterprises are deploying AI faster than they are building the policy, monitoring, and accountability structures to govern it.
Regulatory risk runs through all of the above: the possibility that an AI deployment generates compliance violations as a matter of normal operation, not as the result of a breach.
The seven questions that follow map to these categories. Not all of them are equally urgent for every organization—but every enterprise deploying AI at scale should have documented answers to all of them.
The 7 Questions
Question 1: Do We Know Every AI System Currently Operating Inside Our Environment?
This is the inventory question, and it consistently reveals more than security teams expect.
The problem is not the AI systems that went through formal procurement and security review. Those have been evaluated, approved, and at least partially governed. The problem is everything else: the agents deployed by individual engineering and product teams, the AI features embedded in SaaS platforms already in the stack, the browser extensions employees are using to summarize documents and drafts, the automation workflows built on low-code platforms that connect to internal systems without a security review ever being triggered.
According to Netskope's 2026 Cloud and Threat Report, the average enterprise experiences 223 AI-related data policy violations per month. Source code accounts for 42% of those incidents and regulated data for another 32%. These are not incidents driven by the tools that security approved. They are driven by the tools security does not know exist.
A useful framing for the audit: if the answer to "is this AI system sanctioned?" is "I'm not sure," that is not a sanctioned system. The inventory needs to be complete and continuously maintained, because the environment changes faster than periodic reviews can track.
What a strong answer looks like: A maintained register of every AI system in production, development, and active employee use—including vendor-embedded AI features—with documented data access scope for each.
Question 2: What Data Is Our AI Actually Touching, and Should It Have Access to That Data?
Most organizations have a reasonable grasp of what data they intended to make available to their AI systems. Fewer have a clear picture of what data those systems actually access in practice.
The distinction matters for two reasons. First, AI systems—particularly those with broad retrieval permissions—will access whatever they can reach, not only what they were designed to use. A customer support agent granted access to the full knowledge base will pull from all of it, including sections containing internal pricing logic, unreleased product information, or personnel data that was never meant to appear in customer-facing outputs.
Second, regulatory obligations attach to data types, not to AI use cases. An AI system that incidentally processes personal data in the course of a legitimate business function still triggers GDPR data minimization, purpose limitation, and audit obligations—regardless of whether that data access was intentional. The European Data Protection Board has clarified that user prompts, even routine ones, often contain personal data that activates full GDPR protections.
Data classification needs to precede AI access configuration, not follow it. The question to ask of every AI system is not only "what data can this access?" but "what is the sensitivity classification of everything it can reach, and is that access consistent with the purpose for which the system was deployed?"
What a strong answer looks like: Data classification mapping completed for all AI-accessible repositories, with documented justification for each data category the system is permitted to access.
Question 3: What Does Our AI Vendor Actually Guarantee in Writing—and What Are They Careful Not to Say?
This is the question that legal and procurement teams most commonly underinvest in, and it has become significantly more consequential as AI vendor data policies have grown more complex.
The core issue is the gap between what a vendor's marketing materials imply and what their contracts actually commit to. A vendor privacy page stating that customer data is "not used for training" may refer only to one product tier, or apply only after a specific contract term is executed, or contain exclusions for "de-identified" or "aggregated" data that are broader than they sound.
A practical example: in mid-2026, Atlassian announced that starting August 17, 2026, it would begin using data from Jira, Confluence, and related products to train its AI offerings. Enterprise customers had existing opt-out controls available, but organizations relying only on general privacy assurances rather than explicit contract terms had to act quickly to avoid being included by default.
This pattern is not unique to any single vendor. According to a review of roughly 25 to 35 enterprise AI vendor contracts, approximately one in four enterprise buyers had no signed Data Processing Addendum despite processing personal data through the API. And in the majority of cases, organizations were paying for contractual assurances that the vendor's published policies already provided for free—because no one had read the policy carefully.
The procurement questions that matter: Does our vendor contract explicitly commit that our data will not be used for model training? What are the data retention windows, and can we negotiate zero data retention for our use case? Is a Data Processing Addendum signed and current? Do we have audit rights, or only SLA percentage commitments?
What a strong answer looks like: A signed DPA and contract terms that explicitly address training data use, retention windows, sub-processor disclosure, and audit rights—not implied by policy pages, but committed in writing.
Question 4: Have We Tested Our AI for Prompt Injection and Adversarial Manipulation?
Most enterprise security testing programs were not designed for AI-specific vulnerabilities. Traditional penetration testing covers what it was built to cover: network perimeter, application authentication, known CVE exploitation. It was not built to test whether a malicious instruction embedded in a retrieved document can alter an AI agent's behavior mid-workflow.
Prompt injection has ranked as the top vulnerability on OWASP's LLM Top 10. NIST reported a greater than 2,000% increase in AI-specific CVEs since 2022. Critical vulnerabilities in production enterprise AI tools—including documented cases in Microsoft Copilot and GitHub Copilot—have received CVSS scores above 9.0, placing them in the same severity tier as the most serious conventional security vulnerabilities.
The threat model for an AI agent that retrieves and processes external content is fundamentally different from a closed-context chatbot. An agent summarizing emails, processing invoices, reading documents from customer portals, or retrieving data from external APIs is exposed to content that may contain adversarial instructions. If that agent has permission to take actions—write to records, trigger workflows, send communications—a successful injection translates directly into an unauthorized action, not just a bad response.
The OWASP Agentic Top 10, published in December 2025, provides a baseline threat model specifically for autonomous agent architectures that goes beyond the standard LLM Top 10. Red-team exercises should test adversarial content embedded in every channel the AI system processes, not only direct user inputs.
What a strong answer looks like: Security testing that explicitly covers prompt injection across all input channels—user inputs, retrieved documents, API responses, email content, and any external data the system processes—with remediation evidence on file.
Question 5: What Can Our AI Actually Do, and Who Approved That Scope?
This is the permissions question, and it has become the defining security concern for agentic AI specifically.
The principle of least privilege is well-established in conventional security architecture. It means every system, user, and process should have access only to what it needs to complete its designated function—nothing more. Applying that principle to AI systems requires understanding not just what the system was designed to do, but what it is technically capable of doing given its current permissions.
When an AI agent can read the entire customer database, query financial records, modify account settings, and trigger external API calls simultaneously, the blast radius of a single compromise or adversarial manipulation spans all of those systems. IBM's analysis found that 97% of organizations that suffered AI-related breaches lacked proper access controls. Most of them had systems with permissions that were set for convenience, not security.
The Forrester AEGIS framework (published 2025) includes Identity and Access Management as one of its six foundational domains for agentic AI governance. The specific recommendation: agents should not hold human-equivalent privileges. Access should be scoped to the task, time-limited, and granted through dedicated service accounts rather than shared credentials or inherited human permissions.
Two additional questions follow directly from this: Are there actions our AI system can take that require human approval before execution? And is that approval requirement actually enforced at runtime, or only described in policy documentation?
What a strong answer looks like: Documented permission scope for every AI system in production, with just-in-time access controls for sensitive operations and a defined list of actions that require human-in-the-loop authorization before execution.
Question 6: Do We Have an Audit Trail That Would Satisfy a Regulator—or a Board—if Something Went Wrong?
Most organizations that have experienced an AI-related incident discover their audit trail problem at the worst possible moment: when someone asks what the system was doing before the incident occurred.
The challenge is structural. Enterprise AI systems—particularly agents that operate asynchronously across multiple tools and data sources—generate activity that conventional SIEM and logging architectures were not designed to capture. What API did the agent call, and with what parameters? What data did it read, and which parts of that data influenced the response it generated? What action did it take, and was that action within the scope of its approved behavior policy?
The 2026 EY/AIUC-1 Consortium survey found that only 38% of organizations monitor AI traffic end-to-end across prompts, tool calls, and outputs. The Cloud Security Alliance AI Agent Governance Gap report (April 2026) concluded that the absence of evidence-quality audit trails is simultaneously a security problem and a compliance liability: regulators examining AI-involved incidents will expect organizations to reconstruct what their agents did, why, and with whose authorization.
Beyond compliance, the audit trail serves an operational purpose. It is the mechanism by which governance teams can verify that AI systems are behaving within approved boundaries, catch anomalies before they become incidents, and demonstrate to boards and regulators that governance is an operational reality rather than a documented aspiration.
Organizations often use platforms such as Questa AI to build and maintain this audit capability—providing visibility into AI system activity at the action level, across the full agent estate, rather than only at the input/output boundary.
What a strong answer looks like: Runtime logging of AI system activity at the tool invocation level, with retention aligned to regulatory requirements, anomaly alerting integrated into security operations, and a documented incident response runbook that covers AI-specific scenarios.
Question 7: Where Does Our Data Actually Go, and Under Whose Legal Jurisdiction?
This question has moved from a compliance nicety to a board-level concern faster than most legal teams anticipated.
The core issue is the difference between data residency and data sovereignty. Data residency refers to where data is physically stored. Data sovereignty refers to which country's laws govern that data—and they are not the same thing. An AI platform storing data in European data centers may still be subject to U.S. law if the controlling corporate entity is a U.S. company, which means U.S. authorities can compel access regardless of physical storage location.
In 2026, at least 34 countries have enacted data localization requirements that restrict where AI processing can occur. IBM's 2026 AI sovereignty survey found that 93% of executives now consider AI sovereignty mission-critical. The EU AI Act's August 2026 provisions add a layer of accountability requirements for high-risk AI systems operating in regulated sectors.
For legal and compliance teams, the practical implications are significant. An AI system processing personal data from EU residents through a U.S.-based cloud API may require a valid transfer mechanism under GDPR. Standard Contractual Clauses remain technically available but have faced specific challenges from data protection authorities in France, Austria, and the Netherlands. And for sectors with specific data handling requirements—healthcare under HIPAA, financial services under DORA—the obligations extend beyond general privacy law to include specific controls, audit rights, and in some cases restrictions on cloud processing entirely.
The question to put to every AI vendor: Can you confirm in writing where our data is processed, which legal entities have access to it, whether it is subject to third-country government access requests, and what our audit rights are over the infrastructure handling it? A strong vendor provides documented answers. A weak vendor provides reassurances that cite their own privacy policies rather than your contract terms.
What a strong answer looks like: Documented data flow mapping showing where each AI system sends data, the legal jurisdiction governing that processing, the transfer mechanisms in place, and specific contract terms addressing government access requests and organizational audit rights.
Best Practices: Turning Questions into Controls
Asking the right questions is the first step. Turning the answers into operational controls is the second.
Build the inventory before building the governance policy. You cannot govern what you cannot see. The AI system register needs to be a living document, updated automatically where possible, reviewed regularly by security operations.
Classify data before configuring AI access. Data sensitivity classifications should drive AI permission decisions, not the other way around. If the classification work has not been done, that work comes first.
Convert vendor policy commitments into contract terms. Policy pages can change with a web edit. Contract terms cannot. Every material commitment a vendor makes in their privacy documentation should be replicated explicitly in the signed agreement.
Test security controls adversarially, not just procedurally. Documenting that prompt injection defenses exist is not the same as testing whether they work against adversarial content in every input channel the system processes.
Monitor at the action level, not only the conversation level. For agentic AI systems, the meaningful security events are tool invocations, API calls, and data access patterns—not just the inputs and outputs visible at the conversation boundary.
Define human-in-the-loop requirements explicitly. For every AI system in production, there should be a documented list of action types that require human approval before execution. That list should be enforced at runtime, not just described in policy.
Implementation Checklist
Use this checklist as a starting point for an AI security assessment review:
Inventory and Visibility
- Complete register of all AI systems in production, testing, and active employee use
- Vendor-embedded AI features documented alongside purpose-built deployments
- Data access scope documented for each system in the register
- Process in place for security review before new AI systems go live
Data Access and Permissions
- Data classification mapping completed for all AI-accessible repositories
- Permissions reviewed and reduced to least-privilege baseline
- Time-limited, just-in-time access implemented for sensitive operations
- Human-in-the-loop requirements defined and enforced for high-stakes actions
Vendor Risk
- Data Processing Addendum signed and current for all AI vendors processing personal data
- Contract terms explicitly address training data use and opt-out status
- Data retention windows confirmed and negotiated where appropriate
- Sub-processor list reviewed for each vendor
- Audit rights confirmed in writing, not only implied by policy
Security Testing
- Prompt injection testing completed across all input channels
- Red-team exercises cover adversarial content in retrieved documents and external data
- Vulnerability assessment covers AI-specific attack vectors beyond conventional testing
Monitoring and Audit
- Runtime logging of AI activity at tool invocation level
- AI anomaly alerting integrated into security operations
- Audit log retention aligned to regulatory requirements
- Incident response runbook updated to cover AI-specific scenarios
Data Sovereignty and Compliance
- Data flow mapping documents where each AI system sends data
- Transfer mechanisms confirmed and documented for cross-border processing
- Regulatory obligations mapped against each AI deployment's data handling
- Compliance team engaged before go-live on any AI system processing regulated data
Regulatory Considerations
The seven questions above map directly to regulatory expectations, which makes the governance work doubly useful: it reduces actual risk and generates the evidence regulators expect to see.
GDPR requires documented lawful basis for processing, data minimization, purpose limitation, and the ability to respond to subject access requests—including for data processed through AI systems. The EDPB's guidance that user prompts often constitute personal data makes this more operationally significant than many compliance teams have yet incorporated into their AI policies.
The EU AI Act, fully enforceable for high-risk systems from August 2026, requires transparency, human oversight, technical documentation, and conformity assessments for AI systems in regulated decision-making contexts. For organizations in scope, the audit trail question (Question 6) and the data sovereignty question (Question 7) are not optional governance investments—they are legal requirements with 7% global revenue penalty exposure.
NIST AI RMF provides a practical framework for operationalizing these requirements through its Govern, Map, Measure, and Manage methodology. The 2025 Cyber AI Profile adds specific guidance on AI-cybersecurity risk intersections that maps well to the seven questions above.
ISO/IEC 42001 is increasingly requested by enterprise customers as a due diligence signal. Organizations preparing for certification will find that documented answers to these seven questions provide significant evidence toward the standard's 38 control requirements.
Future Outlook
The questions that feel forward-looking today will be standard due diligence requirements within 18 months.
Enterprise procurement teams are already beginning to include AI governance questionnaires in standard vendor evaluation processes. According to the AI Agent Identity Management CISO Playbook (May 2026), enterprise security questionnaires are now routinely asking how AI agents are identified, scoped, and audited.
The same dynamic is developing on the sell side. Organizations that can demonstrate documented AI governance controls—inventory, access controls, audit trails, vendor contracts with explicit data commitments, security testing evidence—are beginning to differentiate themselves in enterprise sales cycles where procurement teams are applying more scrutiny to how AI features handle customer and partner data.
Gartner projects that 40% of enterprise applications will incorporate task-specific AI agents by the end of 2026. As that adoption expands, the regulatory and customer-driven pressure for governance evidence will follow. The organizations that build governance infrastructure now will not be retrofitting it under deadline pressure when that scrutiny arrives.
FAQs
Q: What is the most important AI security question for an enterprise to ask first?
The inventory question. Before any other governance or security work can be meaningful, organizations need to know which AI systems are actually operating in their environment—including employee-deployed tools and vendor-embedded AI features that were not part of a formal procurement process. Governance controls applied to a partial inventory leave the highest-risk exposure unaddressed.
Q: How do we assess whether our AI vendor's data commitments are sufficient?
Look for commitments in your signed contract, not in the vendor's published policy pages. The specific clauses that matter are: explicit exclusion of your data from model training, defined data retention windows, a current Data Processing Addendum, sub-processor disclosure obligations, and audit rights. If any of these exist only in a policy document rather than a contract term, they can be changed without your agreement.
Q: What is prompt injection, and why does it apply to enterprise AI systems?
Prompt injection is an attack in which malicious instructions are embedded in content that an AI system will process—such as a document, email, or retrieved record. When the system processes that content, it may execute the embedded instruction rather than its intended function. For AI agents that can take actions (write to records, send communications, trigger workflows), a successful prompt injection can result in unauthorized actions rather than merely a bad response.
Q: What is the difference between data residency and data sovereignty?
Data residency refers to the physical location of data storage. Data sovereignty refers to the legal jurisdiction governing the data—which country's laws apply to it, including government access rights. An AI platform storing data in EU data centers can still be subject to U.S. law if the vendor is a U.S. corporation, allowing U.S. authorities to compel access regardless of physical storage location. For regulatory compliance purposes, both dimensions need to be assessed.
Q: How do we know if our AI system has excessive permissions?
Compare what the AI system is technically capable of doing against what it was designed to do. Any access to data repositories, APIs, or systems that is not directly required for the system's designated function represents excess permission. The test is whether a single compromise of that system—through adversarial manipulation, a prompt injection attack, or a credential breach—would expose data or trigger actions beyond the intended use case.
Q: What should an AI audit trail capture to satisfy regulatory expectations?
A defensible audit trail for AI systems should capture the inputs the system received, the data it accessed during processing, the tool calls or API invocations it made, the actions it took as a result, and the output it generated—along with timestamps, authorization context, and retention compliant with applicable regulatory requirements. For agentic systems, audit evidence at the tool invocation level is essential, since the meaningful security events occur at execution rather than at the conversation boundary.
Q: Which regulatory frameworks are most relevant for enterprise AI security in 2026?
The most operationally significant frameworks for most enterprise deployments are GDPR (for personal data processing through AI systems), the EU AI Act (for high-risk AI applications from August 2026), NIST AI RMF (for structured risk management), and ISO/IEC 42001 (for certifiable governance). The OWASP LLM Top 10 and OWASP Agentic Top 10 provide the most actionable technical threat models for security testing purposes.
Conclusion
The security posture of an enterprise AI deployment is not primarily determined by what the model can do. It is determined by the decisions made before and after the model goes live—which data it can access, what actions it is permitted to take, what the vendor is actually committed to in writing, whether the system has been tested against realistic attack scenarios, and whether the organization can reconstruct what the system did if it needs to.
None of the seven questions above are difficult to ask. Most of them have clear answers if the right people are in the room. The challenge is that AI deployment cycles tend to move fast, and the governance questions tend to be deferred until after go-live—at which point some of them become significantly harder and more expensive to address.
If your organization is evaluating AI deployments and wants to ensure that security, compliance, and governance are built in rather than retrofitted, this is the right moment to work through these questions as part of the deployment process rather than in response to an incident.
Questa AI is designed to help enterprise teams maintain the visibility, access controls, and audit capabilities that these questions demand—across an AI estate that is growing faster than manual governance processes can track. If you are ready to assess where your current posture stands, exploring what a governed AI environment looks like is a practical first step.
