What to look for in a software partner when AI is involved – and your industry leaves no room for error

Can they tell you exactly what data their AI tools see?

This is the foundational question, and it has a binary quality to it: either your vendor has a clear, documented answer, or they don’t. There is no middle ground that should satisfy a compliance function.

The concern is straightforward. Most AI coding tools work by sending context – code, prompts, sometimes configuration – to external APIs. The question is what that context contains, and whether it ever touches data that is yours: customer records, behavioral data, PII, anything covered by your data classification policy.

What to ask:

– Which AI tools do your engineers use day-to-day?

– Do any of those tools send data to external APIs? Which ones?

– What is your policy on AI tooling in environments that contain client data?

– How is that policy enforced – at the process level, or the tooling level?

Red flag: “We trust our engineers to use judgment” is not a data governance policy. For a company with SEC disclosure obligations or GDPR exposure, it’s not an acceptable answer.

What good looks like: A partner who can tell you, by tool and by environment, what data each AI system is permitted to access – and who enforces that at the process level, not just on trust.

Who owns the code – and is that actually clean?

IP ownership in AI-assisted development is more complicated than most vendors will admit. The core issue: some AI tools are trained, fine-tuned, or influenced by the data they process.

If your codebase passes through such a system, the provenance of your IP becomes murky. There’s also a secondary question about training data contamination – whether the models your vendor uses were trained on licensed or unlicensed code, and whether that exposure creates copyright risk downstream.

This is an evolving area legally, but it’s one your legal team will ask about, and a serious vendor should have a position on it.

What to ask:

– Do any of your AI tools use client code for model training or fine-tuning?

– What models do you use, and what are their training data policies?

– Can you provide documentation suitable for an IP due diligence review?

Red flag: A vendor who hasn’t read the terms of service of the AI tools their engineers use daily. This is more common than it should be.

What good looks like: Clear documentation of which tools are used, a stated policy that client code is not used for training, and willingness to include IP ownership clauses in the contract that reflect AI-assisted development specifically.

Do they differentiate risk by system – or treat everything the same?

A homepage banner and a payment integration are not the same thing. A mature AI-native development partner understands this and applies different levels of scrutiny depending on what they’re building.

This matters because AI tooling is genuinely excellent for some tasks – generating boilerplate, writing tests, accelerating documentation – and should be treated with much more caution in others. Systems that handle financial transactions, loyalty and rewards data, identity and authentication, or third-party data flows require a different posture.

What to ask:

– How do you decide where AI tooling is appropriate versus where it requires additional review?

– Who reviews AI-generated code in high-compliance contexts, and what does that review process look like?

– Have you worked with systems under PCI-DSS, SOC 2, or GDPR constraints? What changed about your process?

Red flag: “We review all AI-generated code” without any description of what that review actually involves, or who does it. Review is only valuable if the reviewer has the context to catch what the AI got wrong.

What good looks like: A partner who can describe, without prompting, which parts of your system they would treat differently – and why. That demonstrates genuine architectural judgment, not just AI tooling fluency.

Can they support your vendor risk assessment – not just tolerate it?

If your company is publicly traded, you have a vendor risk assessment process. It may be handled by your security team, your legal team, or an external auditor. A development partner who has worked with companies in your position should know this process well – and should be able to move through it without friction.

This isn’t just about paperwork. It’s a signal about how the vendor thinks about accountability. Vendors who are uncomfortable with scrutiny are vendors who have something to be uncomfortable about.

What to ask:

– Have you completed vendor risk assessments for publicly traded clients before?

– Can you provide documentation of your AI usage practices for an internal audit function?

– How do you handle disclosure requirements if your AI tooling changes mid-engagement?

Red flag: Resistance, delay, or vagueness when asked for documentation. A vendor who treats your compliance process as an obstacle rather than a standard part of doing business is telling you something important about how they operate.

What good looks like: A vendor who proactively offers to walk your security or legal team through their AI governance practices – before you have to ask.

Will you be able to maintain what they build – without them?

There is a version of AI-assisted development that creates a new kind of vendor lock-in: proprietary tooling, undocumented decisions, and codebases that only the original team understands well enough to extend. This risk is higher, not lower, when AI is involved – because AI can generate large amounts of code quickly, and that code isn’t always written with future maintainability in mind.

For companies managing long-lived infrastructure – commerce platforms, internal tools, data pipelines – this is a strategic concern. The decision about which vendor to use today has a multi-year tail.

What to ask:

– If we brought this codebase in-house or transitioned to another vendor, what would that involve?

– How do you document architectural decisions, especially where AI was involved in generating options?

– Are there any dependencies in your delivery process on proprietary AI systems that we wouldn’t have access to?

Red flag: Difficulty answering the transition question – or an answer that assumes continued dependency on the original vendor. Healthy long-term partnerships don’t require lock-in to sustain them.

What good looks like: Standard, well-documented code with explicit records of key decisions. A partner who builds as if someone else might need to take over – because they might.

Why this framework leads you toward better partners, not more cautious ones

The five questions above are not a reason to avoid AI-native development partners. They are a way to find the ones who are actually good.

The vendors who can answer these questions clearly are, almost by definition, the vendors who have thought carefully about what they’re doing. That same thoughtfulness shows up in the quality of what they build. Governance and craft are not in tension – they come from the same underlying disposition.

And the performance case for working with a serious AI-native partner is real. Done well, AI-assisted development means faster iteration, better test coverage, more thorough documentation, and engineers who spend less time on repetitive scaffolding and more time on the decisions that actually require judgment. For complex platform work – migrations, API consolidation, multi-system integrations – this matters.

The goal isn’t a vendor who avoids AI. It’s a vendor who uses it with the same rigor they bring to everything else.

How we answer these questions

We built Boldare’s development practice with these questions in mind – partly because our clients ask them, and partly because we think they’re the right questions.

Our AI governance framework covers data containment by environment, IP chain of custody, differentiated review processes for high-compliance systems, and documentation suitable for vendor risk assessments. When we start an engagement with a publicly traded client, the AI governance conversation happens in discovery – not after a compliance incident.

If you’re currently evaluating development partners and want to walk through how we’d answer the questions in this article for your specific context, we’re happy to have that conversation.