AI Policy
This is how Wednesday thinks about AI. It is written for two audiences: our own people, and the clients we work with.
The way we use AI does not change with the work. Whether we are solving our own problems or building a solution for a client, we use AI the same way. What changes when the work is for a client is who owns what we build, what data we can touch, and whose governance we work under. So this policy comes in two parts: how we use AI, and what changes when the work is for a client.
Part 1: How we use AI
Treat AI as a teammate
For any piece of work, start by asking what AI can take on. We want it used wherever it helps: research, thinking through a problem, drafting, automations, workflows, reviewing and writing code.
The shift we care about is how you use it. Treat AI as a teammate, not a co-pilot. A co-pilot sits beside you and waits to be told what to do. A teammate takes a goal and works toward it. The job is not to tell it what to code. The job is to give it the goal, let it get there, and then judge what comes back.
One common case: when you notice yourself doing the same thing again and again, hand it to an agent that runs on its own, without needing your time. That is one example. The same habit applies everywhere. You set the goal and let AI work out how to reach it.
This does not remove your judgment. You still own what you ship. Do not pass something on because a model produced it.
The tools we use
We are a Claude-focused company. Everyone gets a Claude account, standard or Max, depending on what the work needs. That is the tool we standardize on and support.
We also want you using other tools. If something helps you do better work, use it, and tell people what worked. What matters more than the tool is what you put into it, which the data rules below cover.
Devices and accounts
Work happens on company devices and through company accounts. We do not use personal accounts or personal devices for work. That is what keeps our work observable and within our control, which is what the next two sections depend on.
Everything goes through the gateway
Whenever we use a frontier model or an LLM, every agent that talks to that model goes through a gateway. The gateway holds the policies that match the compliance and governance rules of whoever we are working with. It keeps the traffic observable, compliant, and governed. Agents reach models through the gateway, not around it.
What data can go where
What you put into a tool matters more than which tool it is. So we sort data into four tiers. The only question each tier answers is where that data is allowed to go.
Tier | What it is | Where it can go |
|---|---|---|
Public | Already public: published content, marketing, open source | Any approved AI tool |
Wednesday internal | Our own non-public information and our own IP | Approved tools and our gateway. Never personal or free accounts |
Client confidential | Non-public client information that is not personal or regulated | Only through the gateway, under the client's governance, with sign-off |
Client regulated | Personal data, regulated data, and production data | Only where the client's governance allows it, through the gateway, with sign-off. Never anywhere ungoverned |
When you are not sure which tier something is, treat it as the stricter one. Get sign-off first, before any client data goes into a tool.
You own the result
The person owns the outcome of their work, whatever tools they used. "The AI did it" is not a defense. If your name is on the work, you are answerable for it.
The bar the work has to meet
AI-assisted or not, the work has to clear the same bar. Across the company we hold to things like DORA consistency and our shared programming conventions. Each project can add its own on top: a particular tech stack, its own conventions, its own review rules. Both the company bar and the project bar apply.
On some client projects we do not have central visibility, because we are inside their access controls or on their laptops. The same standards still apply there. Those teams track their own metrics and run their own NPS by reaching out to their customers.
Experiment, and share what you find
We want people trying things and saying out loud what worked and what did not. Bring the wins so others can copy them, and bring the failures so others can avoid them. This is how a better way of working spreads across the company.
We have built our own agents this way. Share what you learn so everyone gets the benefit.
Part 2: When the work is for a client
On a client project
When we are on a client project, working from their office or their premises or inside their systems, their governance rules and their systems are the ones we follow. If they give us their laptops, we use them. If they put a wall around their code and their access, we work within it. Their rules come first.
Who owns what we build
When we build agents, workflows, or automations for ourselves, that IP is ours. When we build a solution to a problem that shows up across BFSI companies, that IP is ours too.
When we put our solutions to work with a client, we work in one of two ways.
- The client brings a problem we do not yet have a solution for. We build it at our own cost, deploy it with them, and charge a fee that depends on the arrangement.
- We take a solution we already have and integrate it into their stack to get them the result they are after. From there they can buy the IP from us, or leave it with us to retain, maintain, and manage for them. Both are fine.
Whose rules govern the source code
This follows the IP. If the IP is ours, our gateway governs the source code and how it is handled. If the IP is not ours, and especially when it was written for the client, their rules apply.
When something goes wrong
Mistakes will happen, and we would rather handle them clearly than pretend they will not. There are two kinds, and we treat them differently.
The first is an honest mistake, most often while experimenting on our own work. This is expected. You fix it, log it, and tell the team so no one walks into the same thing. We do not punish it. If experimenting carried a penalty, people would stop experimenting.
The second touches client data or client governance: client data put into an ungoverned tool, an agent run around the gateway, a client's rules ignored. This is serious, because the whole business rests on that trust. The response depends on how bad it was and whether it was careless or deliberate. A genuine slip gets coaching and a fix. Negligence, a repeat, or deliberate misuse can lead to losing access, formal action, and in the worst cases the end of someone's time here. Where a contract or a regulator requires it, we contain the issue and tell the client.
Three things hold in every case. Report it quickly, and people who flag their own mistakes are not penalized for doing so. The person owns the outcome. And every incident is logged, which the gateway already makes possible. The same response applies to everyone, and it is written down.
We review this policy at least once a year, and sooner when the tools or the rules around us change.