AI side projects while employed: a moonlighting and IP check

Why AI projects raise the stakes

Three features make AI side projects riskier than an ordinary hobby app:

• Proximity. If you work on AI at your job, a similar side project is easy to confuse with employer work.
• Data. It is tempting to test on "a few real examples" from work. That is company data, and possibly personal data about customers.
• Tools and accounts. A company-paid AI coding assistant or cloud account may have terms that give the employer rights over what you produce with it, and it leaves records.

Step 1: read four clauses

Find your offer letter, employment agreement and the employee handbook or code of conduct. Look for:

Copy the exact wording of each into a private note. Summaries from colleagues are not reliable; contracts differ even inside one company.

Step 2: score the overlap

Answer yes or no:

1. 1Does the project solve a problem your employer sells a solution for?
2. 2Would your employer's clients be natural users of it?
3. 3Did the idea come from something you learned at work?
4. 4Does it use techniques or designs specific to your employer's systems?
5. 5Would you be uncomfortable showing it to your manager?

If you answered yes to any of 1–4, treat the project as needing disclosure or a different topic. Question 5 is a useful instinct check.

Step 3: keep clean separation

Whatever the contract says, keep these rules:

• Personal device, personal accounts. Build on your own laptop with your own email, GitHub account and API keys.
• Personal time. Not during working hours, and not on a work call running in the background.
• No company data. Use public or synthetic data. If you need realistic examples, generate them.
• No company code. Don't copy snippets, prompts, configuration or internal libraries, even ones you wrote.
• Record your timeline. Commit history on your personal account, with dates, is useful evidence that the work was done separately.

A small script to generate realistic-looking synthetic records instead of borrowing real ones:

import random
import csv
import io

random.seed(7)
CITIES = ["Noida", "Pune", "Jaipur", "Kochi", "Indore"]
ISSUES = ["late delivery", "wrong item", "refund status", "damaged box"]

buf = io.StringIO()
w = csv.writer(buf)
w.writerow(["ticket_id", "city", "issue", "days_open"])
for i in range(1, 11):
    w.writerow([f"T{i:04d}", random.choice(CITIES),
                random.choice(ISSUES), random.randint(0, 9)])

rows = buf.getvalue().strip().splitlines()
print("\n".join(rows[:4]))
assert len(rows) == 11          # header + 10 synthetic tickets

Nothing in it came from an employer, and anyone can reproduce it, which is exactly what you want in a public portfolio.

Step 4: decide whether to disclose

When you disclose, do it in writing and keep a copy. A short email works: "I'm building a personal learning project on <topic> using public data on my own time and equipment. It doesn't relate to our products or clients. Please let me know if this needs approval."

Step 5: before you publish

• Search your code and prompts for company names, internal URLs, colleague names and file paths.
• Remove any example text that came from work.
• Check that API keys are not in the repository history.
• Write a README that says the data is synthetic or public, with sources.

When a side project becomes paid work

If someone asks to pay you for it, or you want to freelance, that usually moves you into "outside employment" under most contracts. Recheck Step 1 before accepting. Freelance AI automation for small businesses covers scoping a first paid project.

A safe side project can be your strongest portfolio piece; see three LLM portfolio pieces with acceptance criteria for ideas that work well on public data. The Generative & Agentic AI add-on gives you projects built on non-employer data from the start.