Cấp K7: Vận hành bộ quy tắc và xử lý khi quy định thay đổi

Cách đọc các nhãn nhỏ trong bài: Có nguồn điều được nêu trong tài liệu gốc; Đề xuất ý kiến hoặc thiết kế của SIPTech; Minh họa ví dụ giả định. Gặp từ lạ? Rê chuột lên từ có gạch chấm, hoặc mở Từ điển thuật ngữ.

1. Bài này dành cho ai và bạn sẽ làm được gì

Bài này dành cho ai: người chịu trách nhiệm hệ thống kiểm (kế toán trưởng, người biết code nhẹ) và chủ doanh nghiệp. Phần lớn bài làm được bằng bảng tính Excel, chỉ một phần nhỏ cần nhờ người biết code.

Bạn cần chuẩn bị: bài này tiếp nối các cấp trước, nên bạn nên có sẵn những thứ mà nội dung bài nhắc tới:

• Sổ quy tắc của hệ thống kiểm (mỗi quy tắc một dòng).
• Bộ cài lỗi (bộ hồ sơ có lỗi cố ý để thử hệ thống, từ cấp K6, xem K6.1) và chỗ ghi ý kiến không đồng ý của người duyệt (xem K2.5).
• Các văn bản pháp luật và quy chế nội bộ mà quy tắc dựa vào (ví dụ thuế, lao động, dữ liệu cá nhân).

Sau bài này bạn sẽ có:

1. Sổ quy tắc có phiên bản và ngày hiệu lực cho từng quy tắc; mỗi hồ sơ biết đã kiểm bằng phiên bản nào.
2. Cổng phát hành: bản sửa chỉ được dùng khi không nhóm hồ sơ nào xấu đi và mọi ca đã sửa trước đây vẫn đúng.
3. Kho ca đã sửa: mỗi lần người duyệt không đồng ý với hệ thống thành một ca kiểm thử.
4. Quy trình khi văn bản pháp luật hoặc quy chế nội bộ đổi.

Thứ bạn cầm đi được sau bài: so quy tac có cột phiên bản và hiệu lực; file kho_ca_da_sua.csv; cong.py (đoạn chương trình ngắn làm "cổng phát hành"); file nhat_ky_thay_doi_quy_dinh.md.

2. Vấn đề bài này giải quyết

"Quy định đổi, nhà cung cấp đổi mẫu hóa đơn, mô hình AI đổi. Làm sao sửa hệ thống mà không làm hỏng cái đang chạy, và sáu tháng sau vẫn giải thích được vì sao một hồ sơ đã được duyệt?"

Các cấp trước giúp hệ thống chạy được. Cấp này lo chuyện khó hơn: giữ cho nó chạy đúng theo thời gian.

Ví dụ thật: theo các nguồn thứ cấp (tức là các trang tóm tắt, không phải văn bản gốc), NĐ 254/2026/NĐ-CP có hiệu lực từ 01/7/2026, thay NĐ 123/2020/NĐ-CP và NĐ 70/2025/NĐ-CP; TT 91/2026/TT-BTC thay TT 32/2025/TT-BTC; có thay đổi về thời điểm lập hóa đơn, nội dung hóa đơn với người mua là người tiêu dùng, trường hợp không phải lập hóa đơn Nguồn V1 đọc qua tóm tắt. Một bộ quy tắc viết năm 2025 có thể sai từ tháng 7/2026 mà không ai biết.

3. Kiến thức nền

3.1 Bài học từ ESCROW (BMO) cho việc sửa bộ quy tắc

ESCROW là tên một nghiên cứu (của BMO) về cách sửa dần bộ quy tắc cho hệ thống AI. Dưới đây là những điều đáng học từ nghiên cứu này.

• Chỉ sửa chỉ dẫn, không đụng vào mô hình. Mô hình giữ nguyên; chỉ sửa "skill" (bộ chỉ dẫn viết bằng ngôn ngữ thường). LLM (mô hình ngôn ngữ lớn, tức AI biết đọc và viết văn bản) đề xuất bản sửa; chỉ bản đã được chấm trên ca thật mới được triển khai; mỗi thay đổi là một bản khác biệt (diff, tức bản so sánh cho thấy chỗ nào thêm, bỏ, sửa) đọc được, có phiên bản Nguồn B1.
• Cổng không thoái lui theo nhóm. Bản sửa phải giữ mức của từng nhóm ca (trong cấu hình mặc định, dung sai 5% tương đối mỗi nhóm), vì tổng có thể tăng trong khi một nhóm giảm Nguồn B1 mục 1 và bảng 3. "Dung sai" là mức tụt tối đa mà cổng còn chấp nhận.
• Chống lặp lại lỗi cũ. Các ca đã sửa được giữ trong một kho; mỗi bản sửa mới phải chạy lại trên kho này. Không có kho, điểm trên ca cũ tụt từ 0,857 xuống 0,7 qua 4 vòng; có kho, giữ khoảng 0,84 Nguồn: bài khác mục 1.4.
• Nguồn ý kiến. Ghi chú của người duyệt, phân tích log (nhật ký ghi lại mỗi lần hệ thống chạy), và khác biệt khi chính sách cập nhật; mỗi ý kiến được chuyển thành một ca có cấu trúc gồm mô tả lỗi và đầu ra đúng Nguồn B1 phụ lục E.
• Chi phí. Chấm lại toàn bộ ca là phần tốn nhất, nên vòng lặp chỉ xử lý được vài trăm ca Nguồn B1 hạn chế. Đề xuất Với SME, đây là lý do giữ đa số quy tắc bằng code: chạy lại hàng trăm ca bằng code mất vài giây và không tốn tiền.

3.2 Trích quy tắc một lần, dùng đến khi chính sách đổi

• Ca Erste: bộ quy tắc trích từ chính sách được dùng lại cho mọi hồ sơ cho đến khi hướng dẫn cập nhật phiên bản mới; chuyên gia xem và sửa được bộ quy tắc trước khi dùng Nguồn B5.

3.3 Ghi đủ cấu hình để tái hiện

• B6: cùng tên mô hình có thể cho kết quả khác qua hai đường gọi khác nhau; kết quả có thể đổi giữa các ngày dưới cùng tên mô hình; bản ghi chỉ ghi tên mô hình thì không xác định được cái gì đã được kiểm định Nguồn B6. Đổi loại GPU (card đồ họa dùng để chạy mô hình) cũng làm 34/776 nhãn thay đổi trong hệ thống tự chạy của họ Nguồn B6.
• Đề xuất SME không cần tái hiện từng byte (tức giống hệt đến từng ký tự). Cần: lưu đầu ra đã dùng để kết luận (K3.4); ghi tên mô hình, đường gọi (API trực tiếp hay qua nền tảng nào; API là cổng để chương trình của bạn gọi dịch vụ AI), phiên bản prompt (câu lệnh đưa cho AI), phiên bản sổ quy tắc, ngày. Khi nhà cung cấp ngừng mô hình, chạy lại bộ cài lỗi trên mô hình mới trước khi chuyển (theo Tra cứu tài liệu nội bộ · Cấp 9 — Vận hành cho SME › Bài 9.4: Xử lý trôi dạt, khi tài liệu đổi và khi mô…).

4. Các bài thực hành

Năm bài dưới đây làm theo thứ tự. Mỗi bài có: việc cần làm, thứ bạn có sau bài, và (nếu có) lỗi hay gặp để tránh.

Bài K7.1: Ngày hiệu lực cho từng quy tắc

• Việc cần làm: thêm vào sổ quy tắc bốn cột: phien_ban, hieu_luc_tu, hieu_luc_den, can_cu (số văn bản, điều, khoản). Bộ chạy chọn quy tắc theo ngày của chứng từ (ngày lập hóa đơn, ngày ký hợp đồng), không theo ngày chạy. Nói cách khác, hồ sơ lập năm ngoái vẫn phải kiểm theo quy tắc của năm ngoái, dù hôm nay bạn mới chạy kiểm.
• Lưu ý: với hóa đơn lập trước 01/7/2026 nhưng điều chỉnh, thay thế sau ngày này, một nguồn thứ cấp cho biết việc điều chỉnh, thay thế làm theo NĐ 254 và TT 91 Nguồn V2 thứ cấp. Quy tắc "ngày nào áp quy định nào" phải do người có chuyên môn viết sau khi đọc văn bản gốc.
• Bạn có sau bài: sổ quy tắc có cột hiệu lực; báo cáo mỗi hồ sơ ghi phien_ban_so_quy_tac.
• Lỗi hay gặp: sửa thẳng quy tắc cũ (mất khả năng giải thích hồ sơ đã kiểm trước đó).

Bài K7.2: Kho ca đã sửa từ ý kiến người duyệt

• Việc cần làm: 1. Mỗi lần người duyệt không đồng ý (K2.5), ghi lại năm thứ: mã hồ sơ, mã quy tắc, hệ thống nói gì, đúng phải là gì, lý do. 2. Hằng tuần, người vận hành chuyển các dòng này thành ca trong bộ cài lỗi (K6.1). 3. Gắn nhãn nhóm cho mỗi ca (ví dụ: hoa_don, ba_ben, hop_dong, ho_so_ns).
• Bạn có sau bài: kho_ca_da_sua.csv (CSV là kiểu file bảng đơn giản, mở được bằng Excel); ca đã vào kho không xóa.

Bài K7.3: Cổng phát hành theo nhóm

• Việc cần làm: trước mỗi lần đổi sổ quy tắc, đổi prompt hoặc đổi mô hình, chạy "cổng" này để quyết định có cho dùng bản mới hay không.

Đoạn mã dưới đây làm gì? Nó so kết quả của bản cũ và bản mới trên cùng bộ ca. Với từng nhóm ca (hóa đơn, hợp đồng...), nó kiểm tra tỷ lệ đúng của bản mới có tụt so với bản cũ không. Nó cũng kiểm tra những ca nằm trong kho ca đã sửa có còn đúng không. Nếu một nhóm tụt hoặc một ca đã sửa bị hỏng lại, cổng trả TU_CHOI kèm lý do; nếu không, trả NHAN. Bạn không cần đọc hiểu từng dòng; chỉ cần biết ý nghĩa của nó, và nhờ một người biết lập trình (hoặc nhờ AI) chạy giúp.

Mã mẫu (đã chạy thử 2026-11-11, python -I -X utf8, dữ liệu giả):

def cong(cu, moi, kho_ca_da_sua, dung_sai=0.0):
    """cu/moi: {ma_ca: (nhom, dung_bool)}; kho_ca_da_sua: tap ma_ca phai luon dung."""
    ly_do = []
    for n in sorted({g for g, _ in cu.values()}):
        a = [d for k, (g, d) in cu.items() if g == n]
        b = [moi[k][1] for k, (g, _) in cu.items() if g == n]
        ra, rb = sum(a)/len(a), sum(b)/len(b)
        if rb < ra - dung_sai: ly_do.append(f"nhom {n} tut {ra:.0%} -> {rb:.0%}")
    hong = [k for k in kho_ca_da_sua if not moi[k][1]]
    if hong: ly_do.append(f"ca da sua bi hong lai: {hong}")
    return ("NHAN", []) if not ly_do else ("TU_CHOI", ly_do)

Kết quả thử: có hai bản sửa.

• Bản sửa thứ nhất làm đúng thêm một ca hợp đồng, không làm sai ca nào. Cổng trả NHAN.
• Bản sửa thứ hai cũng làm đúng thêm ca hợp đồng nhưng làm sai một ca hóa đơn. Tổng vẫn 75% như cũ, nhưng cổng trả TU_CHOI với lý do nhom hoa_don tut 100% -> 50% và ca da sua bi hong lai: ['c2'].

• Đề xuất Dung sai mặc định 0 cho quy tắc mức "cao" (ESCROW dùng 5% tương đối, nhưng với vài chục ca của SME, một ca đã vượt 5%).
• Bạn có sau bài: cong.py chạy trước mỗi lần đổi sổ quy tắc, prompt, hoặc mô hình.

Bài K7.4: Quy trình khi quy định hoặc quy chế đổi

• Việc cần làm Đề xuất: 1. Một người được giao theo dõi văn bản (thuế, lao động, dữ liệu cá nhân) và quy chế nội bộ; mỗi tháng ghi "có gì mới". 2. Khi có văn bản mới: liệt kê quy tắc bị ảnh hưởng (tìm theo cột can_cu). 3. Viết phiên bản mới của quy tắc với hieu_luc_tu; giữ phiên bản cũ. 4. Thêm ca cài lỗi cho điểm mới (ví dụ quy tắc mới về nội dung hóa đơn). 5. Chạy cổng K7.3. Người có thẩm quyền ký phát hành.
• Có thể dùng LLM để đề xuất danh sách quy tắc bị ảnh hưởng từ bản so sánh văn bản cũ/mới (như bước trích quy tắc của Erste), nhưng người duyệt mọi thay đổi Đề xuất.
• Bạn có sau bài: nhat_ky_thay_doi_quy_dinh.md.

Bài K7.5: Lưu trữ và giải thích lại

• Việc cần làm: với mỗi hồ sơ đã kết luận, lưu các thứ sau: 1. Chứng từ gốc (hoặc đường dẫn kèm hash SHA-256, tức một "dấu vân tay" của file để biết file có bị sửa không; cách làm ở Tra cứu tài liệu nội bộ · Cấp 2 - Biến tài liệu thành text có cấu trúc › Bài 2.5 - Ghi nguồn cho mỗi đoạn). 2. JSON đã trích (JSON là cách viết dữ liệu có khung rõ ràng để máy đọc được). 3. Báo cáo. 4. Phiên bản sổ quy tắc. 5. Log lời gọi LLM. 6. Người duyệt và quyết định.
• Thử mỗi quý: chọn ngẫu nhiên 3 hồ sơ cũ, giải thích lại vì sao được duyệt chỉ từ dữ liệu đã lưu.
• Lưu ý: thời hạn lưu trữ chứng từ kế toán, hóa đơn theo pháp luật: chưa tra trong phiên này; hỏi kế toán trưởng hoặc tư vấn. Bài này không phải tư vấn pháp lý.
• Bạn có sau bài: một nếp lưu trữ đủ để giải thích lại từng hồ sơ cũ.

5. Hai cách làm: không cần code và có code (khi nào nên chuyển)

• Không code: sổ quy tắc là file Excel có cột phiên bản và hiệu lực, lưu mỗi phiên bản thành file riêng; bộ cài lỗi chạy tay khi đổi; nhật ký thay đổi là một tài liệu.
• Có code: sổ quy tắc trong Git (công cụ lưu lịch sử mọi lần sửa file); cham.py + cong.py chạy tự động khi có thay đổi.
• Buộc chuyển sang code khi Đề xuất: sổ quy tắc đổi hơn một lần mỗi quý; hoặc có quy tắc mờ dùng LLM (vì mô hình đổi mà không báo); hoặc hơn một người sửa sổ.

6. Tiêu chí "vận hành được" (đo được)

Đề xuất

1. Mọi quy tắc có phiên bản, hiệu lực, căn cứ; mọi báo cáo ghi phiên bản sổ quy tắc.
2. Kho ca đã sửa có ít nhất 20 ca sau 3 tháng (nếu ít hơn, hoặc hệ thống rất tốt, hoặc người duyệt không ghi ý kiến: kiểm bằng K6.5).
3. Mọi thay đổi trong 3 tháng đều qua cổng K7.3 và có người ký.
4. Đã xử lý ít nhất một thay đổi quy định theo K7.4 (NĐ 254/2026 là ứng viên ngay).
5. Thử giải thích lại 3 hồ sơ cũ thành công.

Khi nào dừng hoặc thu hẹp: lỗi lọt sau duyệt nhiều hơn làm tay; người duyệt không theo kịp hàng đợi trong 4 tuần liền; hoặc không ai theo dõi thay đổi quy định.

7. Ví dụ cho doanh nghiệp nhỏ ở Việt Nam

Minh họa

Ba tình huống giả định để bạn dễ hình dung:

a) Văn phòng dịch vụ kế toán (tiếp ví dụ cap-02). Tháng 7/2026: người theo dõi văn bản ghi NĐ 254/2026 và TT 91/2026 có hiệu lực. Danh sách quy tắc có can_cu chứa "NĐ 123" hoặc "NĐ 70": 4 quy tắc. Kế toán trưởng đọc văn bản gốc, viết phiên bản mới cho 2 quy tắc, giữ 2 quy tắc không đổi nhưng cập nhật căn cứ. Thêm 6 ca cài lỗi. Cổng K7.3 nhận. Hóa đơn lập trước 01/7 vẫn kiểm bằng phiên bản cũ.

b) Công ty thương mại dùng LLM cho quy tắc "mô tả hàng phù hợp". Nhà cung cấp API thông báo ngừng mô hình đang dùng. Người vận hành chạy bộ cài lỗi trên mô hình mới 3 lần (K6.3): nhóm hoa_don giữ nguyên, một ca trong kho ca đã sửa bị sai lại. Cổng từ chối. Sửa câu hỏi của quy tắc (thêm một ví dụ lỗi), chạy lại, cổng nhận, rồi mới chuyển.

c) Công ty xây dựng sửa quy chế tạm ứng. Hạn mức theo chức danh đổi từ 01/1. Chỉ sửa bảng hạn mức có cột hiệu lực; quy tắc TU-01 không đổi code. Hồ sơ tạm ứng tháng 12 vẫn kiểm theo hạn mức cũ.

8. Tài liệu tham khảo