Policy · Governance
AI Use & Governance Policy
Our posture is enablement within guardrails. AI tools are approved by default when they meet the requirements of their risk tier — because the sanctioned path should be faster than the workaround.
Design note. This policy never names a specific tool. Tools change weekly; tiers and triggers don’t. If you find yourself adding an app list to this document, something has gone wrong.
Purpose and scope
This policy governs the use of AI at [Company] — including standalone AI tools, AI features inside software we already own, AI agents that act on our behalf, and the non-human identities (service accounts, API keys, OAuth tokens) they use.
Enablement within guardrails. AI tools are approved by default when they meet the requirements of their risk tier. We would rather make the sanctioned path fast than push people to personal accounts we cannot see.
Risk tiers
Every AI tool is classified on four dimensions: what data it can see, what systems it connects to, what privileges it holds, and whether it acts independently or waits for a human.
| Tier | Description | Default controls |
|---|---|---|
| ContainedT1 | Limited data, no connections to company systems, human approves every action (e.g., local/developer tools). | Self-service with registration. API keys must be registered (§4). |
| AssistantT2 | Handles company data, minimal connections, acts only when prompted (e.g., cloud AI assistants). | SSO required. Training opt-out or enterprise agreement required. Data rules (§3) apply. |
| EmbeddedT3 | AI features inside systems of record — inherits the host system’s data and permissions. | Change-managed: new AI features in existing tools require review before enablement, not after. |
| AgentT4 | Standing access to company systems, elevated privileges, acts autonomously. | Deepest review, least privilege, approval gate for new capabilities, audit logging, named owner with quarterly attestation. |
A tool’s tier can change — usually upward, when the vendor ships new capabilities. A tier change is a re-review trigger (§7).
Data rules
Data rules follow the classification of the data, not the name of the tool:
Non-negotiables
These apply at every tier, no exceptions without written security sign-off:
SSO where offered
If the tool supports SSO, we use it.
Every non-human identity is registered
Every API key, OAuth grant, service account, and agent identity has a named owner and an expiry date, recorded centrally. Credentials that cannot be revoked centrally within one hour do not get created.
No org-wide scopes without sign-off
Default is minimum scope: read over write, per-user over org-wide, only what’s shared over whole-drive.
No personal accounts for company data
The company provides sanctioned equivalents; using them is how you stay inside the guardrails.
Ownership
- Every AI tool, integration, and agent has a named owner, assigned at adoption — normally the requester, then delegated to the owning department.
- The owner is accountable for: continued business need, access and spend review, responding to vendor changes, and offboarding the tool when it’s no longer needed.
- Ownership is reassigned the week the owner changes roles or leaves — not at the next audit.
- Unowned tools: 30 days unclaimed → access review; 60 days → suspended.
Getting a tool approved
The paved road: make the sanctioned path the fastest one.
Submit a request with: the tool, the tier you believe it is, the data involved, and the business need.
We commit to a decision on a clock, not a queue.
SLA · T1–T2 within [3] business days · T3–T4 within [10]If we say no, we say what tier-compliant alternative to use instead. A “no” without an alternative is a policy failure, not a user failure.
Re-review triggers
Approvals expire on events, not anniversaries. Any of the following automatically reopens the review:
Incident response
If a vendor is compromised: the NHI registry (§4.2) is the source of truth for what the vendor could touch. Target: all of the vendor’s tokens revocable within one hour of the decision to revoke. The owner (§5) and security jointly execute; the post-incident review checks whether §7 triggers should have fired earlier.
What this policy asks of you
Use the sanctioned tools. Register what you adopt. Name an owner. Tell us when something changes. In exchange: fast approvals, real alternatives instead of bare “no”s, and no blame for what you disclose.
The only unforgivable tool is the one we don’t know about.