Trục 1: Nền tảng
Git-native Compliance
Luận điểm cốt lõi của GCBoK:
Git-native Compliance có nghĩa là tất cả các artefact tuân thủ, quyết định, danh tính và bằng chứng chủ yếu sống trong các kho Git - được quản lý phiên bản, ký GPG, đọc được bằng máy qua OSCAL, có thể xác thực bằng OPA - mà không cần một kho tuân thủ thứ cấp.
Định vị trong phổ mô thức
| Mô thức | Lĩnh vực | Nguồn chân lý |
|---|---|---|
| Cloud-native | Hạ tầng | CNCF |
| GitOps | Triển khai | OpenGitOps Working Group |
| Git-native Compliance | Tuân thủ | GCBoK |
Ba trụ cột của Git-native Compliance
1. Neo giữ bằng mật mã - Mỗi mục trong kho Git được bảo vệ bằng một hash, tùy chọn có chữ ký GPG. Qua đó có thể chứng minh: Ai, Cái gì, Khi nào. Điều này đáp ứng các yêu cầu GoBD về tính bất biến - nhưng một cách native nhờ kiến trúc Git.
2. Khả năng đọc bằng máy - OSCAL (Open Security Controls Assessment Language) cho các kiểm soát bảo mật và kết quả đánh giá. OPA/Rego (Open Policy Agent) cho các quy tắc tuân thủ dưới dạng mã, được kiểm tra tự động đối với trạng thái Git.
3. Tính tất định nhờ V7GUID - Mỗi đối tượng tuân thủ có thể được định địa chỉ duy nhất toàn cầu (UUIDv7), sắp xếp theo thời gian (dấu thời gian 48 bit), phân loại (mã định danh lớp 14 bit) và có thể móc nối trong chuỗi bằng chứng.
Phân định: hồ sơ tuân thủ và các định hướng riêng tư
Git-native Compliance có phạm vi được chủ ý thắt chặt: Trong các kho Git của một doanh nghiệp có các artefact liên quan đến tuân thủ - bằng chứng, quyết định, chứng cứ và bộ quy tắc cần cho việc kiểm tra và khả năng truy vết. Những gì không liên quan đến tuân thủ không thuộc về hồ sơ này.
Điều này đặc biệt không bao gồm việc tập hợp các định hướng cá nhân của người cấp phê duyệt (sau đây gọi là „HITL" - Human In The Loop): các đánh giá, ý kiến, trọng số và tiêu chí cân nhắc riêng tư của họ. Những tập hợp như vậy là thông tin riêng tư được bảo vệ và do đó không được quản lý phiên bản - thường là cục bộ trong một thư mục bị loại trừ qua .gitignore thuộc ngữ cảnh làm việc riêng (mẫu: projections/) - và không được đưa vào tài liệu tuân thủ.
Đồng thời chúng không phải là vô nghĩa: Chính từ chúng mới hình thành các mẫu ADR, tài liệu quyết định và các dữ kiện khác, những thứ sau đó - và chỉ khi đó - mới liên quan đến tuân thủ và thuộc về các kho. Điều được ghi lại là kết quả, không phải đánh giá.
Câu ghi nhớ cho agent: Các định hướng riêng tư của HITL phải được tôn trọng - chúng định hình kỳ vọng, giọng điệu, ranh giới và ưu tiên. Chúng không được ghi lại và không được trích dẫn, dù trong văn bản liền mạch hay trong tài liệu quyết định, bằng chứng hoặc báo cáo - trừ khi HITL cho phép rõ ràng việc ghi lại.
Bổ sung: Trục 5 (Cách thức thực hiện), mục „Các định hướng riêng tư của HITL - quy ước và quy tắc cho agent", và Trục 7 (Quản trị), mục „Từ đánh giá riêng tư đến kết quả có thể chứng minh".
Tự tham chiếu mà không bị Vendor Lock-In
Git-native Compliance tự tham chiếu: Tất cả các phần tử GitCover -
nguồn, tham chiếu, biện pháp, tài liệu - được định địa chỉ và quản lý chỉ thông qua
các kho Git. Chân lý nằm trong chính .git
(commit, tree, hash), không nằm trong các dịch vụ, wiki hay ticket bên ngoài.
Điều này tránh Vendor Lock-In: Mỗi kho tự thân
có thể kiểm toán được, có thể chuyển đi và không có phụ thuộc độc quyền.
Tiêu chuẩn hash: luôn SHA-256, không bao giờ SHA-1
Mỗi kho GitCover được tạo với SHA-256 làm hàm hash đối tượng
(git init --object-format=sha256 hoặc
extensions.objectformat = sha256). SHA-1 bị cấm rõ ràng
(tấn công va chạm). Việc neo giữ bằng mật mã (trụ cột 1) do đó
dựa trên một tiêu chuẩn hash an toàn đã được chứng minh.
Vị trí của các công cụ GitCover
Tất cả công cụ, dịch vụ GitCover và (trong tương lai) máy chủ MCP được
đặt theo kế hoạch dưới /opt/GitCover/ (ví dụ:
WebStaticBuilder-CLI dưới /opt/GitCover/webstatic). Điều này tránh
các vị trí lưu trữ toàn hệ thống, không được quản lý phiên bản. Sau khi onboarding,
/opt/GitCover tự trở thành một kho Git, ghi lại có phiên bản
các tham số môi trường tuân thủ GoBD (BASE_URL, CDN, đường dẫn, phiên bản công cụ).
Tuân thủ như hạ tầng
GitCover không phải công cụ dành cho những người đam mê tuân thủ. Nó là hạ tầng cho tất cả những ai muốn hoàn thành việc tuân thủ. Điều đó có nghĩa là:
- Chi phí thấp nhất có thể - Open Source, không giấy phép độc quyền
- An toàn tối đa - được neo bằng mật mã, không phải bằng các lớp phần mềm
- Khả năng chứng minh đầy đủ - lịch sử Git như audit trail tích hợp
Mô hình kiến trúc: ứng dụng chuyên ngành dọc và xương sống tuân thủ ngang
Beleg-Ketten"| GitCover Zeit <-->|"Policy-Validierung"| GitCover Lohn <-->|"SV/AO/GoBD-Nachweise"| GitCover Mails <-->|"E-Mail-Archivierung"| GitCover OPos <-->|"XML-Daten, Audit-Trails"| GitCover subgraph KISchicht["KI-Agenten-Ebene"] Agent["KI-Compliance-Agent
(eingesperrt im Worktree)"]:::agentBar end Agent -->|"liest/schreibt
nur im zugewiesenen Repo"| GitCover Agent -.->|"OPA-Guardrails
als Pre-Receive-Hooks"| GitCover classDef coverBar fill:#6B7280,color:#FFFFFF,stroke:#4B5563,stroke-width:2px,rx:6,ry:6,min-width:100%,font-size:1.1em,padding:6px,margin:6px; classDef agentBar fill:#0A7F5C,color:#FFFFFF,stroke:#0A7F5C,stroke-width:2px,rx:6,ry:6,font-size:1em,padding:4px,margin:4px;
Cách đọc: Các ứng dụng chuyên ngành dọc (FiBu, chấm công, tính lương, ERP, kho) vẫn độc lập về nội dung và tự chủ về chuyên môn. GitCover tạo thành lớp ngang: các kho Git như xương sống tuân thủ xuyên suốt, kết nối mọi ứng dụng dọc với danh mục OSCAL, policy OPA, chữ ký GPG và chuỗi bằng chứng V7GUID - không có middleware độc quyền và không có kho tuân thủ thứ cấp.
Khung pháp lý
GCBoK đề cập đến các khung quy định sau:
GoBD - Nguyên tắc về hệ thống kế toán dựa trên xử lý dữ liệu điện tử hợp quy
GoBD (Rz. 151-157) yêu cầu một hệ thống kiểm soát nội bộ, khả năng truy vết, tính bất biến và tính đúng thời điểm. Git-native Compliance đáp ứng các yêu cầu này một cách native:
| Yêu cầu GoBD | Đáp ứng Git-native |
|---|---|
| Khả năng truy vết | Lịch sử Git (commit-log) |
| Tính bất biến | Hash Git + chữ ký SSH-/GPG |
| Tính đúng thời điểm | Dấu thời gian V7GUID (UUIDv7) |
| Hệ thống kiểm soát nội bộ | Policy OPA như pre-receive hook |
NIS2 - Network and Information Security Directive
Chỉ thị NIS2 của EU yêu cầu quản lý rủi ro và nghĩa vụ báo cáo đối với hạ tầng trọng yếu. GCBoK định nghĩa các phương pháp phân tích rủi ro NIS2 dựa trên các kho Git.
AI Act - Quy định (EU) 2024/1689
Quy định về AI (AI Act) điều chỉnh các hệ thống AI theo mức rủi ro (bị cấm / rủi ro cao / hạn chế / tối thiểu) và đối với hệ thống rủi ro cao yêu cầu, trong số những điều khác, dữ liệu huấn luyện được ghi lại, bằng chứng về vòng đời mô hình, giám sát của con người và tài liệu sự cố. Định vị git-native: GCBoK không cung cấp hệ thống AI nào và cũng không chứng nhận chúng — nó làm cho bằng chứng (nguồn gốc dữ liệu huấn luyện, phiên bản mô hình/prompt, phê duyệt, sự cố) có thể tái tạo dưới dạng artefact Git. Do đó, Git-native Compliance là một hạ tầng bằng chứng cho các nghĩa vụ AI Act, không phải giả định về sự phù hợp cho chính hệ thống AI.
Cyber Resilience Act (CRA) - Quy định (EU) 2024/2847
CRA buộc nhà sản xuất sản phẩm có yếu tố số phải bảo mật theo thiết kế, quản lý lỗ hổng và nghĩa vụ báo cáo (thời hạn báo cáo từ mùa thu 2026, yêu cầu sản phẩm từ cuối 2027). Định vị git-native: Các kho Git thuần túy và tiện ích OSS thông thường không phải là „sản phẩm có yếu tố số" theo nghĩa CRA; một sản phẩm được kết nối mạng (ví dụ: phân phối dựa trên máy chủ) có thể bị ảnh hưởng. Git-native Compliance hỗ trợ bằng chứng CRA (SBOM, lịch sử lỗ hổng/bản vá, tài liệu phù hợp), nhưng không thay thế dấu CE.
Data Act - Quy định (EU) 2023/2854
Data Act thiết lập nghĩa vụ cung cấp dữ liệu và khả năng chuyển đổi đối với sản phẩm được kết nối mạng và dịch vụ đi kèm (nghĩa vụ sản phẩm từ ngày 12.09.2026, trong số những điều khác) cũng như các quy định về chuyển đổi đám mây. Định vị git-native: Các kho Git có thể chuyển đổi theo thiết kế (clone/mirror/export) — Git-native Compliance hỗ trợ mức độ sẵn sàng cho Data Act (xuất sang định dạng mở: JSON, CSV, OSCAL), nhưng không tạo ra sự phù hợp Data Act toàn diện cho toàn hệ thống.
eIDAS 2.0 - Quy định (EU) 2024/1183
eIDAS 2.0 tạo ra European Digital Identity Wallet và mở rộng các dịch vụ tin cậy đủ điều kiện. Định vị git-native: GitCover kết nối với chữ ký ví/tin cậy (signature container, GCSIG, Facsimile), không thay thế chúng; FES/QES vẫn là các dịch vụ tin cậy do bên ngoài cung cấp.
DSGVO/GDPR - Quy định (EU) 2016/679
DSGVO yêu cầu Privacy by Design. GCBoK định nghĩa các bằng chứng danh tính phi tập trung (kể cả danh tính PGP), neo dữ liệu cá nhân không phải trong cơ sở dữ liệu trung tâm mà trong các cấu trúc Git; PII được giữ trong các kho riêng (không phải trong Git) (trách nhiệm hai cấp, xem Trục 4).
Phân định: hạ tầng bằng chứng so với sự phù hợp sản phẩm
Làm rõ trọng tâm (kinh điển): GCBoK là một hệ thống quy tắc tri thức và bằng chứng mang tính quy phạm. Các văn bản pháp luật EU được nêu (AI Act, CRA, Data Act, eIDAS 2.0, DSGVO) là các khung mà Git-native Compliance cung cấp bằng chứng cho. GitCover không phải nhà sản xuất của một hệ thống AI/sản phẩm/tin cậy được quản lý và không đưa ra tuyên bố phù hợp nào của bên thứ ba. Trách nhiệm về sự phù hợp pháp lý của hệ thống được triển khai vẫn thuộc về đơn vị vận hành (xem GoBD Rn. 21; ma trận trách nhiệm trong gitcover.de/rechtliches).
BSI GS++ & GCBoK Compliance-as-Code
BSI IT-Grundschutz-Kompendium định nghĩa các tiêu chuẩn về an toàn thông tin và ngày càng cung cấp chúng ở các định dạng đọc được bằng máy (như OSCAL). GCBoK sử dụng các danh mục OSCAL được chuẩn hóa này và ánh xạ các kiểm soát BSI trực tiếp vào các quy trình tuân thủ tự động, Git-native (Compliance-as-Code). Nó chuyển các yêu cầu quy định của BSI thành các quy trình kiểm tra có thể vận hành trong hệ sinh thái GitCover.
Hiểu biết về ứng dụng
Các nguyên tắc kiến trúc của GCBoK phải dễ nắm bắt đối với người dùng có ít kiến thức IT. Phần này truyền đạt các mô hình tinh thần giúp việc làm việc với Git-native Compliance trở nên dễ hiểu đối với người mới.
Files over Apps - Nguyên tắc chủ đạo
GCBoK tuân theo nguyên tắc chủ đạo Files over Apps: Các artefact tuân thủ sống dưới dạng tệp trong các kho Git, không phải trong cơ sở dữ liệu ứng dụng độc quyền. Hội thoại, tài liệu, bằng chứng và policy là các tệp Markdown, YAML hoặc JSON trong Git tree - được quản lý phiên bản, có thể ký, có thể kiểm toán. Ứng dụng có thể thay thế; tệp tồn tại lâu dài.
Các artefact GitCover mang một họ phần mở rộng đóng: .gc.md (sidecar tổng quát và artefact Markdown được chuẩn hóa), .gcpn.md (vùng chứa quy trình), .gcsig.md (artefact chữ ký), .gcadr.md (quyết định kiến trúc) cũng như .gc.json/.gc.xml (artefact dữ liệu). V7GUID vẫn là danh tính dưới dạng v7guid trong nội dung; tên tệp không mang nó. Việc khám phá diễn ra qua registry đóng cộng với metadata bắt buộc, không qua một glob rộng.
Điều này khác biệt căn bản với mô thức ứng dụng cổ điển, trong đó phần mềm giữ dữ liệu trong cơ sở dữ liệu riêng và việc xuất dữ liệu là nhu cầu về sau. Với Git-native Compliance, xuất dữ liệu là trạng thái bình thường.
Thư mục hồ sơ số - Mô hình tinh thần
Đối với người dùng có ít kiến thức máy tính, khái niệm về toàn bộ hệ thống tệp là trừu tượng và dễ sai sót. Ẩn dụ về thư mục hồ sơ số giải quyết vấn đề này:
- Git-Working-Directory không phải một thư mục PC lộn xộn, mà là một thư mục hồ sơ số với máy photocopy và sổ nhật ký tích hợp (Git).
- Quy tắc: Một agent AI chỉ được đọc và ghi trong thư mục cụ thể này. Mọi thứ bên ngoài không tồn tại đối với nó.
- Khả năng hiển thị: Mọi thay đổi mà AI thực hiện ngay lập tức được đánh dấu là thay đổi (Git-Status). Người không chuyên thấy: „AI đã thay đổi dòng 4 trong tài liệu quy trình."
- An toàn: Git staging area trở thành cửa sổ xem trước và phê duyệt. Người dùng không cần hiểu Git - họ hiểu nguyên tắc: „AI đề xuất một thay đổi, tôi nhấp vào Tiếp nhận (Commit)."
Nguyên tắc hộp cát
Đối với sự phù hợp GoBD và NIS2, việc giới hạn phạm vi truy cập là nền tảng. Một agent AI chỉ có thể truy cập vào Git-Working-Directory được giao là bị giam hãm về mặt vật lý:
- Ngay cả khi agent bị ảo giác hoặc bị thao túng qua prompt injection, nó không thể thoát ra khỏi kho Git.
- Giải thích cho người dùng: „AI bị giam trong thư mục dự án này. Nó không thể gây hại cho phần còn lại của hệ thống."
- Mọi hoạt động tuân thủ được ghi lại trong lịch sử Git như một lưới an toàn - người dùng giữ toàn quyền tự chủ.
So sánh các môi trường làm việc AI
GCBoK trung lập về công nghệ đối với môi trường làm việc AI. Ba mô thức có thể lựa chọn:
| Tiêu chí | WebUI-first (Trình duyệt) | Desktop-Client (Ứng dụng native) | Nền tảng tất cả trong một |
|---|---|---|---|
| Mô thức | Proxy cấp OS, truy cập hệ thống tệp qua trình duyệt | Client-first, điều phối agent cục bộ/SSH | Không gian làm việc đầy đủ (chat, mail, tài liệu, lịch) |
| Trọng tâm | Quản lý tệp, Git staging, terminal qua trình duyệt | Hệ sinh thái agent, cửa hàng kỹ năng, đa agent | Trung tâm năng suất, thay thế SaaS cục bộ/riêng tư |
| Sandbox | Docker bind mount, cô lập Git worktree | API gating, giới hạn token, quyền cục bộ | Docker container, được đóng gói |
| Ưu điểm | Tích hợp Git liền mạch, Files over Apps | Hiệu năng cao, tích hợp công cụ chặt chẽ | Mạnh mẽ, mọi tác vụ văn phòng trong một giao diện |
| Nhược điểm | Mô hình bảo mật đòi hỏi cấu hình mount cẩn thận | Cấu hình đòi hỏi hiểu biết kỹ thuật | Hạ tầng Docker, dữ liệu bị ràng buộc trong DB riêng |
| Mức phù hợp GCBoK | Rất cao - triết lý chính xác „Files over Apps" | Trung bình - rào cản cấu hình với người không chuyên | Thấp - dữ liệu không được lưu theo kiểu Git-native |
Khuyến nghị: Mô hình appliance lai
Đối với người dùng doanh nghiệp vừa và nhỏ không có kiến thức IT sâu, GCBoK khuyến nghị một mô hình appliance lai:
- Đóng gói hạ tầng (tập trung): Một máy chủ AI headless trong LAN đảm nhận suy luận LLM và quản lý Git. Toàn bộ độ phức tạp được chuyển đến đó.
- Máy trạm client tối giản: Người dùng cuối không bị bắt dùng Docker cục bộ, Python hay Git trên máy tính của mình. Họ chỉ truy cập giao diện web qua trình duyệt (dưới dạng PWA).
- Luồng tương tác: Người dùng sử dụng các chức năng chat và ghi chú. Khi muốn kiểm tra hoặc tạo tài liệu tuân thủ, agent AI làm việc ở chế độ nền trực tiếp trên các thư mục của file server trung tâm. Agent đảm nhận staging, commit và push vào kho Gitea - người dùng thấy một checklist trực quan trong UI.
Mục tiêu: Người dùng không trải nghiệm „AI điều khiển máy tính", mà là một nhân viên xử lý thông minh cho thư mục tuân thủ cụ thể. Họ biết AI làm việc ở đâu, thấy mọi bước trong lịch sử Git và giữ toàn quyền tự chủ mà GCBoK yêu cầu.
Kiến trúc tham chiếu: Mô hình appliance lai
kein Docker, kein Git lokal"]:::clientBar end subgraph KIServer["KI-Server im LAN (headless)"] OWUI["Web-Oberfläche
(Chat + Notizen)"]:::serverBar Agent["KI-Agent
(im Git-Worktree eingesperrt)"]:::agentBar Ollama["LLM-Inferenz
(Ollama, lokal)"]:::serverBar end subgraph FileServer["File-Server / Git-Host"] Gitea["Gitea
(Git-Repositories + IdP)"]:::storageBar Repos["Git-Working-Directories
pro Mandant isoliert"]:::storageBar end Browser -->|"HTTPS"| OWUI OWUI --> Agent Agent -->|"liest/schreibt
nur im zugewiesenen Worktree"| Repos Agent -->|"LLM-Anfrage"| Ollama Agent -->|"Commit + Push"| Gitea Gitea --- Repos classDef clientBar fill:#2563EB,color:#FFFFFF,stroke:#1D4ED8,stroke-width:2px,rx:6,ry:6,font-size:1em,padding:4px; classDef serverBar fill:#6B7280,color:#FFFFFF,stroke:#4B5563,stroke-width:2px,rx:6,ry:6,font-size:1em,padding:4px; classDef agentBar fill:#0A7F5C,color:#FFFFFF,stroke:#0A7F5C,stroke-width:2px,rx:6,ry:6,font-size:1em,padding:4px; classDef storageBar fill:#92400E,color:#FFFFFF,stroke:#78350F,stroke-width:2px,rx:6,ry:6,font-size:1em,padding:4px;
Xem thêm: Việc triển khai thực tế các khung này được mô tả trong Trục 5: Cách thức thực hiện.