What are the signs that an AI vendor’s controls are too discretionary?

What Discretion Looks Like in an AI Vendor Control Model

Controls are discretionary when the vendor can change, interpret, or waive safety and usage restrictions without a crisp, testable rule set. That is a problem because procurement teams cannot tell whether the promised boundary is enforced by policy, code, or reputation management. If the vendor’s answer depends on who you ask, the control surface is already too soft.

Vague lawful-use language is one of the strongest signs of discretion because it signals intent, not enforcement. The practical test is whether the vendor can point to a specific control boundary, a named owner for rule changes, and a predictable process for rollback or exception handling. If those elements are missing, the buyer is being offered judgment calls rather than control.

A second sign is weak auditability. If the vendor cannot show what was blocked, what was allowed, and why, you cannot distinguish a deliberate policy from an informal operator choice. That matters most when the product is used in regulated workflows, production decisioning, or environments where the buyer needs evidence that restrictions were actually applied.

Signs the Boundary Is Too Soft for Procurement

Soft boundaries usually show up as a mix of ambiguity and reversibility. The vendor may say they enforce safe use, but not describe how restrictions are encoded, who approves changes, or how quickly those changes propagate across tenants, models, or deployments. A serious control should survive personnel change, provider policy shifts, and support escalation without becoming ad hoc.

Another warning sign is when the vendor cannot explain continuity if the model provider changes policy. In that case, your control depends on an external relationship rather than an owned operating model. For procurement, that means the same use case could become compliant, restricted, or silently degraded without a clear change-management trail.

Watch for controls that are described as “best effort,” “as needed,” or “case by case” when the use case requires repeatable enforcement. Those phrases are not automatically bad, but they do mean the buyer should treat the control as advisory unless there is evidence of hard enforcement, logging, and exception governance. In practice, discretionary controls tend to fail at scale because they cannot be reviewed, tested, or inherited reliably.

How Buyers Should Judge Enforcement, Reversal, and Evidence

The right question is not whether the vendor has safety intentions, but whether the control can be validated before contract signature. Buyers should ask for the enforcement mechanism, the change authority, the audit trail, and the continuity path in one coherent answer. If any one of those is missing, the vendor has not yet proved that the control is operational rather than rhetorical.

Look for evidence that restrictions are reversible in a governed way, not by informal support action. A vendor with mature controls can explain what triggers a policy change, who can override it, what evidence is retained, and how customers are notified when the operating boundary changes. That is the difference between a control framework and a promise.

For procurement teams, the most useful benchmark is consistency under pressure. A control is credible when the vendor can show that the same rule applies across deployments, escalations, and product updates without relying on individual judgment. If the answer is “it depends,” ask what documentation, logs, or contractual language makes that dependency auditable.

Risk and Threat Considerations

Discretionary controls create exposure because they are easy to reinterpret after deployment and hard to verify during a dispute. That makes them risky not only for compliance, but also for business continuity, since a policy change or support exception can alter what the system is allowed to do.

Failure mechanism: The vendor’s control boundary relies on informal judgment, undocumented exceptions, or opaque policy changes, so the buyer cannot prove what was enforced at any point in time.

Impact: Procurement can end up with false assurance, weak audit evidence, and an unstable operating assumption that breaks when the provider changes policy, ownership, or enforcement posture.

Practitioner Guidance

What to verify: Ask the vendor for the exact control owner, the change process, and the audit record that proves enforcement, then test whether the answer is stable across sales, security, and support teams. If those answers differ, treat that as a governance defect, not a communication issue.

Decision rule: If the vendor cannot show how restrictions are enforced and reversed, do not treat the control as procurement-grade until the mechanism is documented and reviewable. If the control only exists as policy language, require stronger contractual or technical evidence before relying on it.

Practitioner takeaway: The core test is whether the vendor can prove the boundary without relying on trust in a person, because discretionary controls fail precisely when the organisation needs them to be predictable.

Related resources from NHI Mgmt Group

• What are the signs that AI platform access controls are too broad for tenant separation?
• What are the signs that AI access controls are too permissive in a GenAI programme?
• What are the signs that AI agent security controls are too weak?
• What are the signs that AI security controls are too dependent on frontier model defaults?