[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"guide-how-to-write-an-ai-use-policy-your-team-will-follow::en":3,"guide-related-how-to-write-an-ai-use-policy-your-team-will-follow::en":17},{"slug":4,"title":5,"excerpt":6,"body":7,"meta_title":5,"meta_description":8,"keywords":9,"category":15,"published_at":16,"updated_at":16},"how-to-write-an-ai-use-policy-your-team-will-follow","How to Write an AI Use Policy Your Team Will Follow","A policy nobody can act on is worse than no policy, because it moves the same work somewhere you cannot see it. This is how to write one that survives contact with the job.","\u003Ch2>Start from what people are already doing\u003C\u002Fh2>\n\u003Cp>Before writing a word, find out how AI is being used in your organisation today. Not the sanctioned list — the real one. Expense reports show personal subscriptions. Browser and identity logs show which assistants people sign into. A short, non-punitive survey asking what people use and for what will get honest answers if it is clearly not an audit, and the answers are usually more mundane and more widespread than the leadership team expects.\u003C\u002Fp>\n\u003Cp>This matters because a policy written against an imagined situation will forbid things nobody does and stay silent about the thing half the company does daily. It also tells you which needs are real, and a policy that quietly bans a workflow people depend on has not stopped that workflow. It has moved it to a personal account, where you have neither control nor visibility.\u003C\u002Fp>\n\u003Ch2>Name the tools, not the category\u003C\u002Fh2>\n\u003Cp>An employee at their desk at nine in the morning needs to know whether the thing in front of them is allowed. \"Enterprise-grade assistants with appropriate contractual protections\" does not answer that question, and the person asking it will resolve the ambiguity in whichever direction gets their work done. List the approved tools by name, with the plan or tier where that matters, because the free and paid tiers of the same product often differ on exactly the terms you care about.\u003C\u002Fp>\n\u003Cp>Keep the list somewhere it can change without reissuing the policy — a linked page owned by whoever runs the approval process. The policy states the rule; the list is operational data, and coupling the two means the list goes stale at the speed of document revisions rather than the speed of the market.\u003C\u002Fp>\n\u003Ch2>Reuse the data classification you already have\u003C\u002Fh2>\n\u003Cp>Most organisations already have labels for their data, whatever they are called: public, internal, confidential, restricted. Use those, and state which classes may go into which tools. Inventing a new vocabulary for AI creates a second scheme people have to learn and reconcile, and the reconciliation will be done by guesswork at the moment of use.\u003C\u002Fp>\n\u003Cp>Where you do need AI-specific detail, keep it concrete: customer records, credentials and access tokens, unreleased financials, anything under a confidentiality obligation to a third party, personal data about identifiable people. Then say what to do when someone is unsure, because that is the case the rules will not cover, and a named person or channel to ask is worth more than another paragraph of definition.\u003C\u002Fp>\n\u003Ch2>Say what happens to the output\u003C\u002Fh2>\n\u003Cp>Most policies cover input and stop there. That leaves the more common failure unaddressed: a fluent, wrong answer travelling onward because it looked finished. State the review expectation for the outputs that matter. Whether AI-assisted code needs a human review before merge. Whether a draft going to a customer needs someone to read it. Whether generated material can be published without saying so. Whether a number in a report needs to be traced to its source.\u003C\u002Fp>\n\u003Cp>Frame these as the review the work already deserves rather than as AI-specific bureaucracy. Nobody merges unreviewed code from a new contractor either. Setting the expectation in those terms makes it intuitive, and it avoids the impression that AI output is under suspicion while everything else is trusted.\u003C\u002Fp>\n\u003Ch2>Give people a route to ask\u003C\u002Fh2>\n\u003Cp>Every restrictive policy needs a door. If someone needs a tool that is not on the list, there has to be a way to request it, a stated response time, and a real chance of a yes. Without that, the approved list becomes a ceiling on what the organisation can do, and the gap between the ceiling and the need is filled by unmanaged accounts. A request path with a two-week answer does more for compliance than another page of prohibitions.\u003C\u002Fp>\n\u003Ch2>Make it short and findable\u003C\u002Fh2>\n\u003Cp>A policy people cannot find is a policy people cannot follow. One page, linked from wherever the tools are, mentioned in onboarding, and written in the language people use rather than in contract prose. If it takes more than a couple of minutes to read, the parts that matter will be skipped along with the parts that do not, and length is not evidence of rigour.\u003C\u002Fp>\n\u003Ch2>Treat it as a living document\u003C\u002Fh2>\n\u003Cp>Give it an owner and a review date. This field changes fast enough that a policy written a year ago will name products that have been renamed or retired and say nothing about capabilities that did not exist when it was drafted, and a document that is visibly out of date teaches people that none of it is current.\u003C\u002Fp>\n\u003Cp>Then watch the exception requests, because they are the best available feedback on whether the policy is right. Several requests of the same shape mean the rule is wrong or the approved options do not cover a genuine need, and the correct response is to change the rule rather than keep granting the same waiver. A policy that never generates exceptions is not necessarily well written — it may simply be one nobody consults.\u003C\u002Fp>","Most AI policies fail by being restrictive, generic and unfindable. Here is how to write one that answers the questions people actually have at their desks.",[10,11,12,13,14],"ai use policy","ai governance","acceptable use","shadow ai","data classification","privacy-security","2026-09-06T03:30:02+00:00",[18,23,27,31,36,41],{"slug":19,"title":20,"excerpt":21,"updated_at":22},"ai-tool-pricing-models-seat-vs-usage-vs-credits","AI Tool Pricing Models: Seat-Based vs Usage-Based vs Credits","The three common ways AI tools charge — per seat, per usage, and by credits — and how to reason about which one will actually be cheaper for the way your team works.","2026-08-05T14:32:26+00:00",{"slug":24,"title":25,"excerpt":26,"updated_at":22},"how-ai-image-generators-differ-diffusion-vs-the-rest","How AI Image Generators Differ: Diffusion vs the Rest, in Plain Terms","A non-technical explanation of how AI image generators work, why the diffusion approach became dominant, and what practical differences to expect between tools.",{"slug":28,"title":29,"excerpt":30,"updated_at":22},"how-to-automate-your-workflow-without-code","How to Automate Your Workflow Without Code","A practical sequence for building automations that survive: picking the right process, mapping it before touching a tool, and handling the failure cases that break most first attempts.",{"slug":32,"title":33,"excerpt":34,"updated_at":35},"how-to-build-a-chatbot-without-coding","How to Build a Chatbot Without Coding","A practical route to a working chatbot using no-code tools: deciding scope, connecting your own content, handling the questions it cannot answer, and knowing what it will cost.","2026-08-05T14:32:27+00:00",{"slug":37,"title":38,"excerpt":39,"updated_at":40},"how-to-build-an-evaluation-set-that-does-not-go-stale","How to Build an Evaluation Set That Does Not Go Stale","Most evaluation sets are assembled once, from whatever was easy to collect, and then quietly stop representing the work. How to build one from failures you already have, keep it fed from production, protect it from the system it measures, and know when it has expired.","2026-09-09T03:30:02+00:00",{"slug":42,"title":43,"excerpt":44,"updated_at":45},"how-to-change-a-prompt-without-breaking-production","How to Change a Prompt Without Breaking Production","Prompts get edited in a text box and shipped in seconds, which is why they break things quietly: no compiler, no stack trace, no obvious moment of failure. Give them the release discipline code gets.","2026-08-24T03:30:02+00:00"]