[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"glossary-ai-usage-policy::en":3,"gloss-cluster-ai-usage-policy::en":26,"gloss-next-ai-usage-policy::en":9},{"slug":4,"category":5,"name":6,"definition":7,"meta_desc":8,"faq":9,"schema_markup":9,"related":10},"ai-usage-policy","security","AI Usage Policy","An AI usage policy is the internal document telling staff which AI tools they may use, for what work, and what may never be pasted into one. It faces inward, which is what separates it from a vendor's acceptable-use terms: the vendor's document restricts what you may do with their service, and yours restricts what your people may do with anyone's.\n\nThe useful version is short and specific. It names the approved tools rather than describing a category, because \"an enterprise-grade assistant\" is not something an employee can act on at nine in the morning. It states clearly what classes of data are off limits — customer records, credentials, unreleased financials, anything covered by a confidentiality obligation — using the same labels as the organisation's existing data classification, not a new vocabulary invented for AI.\n\nIt also has to say what happens to output, which is the half most policies skip. Whether AI-assisted code needs review before merge. Whether a draft sent to a customer needs a human read. Whether generated material can be published without disclosure. Staff generally understand that input carries risk; the risk that a plausible, wrong answer travels onward unchecked is less obvious and needs stating.\n\nA policy fails in a predictable way: it is written restrictively, published once, and then ignored, because the work it forbids is work people still have to do. If the approved list contains nothing that does what a team needs, that team will use something else on a personal account, and the organisation loses both the control and the visibility. A route for requesting a new tool, with a real response time, does more for compliance than a longer prohibited list.\n\nTreat it as a living document with an owner and a review date. Models, vendors and features change often enough that a policy written a year ago will name tools that have been retired and be silent about capabilities that did not exist when it was drafted. Pair it with training that shows the failure modes rather than only reciting the rules — people follow a rule they understand the reason for.","An AI usage policy tells staff which AI tools are approved, what data may never be pasted in, and what has to be checked before AI output goes anywhere.",null,[11,14,17,20,23],{"slug":12,"name":13},"audit-log","Audit Log (Audit Trail)",{"slug":15,"name":16},"data-classification","Data Classification",{"slug":18,"name":19},"human-in-the-loop","Human-in-the-Loop",{"slug":21,"name":22},"pii","Personally Identifiable Information (PII)",{"slug":24,"name":25},"shadow-ai","Shadow AI",[27,31,34,37,40,43,46,48,51,54,57,60],{"slug":28,"category":5,"name":29,"updated_at":30},"access-review","Access Review","2026-09-08T21:32:37+00:00",{"slug":32,"category":5,"name":33,"updated_at":30},"ai-governance","AI Governance",{"slug":35,"category":5,"name":36,"updated_at":30},"ai-incident-reporting","AI Incident Reporting",{"slug":38,"category":5,"name":39,"updated_at":30},"ai-review-board","AI Review Board",{"slug":41,"category":5,"name":42,"updated_at":30},"ai-risk-tiering","AI Risk Tiering",{"slug":44,"category":5,"name":45,"updated_at":30},"ai-system-inventory","AI System Inventory",{"slug":12,"category":5,"name":13,"updated_at":47},"2026-09-08T21:32:36+00:00",{"slug":49,"category":5,"name":50,"updated_at":47},"blast-radius","Blast Radius",{"slug":52,"category":5,"name":53,"updated_at":47},"break-glass-access","Break-Glass Access",{"slug":55,"category":5,"name":56,"updated_at":47},"bridge-letter","Bridge Letter",{"slug":58,"category":5,"name":59,"updated_at":47},"business-associate-agreement","Business Associate Agreement (BAA)",{"slug":61,"category":5,"name":62,"updated_at":47},"byok","Bring Your Own Key (BYOK)"]