1. Purpose and scope
This policy covers every use of artificial intelligence by Bots & Pieces: AI used to run our own business, AI used while delivering work for a client, and AI built into a system we deliver to a client. It applies to Jacob Roberts and to any subcontractor.
2. The principles we work to
- A human stays accountable. AI does not carry responsibility, and no output is treated as a decision on its own.
- The client owns their data and decides what may be done with it. Silence is not approval.
- Nothing goes into an AI service that the client has not agreed can go there.
- Every AI system we deliver has a defined purpose, defined users, defined inputs and a defined failure behaviour, written down before it is built.
- Where a user is dealing with an AI output, they are told so.
- A system that cannot be tested is not put into production.
- If we cannot explain how a system reaches its output well enough for the client to check it, we say so plainly rather than papering over it.
3. Risk tiers
Every proposed AI use is placed in a tier before work starts. The tier decides what approvals, testing and oversight are required.
| Tier | Examples | What is required |
|---|---|---|
| Low | Drafting internal text, summarising a public document, generating code that a person reviews, formatting or classifying non-personal business data. | No client approval needed for our own internal use. Normal review of output. |
| Medium | Working with client business data, summarising client documents, drafting client-facing content, building an assistant used by client staff. | Named in the statement of work. Client written approval of the tools and data. Documented testing. Human review before anything is acted on. |
| High | Anything touching personal information, anything a customer interacts with directly, anything that triggers an action in a live business system, anything feeding a decision about a person. | All of the above, plus a written risk assessment, defined human review at the decision point, a tested fallback, and client sign-off on the risk assessment before build. |
| Prohibited | See clause 8. | Not built. Declined in writing. |
4. Approved tools
- Every AI service used with business or client information is listed in the Approved Tools Register, with what it is used for, what data it may see, where that data is processed and what the provider’s terms say about training.
- A tool not on the register is not used with client information. Adding one is a deliberate decision, made before use.
- A provider’s terms are re-checked at least annually and whenever the provider announces a change, because a setting that was safe last year may not be now.
- A free or consumer tier is treated as unapproved by default, because those tiers most often reserve the right to train on input.
5. What may and may not go into an AI service
| Data | Position |
|---|---|
| Public information | Fine, in any approved tool. |
| Our own business information | Fine, in an approved tool with training turned off. |
| Client business information | Only where the engagement documents permit it, the client has approved the specific provider in writing, and training is off. |
| Personal information | Only where clause 3 tier High has been worked through, the client has approved it in writing, and the provider is contractually suitable. Minimise or de-identify first wherever the work still functions. |
| Sensitive information | Not without specific legal advice and specific written client approval. Default position is no. |
| Credentials, tokens, API keys | Never, in any tool, in any tier, under any approval. |
| Payment card numbers, identity documents | Never. |
Before sending anything, the provider’s data controls are checked and set: training or model improvement off, retention set to the shortest available, and region set to Australia where the provider offers it.
6. Human oversight
- Every AI system we deliver has a named point where a person reviews before anything irreversible happens.
- An AI output is never the sole basis for a legal, employment, credit, health, safety or other high-impact decision. This is also a term of our client agreement.
- The client is told, in writing, where the human review point is and who is expected to staff it.
- Where a system takes an action automatically, the action is reversible, logged, and bounded by limits agreed with the client in advance.
7. Testing before production
- Write down what the system is for, who uses it, what goes in, what comes out and what it must never do.
- Test normal cases, edge cases and failure cases, using representative data rather than a single happy path.
- Test what happens when the model is unavailable, slow, or returns nonsense, and confirm the fallback works.
- Check the output for obvious bias or unfairness where the system touches people.
- Record the tests, the results and any known limitation in the client project file, and tell the client the limitations before acceptance.
- Do not put a system into production with a known material limitation the client has not been told about in writing.
8. Prohibited uses
We do not build, and we do not use AI for, any of the following. A request for one of these is declined in writing.
- Deciding a person’s employment, credit, housing, insurance, health care or legal position without a human decision-maker who can override it.
- Biometric identification or emotion inference about people.
- Producing content designed to impersonate a real person or organisation.
- Generating fake reviews, fake records, fake receipts or anything intended to be passed off as genuine.
- Scraping personal information from the web to build a profile of somebody.
- Surveillance of staff beyond what the client can lawfully do and has told its staff about.
- Anything designed to evade a legal obligation, a regulator or a security control.
- Anything unlawful, or anything we judge would harm a person even if it is lawful.
9. Telling people they are dealing with AI
- Where a customer or member of the public interacts with an AI system we built, the system says so.
- Where an AI output goes to a person as advice, information or a draft, the limitations are made visible where it is practical to do so.
- Where our own marketing shows AI-generated material, we do not present it as a real client record or a real photograph of a real person.
10. Records to keep for every AI system delivered
- The purpose, users, inputs and outputs, written down.
- The risk tier and, for High, the written risk assessment and client sign-off.
- The providers and models used, and where they process data.
- The client’s written approval of the data and the providers.
- The provider settings applied, including the training setting.
- The test evidence and the known limitations.
- The human review point and who staffs it.
- The fallback and how to invoke it.
- The entry in the AI System Register.
11. When an AI system goes wrong
- Stop the automated action and switch to the fallback or manual process.
- Tell the client what happened, what it affected and what the fallback is.
- Work out whether any information was exposed. If it was, the Data Breach Response Plan takes over.
- Establish whether a wrong output was acted on, and help the client work out what to correct.
- Record it in the Incident Register, fix the cause, and re-test before turning the system back on.
12. Review
This policy is reviewed at least once a year, next on 1 September 2027, and whenever a provider materially changes its terms, a new class of AI capability enters our work, or Australian AI regulation changes. The Australian Government’s Voluntary AI Safety Standard is the benchmark we check ourselves against.
This document was prepared without legal advice. Have an Australian commercial lawyer review it before relying on it for high value, regulated or sensitive-data work.
See also the Privacy Policy, which covers personal information specifically, and the Master Services Agreement, whose clause 6 makes several of these positions contractual.
Websites, apps and automations. Custom-built for you, supported for life.