You’ve got a contractor building your product. You’ve got an AI feature that improves on something already on the market. And you’ve got questions nobody at your last job prepared you to answer. Here’s a second batch of the questions I hear most often from founders building software and AI products, along with straight answers on what actually matters.
My contractor built our platform. Do we own it?
Maybe not. This is one of the most common gaps I see, and it’s almost always invisible until it matters.
Under copyright law, the person who writes the code owns it by default, unless there’s a written agreement transferring that ownership to you. 17 USCS § 201. “Work for hire” isn’t automatic just because you paid someone. For independent contractors specifically, work-for-hire status generally requires a signed agreement stating the work qualifies, and even then, it may not cover everything you’d expect. Cmty. for Creative Non-Violence v. Reid, 490 U.S. 730, 732 (1989), Nationwide Mut. Ins. Co. v. Darden, 503 U.S. 318, 323 (1992). Patent rights work differently but carry the same risk. Whoever conceived the invention is generally the inventor unless there’s an assignment agreement transferring those rights to your company. 35 USCS § 115, 35 USCS § 261.
The fix is a contractor agreement executed before work begins, with clear IP assignment language covering both copyright and any potential patent rights. If you already have contractors working without one, the fix is still available, but it depends on getting their signature on an assignment now. Whether older work is covered depends on how that engagement was documented at the time.
We built an AI feature on top of someone else’s model. Is that ours to protect?
This is where founders get tripped up by an all-or-nothing instinct. The underlying model you’re building on, whether it’s an open-source foundation model or a commercial API, generally isn’t yours to claim. But that doesn’t mean nothing you built is protectable.
What matters is what you added: the specific technical problem you solved, the way you structured inputs and outputs, the workflow that makes the tool useful for your particular use case, or the architecture connecting your system to the underlying model. Protection questions turn on what’s new and non-obvious about your contribution, not on whether you used AI at all. 35 USCS § 102, 35 USCS § 103.
The practical exercise: write down what your engineers actually built that didn’t exist before they built it. If the answer is a thin interface calling an existing API with no meaningful technical modification, that’s a different conversation than if the answer involves a genuinely new processing method or system architecture.
Is a chatbot with our data actually an invention, or just a wrapper?
This question comes up constantly, and it deserves a direct answer: it depends entirely on what’s underneath the label “chatbot.” A tool that takes a general-purpose language model and points it at your company’s documents, with no other technical innovation, is likely to be viewed as an application of existing technology rather than a new invention. That doesn’t make it worthless as a business asset, but it changes what kind of legal protection is realistic.
What can shift that analysis: a novel method for structuring or retrieving the underlying data, a new way of validating or filtering outputs for accuracy, an architecture that solves a specific technical problem in your industry, or a training or fine-tuning approach that produces measurably different results than off-the-shelf alternatives. The label “AI-powered” tells you nothing. The technical substance underneath it tells you everything.
One of our engineers left. Can they take the code with them?
This is where the contractor question above becomes urgent for employees too, just under a different legal framework. In most states, work created by an employee within the scope of their employment belongs to the employer automatically, without a separate assignment agreement. 17 USCS § 201. But “scope of employment” has boundaries, and disputes often arise over work built on personal time, on personal equipment, or before formal employment began.
A written invention assignment agreement, signed at the start of employment, removes the ambiguity. Without one, you may be relying on default rules that vary by state and by the specific facts of how and when the work was created.
Where this leaves you
Every one of these questions traces back to the same underlying issue: paperwork that should have existed before the work started, and a habit of assuming ownership follows payment. It doesn’t. Ownership follows documentation. If you’re building software or AI features and you’re not sure whether your contractor agreements, employee agreements, or IP assignments actually cover what you think they cover, that’s worth a conversation before it becomes a dispute. What’s the gap in your own documentation you’ve been meaning to close? I’d be glad to talk through it.
About Garcia-Zamor: We’re the fractional general counsel for innovators, protecting both your business operations and your intellectual property. Ruy Garcia-Zamor leads business growth strategy as a registered U.S. Patent and Trademark Office patent attorney, Elliott Alderman (40+ years experience) handles intellectual property, Claudia Castillo focuses on employment law, and Amulya Annasamudram (registered U.S. Patent and Trademark Office patent attorney) focuses on patents and intellectual property. Contact us at garcia-zamor.com or (410) 531-9853.
