More and more vendors claim to use AI to develop software faster: coding assistants, agents, test generators, review tools, and pipeline automations. For those purchasing software, this information is not inherently negative—it can be a real advantage if the vendor properly controls data, code, dependencies, tests, and delivery.

The risk arises when “we use AI” becomes a marketing promise without evidence. Procurement, CTOs, CISOs, and legal teams must ask for proof: which tools are used, what data enters the process, what controls verify the code, and what happens if a vulnerability emerges? Due diligence should not block the vendor; it should separate those who use AI in a governed manner from those who have simply accelerated development by shifting the risk onto the client.

The right question is not “do you use AI?”

Asking only if the vendor uses AI yields an unhelpful answer. The correct question is: in which phases of the development lifecycle is AI used, and with what controls? The areas of application can be very different—from generating application code to refactoring, from writing tests to analyzing logs and bug reports, from generating pipelines and IaC to suggesting dependencies, and even assisted code review, documentation, and agents that open pull requests or execute commands.

Every use case has a different risk profile. An assistant that suggests text for documentation is not equivalent to an agent that modifies permissions, queries, pipelines, and dependencies: treating them the same way means underestimating the real risks.

What client data enters AI tools?

The first area of due diligence concerns data handling. The vendor may need logs, tickets, repositories, dumps, payloads, screenshots, or documentation to resolve issues. If these elements enter prompts, chats, agents, or unauthorized tools, the client loses control over data and secrets.

The questions to ask concern whether the vendor can input client code into AI tools, whether they can input logs, tickets, personal data, or production data, whether they use enterprise accounts or personal accounts, whether redaction rules exist, whether prompts or transcripts are stored, whether data is used for training or service improvement, and whether there are contractual restrictions on sub-processors and tools. The answer must be documented, not based on verbal reassurances.

What controls exist for AI-generated or assisted PRs?

The client does not need to ask for every operational detail, but they must understand if AI-generated code is accepted blindly. Useful evidence includes the vendor’s internal AI coding policy, the presence of branch protection and mandatory reviews, examples of PR workflows, CODEOWNERS or reviewers for sensitive areas, commit and release traceability, Code Review reports, and merge-blocking criteria.

Areas that require strong review include auth, permissions, APIs, queries, data, payments, secrets, dependencies, pipelines, cloud, and business logic. If the vendor cannot explain how they control these, the risk remains with the client.

Tests, scanners, and remediation: what evidence exists?

A vendor may claim to use SAST, SCA, secret scanning, and automated tests. The next question is what happens to the findings: which scanners are run and when, which severity levels block the release, who performs triage, how false positives and exceptions are managed, which negative tests cover roles, tenants, inputs, and abuse, how a fix is verified, and which reports are shared with the client.

Scanners and tests do not replace independent verification, but they are a sign of process. If the vendor does not produce reports or does not have remediation SLAs, the controls risk being purely formal.

Dependencies, licenses, and supply chain

AI can suggest libraries, plugins, actions, base container images, and build tools. For the client, this impacts vulnerabilities, licenses, maintenance, audits, and lock-in. Evidence to request includes the list of main dependencies, Software Composition Analysis, license reports, SBOMs when the scope requires it, policies on new dependencies, version and action pinning, CVE management, and the provenance and integrity of artifacts.

A dependency may be technically convenient but unacceptable per client policy. This must be discovered before delivery, not during an audit.

Secrets, environments, and access

Due diligence must verify how the vendor manages credentials, environments, and test data. Points to clarify include the use of synthetic vs. real data, the protection of configuration files, API keys, cloud tokens, and webhook secrets, whether credentials are personal or project-specific, the separation between staging and production, who can access client environments, the presence of access and revocation logs, and what happens when a collaborator leaves the project.

If a client key ends up in prompts, logs, or repositories, the contract must provide for notification, rotation, impact analysis, and clear responsibilities.

Technical clauses to include or verify

Generic “best practice” clauses are not enough. For vendors developing with AI, more concrete requirements are needed, covering allowed AI tools and sub-processors, prohibitions or limits on client data in prompts, the obligation for corporate accounts with enterprise controls, client segregation, human review on sensitive areas, minimum scanning and testing, dependency and license management, vulnerability and incident disclosure, remediation SLAs, the right to audit or independent verification, and the delivery of reports, SBOMs, or evidence when requested.

Legal and procurement teams should not write technical controls alone: they must translate technical requirements into verifiable obligations.

When is independent verification needed?

Documentary due diligence is useful, but not always sufficient. If the software is critical, exposed, multi-tenant, integrated with corporate systems, or handles real data, technical verification that goes beyond the documentation provided by the vendor is required.

Independent verification can include a Code Review of delivered code, auth, APIs, secrets, dependencies, and pipelines; a Web Application Penetration Testing on exposed apps or APIs; and process verification with the Software Assurance Lifecycle if the vendor works continuously. The point is not to duplicate all the vendor’s work, but to verify the points where an error would have a direct impact on the client.

Checklist of questions for the vendor

• Which AI tools do you use in development?
• In which phases: code, tests, review, pipeline, documentation?
• What client data can enter prompts or the context?
• Do you use enterprise accounts, SSO, MFA, and logging?
• Can code or prompts be used for training or service improvement?
• How do you segregate clients, repositories, workspaces, and environments?
• Which controls block merges and releases?
• Which areas require mandatory human review?
• Which scanners do you run and which reports do you share?
• How do you manage dependencies, licenses, SBOMs, and CVEs?
• How do you protect client secrets and credentials?
• What SLAs do you have for remediation and retesting?
• Do you accept independent verification before go-live or final acceptance?

Warning signs

• The vendor talks only about productivity, not controls.
• They cannot say which AI tools they use.
• They use personal accounts or free plans on client code.
• They have no rules on data and prompts.
• They produce no evidence of reviews, tests, or scanners.
• They do not distinguish between generated code and reviewed code.
• They do not check licenses and dependencies.
• They do not accept independent verification on critical perimeters.
• They have no remediation SLAs.
• They do not know who is responsible in the event of a vulnerability.

When to involve ISGroup

ISGroup can support technical due diligence before signing, during the acceptance of a release, or before go-live. The best verification is proportionate: the same level of control is not needed for a low-risk internal tool as for an exposed platform with personal data, roles, and APIs.

FAQ

• Is it risky to choose a vendor that uses AI?
• Not necessarily. It is risky to choose a vendor that uses AI without policies, evidence, reviews, tests, data management, and clear responsibilities.
• Do I need to ask to see all the prompts?
• Not always. Prompts may contain sensitive information belonging to the vendor themselves. Usually, policies, review reports, scanners, tests, SBOMs, corrected findings, contractual clauses, and the right to audit are more useful.
• Which document should I ask for first?
• A policy or description of the vendor’s AI coding process: tools used, prohibited data, mandatory reviews, technical controls, dependency management, and remediation SLAs.
• When is an independent Code Review needed?
• When the delivered code touches auth, APIs, data, secrets, queries, dependencies, pipelines, cloud, or critical business logic.
• When is a Web Application Penetration Testing needed?
• When the app or API is exposed to users, clients, partners, or the internet and handles real data, roles, uploads, payments, or integrations.

Sources and references

• NIST SP 800-218 SSDF
• NIST AI Risk Management Framework
• OWASP SAMM
• OWASP ASVS
• OWASP Code Review Guide
• SLSA