Some AI offerings never get serious security questions.
Others get them before anyone asks for a demo.
The difference usually isn’t the technology. It’s the customer.
Teams responsible for regulated data or high-impact systems tend to want a basic risk conversation early, before features, before pilots, and before anything is connected to their environment.
We see this in our work at Kalles Group. An AI startup recently asked for the short list of questions our security team needs answered before we’ll even try a new product or service in our stack. Not to block progress, but to decide whether testing it would be responsible.
This article lays out the questions those customers tend to care about, along with a real-world example of how they show up in practice and why they surface earlier than many teams expect.
Why these questions come up so early
AI changes the trust boundary. Traditional software typically sits alongside core systems. AI systems often sit between users and systems of record. That shift raises immediate questions about identity, authorization, data handling, and accountability.
Security-minded customers recognize this. So, these conversations happen before demos, pilots, or proofs of concept, not after.
A real example from an AI pilot
We worked with a regulated enterprise recently that was piloting an AI-powered contact center solution. The business goal was straightforward: improve customer experience using conversational AI. The architecture introduced complexity almost immediately.
The AI platform orchestrated customer interactions and integrated with internal systems through an intermediary layer. Authentication and session management lived inside the vendor workflow. Backend systems were accessed using shared credentials rather than user-scoped authorization.
As testing progressed, concerns surfaced:
- It wasn’t clear which AI models were in use or how often they changed
- Sensitive customer interactions were being recorded and transcribed
- Verification flows could be bypassed under certain conditions
- Once a user was authenticated, there was no strong guarantee that downstream systems enforced user-level access controls
The core issue wasn’t model accuracy or prompt behaviour. It was architectural. Identity and authorization were enforced primarily on the vendor side, rather than through the client’s own identity and integration layers.
In practice, when a team can’t clearly explain where data lives, who can access it, and what happens to it over time, evaluation usually stops there.
The takeaway was simple. The AI itself didn’t fail. Missing security fundamentals created uncertainty, and uncertainty slowed adoption.
1. How you handle customer data
The first questions are almost always about data. Security-minded customers want clear answers:
- Where is customer data processed and stored?
- How long is data retained and how does deletion work?
- Is customer data used to train models or improve the product?
- Which third parties or sub processors have access?
Clear answers remove friction early. Vague answers stall momentum.
2. Your integration and permission model
Next comes access. Customers will ask:
- What systems does your product need to integrate with to be useful?
- Does access require individual user consent, admin-level consent, or both?
- What permissions are requested, and is authorization scoped to least privilege?
- Can the product be tested using a low-privilege account before broader rollout?
Teams tend to get uncomfortable when tools immediately require broad admin access without a safe way to evaluate behavior first.
Products that support phased access earn trust faster.
3. What data your AI actually needs
AI adds another layer of scrutiny. Customers want to understand:
- Does the product need broad access to internal data to be effective?
- Can access be limited by role, folder, tag, or permission?
- Is the AI learning from customer data, or operating on narrowly scoped context and prompts?
Security teams aren’t anti-AI. They’re anti-unbounded access.
When a tool can clearly explain what data it needs, and just as importantly what it does not, confidence increases quickly.
Precision builds confidence.
4. Logging, visibility, and accountability
Finally, customers ask about visibility. Common questions include:
- How are users and roles managed?
- What logging and audit capabilities exist?
- Can activity be reviewed if there’s an incident or investigation?
This isn’t about surveillance. It’s about accountability. As Glen Willis, one of our security leaders, often emphasizes, teams gain confidence fastest when audit logging and accountability are built in from day one. Not as a roadmap item, but as a default capability.
What this means for AI startups
None of these questions are exotic. None require perfection. Together, they signal maturity.
When startups can answer them clearly, security-rigorous customers move faster—not slower. They feel respected, not sold to. They see a partner who understands enterprise reality.
If you’re building an AI product for serious environments, don’t wait for these questions to catch you off guard. Build the answers into your product design, documentation, and sales conversations.
Security isn’t the blocker. Ambiguity is. Clear answers remove it.