Trong khoảng thời gian từ ngày 26 tháng 8 đến ngày 2 tháng 9 năm 2026, GitHub đã thay đổi một số cơ chế quản trị của Copilot: chính sách cung cấp mô hình trên toàn cầu, việc ngừng cung cấp một số mô hình được chọn, việc áp dụng các quy tắc loại trừ nội dung trong ứng dụng và CLI, cùng việc xác định mô hình mặc định ở cấp doanh nghiệp hoặc nhóm. Xét riêng lẻ, những thay đổi này giống như các thiết lập quản trị. Khi nhìn tổng thể, chúng cho thấy việc lựa chọn mô hình đang trở thành vấn đề về danh mục, dữ liệu và tính liên tục trong vận hành.
Điểm cần nhớ: chỉ cho phép “Copilot” là chưa đủ. Một tổ chức phải quyết định mô hình nào được cung cấp, cho những nhóm nào, trên loại dữ liệu nào, với những bảo đảm nào và đến thời điểm nào. Cần phân biệt các giá trị mặc định được kế thừa với những quyết định rõ ràng, và mỗi lần ngừng cung cấp mô hình phải kích hoạt các bài kiểm thử hồi quy.
1. Vì sao việc sử dụng nhiều mô hình làm thay đổi hoạt động quản trị
Ban đầu, một trợ lý lập trình được nhìn nhận như một sản phẩm tương đối đồng nhất: một giao diện, một nhà cung cấp và một chính sách trung tâm. Hiện nay, các nền tảng cung cấp nhiều mô hình, đôi khi đến từ các nhà phát hành khác nhau, với những đặc điểm riêng về chi phí, hiệu năng, giấy phép và xử lý dữ liệu.
Mô hình được sử dụng trong nhiều bối cảnh: hoàn thành mã cục bộ, hội thoại, chỉnh sửa nhiều tệp, tác nhân tự động, đánh giá mã hoặc CLI. Quyền phù hợp để viết một bài kiểm thử chưa chắc phù hợp với một tác nhân có thể khám phá kho mã, thực thi lệnh và đề xuất một pull request.
Sự đa dạng này đem lại tính linh hoạt. Một nhóm có thể dùng mô hình nhanh cho các tương tác thường ngày và mô hình tiên tiến hơn cho một cuộc di chuyển phức tạp. Tuy nhiên, nó cũng tạo ra các quyết định ngầm. Một mô hình mới có thể trở nên khả dụng vì kế thừa chính sách toàn cục; một mô hình được ưa chuộng có thể biến mất; một thiết lập bảo mật có thể được áp dụng trong IDE nhưng chưa được áp dụng trên một bề mặt khác.
Do đó, hoạt động quản trị phải bao quát tổ hợp mô hình + tính năng + dữ liệu + nhóm + phiên bản, thay vì chỉ dựa vào tên sản phẩm.
2. Tìm hiểu bốn trạng thái chính sách của GitHub
Ngày 26 tháng 8, GitHub thông báo chính sách toàn cục dành cho các mô hình Copilot đã được cung cấp rộng rãi, với quá trình triển khai từng bước đến ngày 1 tháng 9. Các mô hình được cung cấp rộng rãi nhưng chưa được cấu hình rõ ràng có thể tuân theo trạng thái của chính sách này.
Hoạt động quản trị phân biệt bốn tình huống: được bật rõ ràng, bị tắt rõ ràng, được ủy quyền cho một nhóm hoặc tổ chức, và được ủy quyền cho chính sách mặc định. Giá trị cuối cùng mang tính động: nếu chính sách toàn cục thay đổi, tất cả mô hình tuân theo chính sách đó cũng thay đổi theo.
Sự khác biệt này rất quan trọng đối với việc kiểm toán. Hai mô hình hiển thị là khả dụng có thể xuất phát từ những quyết định hoàn toàn khác nhau. Mô hình thứ nhất đã được đánh giá và bật; mô hình thứ hai xuất hiện do kế thừa. Vì vậy, cần ghi lại nguồn gốc của quyết định và không được xem trạng thái thực tế là bằng chứng cho việc phê duyệt.
GitHub nêu rõ rằng các lựa chọn rõ ràng được giữ nguyên. GitHub cũng cho biết các mô hình có trọng số mở và những mô hình không thuộc phạm vi thỏa thuận lưu giữ dữ liệu của mình sẽ bị tắt theo mặc định trong cơ chế này. Đây là điểm khởi đầu cho việc bảo vệ dữ liệu, chứ chưa phải chính sách hoàn chỉnh: tổ chức vẫn phải kiểm tra các điều kiện áp dụng, khu vực, tính năng và cam kết riêng với khách hàng.
Một thực hành tốt là tắt việc kích hoạt tự động trong các phạm vi nhạy cảm và yêu cầu quyết định rõ ràng cho từng mô hình mới. Trong những môi trường ít quan trọng hơn, có thể cho phép kế thừa cùng với việc rà soát tự động và thông báo cho chủ sở hữu.
3. Xử lý tính bảo mật ở cấp nội dung
Ngày 2 tháng 9, GitHub thông báo ứng dụng Copilot và Copilot CLI hiện đã tuân thủ các chính sách loại trừ nội dung được cấu hình ở cấp doanh nghiệp, tổ chức và kho mã đối với các gói Business và Enterprise. Các tệp bị loại trừ không được sử dụng làm ngữ cảnh trong những quy trình này.
Tính năng này giúp bảo vệ bí mật, mã chịu ràng buộc hợp đồng, dữ liệu độc quyền hoặc các thư mục mà trợ lý không được phép sử dụng. Tuy nhiên, nó không thay thế các biện pháp kiểm soát quyền truy cập. Nhà phát triển hoặc tác nhân có thể đọc một tệp vẫn có khả năng sao chép tệp đó sang một bề mặt khác, tự tóm tắt hoặc cung cấp tệp cho một công cụ bên ngoài.
Vì vậy, việc loại trừ phải nằm trong một chiến lược rộng hơn: phân loại kho mã, tách biệt bí mật, quy tắc DLP, quyền tối thiểu và ghi nhật ký. Việc này cũng phải được kiểm thử trên từng giao diện. Không được giả định rằng chính sách được công bố cho ứng dụng và CLI là giống nhau trên mọi tiện ích mở rộng, tích hợp hoặc API.
Hãy ghi lại ý nghĩa của “bị loại trừ”. Vấn đề không chỉ là nội dung có được đưa vào prompt hay không. Hãy kiểm tra các gợi ý, chỉ mục, bộ nhớ đệm, nhật ký, dấu vết đánh giá và các chức năng bộ nhớ nếu có. Hợp đồng và tài liệu của nhà cung cấp vẫn là nguồn thông tin chính xác.
Bài viết của chúng tôi về Zero Data Retention và Private Safety Processing trình bày chi tiết sự khác biệt giữa lưu giữ, huấn luyện, ghi nhật ký và các biện pháp kiểm soát bảo mật.
4. Chuẩn bị cho việc ngừng cung cấp như một cuộc di chuyển
Ngày 31 tháng 8, GitHub thông báo sẽ ngừng cung cấp một số mô hình kể từ ngày 1 tháng 9 trong phần lớn trải nghiệm Copilot. Danh sách này đáng chú ý có các phiên bản Gemini, Claude và Raptor Mini, kèm theo các lựa chọn thay thế được đề xuất.
Khoảng thời gian thông báo rất ngắn cho thấy không nên mã hóa cứng tên mô hình nếu không có chiến lược thay thế. Một nhóm sử dụng mô hình trong hướng dẫn, tự động hóa, đánh giá hoặc thiết lập doanh nghiệp có thể gặp gián đoạn hoặc thay đổi hành vi âm thầm.
Hãy xử lý mỗi lần ngừng cung cấp như một cuộc di chuyển ứng dụng. Kiểm kê các cách sử dụng, chọn ứng viên, chạy lại các bài đánh giá, đo lường chất lượng và kiểm tra chi phí. Prompt có thể phụ thuộc vào phong cách suy luận, cửa sổ ngữ cảnh hoặc định dạng đầu ra. Thay thế mô hình bằng “mô hình gần nhất” không bảo đảm sự tương đương.
Hãy thêm một lớp logic giữa trường hợp sử dụng và tên thương mại. Chẳng hạn, hồ sơ code-review-standard trỏ đến một mô hình đã được phê duyệt với cấu hình cụ thể. Việc thay đổi nhà cung cấp hoặc phiên bản được thực hiện trong sổ đăng ký mà không cần sửa đổi mọi quy trình.
Hãy theo dõi lịch trình, đồng thời chuẩn bị cho việc thay thế ngoài kế hoạch. Một mô hình có thể bị ngừng vì lý do bảo mật, giấy phép hoặc khả dụng. Mỗi trường hợp sử dụng quan trọng phải có phương án dự phòng đã được kiểm thử và một chế độ suy giảm rõ ràng.
5. Xác định mô hình theo nhóm mà không làm phân mảnh tổ chức
Ngày 2 tháng 9, GitHub thông báo khả năng xác định một mô hình mặc định trong các thiết lập do doanh nghiệp quản lý, với các giá trị khác nhau theo nhóm, cho ứng dụng Copilot, CLI và Visual Studio Code trên các gói Business và Enterprise.
Mức độ chi tiết này rất hữu ích. Một nhóm PHP có thể ưu tiên mô hình hoạt động hiệu quả trên các kho mã và tác vụ của mình; nhóm hỗ trợ có thể tìm kiếm tốc độ và chi phí; nhóm bảo mật có thể yêu cầu một mô hình và chính sách hạn chế hơn.
Rủi ro nằm ở sự phân mảnh. Nếu mỗi nhóm tự lựa chọn mà không có khuôn khổ, doanh nghiệp sẽ không còn biết mô hình nào xử lý dữ liệu của mình, số lượng đánh giá tăng lên và các sự cố trở nên khó tái hiện.
Hãy xác định một danh mục ngắn. Thông thường, hai hoặc ba hồ sơ đáp ứng phần lớn nhu cầu: tương tác nhanh, suy luận phức tạp và ngữ cảnh nhạy cảm. Các nhóm yêu cầu ngoại lệ khi chứng minh được nhu cầu có thể đo lường. Ngoại lệ phải có chủ sở hữu, ngày hết hạn và bộ đánh giá.
Mô hình mặc định không nhất thiết là mô hình duy nhất được phép. Nó là lựa chọn được khuyến nghị. Việc người dùng có thể thay thế mô hình này hay không phụ thuộc vào mức độ rủi ro. Với kho mã công khai, quyền tự do có thể rộng; với một sản phẩm chịu quản lý, mô hình và bề mặt có thể bị áp đặt.
6. Xây dựng sổ đăng ký mô hình và trường hợp sử dụng
Sổ đăng ký là nguồn thông tin chính xác. Với mỗi mô hình, hãy lưu nhà cung cấp, phiên bản, trạng thái trên GitHub, các bề mặt khả dụng, chính sách dữ liệu, khu vực, chi phí, ngày giới thiệu, ngày rà soát và chủ sở hữu nội bộ.
Sau đó liên kết các trường hợp sử dụng: hoàn thành mã, trò chuyện, tác nhân, CLI, đánh giá, tạo bài kiểm thử hoặc di chuyển. Bổ sung phân loại dữ liệu, mức độ tự chủ, các công cụ được phép truy cập, mô hình mặc định và mô hình dự phòng.
Một dòng trong sổ đăng ký có thể ghi: “đánh giá tự động các kho mã nội bộ không thuộc lĩnh vực quản lý đặc biệt; mô hình A; chỉ đưa ra gợi ý; loại trừ nội dung bí mật; bắt buộc phê duyệt của con người; đánh giá hàng tháng; dự phòng bằng mô hình B”.
Sổ đăng ký này phải được lập phiên bản. Một tệp có thể đọc bằng máy cho phép tạo các thiết lập được quản lý, bảng kiểm toán và cảnh báo ngừng cung cấp. Khi cần, các thay đổi phải đi qua một pull request được người phụ trách nền tảng, bảo mật và nghiệp vụ phê duyệt.
Tuy nhiên, đừng biến sổ đăng ký thành một danh mục lý thuyết. Mỗi mục đang hoạt động phải tương ứng với một cách sử dụng được quan sát. Các mô hình không được sử dụng làm tăng phạm vi quản trị mà không tạo ra giá trị.
7. Kiểm thử chất lượng, chi phí và rủi ro trước khi kích hoạt
Một điểm chuẩn chung là chưa đủ để lựa chọn mô hình phát triển. Hãy xây dựng bộ đánh giá từ các tác vụ thực tế đã ẩn danh: sửa lỗi có mục tiêu, hiểu một mô-đun, tạo bài kiểm thử, di chuyển, đánh giá bảo mật và tuân thủ quy ước.
Hãy đo tỷ lệ thành công, lỗi phát sinh, chất lượng giải thích, số lần gọi công cụ, chi phí và độ trễ. Kiểm tra hành vi khi gặp một chỉ dẫn có trong kho mã, một tệp bị loại trừ, một bí mật giả và một yêu cầu ngoài phạm vi.
Đối với các tác nhân, hãy bổ sung tiêu chí hành động: tác nhân có tôn trọng nhánh, các tệp được phép, lệnh và giới hạn hay không? Mô hình tốt nhất trong việc tạo mã chưa chắc là mô hình dễ kiểm soát nhất trong một quy trình tự động.
Hãy chạy lại bộ đánh giá sau mỗi phiên bản mới hoặc thay đổi về bề mặt. Một bản cập nhật GitHub có thể thay đổi cơ chế điều phối xung quanh mô hình, ngay cả khi mô hình vẫn giữ nguyên. Lưu lại kết quả và cấu hình để có thể giải thích sự thay đổi về chất lượng.
Việc kích hoạt được triển khai từng bước: nhóm thí điểm, các kho mã được chọn, theo dõi, rồi mở rộng. Các sự cố và phản hồi của người dùng được đưa vào sổ đăng ký và có thể dẫn đến việc quay lại mô hình trước đó.
8. Thiết lập chu kỳ quản trị hàng quý
Mỗi quý, hãy xem xét danh sách mô hình khả dụng, các quyết định được kế thừa, quy tắc loại trừ, cách sử dụng thực tế, chi phí và ngày ngừng cung cấp đã công bố. Tắt các mô hình không được sử dụng và chỉ gia hạn những ngoại lệ có lý do chính đáng.
Mỗi tháng, hãy theo dõi nhật ký thay đổi của nhà cung cấp và GitHub. Một thay đổi đáng kể phải kích hoạt phân tích mà không cần chờ đến kỳ rà soát hàng quý. Hệ thống tự động có thể mở một ticket khi tên trong sổ đăng ký xuất hiện trong thông báo ngừng cung cấp.
Trước mỗi lần kích hoạt, hãy yêu cầu một phiếu ngắn: nhu cầu, dữ liệu, bề mặt, đánh giá, chi phí, phương án dự phòng và chủ sở hữu. Sau khi kích hoạt, hãy kiểm tra các thiết lập thực tế có khớp với sổ đăng ký hay không. Khoảng cách giữa chính sách được khai báo và cấu hình thực tế là một chỉ báo cần ưu tiên.
Cuối cùng, hãy trao đổi với các nhà phát triển. Giải thích vì sao một số mô hình được cung cấp, cách báo cáo vấn đề và thông tin nào tuyệt đối không được cung cấp cho trợ lý. Một hoạt động quản trị dễ hiểu sẽ nhận được nhiều sự đồng thuận hơn một danh sách hạn chế thiếu bối cảnh.
Kết luận
Sự gia tăng số lượng mô hình trong GitHub Copilot mang lại khả năng thích ứng hữu ích, nhưng biến một thiết lập năng suất thành một hệ thống cần được quản trị. Chính sách toàn cục, loại trừ nội dung, giá trị theo nhóm và việc ngừng cung cấp phải được xử lý cùng nhau.
Một tổ chức vững chắc duy trì sổ đăng ký có phiên bản, làm rõ nguồn gốc các quyết định, đánh giá mô hình trên các tác vụ của mình, chuẩn bị phương án thay thế và kiểm tra biện pháp bảo vệ dữ liệu trên từng bề mặt. Partitech hỗ trợ thiết kế hoạt động quản trị này, tự động hóa các biện pháp kiểm soát và tích hợp Copilot vào một quy trình DevSecOps có thể đo lường.
Tài liệu tham khảo được xác minh ngày 3 tháng 9 năm 2026
- GitHub — “Global model policy generally available”, ngày 26 tháng 8 năm 2026: https://github.blog/changelog/2026-08-26-global-model-policy-generally-available/
- GitHub — “Selected GitHub Copilot models deprecated”, ngày 31 tháng 8 năm 2026: https://github.blog/changelog/2026-08-31-selected-github-copilot-models-deprecated/
- GitHub — “Content exclusions generally available in Copilot app and CLI”, ngày 2 tháng 9 năm 2026: https://github.blog/changelog/2026-09-02-content-exclusions-generally-available-in-copilot-app-and-cli/
- GitHub — “Enterprise-managed settings support any default model”, ngày 2 tháng 9 năm 2026: https://github.blog/changelog/2026-09-02-enterprise-managed-settings-support-any-default-model/