Bring your IT partner in before a proposal connects to business systems or introduces access they will need to support. Give them a description of the work and the information involved so they can assess the actual arrangement.
For an occasional use within tools and information rules already approved by the business, those rules may be enough. If the proposal falls outside them, ask before proceeding.
Agree who handles each decision
Decision | Who needs to contribute |
|---|---|
Is the task worth changing? | The person responsible for the work, with advice where useful |
May this information be used? | The business’s information owner and relevant data or contract advisers |
What can the tool read or change? | Whoever manages the systems, together with the supplier |
Who supports it and pauses it? | The business, IT provider and supplier, according to their agreements |
One person or organisation may cover several parts. Some IT providers offer process and AI advice as well as technical support. Check their actual service rather than assuming what they can or cannot do.
I advise businesses on choosing and testing AI uses, so I have a commercial interest in this work. Whoever provides that advice, the people responsible for the business task need to be involved in the choice.
Send a description they can assess
For a fictional proposal, an enquiry could read:
We want to test a tool that drafts replies using our published delivery policy. A colleague will check and send each reply. Initially it would read a dedicated folder and would have no access to email or order records. >Can you help confirm the account and folder permissions, whether the supplier fits our information requirements and who would support the setup? Please identify any work or charges outside our current agreement.
Add the actual product, plan, information types and timing. If the proposal includes customer material or automated actions, say so explicitly.
Settle support before everyday use
Agree who users contact when a draft is wrong, a connection fails or the supplier changes something. A technical support contract may not cover the quality of a model’s answers. The business still needs someone who understands the task.
Record how access can be removed and how work continues if the tool is paused. The handover guide covers that record. A clear agreement at the beginning avoids discovering the gap during a problem.
