AI usage assessment
We will find every place a model touches your product, read the terms that actually govern each one, and tell you what that use commits you to and what you can prove.
When you need an AI usage assessment

A customer asked how you use AI
A questionnaire arrived asking about models, training data and human review. Once signed, the answer binds you like a contract term, so it has to match what the team does.
Your team adopted tools on its own
Design, engineering and support each picked a service and paid by card. Nobody holds the list, and nobody opened the terms attached to any of them.
No record of what the model made
Generated code, art or text shipped inside something you now sell. Nobody recorded which tool made it, on which plan, or what a person changed afterwards.
You are raising money or selling
A buyer’s questions go straight to how the product was built. An answer you cannot show in documents is the one they will ask you to warrant.
Confidential material went into a prompt
Client data or unreleased work was pasted into a tool. What happened to it next is set by terms nobody opened at the time.
What you get
- A map of every tool
- The terms that actually apply
- Where your record is missing
- Gaps ranked by exposure
- Answers you can give buyers
What an AI usage assessment covers

The assessment answers one question about every place a model touches your work: what did you agree to, and what can you show. The tools themselves are quick to list.
The terms behind them, and the record of what went in and what came out, are what decide your position. Where the question is who owns an asset and whether the chain of title holds, that is an intellectual property audit.
What you send us
- The tools in use, and the accounts and cards they are paid from.
- The plan each one is on: a free tier and a paid tier can differ on training and retention.
- What the product ships: generated code, art, text, voice or translation, and where each sits.
- What you have told customers in contracts, published terms and answered questionnaires.
What we look at
- Inputs: what reaches a model, whose it is, and whether anyone was promised it would not.
- Outputs: what the terms let you sell, sublicense or register, and on which plan.
- Retention and training: whether material is kept, and whether it feeds a model you do not control.
- Human involvement: who reviewed, changed and approved generated material, and what proves it.
Where exposure builds
- A publishing or platform agreement that bans generated material, signed before the team began using it.
- A confidentiality promise in a client contract, against a tool that keeps what it is sent.
- A warranty that the product is original, given while part of it was generated.
- A free tier running in production, on terms that differ from the paid one you were shown.
- A questionnaire answered from memory, which becomes a binding statement once signed.
What lands in the report
- Every tool, what it is used for, and the terms that actually govern that use.
- Each gap, what it costs if it goes wrong, and how soon it has to close.
- The answers you can give a buyer, each with the document that supports it.
- A short set of rules for the team, where you want one.
Sources: under article 2 of the Copyright Treaty of the World Intellectual Property Organization, copyright protection extends to expressions and not to ideas, procedures, methods of operation or mathematical concepts as such. Whether generated material is protected at all is decided by the country.
Stages of work
Starting from the tools you name — 2–3 working days.
You give us the tools in use; we will tell you where that list is thin, because the exposure sits in the ones nobody wrote down.
It dates quickly, so it comes with the places to look when you rebuild it yourself.
Reading the terms behind each tool.
We will read the terms for the plan you are actually on, including what they say about training, retention and commercial use of the output.
Terms change, and the version that binds you is the one in force when the material was made. We will record which version we read and on what date.
Following the data that goes in.
We will trace what reaches each tool: client material, personal data, unreleased work and code that arrived under someone else’s licence.
Each is checked against what was promised to the person it came from. A promise made in one contract becomes an exposure in a tool nobody connected to it.
Following what comes out into the product.
We will follow generated material to the place it ships and check that the rights you sell downstream are rights the terms actually give you.
Where a person shaped the result, we will make sure something records it. That difference matters on the day the material has to be defended.
Checking what you promised others.
Contracts, published terms, security questionnaires and marketing pages all make statements about how the product is built.
We will line them up against what the assessment found and mark every place where the two do not agree, starting with the ones already signed.
The findings, ranked by exposure.
You get one document: what is in use, what governs it, what is missing, and what it would take to close each gap.
Ranking is by what it costs if it goes wrong and how soon it could, so the first few items are the ones to close first.
Rules the team can actually follow.
Where you want one, it ends in a short set of rules: which tools are approved, what may go into them, and what has to be written down each time.
Our other work for studios and publishers sits in the Publishing & Gamedev area.
Our case studies
FAQ
It is a review of how artificial intelligence is used inside your company and what each use commits you to. We start from the tools you name, read the terms of the plan you are on, and trace what goes into each tool and what comes out into the product. The result is a map, gaps ranked by exposure, and the answers you can give a customer or a buyer with a document behind each. It looks at use and does not decide who owns an asset.
Two questions decide it. The terms of the tool say what you may do with the output, and depending on the plan they hand you broad rights or keep some back. Whether the output is protected at all is decided by the country, and countries answer differently: some ask what a person contributed, some name an author by rule, some refuse protection where no person authored it. Until you know which answer is yours, treat generated material as unprotected and record what a person contributed while it is fresh.
That depends on two documents, and both have to be read together. The client contract says what you promised about confidentiality, subprocessors and where material may go. The tool terms say whether what you send is retained, reviewed by people, or used to train a model. Where the two conflict, the promise in the client contract is the one you will be held to, and the conflict stays invisible until someone asks. Where the contract is silent, the honest answer is to ask the client before the material moves.
They ask which tools were used, on what data, under which plan, and what part of the shipped product came out of a model. They ask what you told your own customers, and whether the two answers agree. Then they ask for the documents. An answer given from memory and an answer supported by a record are worth different amounts in a negotiation, because the second one does not turn into a warranty the seller carries afterwards. This is the gap the assessment is built to close.
Discuss
the Task
Speak to our team
Speak to our team. Tell us about your task –
we’ll help you with it in any jurisdiction.
