AI compliance by design: why reviewing your AI feature before launch is too late

Most AI features I review arrive the same way: a demo that works, a launch date on the calendar, and a request for "a quick compliance sign off". By that point the model provider is chosen, the data pipeline is built and the customer has been told the date.

A compliance review three weeks before launch can only document problems, not prevent them. If you're adding AI to a product that handles personal or customer data, the review belongs at design, and it fits in thirty minutes.

I've worked on privacy and security reviews for fintech and healthcare products, where an AI feature that touches customer records is a regulatory question, not only an engineering one.

What goes wrong when compliance comes last

The data is already flowing to a provider whose retention terms nobody read. A customer's master agreement says you must notify them before adding a new subprocessor, and you haven't. The feature uses personal data for a purpose your privacy notice never mentioned. Nobody owns the question of what happens when the model is wrong.

Each of these is cheap at design and expensive at launch. At launch the options narrow to delaying, reworking, or writing down the risk and shipping anyway. Most companies pick the third.

Every company has a privacy by design policy, and a launch checklist where privacy is item 27.

What the laws actually require

Under India's DPDP Act, personal data can only be processed for the purpose people were told about and consented to, or for a narrow set of legitimate uses. Feeding support tickets into a model to train a new feature is a new purpose unless your notice said otherwise.

GDPR Article 25 requires data protection by design and by default, and Article 35 requires a data protection impact assessment for processing likely to result in high risk, which regulators routinely read as covering new technologies like AI.

ISO 42001 asks for an AI system impact assessment, and enterprise buyers now ask whether you have one.

Six questions for design review

What data will the feature send to a model, and does it include personal or customer confidential data?

Which provider and which model, and where is the data processed?

Does the provider retain inputs or use them for training, and which settings or contract terms change that?

Do our customer contracts and privacy notice allow this use, or do we need to notify anyone?

Who reviews outputs before they reach a customer, and what happens when the output is wrong?

How will we know if it starts failing: what do we log, and who looks?

"Quick q, are we ok to send customer tickets to the model?", sent on the Friday before launch, is one of the most expensive messages in product development. These six questions answer it months earlier.

Making it routine

Add the six questions to your design document template. Keep an inventory of AI systems with an owner for each. Treat a new model provider like any other vendor carrying customer data: review it, record it, add it to your subprocessor list.

In Steppe a new AI system is a record with an owner, a data flow and an assessment before it's a release note. That order matters more than the tool you use.

The cheapest compliance review an AI feature will ever get is the one held before anyone writes code.