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à:

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

flowchart TB subgraph HorizotalBackbone["Horizontaler GitCover® Compliance-Backbone"] GitCover["Git Repos/Features · TOP · PII · OSCAL · OPA · GPG · V7GUID · etc."]:::coverBar end subgraph VertikaleAnwendungen["Vertikale Fachanwendungen (Beispiele)"] direction TB FiBu["Finanzbuchhaltung"] Zeit["Zeiterfassung"] Lohn["Lohnabrechnung"] Mails["Geschäftskorrespondenz"] OPos["E-Rechnung Eingang/Ausgang"] end FiBu <-->|"Revisionssichere Ablage
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:

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ý:

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:

  1. Đó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 đó.
  2. 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).
  3. 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

flowchart TB subgraph Client["Client-Ebene (minimal)"] Browser["Browser / PWA
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.