The contract should name which AI features exist, which model providers process your data, what is retained, whether your data trains any model, how to switch features off, and where a human must approve. If a feature is not covered by the agreement, assume it is not covered by your data terms.
Why AI features need separate attention
An AppSec tool may have been reviewed before an AI feature was added. A new assistant that summarises findings or drafts a fix can move code snippets to a different processor than the one you approved. Treat each AI feature as a possible new data flow, and re-run the review.
Questions for the vendor
| Topic | Ask |
|---|---|
| Inputs | What is sent to the model: finding text, code snippets, whole files? |
| Providers | Which model providers and hosting regions process it? Are they on the subprocessor list? |
| Retention | Is input or output stored by the vendor or the provider? For how long? |
| Training | Is customer data used to train or tune any model, by the vendor or a provider? |
| Control | Can AI features be disabled per tenant, per project or per user? |
| Review | Does an AI suggestion ever apply without human approval? |
| Evidence | Is every AI action logged with who approved it? |
Write answers into the order form or security exhibit, not just a sales email. Emails are hard to enforce months later.
Contract points to look for
- Change notice. New AI features or new model providers require advance notice and an objection right. See subprocessor change notice and objection rights.
- Default state. New AI features start off until your admin enables them.
- No training clause. Plain language that your data is not used to train models, covering providers too.
- Output ownership. Who owns suggested fixes and generated content.
- Accuracy disclaimer. Vendors will say output may be wrong. Your side of that is a review process, so require approval gates.
Keep a human in the loop
AI suggestions are drafts. For automated fixes, ask whether changes arrive as pull requests that your normal review and tests cover. Safer defaults are opt in per category and a clear way to turn the whole thing off. Compare your intended controls with pilot automated fixes on one repo first.
Review it in the pilot
Run a test repo containing a harmless marker string through an AI feature, then check what the vendor's logs and your network capture show. Confirm that disabling the feature really stops traffic to the provider.
Safeguard offers autonomous remediation with fix PRs that is off by default, with every category on Manual, and a free scan at gold.safeguard.sh/scan.
Quick check
Is an AI feature covered by the existing DPA?
Not automatically. Confirm that the feature, its providers and its data flows fall inside the agreement, and that the subprocessor list is updated.
Should AI fixes merge automatically?
Start with human approval. Move categories to automatic only after you have measured quality on low risk repos.
Last reviewed: 19 October 2026.
