Someone on the team wires up a model over a weekend. Two weeks later there is a working tool that drafts replies, reads supplier documents, or cleans up a reporting process, and people start using it.
Then it reaches someone who asks who owns what it produces, whose data went into it, and whether your customer agreements allow any of this. That is where a surprising number of internal AI projects stop.
The questions are all answerable. They are just far cheaper to answer before launch than after a client asks them first.
Key takeaways
- Work generated entirely by AI, with no meaningful human input, cannot be registered for copyright in the US, and the Supreme Court declined to revisit that position in March 2026.
- Your model provider's terms decide what happens to the data you send, so read the sections on training, retention and confidentiality before anything sensitive goes near the tool.
- Existing customer contracts often already restrict subprocessors, data location and confidentiality, and an internal AI tool can quietly breach all three.
- The EU AI Act's transparency rules under Article 50 have applied since 2 August 2026 and were not caught by the delays announced for high-risk systems.
- Peer feedback from other builders catches practical failure modes long before a formal review does.
The gap between "it works" and "we can ship it"
A prototype only has to work once, for the person who built it. A shipped tool has to work on a bad day, for someone who did not build it, on data it has never seen.
That gap is mostly not a modelling problem. It is a set of questions about ownership, confidentiality and disclosure that nobody assigned to anyone.
The pattern repeats across teams of every size. The build is quick, and the contractual groundwork is what drags.
Who owns what the model produces
Start with the output, because this is where assumptions do the most damage. US copyright law requires human authorship, and the Copyright Office will refuse to register a work it decides a human did not create.
The point was tested and settled. The DC Circuit affirmed on 18 March 2025 that human authorship is a bedrock requirement for copyright registration, and that an AI system cannot be named as the author of a work. The Supreme Court denied certiorari on 2 March 2026, leaving that ruling in place.
Using AI does not by itself sink your claim. Businesses can still protect work created with sufficient human involvement in the direction, prompting or alteration of the result, and registration applications have to disclose which parts were AI-generated.
The practical upshot is a record-keeping habit, not a ban. If the output matters commercially, keep evidence of the human editing and selection that went into it.
What your model provider's terms actually permit
Every AI provider's terms answer four questions, and you need all four before sensitive data goes near the tool. What happens to your inputs, whether they can be used to improve the model, how long they are retained, and who can access them.
Consumer-tier and enterprise-tier terms from the same vendor often answer these differently. A team that tested on a personal account and then deployed on the same account has usually changed its risk profile without noticing.
This is ordinary supplier diligence wearing new clothes. The same ground gets covered by any decent vendor contract risk checklist, and an AI vendor is not exempt from it.
Ask for the data processing terms in writing. If the provider cannot produce them, that is your answer.
The clauses already sitting in your customer contracts
This is the one that catches people. You may have signed agreements that restrict what you are now planning to do, months or years before anyone mentioned AI.
Look for confidentiality wording that limits disclosure to named parties, subprocessor clauses that require notice or approval before you add a new one, and data location commitments. A third-party model provider is usually a new subprocessor, whatever you call it internally.
Some client contracts now also carry explicit AI clauses requiring disclosure or prior consent before AI is used on their work. These are increasingly common in professional services and in public sector agreements.
The work here is unglamorous and quick. Pull the top ten agreements by revenue, search them for confidentiality, subprocessing and data terms, and see what you actually promised.
The transparency rules that already apply
If you have users or customers in the EU, one deadline has already passed. Article 50 of the AI Act has applied since 2 August 2026, and from that date providers and deployers have had to meet its transparency obligations.
A lot of teams filed the AI Act under next year's problem after the delay headlines, which is the wrong read. The high-risk deadlines moved to 2 December 2027 for standalone Annex III systems and 2 August 2028 for AI embedded in regulated products, but the Article 50 transparency duties, including telling people when they are interacting with an AI system, were left on their original schedule.
There is one narrow exception. Systems already on the market before 2 August 2026 have until 2 December 2026 to meet the machine-readable marking requirement for AI-generated content, and content generated before August does not need retroactive labelling.
The enforcement matters too. From 2 August 2026, national authorities and the AI Office can fine breaches of provider and deployer obligations up to EUR 15 million or 3% of total worldwide annual turnover, whichever is higher.
Pressure-test the build before you formalise it
Legal review tells you whether a design is permissible. It will not tell you that your retrieval step silently drops half the document, or that your prompt behaves differently on a Monday because of how the source system exports data.
Those failures show up when people who have built the same thing look at yours. Somebody has already hit the specific wall you are about to hit, and they usually remember exactly how it went.
That is the value of builder communities over general advice. ForumRix runs as a forum for people building with AI, with boards where members post working builds, share tested prompts and give each other feedback on what broke.
Take the boring questions there rather than the exciting ones. How you handle a document the parser cannot read, or what you log when the model refuses, will save more launch pain than a clever prompt.
A short pre-launch check
Run these five before the tool goes past its first users.
Confirm who at your company owns the output and what human contribution is documented. Read the provider's data terms and write down what they permit. Check your top customer agreements for confidentiality, subprocessor and AI clauses.
Then decide what users are told, and write down what happens when the tool gets something wrong. Name a person responsible for that last one, because an unowned failure path is how a small error becomes a contractual one.
The bottom line
The hard part of shipping AI internally is rarely the model. It is that a tool built in a fortnight touches agreements that took months to negotiate.
None of the checks above need a large legal budget. They need someone to sit down with the contracts you already signed, before the tool becomes something you would struggle to switch off.
Frequently asked questions
Can we copyright what our AI tool produces?
Not if it is entirely machine-generated. The US Copyright Office will refuse registration where a human did not create the work, and that position held after the Supreme Court declined to review it in March 2026. Work with meaningful human direction, editing or arrangement can still be registered, but applications must disclose the AI-generated portions.
Do we have to tell customers we are using AI?
In the EU, Article 50 of the AI Act has required transparency about AI interaction and AI-generated content since 2 August 2026. Elsewhere it depends on your own contracts, and a growing number of client agreements now require disclosure or prior consent regardless of local law.
Does sending data to a model provider break our confidentiality obligations?
It can. Confidentiality clauses often limit disclosure to approved parties, and a model provider is usually a new one. Check whether your agreements require notice or consent before adding a subprocessor, and confirm what the provider does with your inputs.
Who is responsible when the tool gets something wrong?
Whoever your contracts say is responsible for the underlying work, which is almost always you rather than the vendor. Most AI provider terms disclaim liability for outputs, so the practical answer is to define a human review step for anything that leaves your organisation.
The opinions on this page are for general information purposes only and do not constitute legal advice on which you should rely.
%20(2).png)
