Practical guide ·
Our team uses AI: what rules do we need for data and outputs?
Define which tools may be used, what data may enter them and who checks the result before it affects a customer or business decision. Apply those rules to actual use cases. A short policy becomes useful when employees can recognise their task and know the approved way to complete it.
Where do we start without stopping useful work?
Ask teams to name their use cases: drafting replies, analysing contracts, writing code or summarising meetings. For each, record the tool, account type, data involved and where the output goes. A list of software names alone misses the actual risk.
Start with a small group of frequent tasks. If an employee cannot tell whether a document may be uploaded, provide a named escalation route and a workable alternative. An unexplained ban can move the same activity to an account the organisation cannot see.
What data may enter the tool?
Classify the proposed input before use. Public text, internal business material, personal data and credentials require different decisions. Review the actual service terms, account configuration, retention and access arrangements. Do not infer how a business account handles data from a consumer product with a similar name.
Where possible, remove information the task does not need. Replacing a customer’s name is not sufficient if the remaining details still identify them. Never use live credentials as a convenient example in a prompt.
| Task | Check before input | Check before use |
|---|---|---|
| Draft customer reply | No unnecessary customer data | Facts, tone and commitments |
| Compare contracts | Approved handling of confidential text | Original clauses and legal context |
| Suggest code | No secrets; approved repository material | Review and appropriate tests |
| Summarise a meeting | Authority to process the recording | Accuracy and sharing permissions |
Who checks the output?
Assign a reviewer with the competence and time to verify the result. A legal summary needs checked sources and context; generated code needs the appropriate review and testing; a customer message needs factual and confidentiality checks. Clicking “approve” without a basis adds little assurance.
For an illustrative contract comparison, ask the tool to identify candidate differences, then compare them with the original clauses. The authorised person decides what those differences mean. Preserve the approved result and the material checks where the decision warrants a record.
What makes the policy operational?
Name an owner, explain allowed and restricted uses, and provide examples. Train people for the tasks they perform. Article 4 of the EU AI Act concerns AI literacy for providers and deployers; it should not be reduced to purchasing a generic policy document.
Revisit rules when a tool, account setting or use case changes. Record incidents and near misses without discouraging early reporting. The inventory can begin with interviews and supplied records, but should not be described as exhaustive technical discovery.
Explore in detail: Our team uses ChatGPT. What needs to be written down.
How Dyasol can help
Dyasol’s AI use and governance review creates an inventory of identified uses, a risk register and rules for acceptable use and approval. Coverage depends on the agreed interviews, surveys and records.
Sources and context
Examples are illustrative. Practical recommendations should be adapted to the organisation.
General information as of 13 September 2026. Specific obligations depend on the entity, activity and applicable law.