AI
Policy.

01Why this policy exists

Most AI policies are written by companies that bought some AI. Ours is written by a company that builds it, which means the questions we get are sharper: what goes into the model, who is liable when it is wrong, and what happens to our code and data.

This policy answers those questions. It applies to how we use AI internally, to the AI systems we design and build for clients, and to the AI features in the products we run ourselves — currently Partyyy at partyyy.party, which publishes its own AI policy covering the detail. It forms part of our Terms of Service.

02The principles we work to

• A person is always accountable. An AI system is a tool. Responsibility for what it produces sits with the humans who deployed it — us, during delivery, and you, once it is live.
• Be honest about what it is. Nobody interacting with a system we build should be misled into thinking they are talking to a person when they are not.
• Use the least data that works. More context is not automatically better, and every extra field is extra exposure.
• Fit for the actual purpose. A demo that impresses is not the same as a system that holds up on the tail of real traffic. We build and measure for the second.
• Proportionate to the stakes. A tool that drafts internal summaries and a tool that touches customer money deserve very different guardrails.

03How we use AI in our own delivery

We use AI tools in our work — coding assistants and agents, drafting and research support, analysis of documentation and data. It is part of how we deliver quickly.

Two rules govern it:

• A human reviews everything before it reaches you. Code, documents, analysis and recommendations are checked by the person responsible for them. We do not forward unreviewed model output as our work.
• We are responsible for it either way. “The AI wrote it” is not a defence, and we will never offer it as one. Our obligations under the Terms apply to AI-assisted work exactly as they do to everything else.

If you would prefer us not to use AI tools on your engagement, or to restrict which ones, tell us and we will agree it in the statement of work.

04Your data and model providers

This is the part most clients want in writing.

• No client data in consumer AI tools. Confidential material, personal data, credentials and proprietary code do not go into free or personal-tier chatbots.
• Business and API tiers only, chosen for their data handling terms: no training on submitted content, limited retention, and a data processing agreement in place.
• Your accounts, if you prefer. Where you would rather everything ran through your own provider accounts, keys and tenancy, we will work that way, and it is often the cleanest answer for regulated environments.
• Secrets never go in a prompt. Credentials, keys and tokens are handled through a secret store, not pasted into a model context.
• Redaction before submission. Where a task genuinely needs realistic data, we pseudonymise or mask it first, in line with our GDPR statement.

The specific providers used on an engagement are disclosed and agreed as subprocessors — see section 6 of the GDPR statement — and we will tell you before that list changes.

05We do not train on your data

If a project's own purpose is to fine-tune or train a model on your data, that is different — it is your model, trained on your data, for your purposes, under a scope, lawful basis and retention period agreed in writing before any training begins.

Our own products are a separate case

The commitment above is about client data, and it is absolute. Our own products are a different situation, and it would be misleading to let that sentence imply otherwise.

Partyyy includes machine-learning features — suggesting who might get on at a table, for instance — and those models are trained on data from inside Partyyy itself. The model is ours, it runs inside the product, it is used only to make that product work, and it is never shared, sold, or used to train anyone else's foundation models. Client engagement data never enters it. Where these features involve profiling individuals, Partyyy's own AI policy and GDPR statement set out what that means and how to object.

06Human oversight

How much oversight a system needs depends on what it can do:

Informational output

Drafts, summaries, suggestions. The human using it is the check. We design output to be easy to verify, with sources or citations where practical.

Consequential decisions

Anything affecting a person's rights, money, employment or access to a service gets meaningful human review — a real decision, with the authority and information to overturn the system, not a rubber stamp.

Agentic actions

Where a system takes actions through tools, irreversible or outward-facing ones — sending, publishing, paying, deleting — require explicit approval unless you have consciously accepted the risk and we have agreed limits and a rollback path.

We build in an off switch: every system we deliver can be disabled, rate-limited or rolled back without a redeploy.

07What AI cannot do, and we will not pretend otherwise

Large language models are probabilistic. They can produce fluent output that is wrong, invent facts and citations, reflect biases in their training data, behave differently on identical input, and degrade when a provider updates a model underneath you.

What follows from that:

• output from a system we build is not legal, medical, financial or other professional advice, and should not be presented to end users as if it were;
• we do not warrant that any AI system will be accurate, complete or error-free — for client work the warranties are the ones in the agreement we signed, and for our own products they are in that product's terms;
• accuracy is measured against agreed acceptance criteria on a defined evaluation set, not asserted;
• where being wrong is expensive, we will tell you where the failure modes are and design around them, or say the approach is a poor fit.

We would rather lose a piece of work than build something we think will fail quietly in production.

08Evaluation and testing

Systems we deliver come with the means to tell whether they still work:

• an evaluation set built from real cases, including awkward and adversarial ones, not just the happy path;
• measurable acceptance criteria agreed with you before build;
• regression runs when prompts, models, tools or data change;
• latency and cost budgets, measured rather than estimated;
• monitoring and logging in production, so drift and degradation are visible;
• guardrails — input validation, output checks, refusal handling, rate limits — sized to the risk.

Model providers deprecate and update models. We will flag version pinning and an upgrade path as part of design, so a provider's release note is not your outage.

09Bias, fairness and accessibility

Models reflect their training data, and a system can produce systematically worse outcomes for some groups without anyone intending it. Where a system touches people — hiring, lending, eligibility, support triage, content moderation — we test for disparate outcomes across relevant groups as part of evaluation, and document what we found and what we did about it.

We will tell you plainly where a limitation cannot be engineered away, so you can decide whether the use case is appropriate at all. We also build interfaces to normal accessibility standards; an AI feature is not an excuse for an inaccessible one.

10Telling people they are using AI

We recommend, and will design for, clear disclosure to end users that they are interacting with an AI system — including what it can and cannot do, how to reach a human, and how their input is used and retained. In several jurisdictions this is becoming a legal requirement rather than good manners.

We will not build a system whose purpose is to deceive people into believing they are dealing with a human, or to impersonate a real, identifiable individual without that person's clear consent.

11Security of AI systems

AI systems have their own attack surface, and we treat it as such:

• Prompt injection. Content retrieved from documents, web pages, emails or tool results is data, not instructions. Systems we build are designed on that assumption, with untrusted content kept away from privileged actions.
• Tool permissioning. Agents get the narrowest set of tools and scopes that does the job, with destructive operations gated.
• Output validation. Model output that reaches a database, a shell, a browser or another system is validated and escaped like any other untrusted input.
• Data leakage. Retrieval respects the requesting user's permissions — a chat interface must not become a way around your access controls.
• Abuse and cost. Rate limiting, spend caps and alerting, so a loop or an attacker cannot run up an unbounded bill.
• Logging. Prompt and output logging is configured deliberately, with retention and redaction agreed, because those logs often contain the most sensitive data in the system.

12Intellectual property in AI-assisted work

Ownership of deliverables is dealt with in the agreement we sign for an engagement, and AI-assisted work is treated there the same as any other. Two points specific to AI are worth stating:

• Open-source licences still apply. Where an assistant reproduces material subject to an open-source licence, that licence governs it. We use tooling and review to catch this, and will tell you about any component with licence obligations attached.
• Copyright in purely machine-generated output is unsettled in several jurisdictions. We assign what can be assigned and licence the rest, so you can use the deliverable as intended regardless of how that question is eventually resolved.

13Regulation

AI regulation is moving. Our approach is to build systems that will survive it rather than chase each change:

• Data protection. UK and EU GDPR apply to AI like anything else — lawful basis, transparency, minimisation, and the Article 22 restrictions on solely automated decisions with legal or similarly significant effects. See our GDPR statement.
• EU AI Act. Where a system falls in scope, we will help you work out its risk classification and what that means — documentation, logging, human oversight, transparency — and build accordingly. Classification and the obligations that follow are ultimately the deployer's or provider's call, and we will tell you which one we think you are.
• Sector rules. Financial services, healthcare, legal and public sector work carry their own requirements. Tell us which apply and we will design to them; we do not assume our reading of your regulator beats yours.

None of this is legal advice. We build to the requirements you and your advisers identify.

14What we need from you

• Tell us the real use case, including the awkward edge cases and who is affected by a wrong answer.
• Make sure you have the rights and a lawful basis for the data you give us and for the use case itself.
• Own the final decisions the system informs — particularly where they affect people.
• Keep monitoring after handover. Evaluation is not a one-off; models, data and users all move.
• Tell us if you plan to use a deliverable for something materially different from what it was built and tested for.

15Raising a concern

If you think a system we built is behaving unsafely, unfairly or unexpectedly, tell us at hello ( at ) antcodelabs.ai with “AI concern” in the subject line. We will acknowledge it within one working day and agree containment steps with you before working out the fix.

The same address works for questions about this policy. We would rather hear about it early.

16Changes to this policy

AI practice changes quickly and this policy will change with it. The date at the top shows when it last did. Where a change materially affects a live engagement, we will tell you rather than rely on you noticing.