10 questions to ask any AI development partner about compliance.

Most AI development agencies will tell you they can build what you need. Few will tell you, unprompted, what happens to that system when a regulator, an enterprise customer's security team, or an investor's due diligence process asks about it. This is a checklist to ask before you sign — of us, or of anyone else you are evaluating.

These are not trick questions. They are the questions that expose whether compliance is something a partner builds in, or something they plan to figure out later — usually at your expense.

1. Is compliance scoped before development starts, or after?

Ask when regulatory scoping happens in the project timeline. If the answer is "we'll figure that out once the system is working," the architecture is being decided without knowing what it needs to prove later — which usually means rework once it does.

A partner building compliance in will describe a scoping step — typically one to two weeks — that happens before or alongside the first sprint, not after the demo.

2. Who classifies the system's risk level, and against which regulations?

Every AI system falling under the EU AI Act needs a risk classification. Ask who does this, how, and whether it is documented. "We'll deal with that if it comes up" is not an answer a regulator or an auditor will accept, and it should not be one you accept either.

3. Is the audit trail built in, or added later?

An audit trail — a record of what the AI decided, on what input, using which model version — has to be designed into the data pipeline. It cannot be bolted onto a finished system without touching the database schema and the processing logic. Ask to see what a sample audit log looks like from a system they have actually shipped.

4. Can the system explain its own decisions?

Explainability is a specific, testable requirement under the EU AI Act for high-risk systems — not a nice-to-have. Ask whether the model architecture was chosen with explainability in mind, or whether it is a black box that will need a separate project to interpret later.

5. Who owns the compliance documentation after the engagement ends?

Technical documentation, data maps, and risk assessments need to be usable by you — not locked in a format only the vendor can read, and not owned in a way that leaves you unable to update them without going back to the same vendor.

6. What happens when a regulation changes after handover?

Regulations evolve. Ask whether the partner offers any ongoing relationship for this, or whether their involvement ends at deployment and every future regulatory change becomes your problem to solve from scratch — usually with a team that does not know the system.

7. Has the team taken a system through a live audit?

There is a real difference between a team that has read the EU AI Act and a team that has sat across the table from an auditor or regulator with a system they built. Ask for a specific example, not a general claim.

8. Is data handling documented as the system is built, or reconstructed later?

GDPR and DPDP compliance require knowing what personal data the system processes, its lawful basis, and its retention and deletion rules. Ask whether this is documented as data flows are built, or whether it would need to be reverse-engineered from the finished system months later — which is slower, incomplete, and expensive.

9. What does compliance later actually cost, versus compliance now?

Ask any partner to give you a straight answer on this — not a hand-wave. A partner who has genuinely thought about it will have a number, or at least a clear explanation of what drives the cost difference. A partner who has not thought about it will change the subject.

10. What do you receive at handover, beyond working code?

A working application is the baseline, not the differentiator. Ask specifically what documentation ships with it: a risk classification, a data map, a compliance summary an auditor could review. If the answer is just "the code and a README," you are the one who will have to produce that documentation later — under deadline pressure, without the context the development team had.

The bottom line

None of these questions require you to understand AI regulation yourself. They only require a partner who has already done that work and can show it — in the architecture, in the documentation, and in what they hand you at the end. Ask them of every partner you evaluate, including us.