A Miami company using artificial intelligence may have several valuable assets at once: a technical implementation, software, training material, a distinctive product identity, and confidential operating knowledge. Calling all of them AI intellectual property obscures the decisions that matter. Each asset has different evidence requirements, different ownership questions, and different risks when shared with customers or vendors.

This article combines current agency guidance with computer-security research and an original asset analysis. The examples are hypothetical Miami businesses, not reported client matters. The objective is to help founders organize a professional review without assuming that using AI either eliminates intellectual property protection or automatically creates it.

The inventorship guidance changed

On November 26, 2025, the USPTO issued revised guidance that rescinded its February 2024 AI inventorship guidance. It states that the same inventorship standard applies whether or not AI tools were used, and only natural persons can be named inventors. Older explainers should therefore be checked against the current guidance.

The practical question is what the humans conceived, not whether a project contains an AI component. Our documentation recommendation is to record the technical problem, the alternatives considered, the decisions each contributor made, and the evidence supporting the resulting implementation. A tool log can supplement that record, but a pile of prompts is not a complete account of the invention.

Inventorship is also separate from ownership and patentability. A company should ask counsel who the inventors are, how rights reach the business, and whether the claimed subject matter satisfies the applicable requirements. A favorable answer to one question does not settle the others. Keep those conclusions separate in internal presentations and investor materials.

Copyright asks about human expression

The Copyright Office’s January 2025 report announcement explains that AI-assisted material can contain protectable human authorship. Human creative arrangement or modification may matter, while merely providing prompts is insufficient by itself. This concerns expressive authorship; it is not the same test as patent inventorship.

For a Miami design studio building an interactive exhibit, preserve the human-authored script, edits, compositions, and selection decisions. For a software team, preserve code history and contributor records. The useful question is which expressive elements a human actually determined. Do not promise a customer exclusive ownership of every generated pixel simply because the company paid for an AI subscription.

Our original five-layer analysis

Consider a hypothetical Miami startup that helps warehouses interpret images from loading docks. We divided its offering into five layers and assigned a distinct review question to each. This is an original analytical exercise, not a claim that any particular implementation is patentable or that all companies have exactly five assets.

The comparison reveals an important dependency. A team might have a plausible technical invention yet lack permission to reuse customer images for training. It might own code while relying on a model license with distribution restrictions. These are hypothetical possibilities, not findings about any vendor. A single statement that the company owns its AI does not answer them.

Our suggested review order follows the next business event. Before a pilot, focus on data access and permitted uses. Before a public technical presentation, assess disclosure and filing questions. Before promising a customer exclusivity, inspect the rights the company actually controls. This sequence is a planning tool and should be adjusted to real deadlines.

What memorization research does and does not prove

In Extracting Training Data from Large Language Models, Carlini and colleagues demonstrated recovery of hundreds of verbatim training sequences from GPT-2. The 2021 USENIX study is evidence that memorization and extraction can occur under the studied conditions. It does not establish that every current model, enterprise contract, or deployment exposes confidential input.

Our business inference is narrower than a blanket warning against AI: inspect the actual system. Determine whether submitted material is retained, used for training, accessible to other users, or handled by subprocessors. Ask for documented settings and contractual terms. A vendor’s general marketing description should not substitute for the configuration your team is using.

For sensitive invention material, create an approved route for tool use before employees improvise one. A workflow can specify which tools are permitted, which material requires review, and who can authorize exceptions. The goal is to support productive engineering while preserving a record of how important information was handled.

Turn secrecy into an operational question

WIPO’s guide identifies reasonable protective steps as part of trade-secret protection. For our warehouse example, the practical task is to identify which configurations, evaluation sets, or operating procedures are treated as confidential and who can access them. Labeling an entire repository secret without an access plan leaves essential questions unanswered.

Map three movements of information: what enters the system, what leaves it, and what vendors retain. Then assign a responsible owner to each movement. This simple diagram can expose a gap between a confidentiality clause and an actual export feature. It can also show where a customer expects deletion but a backup or analytics process retains material.

The diagram is our proposed review method, not a certification of legal compliance. Its value comes from linking technical behavior to contractual promises. Engineers can describe what the system does; counsel can assess whether the rights and obligations match. Neither group should have to infer the other group’s assumptions.

Technical evidence needs a baseline

When a founder says an AI product is better, ask better than what, on which data, and under what operating conditions. A meaningful technical brief identifies the baseline, evaluation method, failure cases, and changes introduced by the team. These records can support discussions about the invention while also improving the company’s product claims.

Suppose the illustrative dock system reduces false alerts in one controlled test. That result should not become a claim of universal improvement across all terminals. Record lighting, camera placement, sample selection, and the definition of a false alert. A smaller claim supported by reproducible evidence is more useful than a broad assertion nobody can reconstruct.

Patent analysis still requires legal judgment; a favorable benchmark does not establish patentability. Conversely, an invention may concern an architectural improvement whose commercial value is not captured by one accuracy number. The point is to give the reviewer enough technical detail to understand the claimed contribution and its alternatives.

Prepare an AI diligence packet

Build a packet with a product diagram, contributor list, model and software inventory, data permission records, test summaries, and a disclosure timeline. Separate confirmed facts from open questions. If a license is missing, identify the missing document and the person responsible for obtaining it instead of filling the gap with an assumption.

For customer contracts, identify what the company can realistically deliver: access to a service, rights in custom code, rights to use outputs, or particular confidentiality commitments. These are different promises. A procurement conversation becomes clearer when sales language is tied to the actual assets and dependencies described in the packet.

Separate a demonstration from a rights promise

A working demonstration answers whether a feature can perform a task under the conditions shown. It does not, by itself, answer who owns every component or what rights can be transferred to a customer. Our suggested sales review pairs each proposed promise with the document or technical fact that supports it.

For the illustrative warehouse startup, a promise to provide an output may require one set of permissions, while a promise to transfer the underlying model may require another. A customer might also ask for exclusivity in an industry or territory. Record those requests precisely and obtain review before treating them as standard features of the service.

This creates a useful feedback loop between product, sales, and counsel. Product staff explain the architecture, sales staff identify the commercial request, and counsel evaluates the relevant rights and obligations. The resulting answer can be narrower and more reliable than a general claim that the company owns everything. Preserve the reasoning so the next contract discussion starts with verified facts instead of repeating the investigation. Review this periodically.

A practical starting point for Miami teams

At the next product review, choose one feature and trace its history from human conception through data, code, testing, and deployment. Record the contributors and external materials involved. That exercise often produces a more useful legal brief than a broad request to patent an AI platform.

AI changes tools and development speed, but it does not remove the need to explain human contribution, ownership, permissions, and disclosure. Current guidance and technical research help separate these issues. A Miami business can then obtain advice on a specific invention and workflow, with evidence that supports the discussion rather than a collection of assumptions about what AI ownership means.