# Dựng AI side project để kiếm tiền khi đang đi làm: cái gì public, cái gì phải giấu
Tôi hay đọc xung quanh để bắt mạch chuyện "dùng AI để làm tiền". Gần đây cái không khí nóng hẳn lên. Người ta bắt đầu thấy những hội nhóm riêng dành cho các agent — nơi người build agent tụm lại chia sẻ — và dân làm workflow thì hăm hở kể chuyện họ huấn luyện con agent của mình để đốt ít tiền hơn. Mọi người đang dựng, đang thử, đang kiếm tiền từ những con máy tự động.
Và giữa cái sôi động đó, có một câu hỏi gần như không ai nhắc: nếu bạn còn đi làm, thì cái side project AI của bạn thật sự là của bạn đến mức nào?
Câu này nhiều người gạt đi. Họ nghĩ "tối làm sau giờ thì của mình chứ". Rồi họ dựng, họ đăng, họ kiếm tiền. Đến lúc nào đó mới vỡ ra là mình đã đi trên một ranh giới khá mong manh mà mình chưa từng vẽ.
Bài này không phải là lời khuyên luật — tôi không phải luật sư. Nó là một thói quen tôi tự đặt cho mình, và vì sao nó giúp tôi ngủ ngon trong khi vẫn tiếp tục xây mấy con máy để làm ra giá trị. Hy vọng nó hữu ích cho anh em đang trong tình cảnh giống tôi.
Cái "phép màu" hầu như ai cũng tin
Có một mặc định rất phổ biến, và nó nguy hiểm vì nó nghe rất hợp lý: "Tối nào mình cũng về nhà mở laptop, tự mình code, tự mình chạy, không đụng gì tới máy của công ty, thì nó là của mình — công ty không liên quan."
Nghe ổn. Nhưng cái mặc định đó trượt qua vài điều mà nhiều người không để ý:
- ▹Bạn không chỉ mang "giờ" về nhà, bạn còn mang "đầu". Kiến thức, kinh nghiệm, cách giải một bài toán — thứ bạn học được trong công việc hàng ngày. Thứ đó rất khó "tách vỏ" để nói rằng nó không thuộc về phía công ty.
- ▹Bạn làm gần một thứ với thứ bạn làm lúc đi làm. Xây một agent xử lý dữ liệu ở sở, rồi cũng xây một agent xử lý dữ liệu ở nhà — khác công ty, nhưng thuật toán, kỹ thuật, cách đặt pipeline gần như y hệt.
- ▹Càng đi làm lâu, cái "của riêng" càng ít. Cái bạn tưởng là "ý tưởng sáng tạo của mình" thật ra là phần lớn đúc kết từ hàng nghìn giờ bạn được trả lương để làm.
Đây không phải là chuyện có làm tội, mà là chuyện bạn tự có chế độ bảo vệ cho mình trước khi mọi thứ trở nên khó nói.
Thứ khiến chuyện này nhạy với "công ty Nhật"
Tôi làm ở một công ty Nhật, chỗ có quy định về tài sản trí tuệ khá nghiêm ngặt. Với văn hoá Nhật, chữ ký trên hợp đồng là chữ ký — họ rất coi trọng "thỏa thuận". Và hầu hết hợp đồng của nhân viên đều có một điều khoản nói rằng: những gì bạn tạo ra liên quan tới công việc, dù làm ngoài giờ hay ở nhà, thường được coi là thuộc về công ty nếu nó nằm trong "phạm vi công việc".
Cái phạm vi đó là chỗ mơ hồ nhất. Nó không chỉ là "code bạn viết tại bàn công ty". Nó gồm cả:
- ▹Một con agent bạn dựng để giải quyết bài toán mà chính công việc của bạn gợi ra.
- ▹Một quy trình tự động bạn viết dựa trên cách vận hành bạn biết từ chỗ làm.
- ▹Một bộ dữ liệu, một cấu hình, một kiến trúc mà bạn nhìn quen mắt vì ngày ngày bạn chạm vào ở cơ quan.
Đừng để tới lúc bạn đăng lên mạng một thứ "hay ho" rồi nhận ra nó có bóng dáng quá rõ của thứ thuộc về công ty. Đến lúc đó, việc thu hồi về là rất khó, và cái uy tín bạn xây được trong "hội" có thể mất sạch chỉ vì một chữ nhầm.
Luật tôi tự đặt: hai phòng, một cửa cắt
Vậy tôi làm gì? Tôi không muốn từ bỏ việc xây side project — vì đó là nơi tôi học, là nơi tôi tự do thử thứ mới, là nơi giá trị của tôi (và mong muốn kiếm tiền từ nó) thuộc về tôi thật sự. Nên thay vì cấm mình, tôi đặt một cái ranh giới rõ ràng từ trước — để không phải tự vấn mỗi lần muốn đăng một bài, và không phải "tự thương lượng" với chính mình lúc nửa đêm.
Rule của tôi đơn giản là hai phòng tách bạch:
Phòng một — dự án cá nhân: PUBLIC. Những thứ tôi làm cho riêng mình, từ ý tưởng của riêng mình, không dính công việc chỗ làm — thứ này tôi thoải mái đăng công khai. Ghi tên thật, blog, GitHub, chia sẻ quy trình, kể cả kiếm tiền từ nó. Đây là chỗ tôi được phép "show off", được phép đóng góp, được phép xây cái tên của mình.
Phòng hai — việc liên quan tới công ty: GIẤU TÊN. Thứ nào chạm tới công việc, tới kiến thức tôi lấy từ chỗ làm, hoặc thứ nếu đăng lên sẽ khiến người ta nhìn ra bóng dáng của công ty — thứ đó không bao giờ có tên tôi. Cũng không mang source, không mang dữ liệu, không mang cách vận hành ra ngoài. Tôi giữ nó là "việc nội bộ" hoặc để lại trong công việc.
Cái hay của rule này không nằm ở nội dung, mà nằm ở chỗ nó được đặt ra trước, khi tôi còn tỉnh táo — chứ không phải khi tôi đang hào hứng vì con máy vừa chạy ra một thứ hay. Lúc hào hứng, ai cũng dễ "mềm" hơn với chính mình. Một rule ghi sẵn như một cái bumper và bắt tôi phải dừng lại và hỏi: cái này thuộc phòng nào?
Những chỗ tôi từng đắn đo (và cách xử)
Để anh em dễ hình dung, đây là vài tình huống "xám" mà tôi từng đụng và hướng tôi xử:
1. Cùng một kỹ thuật, dùng ở hai nơi. Tôi học cách tối ưu chi phí để chạy agent ở công việc. Nó rất hay, và tôi muốn chia sẻ. Đây là lúc nhiều người vấp: chia sẻ kỹ thuật chung thì ổn (kiểu "đừng để model làm việc mà một luật đơn giản làm được", "đặt bộ lọc cứng trước"), nhưng đừng chia sẻ cách tôi áp dụng nó vào đúng bài toán của công ty, kèm số liệu, cấu hình, kiến trúc thật. Học phần tư duy. Giữ phần triển khai.
2. Dữ liệu và số liệu. Số liệu là thứ dễ lộ nhất. Nếu quy trình của tôi sinh ra một con số "trông rất ấn tượng" mà nó đến từ dữ liệu của công ty — con số đó cũng thuộc phòng hai. Tôi viết bài bằng trải nghiệm cá nhân, không vẽ con số cụ thể lên đó.
3. Prompt / pipeline có nghe ra "chỗ làm". Vài con agent tôi xây cho riêng mình có kiến trúc giống hệt mấy cái tôi xây lúc đi làm. Nếu tôi đăng nó lên, một người nào đó trong công ty sẽ nhận ra chữ ký. Vậy nên bài viết của tôi dùng pseudo-code minh hoạ và ghi rõ đây là cơ chế minh hoạ, không phải source thật — để chia sẻ được cái tư duy mà không lộ cái "nhà máy".
Cái dao cắt chung của tôi là câu hỏi đơn giản:
"Nếu người quản lý (hoặc người sở hữu thứ này) đọc bài của tôi, họ có cảm thấy mình đang ngồi xem thứ của họ bị đem ra ngoài không?"
Nếu câu trả lời là "có" hoặc "không chắc", nó thuộc phòng hai. Chỉ khi tôi chắc chắn "không", nó mới đáng đem ra với anh em.
Một chiếc checklist để áp dụng
Nếu anh em muốn tự đặt rule cho mình, đây là dạng checklist tôi dùng (đây là khung tư duy, không phải nguồn triển khai):
Trước khi đăng / chia sẻ một side project, hỏi:
1. Ý tưởng này tôi nghĩ ra ở đâu — trong giờ làm, hay sau giờ?
2. Nó có dùng kiến thức / dữ liệu / cách vận hành tôi biết từ công việc không?
3. Nếu không nêu tên công ty, người trong nghề có nhận ra nó không?
4. Tôi có sẵn sàng để người sở hữu (công ty) thấy tôi "show" nó không?
5. Tôi có đang trích dẫn số liệu, config, code thật từ công việc không?
- Nếu 1,2 = "có/không chắc" -> thuộc phòng hai, giấu tên.
- Nếu câu nào lấn cấn, đừng đăng hôm nay. Viết lại sao cho chỉ còn
cái "tư duy" chung, bỏ hết cái "bằng chứng" cụ thể.Kết
Cái mạnh nhất của chuyện này không phải là "bạn nên giấu nhiều hơn". Nó là bước vẽ ranh giới trước khi bạn thật sự cần đến nó — để bạn không phải vừa xây con máy kiếm tiền, vừa lo lắng nửa đêm rằng mình có đang đi lệch không. Một rule rõ ràng sẽ cho bạn tốc độ: bạn không mất thời gian tự vấn mỗi lần, bạn làm nhiều hơn, và bạn ngủ ngon hơn.
Người ta cứ nói "build in public" như một điều phải làm để kiếm tiền. Đúng, nhưng "build in public" một cách có trách nhiệm mới là thứ bền. Ranh giới không phải để kìm bạn, nó để bạn bay xa hơn mà không sợ rơi.
Anh em đang đi làm mà cũng xây side project — anh em xử ranh giới này thế nào? Anh em có tự đặt một luật "chỉ mình biết" không, hay chưa từng nghĩ tới? Góc nào anh em muốn mình mổ tiếp — cách tách "phần tư duy" khỏi "phần triển khai" khi viết blog, hay cách quản lý những con agent "vừa giống chỗ làm"? Cứ comment, mình sẽ viết tiếp ở zeodavu.com/blog.
Một phần của chuỗi mổ xẻ kỹ thuật và trải nghiệm thật tại zeodavu.com/blog. Điều tôi chia sẻ là cách tư duy về ranh giới, không phải lời khuyên luật, và không phải blueprint để sao chép — thứ đáng giữ là câu hỏi, không phải danh sách công cụ.
Nếu thấy hữu ích, theo dõi zeodavu.com — mỗi bài là một thứ mình thật sự dùng, vấp, và sửa lại.