Governance

AI Usage Policy

Version 2.0 · Last updated: 3 May 2026

This policy explains how BuiltByGo Ltd uses artificial intelligence (AI) tools in our work, the safeguards we apply to protect client data and intellectual property, and the contractual mechanisms by which we hold ourselves accountable to those safeguards.

We publish this policy in detail because AI use in agency settings is a real procurement question, and we'd rather pre-empt it than answer it differently for each client.

Our position

We use AI tools — including large language models, code-generation assistants, AI-powered testing, and AI-assisted research — to improve efficiency, quality, and consistency in our development work. AI is a tool that augments our team's expertise. It does not replace human judgement, oversight, or accountability for any client deliverable.

Every decision affecting a client's project, data, brand, or commercial interests is made by a human team member with the experience and authority to make it. AI tools accelerate the work; they do not own it.

Tools we use

We list our AI tools openly because transparency is the right default and because our clients' procurement teams will ask.

Core tools

Excluded tools

We do not use AI tools that would compromise our data protection commitments:

• We do not use Claude.ai consumer tier (Free / Pro) for any work involving client information; client work runs through the Commercial API
• We do not use AI tools that train on user inputs by default and lack an enforceable opt-out
• We do not use AI-powered content scrapers, screen-recorders, or session-replay tools on client sites without explicit consent

Operational rules

Rule 1: No production personal data to AI APIs without prior anonymisation

This is the operational core of our policy. Production personal data — names, contact details, transactional records, user-submitted content, broker data, customer data — is never passed to AI APIs without prior anonymisation, regardless of the AI tool's training or retention policies.

This applies to:

• Database queries via AI-assisted tools (e.g. via MCP integrations connected to production databases)
• Code-generation prompts that would otherwise include real user records
• Debugging sessions, log analysis, and incident investigations
• Documentation and technical writing

When real production data is needed for legitimate technical work, it is first anonymised, pseudonymised, or replaced with synthetic test data.

Rule 2: AI tools as conditional sub-processors

We list our AI tools as conditional sub-processors in our Sub-processors register. This means:

• We disclose them as part of our standard sub-processor disclosure
• Their use is governed by Rule 1 (anonymisation) — they only "process" personal data in the legally relevant sense if Rule 1 is breached
• New AI tools require client approval before being added, on the same 30-day notice / 14-day objection cycle as any other sub-processor

We chose this position deliberately. Most agencies don't disclose AI sub-processors at all. We think the right answer is disclosure with clear operational policy.

Rule 3: Read-only credentials by default

Where AI tools are connected to production systems via integrations such as MCP, the credentials provided to those tools are read-only unless write access is explicitly required for a specific task and approved by a senior team member. Production write/delete operations via AI-mediated channels require human-in-the-loop approval at the time of execution.

Rule 4: Human review of all AI-generated output

All AI-generated code, content, configuration, or analysis is reviewed by a qualified team member before being incorporated into client deliverables, deployed to production, or shared with the client. Our team retains full responsibility for the quality, security, and correctness of all work product.

Rule 5: No client source code to public AI services

We do not submit client source code to public AI services (defined as services that are not running under the same Commercial Terms / DPA as our core tooling) without explicit client permission documented in the Statement of Work.

Rule 6: AI is not a decision-maker

AI tools do not make decisions affecting client projects, data, contracts, or commercial relationships. AI assists humans who decide. This is non-negotiable.

Rule 7: Client opt-out

If a client engagement requires that BuiltByGo not use AI tools at all in connection with their work, this can be specified in the Statement of Work and we will operate without AI assistance for that engagement.

What we don't do

To make Rule 1 concrete, here are specific things we do not do:

• We do not run “show me all contact form submissions from last week” prompts against AI tools connected to production data
• We do not paste real customer email addresses, names, or transactional records into AI prompts for debugging
• We do not allow AI-assisted tooling to autonomously query production databases for real records during testing or development
• We do not use AI tools that train on client confidential information (under our chosen tools' Commercial Terms, training on inputs is contractually prohibited; we do not use tools without that protection)
• We do not generate client-facing content (proposals, contracts, emails, deliverables) without human review and approval

Why our position is what it is

The risk we're managing

Modern AI tools, when integrated into developer workflows via APIs and MCP-style integrations, can be powerful but also become a vector for inadvertent data exposure. A developer asking a connected AI assistant a casual question like “what's the latest activity for user X?” can, in a poorly-governed setup, cause real production data to flow to an AI provider as part of the prompt.

That data flow constitutes processing under GDPR. Without operational controls, it makes the AI provider an undisclosed sub-processor. That's the failure mode we're protecting against.

The choice

Two extreme positions exist: (a) ban AI tools entirely (loses real productivity benefit, doesn't reflect modern development reality), or (b) use them freely (creates the risk above). Neither is the right answer.

Our position is the middle ground: use AI tools openly, with named tools, governed by an enforceable operational policy that prohibits the failure mode.

Transparency and review

Client questions

If you have questions about how AI is used on your project, ask. We're happy to discuss specific practices and adjust them where reasonable to meet your requirements.

Annual review

This policy is reviewed at least annually and on material change to AI tooling, regulation, or our operational practices.

Procurement evidence

Procurement teams evaluating BuiltByGo can request:

• A list of AI tools currently in use (current state, not aspirational)
• Confirmation of training/retention settings on each tool
• Anonymisation policy operationalised in writing
• Worked examples of how a typical task involving production data is handled

Contact privacy@builtbygo.com.

Document history

Contact

• AI usage and policy questions: privacy@builtbygo.com
• General enquiries: hello@builtbygo.com