Author an Enforceable AI Acceptable-Use Policy

Tier: Advanced · Workflow area: AI governance, risk & compliance

This playbook authors that policy for your organization, aligned to ISO 42001 controls and aware of India's DPDP obligations, so the document is both a governance artifact and an operational control. It is the policy that makes every other control in this track — approved endpoints, data minimization, red-team gates — actually mandatory rather than optional.

When to reach for this

• •
  Your org has employees using AI tools with no clear, enforceable rules about what data may go where.
• •
  You need an AI AUP for ISO 42001 alignment, a client requirement, or DPDP-driven data-handling discipline.
• •
  Existing policy is vague ("use AI responsibly") and provides no basis for enforcement or exceptions.
• •
  Skip authoring a fresh policy if a current, enforceable one exists — refresh and gap-check it instead of rewriting.

The workflow

1. 1.

   Classify data before you write a single clause. The policy hinges on data tiers — public, internal, confidential, regulated/personal. Every rule downstream references these tiers.

2. 2.

   Map approved tools to data tiers. State explicitly which endpoints are allowed for which data. This is the enforceable core.

   Copy

   Data tier            Approved AI tools                         Prohibited
   Public               Any approved assistant                    —
   Internal             Enterprise/approved endpoints only        Public free tiers
   Confidential         Enterprise endpoint with no-training      Any consumer tool
   Regulated / personal Local model or on-prem only; redact first Any external endpoint
   

3. 3.

   Write prohibitions as testable clauses. "Do not paste customer PII into consumer AI tools" is enforceable; "protect data" is not. Each prohibition should be something you can detect a violation of.

   Copy

   3.2  Personal data as defined under the DPDP Act 2023 must not be submitted to any
        AI endpoint that is not on the approved-for-regulated-data list. Redaction or a
        local model is required before processing such data.
   

4. 4.

   Define detection and consequences. State how violations are surfaced (DLP on egress, endpoint allowlisting, audit logs) and the consequence path. A rule with no detection is a suggestion.

5. 5.

   Build an exception process. Real work needs exceptions; an AUP without a governed exception path gets ignored wholesale. Define who approves, for how long, with what compensating control.

6. 6.

   Align to ISO 42001 and DPDP, and assign an owner. Reference the 42001 policy control (pb-48) and DPDP purpose-limitation, security-safeguard, and consent obligations (pb-52). Name the accountable owner and a review cadence.

Verify before you trust it

A policy is enforceable when each clause is testable and each rule has a detection path. Walk the clauses and, for each, ask "how would we catch a violation, and what happens then?" — a clause with no answer is aspirational and should be rewritten concretely or cut. Run the scenario test: take three realistic situations (an engineer pasting a client log into a consumer tool, an analyst processing personal data, a team wanting an unapproved tool) and confirm the policy gives a clear, unambiguous ruling and a defined path for each. Ambiguity that forces a judgment call is where policies fail in practice. Finally, confirm the DPDP-sensitive clauses actually reflect the Act's obligations (purpose limitation, security safeguards, consent) rather than generic privacy language, and that a named owner has approved the document.

Pitfalls

• Aspirational language. "Use AI responsibly" cannot be enforced or audited. Every clause must be concrete and testable.
• No exception path. A policy with no governed way to say yes to legitimate edge cases gets bypassed entirely. Build the exception process in.
• Rules with no detection. A prohibition you cannot detect a breach of trains people that the policy is theater. Pair each with a detection mechanism.
• Ignoring the services reality. Client data often cannot go to public tools at all. The tool-to-tier mapping must encode per-client and per-data-tier constraints, not a single blanket allowance.
• Set-and-forget. Tool approvals and the legal landscape (DPDP phasing) change. An unmaintained AUP misstates what is allowed. Tie it to a review cadence.

Tools

• ISO/IEC 42001 controlsthe AI-policy and governance control themes the AUP satisfies, giving it a recognized framework anchor.
• AI acceptable-use policy templatea structured starting skeleton (data tiers, tool mapping, prohibitions, exceptions) adapted to the org rather than adopted verbatim.
• India DPDP Act 2023the free legal reference whose purpose-limitation, security-safeguard, and consent obligations the personal-data clauses must reflect.

Client-safe variant

When authoring an AUP for a client, write it around their data classification, their approved-tool inventory, and their regulatory posture — a generic template imposed on a client is unenforceable and unowned. Keep the drafting inside their governance environment, encode their per-client and per-data-tier constraints (especially the services-company reality that some client data may never leave an on-prem or approved endpoint), and hand the policy to their designated owner with a review cadence. For Indian clients, ensure the personal-data clauses track DPDP obligations and the CERT-In/DPB breach-reporting interplay (pb-52). Deliver an enforceable document their security team can operate; do not reuse one client's tool allowlist or classifications for another.