Top 5 kinh nghiệm thực tế về luật cho đội công nghệ

Top 5 kinh nghiệm thực tế về luật trong bài này không đến từ giáo trình hay lớp học lý thuyết. Đội ngũ chúng tôi ghi lại sau nhiều năm làm việc cùng các doanh nghiệp công nghệ nhỏ và vừa. Chúng tôi hỏi thẳng họ từng vướng gì, mất bao nhiêu tiền, và bài học nào buộc họ phải đổi quy trình. Những gì đọng lại thường không phải điều luật phức tạp. Đó là các lỗi rất đời, lặp đi lặp lại ở nhiều dự án khác nhau.

Bạn có thể đọc lướt danh sách này trong vài phút. Nhưng nếu đang chuẩn bị ký hợp đồng phần mềm hoặc nhận dự án outsource, hãy đọc chậm lại. Một điều khoản viết sai có thể khiến bạn mất vài chục triệu đồng. Một câu trích dẫn văn bản không đúng có thể khiến cả hồ sơ phải làm lại từ đầu.

Vì sao đúng 5 kinh nghiệm này được chọn?

Chúng tôi không chọn theo cảm hứng. Mỗi mục dưới đây phải vượt qua ba tiêu chí cùng lúc. Tiêu chí thứ nhất là tần suất, tức sự cố phải lặp lại ở nhiều doanh nghiệp khác nhau chứ không phải trường hợp cá biệt. Tiêu chí thứ hai là mức thiệt hại, gồm tiền đàm phán lại, tiền chậm tiến độ và tiền thuê luật sư phải đủ lớn để đội nhớ lâu. Tiêu chí thứ ba là tính khả thi, nghĩa là vấn đề phải phòng tránh được bằng một checklist đơn giản. Không ai muốn thuê pháp chế thường trực chỉ để tránh vài lỗi cơ bản.

Đối tượng phù hợp nhất với danh sách này là PM, BA, CTO và founder chưa có bộ phận pháp chế riêng. Đây là những người vừa lo sản phẩm, vừa lo kỹ thuật, vừa phải ký hợp đồng với khách hàng và nhà cung cấp. Áp lực thời gian khiến họ thường bỏ qua các bước kiểm tra pháp lý. Đó chính là lúc rủi ro xuất hiện. Bạn có thể tham khảo thêm kinh nghiệm về quyết định, nghị định, thông tư như bước nối tiếp sau khi đọc xong bài này.

Một điểm cần nói rõ ngay từ đầu: đây là kinh nghiệm tổng hợp từ thực tế của đội ngũ chúng tôi và một số đối tác quen. Nó không phải kết luận pháp lý và không thay thế ý kiến luật sư. Mọi quyết định cuối cùng vẫn phải đối chiếu với văn bản gốc do cơ quan nhà nước ban hành.

Kinh nghiệm 1 — Đọc điều khoản chấm dứt trước khi nhìn tới giá

Đây là mục nặng ký nhất trong danh sách. Điều khoản chấm dứt hợp đồng là nơi tập trung nhiều tranh chấp nhất mà đội ngũ chúng tôi từng chứng kiến. Nói cách khác, phần lớn các vụ cãi nhau giữa khách hàng và nhà cung cấp đều xoay quanh ba câu hỏi: ai được quyền dừng, dừng khi nào, và dừng thì mất gì.

Phần lớn đội outsource đọc giá trước. Họ so sánh đơn giá nhân sự theo giờ, đơn giá theo gói, rồi mới lật sang các điều khoản còn lại. Thứ tự đó sai. Giá chỉ là một con số. Điều khoản chấm dứt mới là thứ quyết định bạn có bị kẹt giữa dòng hay không.

Hãy hình dung một hợp đồng outsource sáu tháng, giá trị 800 triệu đồng. Khách muốn dừng ở tháng thứ hai. Nếu hợp đồng chỉ ghi “bên A có quyền chấm dứt vì lý do chính đáng”, bạn gần như không có cơ sở để đòi bồi thường. Cụm “lý do chính đáng” nghe hợp lý, nhưng mơ hồ đến mức ai cũng có thể diễn giải theo hướng có lợi cho mình.

Vì sao điều khoản này quan trọng hơn cả giá? Vì nó khóa dòng tiền của bạn. Khi khách dừng giữa dòng, bạn vẫn phải trả lương cho đội đã tuyển. Bạn vẫn phải trả tiền hạ tầng đã thuê. Một hợp đồng giá cao nhưng điều khoản chấm dứt rõ ràng vẫn an toàn hơn hợp đồng giá thấp nhưng khiến bạn bị khóa chân.

Cách làm cụ thể theo kinh nghiệm của chúng tôi là yêu cầu ghi rõ ba thứ. Thứ nhất là thời gian báo trước khi chấm dứt, thường 30 ngày được xem là hợp lý với dự án dài hạn. Thứ hai là mức bồi hoàn cho phần việc đã làm dở, tính theo tỷ lệ hoàn thành hoặc theo số giờ đã bỏ ra. Thứ ba là định nghĩa “lý do chính đáng” bằng một danh sách đóng, ví dụ chậm bàn giao quá 15 ngày hoặc vi phạm điều khoản bảo mật. Đừng để cụm từ này mở.

Sai lầm hay gặp là nhiều bên copy điều khoản chấm dứt từ mẫu hợp đồng tải trên mạng. Mẫu đó thường được viết cho hợp đồng mua bán hàng hóa, không phải hợp đồng dịch vụ phần mềm. Bản chất hai loại khác nhau nên điều khoản cũng phải khác nhau. Chúng tôi từng gặp một trường hợp: đội outsource dùng mẫu hợp đồng mua bán cho dự án phát triển app, đến khi khách dừng giữa dòng thì hai bên tranh cãi mất gần hai tháng vì không ai định nghĩa được “phần việc đã hoàn thành” là gì.

Một mẹo nhỏ từ kinh nghiệm thực tế: trước khi ký, hãy tự hỏi “nếu khách dừng ở tháng thứ hai, tôi mất bao nhiêu tiền?”. Nếu không trả lời được trong 30 giây, bạn chưa đọc kỹ điều khoản chấm dứt.

Kinh nghiệm 2 — Ghi rõ quyền sở hữu trí tuệ của code do AI sinh ra

Đây là vấn đề mới xuất hiện trong vài năm gần đây khi các công cụ AI hỗ trợ viết code trở nên phổ biến. Nhiều đội lập trình dùng trợ lý AI hằng ngày mà chưa từng đưa điều khoản về nó vào hợp đồng. Đó là một khoảng trống rủi ro mà chúng tôi khuyên các đội nên lấp sớm.

Nói dễ hiểu: khi lập trình viên dùng công cụ AI để sinh ra một đoạn code, câu hỏi đặt ra là đoạn code đó thuộc về ai. Thuộc về lập trình viên, thuộc về công ty, hay thuộc về bên cung cấp công cụ AI? Hiện chưa có câu trả lời rõ ràng và thống nhất cho mọi trường hợp, cả ở Việt Nam lẫn nhiều nơi khác.

Vì sao phải giải quyết trước khi ký, chứ không phải sau? Vì hợp đồng với khách thường ghi một câu rất chắc: “toàn bộ sản phẩm bàn giao thuộc sở hữu của khách”. Nếu trong sản phẩm đó có đoạn code do AI sinh ra mà quyền sở hữu chưa rõ ràng, bạn đang cam kết một thứ mà chính mình chưa chắc sở hữu. Khi khách phát hiện, hậu quả thường không nhỏ.

Cách làm cụ thể mà đội ngũ chúng tôi áp dụng gồm ba việc. Thứ nhất, ghi trong quy chế nội bộ rằng code do AI sinh ra trong giờ làm việc là tài sản của công ty, không phải của cá nhân lập trình viên. Thứ hai, yêu cầu lập trình viên khai báo khi dùng công cụ AI cho phần code lõi, để công ty kịp đánh giá rủi ro. Thứ ba, khi làm việc với khách, thêm một câu miễn trừ hợp lý: bên cung cấp nỗ lực tối đa nhưng không đảm bảo tuyệt đối về tính nguyên bản của phần code do công cụ AI sinh ra. Câu này nên được thương lượng ngay từ đầu, không phải thêm vào phút cuối.

Hạn chế thật cần nói thẳng: hiện chưa có án lệ cụ thể tại Việt Nam cho tình huống code do AI sinh ra. Bạn cần tham chiếu Luật Sở hữu trí tuệ hiện hành và các văn bản hướng dẫn liên quan. Nếu hợp đồng có giá trị lớn, hãy hỏi luật sư trước khi cam kết với khách. Đừng để lập trình viên tự quyết trong các cuộc trao đổi với khách hàng.

Chúng tôi từng chứng kiến một trường hợp khá điển hình. Một công ty phần mềm nhỏ nhận dự án xây dựng hệ thống quản lý nội bộ. Đội kỹ thuật dùng công cụ AI sinh ra một module xử lý dữ liệu khá phức tạp. Khi bàn giao, khách yêu cầu xác nhận quyền sở hữu với toàn bộ mã nguồn. Công ty không trả lời được rõ ràng cho phần code AI sinh ra, buộc phải viết lại module đó từ đầu để tránh rủi ro. Chi phí phát sinh không lớn về tiền, nhưng làm chậm tiến độ gần ba tuần và khiến khách mất niềm tin.

Nếu bạn đang cân nhắc thuê đối tác công nghệ có dùng AI, hãy tham khảo thêm cách đánh giá công ty ứng dụng AI trước khi ký hợp đồng. Đặt cạnh nhau, hai nội dung này bổ sung cho nhau khá tốt.

Kinh nghiệm 3 — Lưu log và bằng chứng khi làm việc với khách qua kênh chat

Đây là mục mà đội PM và CSKH nên đọc kỹ. Khi xảy ra tranh chấp về phạm vi công việc, bên nào có log đầy đủ thường ở thế mạnh hơn hẳn. Con số này không phải thống kê chính thức, mà là quan sát của chúng tôi qua nhiều vụ việc thực tế.

Ở Việt Nam, phần lớn trao đổi dự án diễn ra qua Zalo hoặc các ứng dụng chat khác. Nhanh, tiện, ai cũng dùng. Nhưng chat cá nhân có một điểm yếu chí mạng: khó xác thực và dễ mất dữ liệu khi đổi máy hoặc đổi số. Khi ra tranh chấp, một đoạn chat không được xem là bằng chứng mạnh như email, đặc biệt là chat qua tài khoản cá nhân.

Vì sao log lại quan trọng đến vậy? Vì tranh chấp về phạm vi công việc thường không phải cãi nhau về đúng sai. Nó là cãi nhau về ký ức. Khách nhớ là “đã yêu cầu thêm tính năng X”. Bạn nhớ là “đã nói rõ X nằm ngoài phạm vi hợp đồng”. Ai có bằng chứng, người đó có lợi thế. Ký ức hai bên thường không khớp, nhất là khi dự án kéo dài nhiều tháng.

Quy trình chúng tôi khuyên áp dụng gói gọn trong ba bước. Mọi trao đổi qua chat đều phải được chốt lại bằng email trong cùng ngày làm việc. Email chốt phải ghi rõ nội dung thống nhất, người chịu trách nhiệm và thời hạn. Log chat cần được lưu tối thiểu 24 tháng, đề phòng tranh chấp phát sinh muộn. Ba bước này nghe đơn giản nhưng nếu duy trì đều đặn sẽ tiết kiệm rất nhiều thời gian về sau.

Sai lầm phổ biến là chỉ chốt bằng miệng. Kiểu “ok em làm đi” trong cuộc gọi không để lại dấu vết gì. Vài tháng sau, không ai nhớ nổi ai đã nói gì, kể cả chính bạn. Khi tranh chấp nổ ra, bên có ghi chép đầy đủ gần như luôn nắm thế chủ động.

Một mẹo nhỏ nhưng hiệu quả: dùng một câu chốt cố định sau mỗi cuộc trao đổi quan trọng. Ví dụ “em tóm tắt lại nội dung mình vừa thống nhất, anh/chị xác nhận giúp em trong email này nhé”. Câu này vừa giữ phép lịch sự với khách, vừa tạo bằng chứng cho cả hai bên. Chúng tôi từng thấy nhiều đội chỉ cần áp dụng câu chốt này mà giảm hẳn các cuộc tranh cãi về sau.

Với freelancer nhận dự án nhỏ, cách này càng quan trọng. Bạn không có bộ phận pháp chế đứng sau. Một email xác nhận đôi khi là tài sản duy nhất bạn có khi khách đổi ý giữa dòng.

Kinh nghiệm 4 — Tra cứu văn bản gốc thay vì tin bài tổng hợp trôi nổi

Đây là lỗi tốn kém nhất mà đội ngũ chúng tôi ghi nhận. Nhiều đội trích dẫn sai quy định vì đọc bản tin cũ trên mạng hoặc các bài tổng hợp không ghi rõ nguồn. Sai sót loại này thường khó phát hiện vì bản thân người đọc tin là mình đúng.

Vì sao dễ sai đến vậy? Vì một văn bản pháp luật có thể được sửa đổi, bổ sung hoặc thay thế theo thời gian. Bài viết trên mạng thì không tự cập nhật. Bạn đọc một bài tổng hợp từ vài năm trước, áp vào tình huống hiện tại, và kết quả là trích dẫn không còn đúng. Điều tệ hơn là bạn có thể đã dùng thông tin đó để ra quyết định.

Nói dễ hiểu: văn bản gốc là “bản chính”. Bài tổng hợp là bản sao chép lại. Bản sao chép lại có thể thiếu ý, sai số điều, hoặc đã lỗi thời. Khi ra quyết định, bạn phải dựa vào bản chính. Một cách nhanh để phân biệt: bản chính luôn ghi rõ số văn bản, ngày ban hành, cơ quan ban hành và tình trạng hiệu lực.

Cách tra cứu chúng tôi khuyên dùng gồm ba việc. Tra trên cổng thông tin văn bản pháp luật chính thống của cơ quan nhà nước trước tiên. Kiểm tra phần tình trạng hiệu lực của văn bản, xem còn hiệu lực, hết hiệu lực hay đã bị sửa đổi. Đọc cả văn bản sửa đổi, bổ sung nếu có, chứ không chỉ đọc bản gốc ban đầu.

Hạn chế thật: một số văn bản mới chưa được đăng toàn văn công khai hoặc chưa cập nhật trên các cổng tra cứu phổ biến. Trong trường hợp đó, bạn phải kiểm chứng chéo ít nhất hai nguồn chính thống. Nếu hai nguồn không khớp nhau, đừng đoán bừa. Hãy chờ văn bản chính thức hoặc hỏi người có chuyên môn.

Với doanh nghiệp công nghệ ký hợp đồng với nhà cung cấp nước ngoài, bước tra cứu còn quan trọng hơn. Hợp đồng công nghệ thường viện dẫn nhiều văn bản khác nhau, từ luật thương mại đến quy định về dữ liệu. Bạn có thể xem thêm cách tra cứu văn bản pháp luật khi ký hợp đồng công nghệ để đi đúng trình tự và tránh bỏ sót bước.

Một ví dụ cụ thể mà đội ngũ chúng tôi từng gặp: kế toán của một công ty phần mềm trích dẫn mức phạt theo thông tin hướng dẫn cũ. Mức phạt thực tế đã thay đổi từ trước đó. Sai lệch không lớn về tiền, nhưng khiến hồ sơ bị trả lại và chậm cả tháng. Cái mất ở đây không phải tiền phạt, mà là thời gian và uy tín với đối tác.

Kinh nghiệm 5 — Phân loại rủi ro trước khi ký, đừng ký rồi mới phân loại

Khá nhiều đội cho biết từng phải đàm phán lại hợp đồng vì bỏ qua bước này. Đàm phán lại rất tốn kém. Bạn đã đặt quan hệ, đã triển khai công việc, giờ phải quay lại bàn điều khoản. Khách thường không vui, và vị thế đàm phán của bạn đã yếu hơn nhiều so với lúc đầu.

Phân loại rủi ro nghĩa là gì? Nói đơn giản, trước khi ký, bạn liệt kê những gì có thể xảy ra với hợp đồng đó. Sau đó xếp chúng vào các nhóm theo mức độ nghiêm trọng và khả năng xảy ra. Mỗi nhóm sẽ có cách xử lý khác nhau, từ việc thuê luật sư xem xét cho tới việc dùng mẫu hợp đồng có sẵn.

Vì sao phải làm trước khi ký? Vì sau khi ký, mọi thứ đã cố định. Bạn không còn đòn bẩy để thương lượng. Ký rồi mới phát hiện rủi ro là ký trong thế bị động, và chi phí sửa sai thường cao hơn nhiều lần so với chi phí chuẩn bị ban đầu.

Cách phân loại chúng tôi thường gợi ý gồm ba mức. Với rủi ro cao, ví dụ hợp đồng giá trị lớn, khách nước ngoài hoặc phụ thuộc một nhà cung cấp duy nhất, nên đưa luật sư xem trước và thương lượng kỹ các điều khoản chấm dứt cùng bồi thường. Với rủi ro vừa, kiểu dự án 3–6 tháng với khách trong nước đã biết nhau, có thể dùng checklist nội bộ và soạn điều khoản rõ ràng, không cần luật sư cho từng câu. Với rủi ro thấp, gói dịch vụ nhỏ thanh toán một lần, dùng hợp đồng mẫu có sẵn và chỉ chỉnh phần thông tin hai bên là đủ.

Đối tượng phù hợp với bước này là doanh nghiệp đang nhận đầu tư, doanh nghiệp mua sắm thiết bị, và đơn vị nhập linh kiện. Những hợp đồng này thường có nhiều bên liên quan, nhiều điều khoản phụ, và ít cơ hội sửa sai. Nếu bạn đang ký hợp đồng dịch vụ công nghệ có cam kết chất lượng, việc hiểu rõ thuật ngữ SLA trong hợp đồng dịch vụ công nghệ cũng nằm trong bước phân loại rủi ro này.

Hạn chế thật: một bảng phân loại rủi ro tử tế sẽ mất vài ngày công để làm lần đầu. Nhiều đội bỏ qua để kịp deadline. Đến khi rủi ro xảy ra, chi phí xử lý thường cao gấp nhiều lần thời gian tiết kiệm được. Chúng tôi từng thấy một đội tiếc hai ngày làm bảng rủi ro, để rồi mất gần hai tháng đàm phán lại với khách.

Mẹo từ đội ngũ chúng tôi: nếu không đủ thời gian phân loại cả hợp đồng, hãy phân loại năm điều khoản quan trọng nhất trước. Cách này mất khoảng hai giờ, nhưng chặn được phần lớn rủi ro lớn.

Khi nào 5 kinh nghiệm này chưa đủ?

Có ba tình huống mà checklist không cứu được bạn. Nhận diện sớm để gọi đúng người, đúng lúc.

Thứ nhất, khi dự án liên quan tới dữ liệu cá nhân quy mô lớn. Việc thu thập, lưu trữ và xử lý dữ liệu cá nhân chịu sự điều chỉnh của Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân. Phạm vi áp dụng rộng, mức xử phạt có thể lớn, và các yêu cầu kỹ thuật khá chi tiết. Đây là lĩnh vực cần chuyên gia riêng, không thể xử lý bằng một checklist chung.

Thứ hai, khi có yếu tố nước ngoài. Nhà cung cấp nước ngoài, khách hàng nước ngoài, hoặc dữ liệu đặt trên máy chủ nước ngoài đều đưa bạn vào vùng hợp đồng quốc tế. Luật áp dụng, cơ quan giải quyết tranh chấp, ngôn ngữ hợp đồng — tất cả đều phức tạp hơn hợp đồng trong nước. Hãy tìm luật sư có kinh nghiệm hợp đồng quốc tế thay vì tự xử lý.

Thứ ba, khi đã xảy ra tranh chấp. Năm kinh nghiệm này là phòng ngừa, không phải xử lý hậu quả. Khi tranh chấp đã nổ ra, bạn cần người đại diện, cần chiến lược và cần bằng chứng được trình bày đúng cách. Cố tự xử lý thường làm tình hình tệ hơn, đặc biệt là khi đã có thư từ qua lại giữa hai bên.

Một dấu hiệu khác đáng lưu ý: khi giá trị hợp đồng vượt quá một ngưỡng nào đó so với quy mô công ty. Ngưỡng này tùy doanh nghiệp, nhưng nguyên tắc chung là nếu mất hợp đồng đó công ty gặp khó, hãy đầu tư cho nó đúng mức.

Biến 5 kinh nghiệm thành checklist nội bộ trong một buổi chiều

Nghe thì nhiều, nhưng làm thực tế khá nhanh. Đội ngũ chúng tôi gói lại thành ba việc, làm trong một buổi chiều là xong bản đầu tiên. Bạn không cần chờ tới khi có bộ phận pháp chế chuyên trách mới bắt đầu.

Việc đầu tiên là tạo một file một trang. Mỗi kinh nghiệm ở trên, viết ba câu hỏi dạng “đã làm chưa?”. Chẳng hạn với kinh nghiệm về điều khoản chấm dứt: đã ghi rõ thời gian báo trước chưa, đã định nghĩa lý do chính đáng chưa, đã tính thiệt hại nếu dừng giữa dòng chưa. File này dùng ngay trong bước review hợp đồng.

Việc thứ hai là giao một người làm owner. Người này không nhất thiết là luật sư. Có thể là PM hoặc nhân sự hành chính. Điều quan trọng là có người chịu trách nhiệm cập nhật và nhắc nhở cả đội. Nhịp review hợp lý là mỗi quý một lần, hoặc sớm hơn khi có văn bản mới ảnh hưởng trực tiếp tới hoạt động công ty.

Việc thứ ba là chèn bước tra cứu văn bản gốc vào quy trình mua sắm và ký kết. Đừng để tới lúc ký mới tra. Hãy tra khi bắt đầu soạn thảo, để kịp điều chỉnh nếu phát hiện quy định mới hoặc văn bản đã thay đổi.

Với doanh nghiệp đang kinh doanh trực tuyến, checklist pháp lý còn có một mục riêng: nghĩa vụ đăng ký website với cơ quan quản lý. Nếu bạn chưa rõ trường hợp nào bắt buộc, có thể tham khảo giải thích về website nào phải đăng ký với Bộ Công Thương. Đây là việc nhỏ nhưng rất dễ bị bỏ sót, đặc biệt là với các website bán hàng mới lập.

Cuối cùng, đừng biến checklist thành hình thức. Một file một trang được dùng thật tốt hơn một quy trình hai mươi trang bị bỏ xó. Điều quan trọng là cả đội biết nó tồn tại và dùng nó trong công việc hằng ngày.

Câu hỏi thường gặp về kinh nghiệm thực tế về luật

Năm kinh nghiệm này có thay thế được luật sư không?

Không. Chúng là lớp phòng ngừa cơ bản, giúp bạn tránh các lỗi phổ biến. Luật sư vẫn cần thiết cho các tình huống phức tạp, hợp đồng giá trị lớn hoặc khi đã có tranh chấp. Mục tiêu của checklist là giảm số lần phải gọi luật sư, chứ không loại bỏ hoàn toàn.

Doanh nghiệp công nghệ nhỏ 5–10 người có cần áp dụng đủ cả năm mục không?

Áp dụng đủ cả năm là tốt, nhưng nếu phải ưu tiên, hãy bắt đầu với kinh nghiệm 1 và 4. Đây là hai mục gây thiệt hại nhiều nhất theo ghi nhận của chúng tôi. Kinh nghiệm 3 và 5 có thể làm ở mức đơn giản trước. Kinh nghiệm 2 nên làm ngay nếu đội bạn có dùng công cụ AI để viết code.

Điều khoản về code do AI sinh ra nên ghi thế nào cho đúng?

Nên ghi rõ ba điểm: ai sở hữu code do AI sinh ra trong phạm vi công việc, nghĩa vụ khai báo khi dùng công cụ AI cho phần code lõi, và mức miễn trừ trách nhiệm liên quan tới tính nguyên bản. Cả ba điểm này nên được thương lượng từ đầu, ghi vào hợp đồng chứ không chỉ trao đổi miệng. Nếu