# {{ORG_NAME}} — AI Tool Request Workflow Charter

**Effective date:** {{EFFECTIVE_DATE}}
**Owner:** {{WORKFLOW_OWNER_NAME}}, {{WORKFLOW_OWNER_TITLE}}
**Review cadence:** {{REVIEW_CADENCE}} (e.g., annually)

## Purpose

This charter describes how {{ORG_NAME}} handles requests for new AI tools — submission, routing, decision, audit. It exists so that adopting a new AI tool follows one defined path with traceable evidence, replacing the ad-hoc Slack-or-email pattern.

## Scope

Applies to every request to use a new AI tool, AI-enabled feature, or AI API at {{ORG_NAME}}. This includes:

- New SaaS subscriptions.
- New free-tier tools used for company work.
- New AI APIs called from internal systems.
- Material changes to existing approved tools (e.g., a new data category being processed).

Out of scope: continued use of already-approved tools.

## Submission

Requests are submitted at {{REQUEST_PATH}} (e.g., "AIRegistra → Requests → New request"). The submission captures, at minimum:

- Tool name and vendor.
- Intended use and team.
- Data class(es) the tool will touch.
- Estimated user count and monthly cost.
- Requester contact and manager.

The submitter is the requester of record. They get notified at every stage of the workflow.

## Routing

Requests route based on the tool's data classification and estimated cost:

| Data class | Estimated cost | Approver |
|---|---|---|
| Public / Internal | < {{LOW_COST_THRESHOLD}} | {{LOW_COST_APPROVER}} |
| Public / Internal | ≥ {{LOW_COST_THRESHOLD}} | {{MID_COST_APPROVER}} |
| Confidential | any | {{CONFIDENTIAL_APPROVER}} |
| Restricted (PII / regulated) | any | {{RESTRICTED_APPROVER}} + {{COMPLIANCE_OWNER}} |

Routing rules are configured in {{REQUEST_PATH}} → settings → routing.

## Decision

Approvers must respond within {{SLA}} business days. The four possible decisions are:

- **Approve** — tool added to {{REGISTER_LOCATION}} as Approved; requester notified; AI Act readiness implications captured.
- **Approve with conditions** — same as above, with conditions documented (e.g., "no Confidential data without follow-up review", "trial only, re-review in 90 days").
- **Restrict** — request denied for the proposed scope; tool may be allowed for a different scope. Documented.
- **Deny** — request denied. Documented.

Each decision must include a written **rationale**. The rationale is the load-bearing piece of audit evidence.

## Communication

Decisions are communicated to the requester via {{REQUEST_PATH}} notifications and, optionally, email. The decision rationale is visible to the requester in full.

## Audit and review

Every request, regardless of decision, is retained in {{REQUEST_PATH}} for at least {{RETENTION_PERIOD}} (e.g., 6 years, matching the Act's general document retention guidance). Quarterly, {{WORKFLOW_OWNER_NAME}} reviews:

- Average decision latency vs. SLA.
- Approval / restriction / denial ratios by data class.
- Pattern of repeat requests (signals a tool gap).

The review output feeds into the policy review.

## Roles and responsibilities

- **Requesters** — submit complete information; respond to clarifying questions within {{REQUESTER_RESPONSE_SLA}} business days.
- **Approvers** — respond within SLA; provide written rationale; recuse for conflicts of interest.
- **{{WORKFLOW_OWNER_NAME}}** — maintains the routing rules; runs the quarterly review.
- **{{COMPLIANCE_OWNER_NAME}}** — reviews approvals involving Restricted or Regulated data.

## Review and updates

This charter is reviewed every {{REVIEW_CADENCE}}. Material updates are communicated to all approvers and to the staff lists below.

---

**Distribution.** This charter is distributed to: all approvers, all people managers, and the compliance and security owners. New hires receive it as part of onboarding.

*This template is provided by AIRegistra (Mindysm OÜ, Tallinn, Estonia) as a starting point. It is general guidance, not legal advice — review with your own counsel before adoption.*